Tìm kiếm
40 kết quả cho “Cassandra”. Tìm không phân biệt dấu.
- Avoid pitfalls in scaling your Cassandra cluster: lessons and remedies Bài tóm tắt · Walmart · 2017
…tps://medium.com/walmartlabs/avoid-pitfalls-in-scaling-your-cassandra-cluster-lessons-and-remedies-a71ca01f8c04) Bối cảnh Nhiều team ở Walmart dùng Cassandra làm nguồn dữ liệu chín…
- DynamoDB: Why migrate to DynamoDB from Cassandra? Bài tóm tắt · Expedia · 2018
…om/expedia-group-tech/dynamodb-why-migrate-to-dynamodb-from-cassandra-f4955be87b19) Bài thứ 2 trong series về DynamoDB của Expedia Group Tech. Đây là bài so sánh và đánh giá , khôn…
- How we build a robust analytics platform using Spark, Kafka and Cassandra Bài tóm tắt · Walmart · 2018
…-we-build-a-robust-analytics-platform-using-spark-kafka-and-cassandra-lambda-architecture-70c2d1bc8981) Bài ngắn (3 phút đọc), mô tả kiến trúc ở mức khối. Site chặn crawler; ghi ch…
- Call me maybe: Cassandra Bài tóm tắt · Jepsen · 2013
…: Khó — [bài gốc](https://aphyr.com/posts/294-call-me-maybe-cassandra) Bài thời kỳ đầu của Jepsen (blog cá nhân); ghi "theo Kingsbury" với các nhận định. Bối cảnh - Cassandra theo…
- Orchestrating Cassandra on Kubernetes with Operators Bài tóm tắt · Yelp · 2020
…gốc](https://engineeringblog.yelp.com/2020/11/orchestrating-cassandra-on-kubernetes-with-operators.html) Đi trước loạt bài Kafka on PaaSTA () với cùng cách làm. Bối cảnh - Cassandr…
- How we moved our Food Feed from Redis to Cassandra Bài tóm tắt · Zomato · 2016
…ww.zomato.com/blog/how-we-moved-our-food-feed-from-redis-to-cassandra) Bối cảnh - Food Feed là một phần của social graph: review, ảnh của bạn bè, ưu đãi từ nhà hàng đã lưu. Ban đầu…
- Netflix Billing Migration to AWS — Part II Bài tóm tắt · Netflix · 2016
…app mới (Spring Boot, Spring Integration) với dữ liệu trong Cassandra ở nhiều region; batch cũ vẫn ở DC nên dữ liệu được đồng bộ ngược qua SQS + dead letter queue về một region có…
- Wix Inbox Journey: 3 Approaches for Zero Downtime Database Migration Bài tóm tắt · Wix · 2021
…nước. Ứng dụng chat của Wix Inbox (trong bộ CRM) chạy trên Cassandra tự quản lý trên EC2 , dùng chung cho nhiều microservice. - Vì sao không ổn định: - partition key = chatroom id…
- Scaling Time Series Data Storage — Part I Bài tóm tắt · Netflix · 2018
…iên, số giờ xem mỗi người. - Bản cloud-native đầu tiên dùng Cassandra : hợp time series (mỗi row số cột động), tỉ lệ ghi:đọc khoảng 9:1, chọn nhất quán cuối thay vì mất availabilit…
- Netflix Billing Migration to AWS Bài tóm tắt · Netflix · 2016
…Tách Oracle theo nhu cầu nhất quán: dữ liệu subscriber sang Cassandra (cần multi-region, sẵn sàng cao); dữ liệu thanh toán cần giao dịch ACID sang MySQL . - Đơn giản hoá trước khi…
- Keeping Counts In Sync Bài tóm tắt · SoundCloud · 2018
…và backfill do bug). - Cả tầng batch và tầng realtime dùng Cassandra : batch nạp bằng SSTable loading; realtime dùng distributed counter của Cassandra, mỗi event là một lệnh tăng/…
- Lessons from Building Observability Tools at Netflix Bài tóm tắt · Netflix · 2018
…hi: dữ liệu luôn đọc theo khoá chính + khoảng thời gian thì Cassandra ; cần query theo nhiều trường thì Elasticsearch ; dữ liệu cũ (người dùng chủ yếu xem tuần gần nhất) giữ lâu hơ…
- Scaling Pinterest - From 0 To 10s Of Billions Of Page Views A Month In Two Years Bài tóm tắt · Pinterest · 2013
…e paper: MySQL chia theo chức năng (5 DB + 9 slave), 4 node Cassandra, 15 node Membase (3 cụm), Memcache, Redis, Elasticsearch, 3 cụm Mongo, chỉ với 3 kỹ sư. Năm công nghệ DB khác…
- Active-Active for Multi-Regional Resiliency Bài tóm tắt · Netflix · 2013
…fic). - Dữ liệu: mọi dữ liệu đọc/ghi phục vụ user nằm trong Cassandra nhân bản đa region. Thí nghiệm: ghi 1 triệu bản ghi ở một region, 500 ms sau đọc ở region kia dưới tải product…
- Learn to stop using shiny new things and love MySQL Bài tóm tắt · Pinterest · 2015
…p, Pinterest chạy cùng lúc MySQL, Memcache, MongoDB, Redis, Cassandra, Membase và Elasticsearch; theo tác giả, "mọi thứ đều cháy theo cách riêng". Các công ty database mới chào mời…
- Roshi: a CRDT system for timestamped events Bài tóm tắt · SoundCloud · 2014
…p mới nhất trước. - Cách đang chạy là fan-out on write trên Cassandra: mỗi user một row làm "inbox"; ai đó repost thì chèn event vào inbox của mọi follower. Đọc nhanh, nhưng theo S…
- Scaling Time Series Data Storage — Part II Bài tóm tắt · Netflix · 2018
…g một quý; rollout preview bị hoãn vì ảnh hưởng tới nó. Cụm Cassandra đã lớn nhất và gần giới hạn kích thước mà ít ai vượt qua được. - Client library lấy toàn bộ dữ liệu rồi mới lọ…
- Architecting Restaurant Wait Time Predictions Bài tóm tắt · Yelp · 2019
…service online viết bằng Python lấy feature từ kho online (Cassandra cho kết quả ETL Spark, MySQL cho trạng thái nhà hàng) rồi gọi model server Java nội bộ (thư viện XGBoost Java…
- Chọn database theo workload Chủ đề Thành viên
Không có database tốt nhất, chỉ có database hợp với mẫu đọc/ghi ở một quy mô cụ thể. Mẫu đó thay đổi khi sản phẩm lớn lên. Ngoài ra, chuyên môn vận hành của đội cũng là một phần của "workload".
- Sharding và tách database Chủ đề Thành viên
Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một sự cố ở DB đó làm sập mọi tính năng.
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lúc.
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- Giao dịch phân tán và nhất quán xuyên service Chủ đề Thành viên
Với một DB quan hệ, BEGIN … COMMIT lo hết. Khi dữ liệu bị chia (shard, tách service, thêm Redis bên cạnh Postgres), một thao tác nghiệp vụ chạm nhiều nơi, và câu hỏi khó nhất trở thành "timeout rồi, việc đó đã xảy ra…
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phản ứng…
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- Sinh ID phân tán Chủ đề Thành viên
Khi chỉ có một database, AUTOINCREMENT là đủ. Khi dữ liệu nằm trên nhiều máy, ID không còn duy nhất toàn hệ thống. Đây thường là thứ đầu tiên vỡ khi phân tán dữ liệu. Yêu cầu hay gặp: duy nhất, sắp được theo thời gian,…
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Stream processing Chủ đề Thành viên
Khi batch hằng ngày hay hằng giờ không còn đủ tươi (chi tiêu quảng cáo phải dừng đúng lúc chạm ngân sách, dashboard MRR không được trễ 24 giờ, alert phải bắn khi contest sắp đầy), hệ phải tính liên tục trên luồng sự…
- Xử lý sự cố và on-call Chủ đề Thành viên
Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:
- Netflix Công ty Thành viên
Sự cố hỏng DB năm 2008 dẫn tới 7 năm lên AWS theo hướng cloud-native . Bài kiểm tra lớn đầu tiên là sự cố AWS US-East năm 2011: kiến trúc stateless, nhiều zone, fallback chịu được, nhưng rút khỏi zone phải làm tay. Từ…
- Walmart Công ty Thành viên
Nhiều team ở Walmart dùng Cassandra làm nguồn chính (hàng chục tới hàng trăm nghìn ops/giây). Năm bài học (2017): shard key nhân tạo chống partition lệch, tách Solr khỏi Cassandra, không đọc/ghi cả hàng, cẩn thận với…
- How Discord Stores Billions of Messages Bài tóm tắt · Discord · 2017
…tin nhắn trong Redis), không phải blob store, mã nguồn mở. Cassandra là lựa chọn duy nhất thỏa hết. - Mô hình dữ liệu: khóa chính ((channel id, bucket), message id) . message id l…