Tìm kiếm
40 kết quả cho “sharding theo user”. 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".
- Geosharded Recommendations Part 1: Sharding Approach Bài tóm tắt · Tinder · 2019
…https://medium.com/tinder/geosharded-recommendations-part-1-sharding-approach-d5d54e0ec77a) Sheet trỏ tới phần 3 (consistency); wiki đọc phần 1 (cách chia shard). Phần 2: ; phần 3:…
- 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…
- 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…
- 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…
- Database-per-User Architecture With Isolated Application Environments Bài tóm tắt · Neon · 2024
Bài trước trong loạt: database-per-user với môi trường ứng dụng dùng chung (một bản ứng dụng nói chuyện với DB riêng của từng khách). Bài này: môi trường ứng dụng cô lập, mỗi khách một bản sao toàn bộ hệ thống.
- How we scaled reads on the Twitter Users Database Bài tóm tắt · Twitter · 2023
…lớn nhất thế giới, được xây trên Gizzard , chính framework sharding MySQL từng dùng cho tweet năm 2010–2013 (, ). Gizzard có những tính năng riêng như quorum read. - Theo thời gia…
- YouTube Architecture Bài tóm tắt · YouTube · 2007
…video được ưu tiên, tính năng mạng xã hội sang cụm kém hơn. Sharding giảm 30% phần cứng và replica lag về 0. - Data center: từ managed hosting (sống bằng thẻ tín dụng) sang colocat…
- Working with PostgreSQL Bài tóm tắt · Zerodha · 2021
…allel worker bằng số core để gom dữ liệu nhiều partition. - Sharding bằng postgres fdw , theo năm tài chính: loại Citus vì phải thêm cột reference ID vào mọi bảng và viết lại hàng…
- How WhatsApp Grew to Nearly 500 Million Users, 11,000 cores, and 70 Million Messages a Second Bài tóm tắt · WhatsApp · 2014
465 triệu user/tháng; 19 tỉ tin vào và 40 tỉ tin ra mỗi ngày; 600 triệu ảnh, 200 triệu voice, 100 triệu video mỗi ngày.
- Maximum Warp: Building Migrations for Slack Enterprise Grid Bài tóm tắt · Slack · 2017
Mô hình 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.
- Scaling Pinterest - From 0 To 10s Of Billions Of Page Views A Month In Two Years Bài tóm tắt · Pinterest · 2013
…đúng với dữ liệu không có giá trị tiền bạc). Clustering hay sharding - Clustering (Cassandra, Membase, HBase: dữ liệu tự phân phối, tự di chuyển, node nói chuyện với nhau) theo kin…
- Similarity Engine at eBay Bài tóm tắt · eBay · 2023
eBay (12/2022) có khoảng 134 triệu người dùng và 1,7 tỉ listing đang hoạt động. Tìm kiếm theo từ khoá vấp từ đồng âm, query đuôi dài, ý định người dùng; team CoreAI dựng một engine ANN để tìm listing giống nhau theo…
- Geosharded Recommendations Part 2: Architecture Bài tóm tắt · Tinder · 2019
Phần 1 đã chốt thuật toán chia geoshard trên S2 và đóng gói thành một microservice nội bộ. Phần 2 trả lời ba câu hỏi triển khai: "shard" cụ thể là gì trong Elasticsearch, cluster cần cỡ nào, và cân tải ra sao.
- Geosharded Recommendations Part 3: Consistency Bài tóm tắt · Tinder · 2019
Sau khi shard theo địa lý, có hai kho dữ liệu phải khớp nhau:
- Scaling Datastores at Slack with Vitess Bài tóm tắt · Slack · 2020
…y đổi chính - Cân nhắc "sửa tại chỗ hay thay thế": - Tự xây sharding linh hoạt trong webapp đã được prototype, nhưng logic app dính chặt vào cách lưu dữ liệu; cách này cũng không g…
- 5-year Evolution of Ele.me's Transaction System - Part 2 Bài tóm tắt · Ele.me · 2020
DB đơn hàng: 1 primary MySQL + 5 secondary + 1 node cho MHA. Không chịu được tải đột biến: nếu phòng kinh doanh không báo trước khuyến mãi thì secondary sập và chỉ còn biết chuyển qua lại giữa các DB.
- How Figma's databases team lived to tell the scale Bài tóm tắt · Figma · 2024
Stack DB của Figma tăng gần 100 lần từ 2020. Cuối 2022 đã có cache, read replica và khoảng 12 DB tách dọ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:
- How we modified our infrastructure to deploy an EU data center Bài tóm tắt · Asana · 2020
Khách hàng doanh nghiệp muốn chọn nơi đặt dữ liệu; Asana mở hạ tầng ở châu Âu (12/2019).
- 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:
- Load test và kiểm chứng capacity Chủ đề Thành viên
Trước một mốc tải chưa từng gặp (ra mắt game, tính năng mới gửi push toàn quốc, mùa giải, tăng trưởng nhanh), cần biết hệ chịu được bao nhiêu, cái gì gãy trước, và cần bao nhiêu máy. Test từng service riêng không đủ vì…
- Độ 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.
- 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ả…
- 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…
- 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…
- 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:
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- 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…
- 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ừ…
- 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…
- WhatsApp Công ty Thành viên
WhatsApp là ca hiếm: blog kỹ thuật gần như chỉ kể hai giai đoạn, và hai giai đoạn ấy giải hai bài khác hẳn nhau. Giai đoạn Erlang (2011–2014) là câu chuyện tối ưu một hệ nhỏ người: năm 2012, một server FreeBSD + Erlang…
- 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…
- Dropbox Công ty Thành viên
Dropbox luôn là hybrid: metadata ở data center riêng, nội dung file trên S3. Ở ~500 PB họ tự xây Magic Pocket, theo Dropbox vì hiệu năng và unit economics . Cái giá kèm theo là phải tự dựng cả backbone và edge network .…
- October 2024 queue retrospective Bài tóm tắt · Inngest · 2024
Inngest chạy durable workflow cho khách; lõi là một queue đa tenant có flow control theo key do user đặt. Tháng 10/2024 họ nâng cấp liên tục; kết quả cuối tháng là P95 latency thực thi khoảng 50 ms với hàng chục nghìn…
- Upgrading a 56TB database that's growing at 250GB per day with (nearly) no downtime Bài tóm tắt · Trigger.dev · 2026
Một cụm Aurora Postgres khoảng 56 TB: bảng run 29,4 TB, các bảng liên quan tới run 25,4 TB, dữ liệu control plane (tổ chức, project, billing, deploy) chỉ 1,23 TB. Tăng 250 GB/ngày.
- Meta's Infrastructure Evolution and the Advent of AI Bài tóm tắt · Meta · 2025
Facebook khởi đầu trên LAMP (Linux, Apache, MySQL, PHP). Đến 2025 phục vụ hơn 3,4 tỷ người.