Cách Discord lưu trữ hàng nghìn tỷ tin nhắn (2023)
(discord.com)- Khi lượng lưu trữ tin nhắn của Discord tăng từ hàng tỷ lên hàng nghìn tỷ, gánh nặng vận hành cụm Cassandra 177 node vào đầu năm 2022 và độ trễ khó dự đoán đã trở nên không còn dễ chấp nhận
- Thiết kế Cassandra xoay quanh
channel_idvà bucket thời gian đã tạo ra hot partition dưới lưu lượng đọc tập trung từ các máy chủ lớn, còn đọc/ghi theo quorum khiến độ trễ lan rộng ảnh hưởng tới nhiều người dùng hơn - Discord đặt một data service viết bằng Rust giữa API và cơ sở dữ liệu, gộp các yêu cầu đồng thời vào cùng một hàng dữ liệu và dùng định tuyến băm nhất quán theo ID kênh để giảm tải cho cơ sở dữ liệu
- Quá trình chuyển sang ScyllaDB được thực hiện bằng một cụm mới và trình migrator viết bằng Rust, rút khối lượng công việc dự kiến 3 tháng với Spark xuống còn 9 ngày, đồng thời di chuyển tối đa 3,2 triệu tin nhắn mỗi giây
- Sau khi chuyển đổi vào tháng 5/2022, số node giảm từ 177 Cassandra xuống 72 ScyllaDB, p99 truy vấn tin nhắn cũ cải thiện từ 40~125ms xuống 15ms, còn p99 chèn tin nhắn từ 5~70ms xuống 5ms
Gánh nặng vận hành ngày càng lớn với Cassandra
- Năm 2017, Discord đã công bố cách lưu trữ hàng tỷ tin nhắn, chia sẻ quá trình chuyển từ MongoDB sang Cassandra
- Mục tiêu khi đó là một cơ sở dữ liệu có thể mở rộng, chịu lỗi tốt và cần tương đối ít công bảo trì, nhưng khi lượng lưu trữ tăng lên, chính cụm Cassandra lại trở thành một gánh nặng vận hành lớn
- Cụm
cassandra-messagesdùng để lưu trữ tin nhắn đã tăng từ 12 node vào năm 2017 lên 177 node vào đầu năm 2022, lưu trữ hàng nghìn tỷ tin nhắn - Đội vận hành thường xuyên bị gọi vì sự cố cơ sở dữ liệu, độ trễ khó dự đoán, và cần giảm bớt các công việc bảo trì có chi phí quá cao
Schema tin nhắn và hot partition
- Schema tin nhắn đã được đơn giản hóa gồm
channel_id,bucket,message_id,author_id,content, với khóa chính là((channel_id, bucket), message_id) - ID của Discord dựa trên Snowflake nên có thể sắp xếp theo thời gian, và tin nhắn được phân vùng theo kênh cùng cửa sổ thời gian tĩnh gọi là bucket
- Trong Cassandra, toàn bộ tin nhắn của một kênh và bucket cụ thể được lưu cùng nhau, rồi sao chép sang nhiều node theo hệ số replication
- Máy chủ nhóm bạn nhỏ và máy chủ quy mô hàng trăm nghìn người có chênh lệch khối lượng tin nhắn rất lớn, và sự khác biệt này dẫn tới chênh lệch tải theo từng partition
- Ghi sẽ được append vào commit log và cấu trúc bộ nhớ memtable trước khi flush xuống đĩa, nhưng đọc thì có thể phải tra cứu cả memtable lẫn nhiều SSTable nên tốn kém hơn
- Khi các lượt đọc đồng thời dồn vào một máy chủ lớn, một partition cụ thể sẽ trở thành hot partition, làm tăng độ trễ ở node đó và ảnh hưởng cả các truy vấn khác
- Vì Discord dùng quorum consistency level cho cả đọc lẫn ghi, độ trễ tăng ở node xử lý hot partition sẽ lan rộng ảnh hưởng tới nhiều người dùng hơn
Nút thắt bảo trì Cassandra
- Compaction của Cassandra cũng là nguyên nhân lặp đi lặp lại dẫn tới ứng phó sự cố
- SSTable cần được compact trên đĩa để cải thiện hiệu năng đọc, nhưng nếu compaction bị tồn đọng thì chi phí đọc sẽ tăng
- Trong lúc một node đang compaction, độ trễ có thể tăng dây chuyền
- Discord thường xuyên phải thực hiện quy trình mà họ gọi là “gossip dance”
- Loại node ra khỏi luồng traffic để chạy compaction
- Đưa node trở lại để nó bắt kịp các hint từ Cassandra hinted handoff
- Lặp lại quá trình này cho tới khi hết backlog compaction
- Việc tinh chỉnh JVM garbage collector và cấu hình heap cũng tốn rất nhiều thời gian, còn GC pause tạo ra các đợt tăng đột biến độ trễ lớn
Vì sao chuyển sang ScyllaDB
- Ngoài dữ liệu tin nhắn, Discord còn vận hành nhiều cụm Cassandra khác và các vấn đề tương tự cũng xuất hiện ở từng cụm
- ScyllaDB, từng được Discord nhắc tới trong bài viết trước, là cơ sở dữ liệu tương thích Cassandra, được viết bằng C++, cung cấp hiệu năng tốt hơn, repair nhanh hơn, cô lập workload dựa trên kiến trúc shard-per-core và không có garbage collection
- ScyllaDB không phải không có vấn đề, nhưng việc được viết bằng C++ thay vì Java và không có garbage collector tạo ra sự đối lập trực tiếp với các vấn đề vận hành của Cassandra
- Sau khi xác nhận các cải thiện qua thử nghiệm và kiểm thử, Discord quyết định chuyển toàn bộ cơ sở dữ liệu sang ScyllaDB, và tới năm 2020 đã hoàn tất với mọi cơ sở dữ liệu trừ
cassandra-messages - Cụm tin nhắn được giữ lại đến cuối cùng vì đây là cụm lớn với hàng nghìn tỷ tin nhắn và gần 200 node
- Hiệu năng truy vấn ngược của ScyllaDB trong các bài kiểm tra ban đầu chưa đáp ứng yêu cầu
- Truy vấn ngược là trường hợp quét theo hướng ngược với thứ tự sắp xếp của bảng, ví dụ quét tin nhắn theo thứ tự tăng dần
- Khi đội ScyllaDB ưu tiên triển khai cải thiện hiệu năng, yếu tố cuối cùng cản trở quá trình di chuyển cơ sở dữ liệu cũng được gỡ bỏ
Data service dựa trên Rust
- Discord cho rằng chỉ thay cơ sở dữ liệu thôi thì chưa thể tự động giải quyết toàn bộ vấn đề, nên họ cũng thay đổi cả lớp phía trên cơ sở dữ liệu
- Họ đặt một data service giữa API monolith và cụm cơ sở dữ liệu để kiểm soát các yêu cầu đồng thời hướng tới cơ sở dữ liệu
- Data service được viết bằng Rust
- Discord trước đó cũng đã dùng Rust cho một số dự án
- Rust mang lại tốc độ cấp độ C/C++ mà không phải đánh đổi về độ an toàn
- Hệ sinh thái Tokio được dùng làm nền tảng xây dựng hệ thống I/O bất đồng bộ, đồng thời có hỗ trợ driver cho Cassandra và ScyllaDB
- Data service có gần như một endpoint gRPC cho mỗi truy vấn cơ sở dữ liệu và cố ý không chứa business logic
- Trọng tâm là gộp yêu cầu
- Nếu nhiều người dùng đồng thời yêu cầu cùng một hàng dữ liệu, cơ sở dữ liệu chỉ bị truy vấn một lần
- Yêu cầu đầu tiên tạo một worker task trong service, các yêu cầu sau sẽ kiểm tra sự tồn tại của task đó rồi đăng ký theo dõi
- Worker task truy vấn cơ sở dữ liệu và trả hàng kết quả cho tất cả subscriber
Tăng hiệu quả gộp bằng định tuyến
- Ở phía trước data service, Discord áp dụng định tuyến dựa trên băm nhất quán
- Mỗi yêu cầu gửi tới data service đều có routing key, và với tin nhắn thì routing key là ID kênh
- Mọi yêu cầu của cùng một kênh sẽ đi tới cùng một instance service, nhờ đó cơ chế gộp yêu cầu hoạt động hiệu quả hơn
- Ví dụ, khi một thông báo
@everyonexuất hiện trong máy chủ lớn, rất nhiều người dùng có thể mở ứng dụng và đọc cùng một tin nhắn, làm lưu lượng tới cơ sở dữ liệu tăng đột biến - Trong kiến trúc cũ, tình huống này có thể dẫn tới hot partition và buộc đội vận hành phải can thiệp, nhưng data service đã giảm mạnh các đợt tăng vọt traffic hướng tới cơ sở dữ liệu
- Dù cải tiến này không xóa bỏ hoàn toàn hot partition và độ trễ trên cụm Cassandra, nó đã giúp Discord có thêm thời gian để chuẩn bị cụm ScyllaDB mới và tiến hành migration
Di chuyển hàng nghìn tỷ tin nhắn
- Các yêu cầu cho migration rất rõ ràng
- Phải di chuyển hàng nghìn tỷ tin nhắn
- Không được có downtime
- Cassandra vẫn liên tục gây ra các đợt ứng phó sự cố nên quá trình phải kết thúc nhanh
- Trước tiên, Discord dựng một cụm ScyllaDB mới dùng super-disk storage topology
- Dùng Local SSD để có tốc độ cao
- Dùng RAID để mirror dữ liệu sang persistent disk
- Cấu hình này kết hợp tốc độ của đĩa cục bộ với độ bền của persistent disk
- Kế hoạch ban đầu là từ thời điểm cutover, dữ liệu mới sẽ dùng ScyllaDB còn dữ liệu cũ sẽ được chuyển phía sau
- Dữ liệu mới bắt đầu được ghi kép vào cả Cassandra lẫn ScyllaDB, đồng thời Discord chuẩn bị Spark migrator của ScyllaDB
- Spark migrator cần rất nhiều tinh chỉnh, và sau khi cấu hình xong, thời gian hoàn tất ước tính là 3 tháng
- Sau đó Discord mở rộng thư viện cơ sở dữ liệu tốc độ cao sẵn có và viết lại data migrator bằng Rust
- Đọc token range từ cơ sở dữ liệu
- Ghi checkpoint cục bộ bằng SQLite
- Gửi dữ liệu hàng loạt sang ScyllaDB
- Trình migrator Rust mới rút thời gian hoàn tất dự kiến xuống còn 9 ngày, và tốc độ này cho phép họ thực hiện toàn bộ quá trình chuyển đổi trong một lần thay vì dùng cách tiếp cận phức tạp theo thời gian
Chuyển đổi và xác minh
- Migration diễn ra với tốc độ tối đa 3,2 triệu tin nhắn mỗi giây
- Tiến độ bị kẹt ở mức 99,9999% vì trong vài token range cuối cùng của Cassandra có các dải tombstone khổng lồ chưa được compact
- Sau khi compact các token range đó, migration hoàn tất chỉ sau vài giây
- Discord thực hiện xác minh dữ liệu tự động bằng cách gửi một tỷ lệ nhỏ yêu cầu đọc tới cả hai cơ sở dữ liệu rồi so sánh kết quả, và không phát hiện vấn đề gì
- Cụm ScyllaDB hoạt động ổn định ngay cả dưới toàn bộ traffic production, trong khi Cassandra ngày càng gặp các vấn đề độ trễ thường xuyên hơn
- Đội ngũ đã chuyển ScyllaDB thành primary database ngay tại hiện trường
Hiệu năng và quy mô sau chuyển đổi
- Việc chuyển cơ sở dữ liệu tin nhắn diễn ra vào tháng 5/2022
- Sau đó việc vận hành trở nên yên ắng và ổn định, không còn cảnh phải ứng phó sự cố suốt cuối tuần hay liên tục điều chỉnh node trong cụm để giữ uptime
- Số node giảm từ 177 node Cassandra xuống còn 72 node ScyllaDB
- Dung lượng đĩa trên mỗi node ScyllaDB là 9TB, lớn hơn mức trung bình 4TB của node Cassandra
- Tail latency cũng được cải thiện rõ rệt
- p99 truy vấn tin nhắn cũ: Cassandra 40~125ms → ScyllaDB 15ms
- p99 chèn tin nhắn: Cassandra 5~70ms → ScyllaDB 5ms
- Nhờ cải thiện hiệu năng, Discord có thể tự tin hơn vào cơ sở dữ liệu tin nhắn và mở ra các trường hợp sử dụng sản phẩm mới
Khả năng xử lý tải được kiểm chứng trong traffic World Cup
- Cuối năm 2022, trong thời gian World Cup, khi người dùng toàn cầu theo dõi các trận đấu, biểu đồ gửi tin nhắn của Discord cũng xuất hiện các đỉnh tương ứng với những khoảnh khắc ghi bàn
- Biểu đồ gửi tin nhắn trong trận chung kết World Cup cho thấy nhiều spike tương ứng với các diễn biến trận đấu
- Quả phạt đền của Messi và lợi thế 1-0 cho Argentina
- Bàn thắng tiếp theo của Argentina
- Plateau kéo dài 15 phút trong giờ nghỉ giữa hiệp
- Spike khi Mbappe ghi bàn cho Pháp rồi 90 giây sau ghi thêm bàn gỡ hòa
- Kết thúc thời gian thi đấu chính thức và bước vào hiệp phụ
- Chat trong giờ nghỉ giữa hai hiệp phụ
- Bàn thắng tiếp theo của Messi
- Bàn gỡ hòa của Mbappe
- Kết thúc hiệp phụ và bước vào loạt sút luân lưu
- Cú sút hỏng của Pháp và chức vô địch của Argentina
- Ngay cả khi lưu lượng gửi tin nhắn tăng mạnh, data service viết bằng Rust và ScyllaDB vẫn xử lý được traffic
- Hệ thống cuối cùng đã được định hình để có thể xử lý hàng nghìn tỷ tin nhắn
1 bình luận
Ý kiến trên Hacker News
Bài viết này có vẻ đổ lỗi khá nhiều cho garbage collection, nhưng nếu xem bài trước [0] thì có vẻ vấn đề gần với giới hạn trong cách dùng Cassandra, cách Cassandra xử lý xóa hàng loạt, hoặc cả hai
Một người dùng đã xóa hàng triệu tin nhắn qua API, chỉ để lại 1 tin nhắn trong kênh; vì Cassandra xử lý thao tác xóa bằng tombstone, nên khi người dùng mở kênh đó, dù thực tế chỉ có 1 tin nhắn, hệ thống vẫn phải quét hàng triệu tombstone. Giải thích là trong quá trình đó, rác được tạo ra nhanh hơn tốc độ JVM có thể thu gom
Ngoài ra bài có nói đến tinh chỉnh GC, nhưng nhìn [1] thì có vẻ họ cũng không tinh chỉnh nhiều, và có lẽ đang dùng phiên bản Cassandra, cũng như JVM, khá cũ. Việc họ vừa mới chuyển khỏi CMS cũng là một yếu tố lớn
0) https://discord.com/blog/how-discord-stores-billions-of-messages
Ngay cả nếu trước đây họ đang dùng sai giải pháp, tôi vẫn nghĩ một giải pháp khó dùng sai sẽ tốt hơn
Nếu năm 2022 mà họ dùng Java 11 thì đó là runtime 4 năm tuổi, còn nếu dùng Java 8 thì là runtime 8 năm tuổi, nên rất có khả năng họ đã bỏ lỡ khá nhiều hiệu năng
Needs (2023)
Tầng dịch vụ này trông giống một Varnish Cache phân tán lớn và hào nhoáng. Việc họ chọn từ “coalesce” thay vì nhắc đến caching khiến có vẻ như họ không thực sự cache nhiều, nhưng nó làm tôi nhớ đến “grace mode” của Varnish và mục đích ngăn stampede, tức bối cảnh lần đầu tôi nghe đến ‘request coalescing’ https://varnish-cache.org/docs/6.1/users-guide/vcl-grace.htm...
Cũng vui khi thấy consistent hashing liên tục xuất hiện. Đây là một kỹ thuật kiểu băng keo rất hay, đã chứng minh được hữu ích trong các tình huống tương tự. Nếu biết thứ gì nên nằm ở đâu, mọi người cũng sẽ biết phải đến đâu để tìm nó
proxy_cache_use_stale updating;Đồng sáng lập ScyllaDB có bổ sung vài điểm: Discord không thể hoàn tất repair với Cassandra, nhưng với Scylla thì không như vậy; Scylla có nhiều điểm chung với Cassandra như LSM tree và compaction, nhưng nhờ bộ lập lịch CPU/IO riêng, nó có thể ưu tiên truy vấn cao hơn compaction
Họ nói có thể trì hoãn compaction đến những khoảng nửa mili giây khi đủ băng thông nhàn rỗi, và có nhiều bài viết liên quan. Scylla có một chế độ an toàn hơn tên là
tombstone_gc=repairđã 1,5 năm tuổi, và kiến trúc mới dựa trên Raft cùng tablets vừa ra mắt gần đây được xem là thay đổi lớn tiếp theo cho người dùngNhững vấn đề kiểu này ngay từ đầu đã không tồn tại nếu dùng IRC, một giao thức chat phân tán đã tồn tại hơn 40 năm
Nó còn có ưu điểm là có đặc tả mở và nhiều bản triển khai. Cũng không phải một khu vườn có tường bao. Nếu nghĩ IRC đã quá cũ kỹ trong thời hiện đại thì có thể nhìn sang Matrix hoặc XMPP. Thật khó hiểu vì sao Discord lại thống trị được, và thậm chí gần như là một bi kịch
IRC về cơ bản đòi hỏi bouncer nếu muốn theo dõi cuộc trò chuyện trên nhiều thiết bị. Nó cũng không mã hóa tin nhắn, chỉ tùy chọn mã hóa kết nối giữa client và server. Nếu không có mã hóa đầu cuối, sẽ không có quyền riêng tư trước server hay người vận hành, và server đó là một điểm lỗi đơn lẻ dễ trở thành mục tiêu
Giao thức Matrix vẫn đang thay đổi và các bản triển khai không theo kịp đặc tả. Nếu không dùng Element thì sẽ tụt hậu về tính năng và bảo mật. XMPP cũng như IRC, phụ thuộc vào các phần mở rộng tùy chọn cho những tính năng cơ bản như mã hóa đầu cuối, và client có thể không hỗ trợ đầy đủ, đúng cách
Tôi khuyên nên đọc phân tích của soatok: https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...
Vụ Snowden năm 2013 đã là chuyện 11 năm trước. Giờ đây mã hóa đầu cuối nên được xem là tính năng mặc định, như một thứ hàng hóa phổ thông, và cần được đòi hỏi kiên trì như cách từng đòi hỏi HTTPS. Tất nhiên Discord không triển khai mã hóa đầu cuối
Gần đây một nhóm rất kỹ thuật mà tôi tham gia đã chuyển từ Telegram sang Matrix, nhưng trải nghiệm người dùng không tốt. App có lỗi và nhìn cũng không đẹp, còn app “Element” mới không hỗ trợ SSO nên tôi không dùng được tài khoản. Với người chịu tự mày mò như tôi thì đó là những bất tiện nhỏ chấp nhận được, nhưng tôi không thể thuyết phục bạn bè dùng nó
Tải exe về, cài đặt, tạo tài khoản là chạy được ngay. Ai cũng làm được. Có nhiều phần mềm hữu ích và tuyệt vời, nhưng phần lớn không dễ với công chúng phổ thông, một số hoặc đa số thậm chí còn không có GUI. Người ta chọn bán danh tính của mình, thậm chí trả tiền, thay vì chịu đựng quá nhiều bước
Kết luận tôi rút ra từ bài viết này có thể hơi khác với ý định của tác giả
“Cái cuối cùng? Người bạn cassandra-messages của chúng ta. [...] Ngay từ đầu nó đã là một cụm lớn. Với hàng nghìn tỷ tin nhắn và gần 200 node, bất kỳ quá trình di trú nào cũng chắc chắn là một công việc phức tạp.”
Xét đến quy mô của Discord, chưa tới 200 node cho kho lưu trữ tin nhắn có vẻ nhỏ đến đáng ngạc nhiên. Tôi đã kỳ vọng một kiến trúc phức tạp hơn, nhắm tới khả năng mở rộng nhanh hơn nhiều và có nhiều thành phần chuyển động hơn. Độ phức tạp thực tế chắc chắn cao hơn những gì bài viết nêu, nhưng nhớ lại kinh nghiệm từng chịu trách nhiệm một phần cho hơn 200 node vật lý làm ít việc hơn, tôi tự hỏi kiến trúc cloud hiện đại đang bị thiết kế quá mức đến đâu
Từ kinh nghiệm từng lưu hàng chục tỷ bản ghi bằng một tập node Cassandra nhỏ hơn nhiều, Cassandra thực sự là nỗi đau khi trực on-call và đã là nguyên nhân của vài sự cố lớn
[0] https://news.ycombinator.com/item?id=34950843
Bài viết được viết rất hay. Thật tốt khi một phần của giải pháp không phải là đưa vào một thứ hoàn toàn khác, mà là chuyển sang ScyllaDB, có thể dùng như một sản phẩm thay thế cho Cassandra
Discord về cơ bản khiến việc xóa các tin nhắn cũ trở nên bất khả thi. Đây là một cơn ác mộng về quyền riêng tư, và tôi tự hỏi vì sao EU chưa can thiệp
Câu hỏi cốt lõi có thể được rút gọn thành: nên xem Matrix gần với email hơn, hay gần với Facebook hơn. Nếu là email, mọi người sẽ kinh hoàng khi người gửi có thể xóa tin nhắn của họ khỏi mail spool của tôi; còn nếu là Facebook, mọi người sẽ kinh hoàng khi bài đăng vẫn xuất hiện ở đâu đó sau khi họ đã thực thi quyền xóa
Lời giải thích là để xử lý điều này cần có phán đoán, và họ đã tiếp cận bằng cách trước hết cân nhắc tinh thần của GDPR thực sự nhằm đạt được điều gì
https://matrix.org/blog/2018/05/08/gdpr-compliance-in-matrix...
Vấn đề dưới góc nhìn GDPR là Discord khiến việc xóa những dữ liệu này trở nên khó khăn. Khi phát hiện ý định xóa dữ liệu tài khoản, họ hướng người dùng sang “ẩn danh hóa”; công khai thì tên người dùng được tách khỏi tin nhắn, nhưng vẫn có thể truy vết về một cá nhân cụ thể. Nếu phía máy chủ cũng xử lý như vậy, để thực thi yêu cầu xóa thông tin định danh cá nhân của người dùng sẽ phải rà soát một lượng tin nhắn khổng lồ hoặc xóa hàng loạt tin nhắn cũ
Tôi cho rằng Nghị viện EU không phải là một nghị viện thực sự, vì luật mới chỉ có thể do Ủy ban đề xuất còn nghị viện được bầu chủ yếu chỉ biểu quyết; và bên kiểm soát Ủy ban không phải công chúng mà là Bộ Ngoại giao Mỹ. Newsguard, các Big Tech Mỹ không phải Musk, và Discord cũng nằm trong cùng mạng lưới đặc quyền chính trị–tài chính đó, với rất nhiều cựu nhân sự Bộ Ngoại giao
Nếu không có sự phẫn nộ rộng rãi của công chúng, các cơ quan cấp EU rất dễ bị thao túng; còn dư luận thì cũng bị giới đặc quyền kiểu cyberpunk kiểm soát, những kẻ huấn luyện LLM bằng dữ liệu Discord bất hợp pháp và nhắm mục tiêu quảng cáo bầu cử. Rốt cuộc, cần lo ngại rằng ta có thể đi đến một trạng thái kiểu Orwell, nơi không thể thoát khỏi tầng lớp đặc quyền vĩnh viễn
Tuy vậy, tôi chỉ đánh giá phần lớn những điều trên là có xác suất đúng theo nghĩa rộng hơn 50% một chút, nên hãy tiếp nhận với rất nhiều hoài nghi
Cassandra về bản chất gần với một bảng băm phân tán chịu lỗi mà phần lớn chỉ ghi thêm. Nếu bạn cần chính xác thứ đó với thông lượng ghi cao thì đây là một lựa chọn tốt
Tôi không hiểu vì sao mọi người lại dùng nó như một cơ sở dữ liệu. Bạn sẽ nhanh chóng đụng giới hạn, và nỗi đau khi cố dùng nó như cơ sở dữ liệu sẽ càng tệ hơn khi quy mô tăng lên
Nếu vậy thì tôi thấy nó không hợp lý làm kho lưu trữ tin nhắn cho máy chủ chat. Nó có vẻ phù hợp làm đích thu thập log của hệ thống phân tán, nơi nhiều client đổ dữ liệu vào nhưng hầu hết thậm chí không cần kiểm tra log, nên số lần đọc một mục cụ thể thường nhỏ hơn 1. Tin nhắn Discord rõ ràng không phải trường hợp đó
Theo kinh nghiệm của tôi, tôi chưa từng thấy dự án nào bắt đầu dùng Cassandra mà sau khoảng 1 năm vẫn tiếp tục dùng nó. Mất khoảng 1 năm để đụng giới hạn, rồi cuối cùng họ thay bằng một cơ sở dữ liệu như Postgres
Tôi không hiểu vì sao không thể đơn giản là sharding. Mỗi ‘server’ của Discord chẳng phải được cô lập với nhau sao? Nếu chúng không thể gửi tin nhắn cho nhau, tôi tự hỏi tại sao không chia hàng nghìn tỷ tin nhắn thành hàng nghìn shard, để mỗi shard xử lý vài tỷ tin nhắn
Bài viết nói rằng “đội ngũ ScyllaDB đã ưu tiên công việc cải tiến và triển khai truy vấn ngược hiệu năng cao, loại bỏ trở ngại cơ sở dữ liệu cuối cùng trong kế hoạch migration”
Tôi tò mò họ đã phải trả bao nhiêu để yêu cầu làm việc đó trước khi thậm chí dùng ScyllaDB