Tìm kiếm
26 kết quả cho “Cassandra multi-region”. Tìm không phân biệt dấu.
- 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…
- 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…
- Độ 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.
- 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…
- The process: Implementing Yelp's failover strategy Bài tóm tắt · Yelp · 2021
Yelp phục vụ từ hai region AWS ở hai bờ nước Mỹ. Request chỉ đọc (phần lớn traffic) đi tới region gần nhất, có logic cân tải giữa hai bên.
- Instagration Pt. 2: Scaling our infrastructure to multiple data centers Bài tóm tắt · Instagram · 2015
…dụ job async chỉ dùng trong vùng). - Storage: PostgreSQL và Cassandra replicate xuyên vùng, nhất quán sau (eventual). Mỗi vùng có read replica vì đọc nhiều hơn ghi rất nhiều. Ghi P…
- Moving to DynamoDB to Increase Application Resiliency Bài tóm tắt · CapitalOne · 2021
…dùng database managed trên AWS (không tự vận hành MongoDB, Cassandra). Các lựa chọn đã cân nhắc Lựa chọn Ưu Nhược (lúc đánh giá, 2019) --- --- --- Aurora Global Database Failover…
- 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.
- 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…
- 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:
- 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:
- 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:
- 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…
- 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:
- 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…
- Yelp Công ty Thành viên
Kafka của Yelp (hàng chục tỷ message/ngày) chuyển từ EC2 + Puppet lên PaaS nội bộ PaaSTA trên Kubernetes với operator tự viết và Cruise Control (2021) ; migration không downtime bằng cách gấp đôi broker rồi dời…
- Discord Công ty Thành viên
Hiếm có công ty nào kể cùng một bài toán qua 6 năm như Discord. Năm 2015 họ cố ý dùng một replica set MongoDB để ra sản phẩm trong 2 tháng, kèm đường thoát. Họ phân tích workload rồi chuyển sang Cassandra 12 node với…
- Lessons Netflix Learned from the AWS Outage Bài tóm tắt · Netflix · 2011
…i. - Tránh EBS làm kho dữ liệu chính; dựa vào S3, SimpleDB, Cassandra (không bị ảnh hưởng trong sự cố). Coi mọi tài nguyên khác là tạm thời. Kết quả: dịch vụ chạy không cần can thi…
- Business Continuity & Disaster Recovery in the Microservices world Bài tóm tắt · Walmart · 2019
Hệ Integrated Fulfilment (app và backend cho nhân viên cửa hàng soạn đơn pickup/giao hàng) tăng trưởng mạnh và được viết lại. Yêu cầu chính: liên tục kinh doanh; một sự cố ảnh hưởng khách hàng nhiều nước.
- Wix Công ty Thành viên
Năm 2015 Wix dùng MySQL như một kho key/value (blob, không join, không transaction, GUID do client sinh) cho bảng phân giải URL → site, active-active 3 DC, đọc khoảng 1 ms; theo Wix, "MySQL là NoSQL tốt hơn" . Năm 2021,…
- Pinterest Công ty Thành viên
Năm 2015 Pinterest sinh sẵn nội dung cho mọi user và lưu trong HBase, cách đã đưa họ tới 100 triệu MAU nhưng tốn lưu trữ và khó thử nghiệm. Họ xây 9 hệ thống C++/RocksDB để sinh feed lúc đọc . Phía dưới là tầng cache…
- Twitter Công ty Thành viên
Khi rời một MySQL duy nhất sang Cassandra và MySQL shard (Gizzard), thứ vỡ đầu tiên là sinh ID, dẫn tới Snowflake (64 bit, k-sorted, không phối hợp) . Sau World Cup 2010, họ nhận ra monolith Rails (~200 kỹ sư) và…
- Why Uber Engineering Switched from Postgres to MySQL Bài tóm tắt · Uber · 2016
…sharding tự xây trên MySQL. Một số trường hợp đặc biệt dùng Cassandra. - Phân tích dựa trên Postgres 9.2 , bản khá cũ. Uber cho rằng kiến trúc lưu trữ này không đổi nhiều ở các bản…