Tìm kiếm
40 kết quả cho “shard theo loại dữ liệu”. Tìm không phân biệt dấu.
- Scaling Time Series Data Storage — Part II Bài tóm tắt · Netflix · 2018
…ên dùng dữ liệu nào cần ở mức chi tiết nào trong bao lâu. - Shard cụm theo loại dữ liệu , rồi với dữ liệu xem đầy đủ shard theo tuổi : Recent (vài ngày), Past (vài ngày đến vài năm…
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- 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.
- 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 Pinterest: How we scaled our MySQL fleet Bài tóm tắt · Pinterest · 2015
…bình — [bài gốc](https://medium.com/@Pinterest Engineering/sharding-pinterest-how-we-scaled-our-mysql-fleet-3f341e96ca6f) Bối cảnh - 2011 Pinterest tăng trưởng cực nhanh; khoảng 9…
- Herding elephants: Lessons learned from sharding Postgres at Notion Bài tóm tắt · Notion · 2021
…Độ khó: Trung bình — [bài gốc](https://www.notion.com/blog/sharding-postgres-at-notion) Bối cảnh - Một Postgres monolith (RDS) đã chạy 5 năm qua 4 bậc độ lớn tăng trưởng. Đến giữa…
- Scaling Etsy Payments with Vitess: Part 3 – Reducing Cutover Risk Bài tóm tắt · Etsy · 2023
…tess giữ đúng đảm bảo dữ liệu mà ứng dụng cần. - Vitess che sharding khá tốt, nhưng có những loại lỗi chỉ xuất hiện sau khi chuyển từ keyspace chưa shard sang đã shard. Thay đổi ch…
- The history of Postgres sharding Bài tóm tắt · PlanetScale · 2026
…i gốc](https://planetscale.com/blog/the-history-of-postgres-sharding) Nguồn thứ cấp, do nhà cung cấp viết: bài tổng quan lịch sử, kết thúc bằng giới thiệu sản phẩm Neki của chính P…
- Migrating Etsy's database sharding to Vitess Bài tóm tắt · Etsy · 2026
…(https://www.etsy.com/codeascraft/migrating-etsyas-database-sharding-to-vitess) Bối cảnh - Etsy shard MySQL từ khoảng 2010 : ~1.000 bảng trên ~1.000 shard, hơn 425 TB, ~1,7 triệu r…
- Geosharded Recommendations Part 2: Architecture Bài tóm tắt · Tinder · 2019
…Độ khó: Trung bình — [bài gốc](https://medium.com/tinder/geosharded-recommendations-part-2-architecture-3396a8a7efb) Phần 2 của series 3 phần. Phần 1 (cách chia shard): ; phần 3 (c…
- 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…
- Scaling Pinterest - From 0 To 10s Of Billions Of Page Views A Month In Two Years Bài tóm tắt · Pinterest · 2013
…hời trưởng thành": sau một đợt kiến trúc lại, chỉ còn MySQL shard (66 DB + 1 slave mỗi cái), Redis, Memcache, Solr shard; 6 kỹ sư. - 10/2012: khoảng 4 lần so với tháng 1: 180 web e…
- Working with PostgreSQL Bài tóm tắt · Zerodha · 2021
…ịch) tự host trên EC2: hàng trăm tỷ dòng, gần 20 TB, 4 node shard (2021). HA bằng failover replica đơn giản; backup bằng snapshot đĩa AWS. - Workload đặc biệt: 99% lượt ghi diễn ra…
- Maximum Warp: Building Migrations for Slack Enterprise Grid Bài tóm tắt · Slack · 2017
…h dữ liệu Slack: mọi dữ liệu của một team nằm trên cùng một shard MySQL , băm theo ID 64-bit của team. Dàn tải tốt, nhưng khó với dữ liệu vượt ranh giới một team. - Enterprise Grid…
- Scaling Etsy Payments with Vitess: Part 1 – The Data Model Bài tóm tắt · Etsy · 2023
…ển 23 bảng, hơn 40 tỉ dòng, từ bốn database thanh toán chưa shard vào một môi trường shard do Vitess quản lý. Vitess đã quản lý hạ tầng DB từ trước, nhưng đây là lần đầu dùng vinde…
- Diving into Uber's cutting-edge data infrastructure Bài tóm tắt · Onehouse · 2024
…deploy/restart cụm; nhiều bản sao dữ liệu; thêm replica cho shard nóng; erasure coding và tiered storage cho dữ liệu cũ. - Hiệu năng: reader vector hoá, nested column, predicate pu…
- 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.
- How Figma's databases team lived to tell the scale Bài tóm tắt · Figma · 2024
…băng ; - mô hình quan hệ phức tạp không hợp NoSQL. - Tự xây shard ngang trên RDS Postgres, nhưng chỉ một tập tính năng hẹp. Ví dụ không hỗ trợ transaction nguyên tử xuyên shard. -…
- Scaling Datastores at Slack with Vitess Bài tóm tắt · Slack · 2020
…u bằng LAMP. Mọi dữ liệu trên MySQL, gồm ba loại cluster: - Shards chứa dữ liệu khách hàng, shard theo workspace id : mọi dữ liệu của một workspace nằm trên một shard. - Metadata đ…
- Hạ tầng tìm kiếm Chủ đề Thành viên
Lúc đầu, tìm kiếm là LIKE trên database hoặc một thư viện (Lucene) nhúng trong app. Khi dữ liệu và tính năng tăng, search thành một hệ có trạng thái riêng, khác database ở mấy điểm:
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- 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…
- 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:
- 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:
- Scaling Prometheus to billions of samples a second Bài tóm tắt · Hudson River Trading · 2021
…ột instance, một instance "global" gom một phần dữ liệu) và sharding (gom lại cũng qua federation). Một instance mỗi DC hợp với môi trường giao dịch phân tán, nhưng không hợp với m…
- 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:
- Độ 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.
- Xác thực và phân quyền (authn/authz) Chủ đề Thành viên
Ở monolith, mỗi dữ liệu thường chỉ có một đường vào, nên kiểm tra quyền nằm ngay đó: một hàm hasaccess?, một API mỗi resource. Khi hệ thống tách thành nhiều service, nhiều client, nhiều loại token, cả hai nửa đều vỡ:
- Redesigning Workers KV for increased availability and faster performance Bài tóm tắt · Cloudflare · 2025
…R2 và Durable Objects), có sẵn chuyên môn và tự động hoá. - Shard nhiều cụm , mỗi cụm nhân 3, nhất quán mạnh trong shard; nhiều cụm thay vì một cụm khổng lồ để thu nhỏ blast radius…
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Query planner và hiệu năng truy vấn Chủ đề Thành viên
Database quan hệ không chạy SQL theo đúng cách nó được viết. Query planner chọn một plan (dùng index nào, join kiểu gì: nested loop, merge, hash; dừng sớm khi có LIMIT hay không) dựa trên thống kê về dữ liệu: số dòng,…
- Failing to Auto Scale Elasticsearch in Kubernetes Bài tóm tắt · Zalando · 2024
…Pod rải qua mọi AZ; Elasticsearch bật zone awareness để rải shard theo AZ. - Giờ cao điểm buổi sáng tải gấp khoảng 3 lần , nên họ scale theo lịch bằng một bộ cronjob khá phức tạp (…
- 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…
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- 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…
- 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,…
- Avoiding Double Payments in a Distributed Payments System Bài tóm tắt · Airbnb · 2019
…key, bảng thông tin idempotency luôn đọc/ghi trên master đã shard , gộp transaction bằng Java lambda, phân loại lỗi retryable/non-retryable. - Mỗi request chia ba pha : Pre-RPC (gh…
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- Timestone: Netflix's High-Throughput, Low-Latency Priority Queueing System Bài tóm tắt · Netflix · 2022
…ndex phụ trong bộ nhớ cho dequeue theo filter) nằm cùng một shard nhờ hash tag. Gần như mọi thao tác là Lua script (Redis chạy nguyên tử). Mọi API đổi trạng thái là idempotent. - I…
- 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…