Tìm kiếm
40 kết quả cho “shard theo team”. Tìm không phân biệt dấu.
- 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".
- 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…
- Cloud Native MySQL Sharding with Vitess and Kubernetes Bài tóm tắt · Vitess · 2015
…i gốc](https://vitess.io/blog/2015-10-06-cloud-native-mysql-sharding-with-vitess-and-kubernetes/) Bài của engineer YouTube giới thiệu Vitess 2.0 (khi đó còn alpha) chạy trên Kubern…
- 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…
- 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. -…
- Online index migration and shard-scaling in OpenSearch with AOSC Bài tóm tắt · Atlassian · 2026
…tenant lớn khỏi index dùng chung (noisy neighbor), tăng số shard khi tenant lớn lên, bỏ field (bỏ vector embedding không cần thì nhanh hơn rõ), đổi text sang keyword , làm phẳng f…
- Tracing phân tán và log theo request Chủ đề
Khi một request đi qua hàng chục service, metric của từng service cho biết có chậm, log của từng service cho biết từng mảnh; không cái nào trả lời "request này chậm vì đâu" hay "trang này tốn bao nhiêu". Tracing phân…
- Building a fault-tolerant metrics storage system at Airbnb Bài tóm tắt · Airbnb · 2026
…ượng và tốc độ series, số rule, chu kỳ đánh giá). - Shuffle sharding: mỗi tenant chỉ ghi vào một tập con node storage và query chỉ dùng một tập con query worker; một tenant bị tấn…
- How to Pitch Apache Kafka Bài tóm tắt · Zillow · 2020
…ưu offset trong chính nó. - Kinesis giới hạn 5 lần đọc/giây/shard , consumer chia nhau throughput nên phải biết về nhau (enhanced fan-out tốn thêm tiền); Kafka chỉ bị giới hạn bởi…
- 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 đ…
- Similarity Engine at eBay Bài tóm tắt · eBay · 2023
…node lỗi thì chạy lại chỗ khác; dữ liệu embedding được chia shard theo shard key hoặc thuật toán phân cụm, mỗi shard một index HNSW hoặc ScaNN. Shard là đơn vị scale; số shard tự c…
- 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.
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- 5-year Evolution of Ele.me's Transaction System - Part 2 Bài tóm tắt · Ele.me · 2020
…t số API mở quá "thô" sinh ra SQL rất kém. Thay đổi chính - Shard DB và bảng (9/2015 → 3/2016) , do team DAL dẫn dắt: hai chiều, mỗi chiều 120 shard , định tuyến được theo user ID,…
- Scalability and Load Testing for VALORANT Bài tóm tắt · Riot Games · 2020
…ời cùng lúc; mục tiêu đặt ra là 2 triệu người đồng thời mỗi shard , dựa trên số liệu League và kế hoạch mở nhiều region. - Test từng service không đủ vì một thao tác của người chơi…
- Etsy's Journey to TypeScript Bài tóm tắt · Etsy · 2021
Etsy hơn 16 năm tuổi; monorepo có hơn 17.000 file JavaScript trải qua nhiều thế hệ site. Khó biết phần nào là thực hành tốt, phần nào là nợ kỹ thuật; JavaScript ít ràng buộc nên dùng thư viện sai dễ xảy ra. Một năm rưỡi…
- 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…
- Research at scale: Orchestrating ML for systematic trading Bài tóm tắt · Optiver · 2025
Theo Optiver, giao dịch hệ thống dựa vào sức mạnh của "cỗ máy nghiên cứu": thí nghiệm hôm nay thành model, tín hiệu, kiểm tra rủi ro và hạn mức vị thế ngày mai. Vòng nghiên cứu: đặt giả thuyết → chạy thí nghiệm → đánh…
- 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…
- 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ả…
- 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:
- 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.
- 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:
- 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…
- Độ 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.
- 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:
- 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…
- 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:
- 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ỡ:
- 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…
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thêm…
- 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.
- Slack Công ty Thành viên
Slack bắt đầu bằng LAMP và giữ PHP vì môi trường của nó (mỗi request trạng thái sạch, vòng lặp sửa–tải lại). Họ cải tiến dần bằng HHVM và Hack thay vì viết lại . Tầng dữ liệu đi từ MySQL active-active shard theo…
- Zillow Công ty Thành viên
Zillow cho thấy một công ty dữ liệu đi từ ứng dụng web có cache tự làm sang nền tảng dữ liệu, ML và thí nghiệm dùng chung. Năm 2012 các sản phẩm mới đã chạy trên AWS: nền tảng website cho môi giới trên WordPress dùng…
- Etsy Công ty Thành viên
Etsy shard MySQL từ khoảng 2010 bằng ORM tự viết: gán shard ngẫu nhiên, lưu ánh xạ trong một index DB, thành điểm hỏng chung. Từ 2018 họ chuyển sang Vitess mà không dời dữ liệu (vindex lai: SQLite cho ID cũ, hash cho ID…
- Uber Công ty Thành viên
Một vòng đủ: monolith → microservices → tổ chức lại microservices. Năm 2012–2013 Uber có hai monolith; khi lên hàng trăm kỹ sư thì tách. Lý do chủ yếu là tổ chức. Năm 2015 họ có 500+ service và phải chuẩn hoá contract…
- 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ừ…
- Stack Overflow Công ty Thành viên
Phản ví dụ nên đọc sớm cho niềm tin "lớn thì phải scale out". Năm 2009, với 16 triệu page view mỗi tháng, Stack Overflow chạy hai web server và một SQL Server, chạm giới hạn thì nâng RAM; theo Jeff Atwood, phần cứng rẻ…
- Airbnb Công ty Thành viên
Airbnb chuyển từ một ứng dụng Rails khổng lồ sang SOA, và lộ ra chi phí test: deep integration test cho mọi service không scale, nên họ chuyển sang tháp test + CD có canary analysis . Năm 2025 với ba trụ sản phẩm, data…