KillrChat presentation
2 likes875 views
This document summarizes a presentation about the KillrChat messaging application. KillrChat is a scalable messaging app built using AngularJS, Spring, and Cassandra. It demonstrates de-normalization and provides an exercise for attendees to work with user and chat room management, as well as chat messages. The document outlines the architecture, data models, and solutions for handling concurrent requests to avoid inconsistencies through the use of lightweight transactions in Cassandra.
KillrChat presentation
- 1. @doanduyhai KillrChat Presentation DuyHai DOAN, Technical Advocate
- 2. @doanduyhai KillrChat presentation! 2 What is KillrChat ? • scalable messaging app Why KillrChat ? • show real life de-normalization • DIY exercise • provide real application for attendees • highlight Cassandra eco-system
- 3. @doanduyhai Technology stack! 3 AngularJS UI Bootstrap SockJS Spring REST Spring Security Spring Messaging Cassandra Achilles Object Mapper
- 4. @doanduyhai Architecture! 4 Tomcat Spring C* HTTP Rest Spring {Boot,Security, Rest, Messaging} Cassandra, Achilles In-memory broker Embedded/local Cassandra Single node AngularJS, UI Bootstrap, SockJS
- 5. @doanduyhai Architecture! 5 Tomcat Spring … Broker (RabbitMQ, ZeroMQ, Kafka…) Tomcat Spring Tomcat Spring Scaling out
- 7. @doanduyhai Getting started! 7 Clone the Git repository git clone https://github.com/doanduyhai/killrchat.git Go into the ‘killrchat’ folder and launch tests cd killrchat mvn clean test
- 8. Exercise 1! User account management!
- 10. @doanduyhai Data model! 10 CREATE TABLE killrchat.users( login text, pass text, //password is not allowed because reserved word lastname text, firstname text, bio text, email text, chat_rooms set<text>, PRIMARY KEY(login));
- 12. @doanduyhai User’s chat rooms data model! 12 How to store chat rooms for an user ?! CREATE TABLE killrchat.user_rooms( login text, room_name text, PRIMARY KEY((login), room_name)); • pros: can store huge room count per user (106) • cons: separated table, needs 1 extra SELECT!
- 13. @doanduyhai User’s chat rooms data model! 13 Best choice! • 1 SELECT fetches all data for a given user • usually, 1 user is not in more that 1000 rooms at a time • stores only room name CREATE TABLE killrchat.users( login text, … chat_rooms set<text>, //list of chat rooms for this user PRIMARY KEY(login));
- 14. @doanduyhai Lightweight Transaction! 14 Avoid creating the same login by 2 different users ? ☞ use Lightweight Transaction! INSERT INTO killrchat.users(room_name, …) VALUES (‘jdoe’, …) IF NOT EXISTS ; Expensive operation! ☞ do you create a new account every day ?!
- 15. Demo
- 16. Exercise 2! Chat room management!
- 18. @doanduyhai Data model! 18 CREATE TABLE killrchat.chat_rooms( room_name text, creation_date timestamp, banner text, creator text, // de-normalization creator_login text, participants set<text>, // de-normalization PRIMARY KEY(room_name));
- 21. @doanduyhai De-normalization! 21 CREATE TABLE killrchat.chat_rooms( room_name text, … creator text, // JSON blob {login: …, firstname: …, lastname: …} … participants set<text>, // JSON blob {login: …, firstname: …, lastname: …} PRIMARY KEY(room_name));
- 22. @doanduyhai Lightweight Transaction! 22 Avoid creating the same room by 2 different users ? ☞ use Lightweight Transaction! INSERT INTO killrchat.chat_rooms(room_name, …) VALUES (‘games’, …) IF NOT EXISTS ;
- 23. Demo
- 24. Exercise 3! Participants management! Room deletion!
- 25. @doanduyhai Participant joining! 25 Adding new participant! UPDATE killrchat.chat_rooms SET participants = participants + {…} WHERE room_name = ‘games’; ❓ What if the creator deletes the room at the same time ?
- 26. @doanduyhai Concurrent delete/update! 26 UPDATE chat_rooms SET participants = participants + {login: ‘jdoe’, …} WHERE room_name = ‘games’; DELETE FROM chat_rooms WHERE room_name= ‘games’; result games participants creator banner ... {login: ‘jdoe’, …} ∅ ∅ ∅
- 27. @doanduyhai Participant joining! 27 Solution ☞ use Lightweight Transaction! UPDATE killrchat.chat_rooms SET participants = participants + {…} WHERE room_name = ‘games’ IF EXISTS;
- 28. @doanduyhai Concurrent delete/update! 28 UPDATE chat_rooms SET participants = participants + {login: ‘jdoe’, …} WHERE room_name = ‘games’ IF EXISTS; DELETE FROM chat_rooms WHERE room_name= ‘games’ IF creator_login = ‘jdoe’; OK
- 29. @doanduyhai Concurrent delete/update! 29 UPDATE chat_rooms SET participants = participants + {login: ‘jdoe’, …} WHERE room_name = ‘games’ IF EXISTS; DELETE FROM chat_rooms WHERE room_name= ‘games’ IF creator_login = ‘jdoe’; Room deleted
- 30. @doanduyhai Participant leaving! 30 Removing participant (no read-before-write)! UPDATE killrchat.chat_rooms SET participants = participants - {…} WHERE room_name = ‘games’; ❓ What if the creator deletes the room at the same time ? • we’ll create a tombstone • tombstone will be garbage-collected by compaction !
- 31. @doanduyhai Concurrent delete/update! 31 UPDATE chat_rooms SET participants = participants - {login: ‘jdoe’, …} WHERE room_name = ‘games’; DELETE FROM chat_rooms WHERE room_name= ‘games’; result games participants creator banner ... ∅ ∅ ∅ ∅
- 32. @doanduyhai Deleting room! 32 What if participant leaving at the same time ? • not a problem, tombstone will be garbage What if participant joining at the same time ? ☞ use Lightweight Transaction! Only room creator can delete room, no one else! ☞ use Lightweight Transaction !
- 33. @doanduyhai Deleting room! 33 DELETE killrchat.chat_rooms WHERE room_name = ‘games’ IF creator_login = <current_user_login>; Solution Advantages • current user login coming from Security context, no cheating ! • slow but how often do you delete rooms ?
- 34. Demo
- 35. Exercise 4! Chat messages management!
- 36. @doanduyhai Scalability! 36 n1 n2 n3 n4 n5 n6 n7 n8 A B C D E F G H Scaling messages by room name! games message1 … messageN … politics message1 … messageN … java message1 … messageN … cassandra message1 … messageN … scala message1 … messageN …
- 37. @doanduyhai Data model! 37 CREATE TABLE killrchat.chat_room_messages( room_name text, message_id timeuuid, content text, author text, // JSON blob {login: …, firstname: …, lastname: …} system_message boolean, PRIMARY KEY((room_name), message_id) ) WITH CLUSTERING ORDER BY (message_id DESC);
- 38. @doanduyhai Data model! 38 Clustering column message_id order by DESC • latest messages first • leverage the new row cache in Cassandra 2.1 Improvements • current data model limits messages count to ≈ 500 ⨉ 106 • bucketing by day is the right design PRIMARY KEY((room_name, day), message_id) //day format yyyyMMdd
- 39. Demo
- 40. Q & R ! "!