Tìm kiếm
40 kết quả cho “database proxy”. Tìm không phân biệt dấu.
- How Stripe's document databases supported 99.999% uptime with zero-downtime data migrations Bài tóm tắt · Stripe · 2024
…hó — [bài gốc](https://stripe.dev/blog/how-stripes-document-databases-supported-99.999-uptime-with-zero-downtime-data-migrations) Bối cảnh - Stripe chọn MongoDB từ 2011 (Atlas chưa…
- Beyond synthetic testing: Capturing and replaying real database workloads at Airbnb Bài tóm tắt · Airbnb · 2026
…cture/beyond-synthetic-testing-capturing-and-replaying-real-database-workloads-at-airbnb/) Bối cảnh - Fleet MySQL-compatible của Airbnb (2026): hàng trăm cụm , hàng nghìn use case,…
- 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".
- Partitioning GitHub's relational databases to handle scale Bài tóm tắt · GitHub · 2021
…/engineering/infrastructure/partitioning-githubs-relational-databases-scale/) Bối cảnh - Hơn 10 năm trước GitHub bắt đầu bằng Rails + một MySQL . - Các bước tiến hoá trước 2019: tá…
- How Figma's databases team lived to tell the scale Bài tóm tắt · Figma · 2024
…Nâng cao — [bài gốc](https://www.figma.com/blog/how-figmas-databases-team-lived-to-tell-the-scale/) Bối cảnh - Stack DB của Figma tăng gần 100 lần từ 2020 . Cuối 2022 đã có cache,…
- The growing pains of database architecture Bài tóm tắt · Figma · 2023
…ốc](https://www.figma.com/blog/how-figma-scaled-to-multiple-databases/) Bối cảnh - 2020: thêm tính năng, chuẩn bị ra sản phẩm thứ hai, user tăng. Traffic DB tăng khoảng 3 lần mỗi n…
- Unlocking Horizontal Scalability in Our Web Serving Tier Bài tóm tắt · Airbnb · 2016
…vài service Java; dữ liệu lõi trong MySQL trên RDS, đã tách database theo chức năng năm 2015. - MySQL community dùng mô hình một thread mỗi kết nối. Số kết nối từ app server tăng t…
- How we scaled reads on the Twitter Users Database Bài tóm tắt · Twitter · 2023
…nfrastructure/2023/how-we-scaled-reads-on-the-twitter-users-database) Bối cảnh - URS (User Reservation System) , theo Twitter là một trong những hệ thống loại này lớn nhất thế giới…
- Migrating Etsy's database sharding to Vitess Bài tóm tắt · Etsy · 2026
…[bài gốc](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,…
- How We Built Fly Postgres Bài tóm tắt · Fly.io · 2022
…thật nằm ở us-east-1 , phần chạy ở edge là cache. Khách xin database từ ngày đầu; họ từ chối hơn 300 ngày, có thử Redis dùng chung ("bị nguyền") và cân nhắc CockroachDB managed. -…
- Analysis of recent downtime & what we're doing to prevent future incidents Bài tóm tắt · Asana · 2019
…ệu dùng chung cho mọi team/workspace của user nằm trong một database dùng chung (MySQL trên RDS, cấu hình HA). - Ba lần downtime vì database này: ít nhất 92 phút (29/7/2019), 51 ph…
- Alibaba Upgrades Dubbo3 to Fully Replace HSF2 Bài tóm tắt · Alibaba · 2023
Sau khi đưa toàn bộ lên cloud, Alibaba muốn stack microservice nội bộ chạy trên middleware mã nguồn mở thay cho framework RPC nội bộ HSF (và Dubbo2 ở Alibaba Cloud).
- Scaling Datastores at Slack with Vitess Bài tóm tắt · Slack · 2020
Slack bắt đầu bằng LAMP. Mọi dữ liệu trên MySQL, gồm ba loại cluster:
- 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.
- 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…
- 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…
- 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ả…
- 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:
- 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:
- 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:
- 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…
- 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,…
- Batching và khấu hao round-trip Chủ đề Thành viên
Nhiều nút thắt không nằm ở việc mỗi thao tác tốn bao nhiêu công, mà ở chi phí cố định trả cho mỗi thao tác: một round-trip mạng, một lần fsync, một PUT lên object storage, một syscall, một transaction. Khi chi phí 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:
- 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…
- 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 ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- 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.
- Độ 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:
- 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…
- Alibaba Công ty Thành viên
Database của Alibaba đi qua ba giai đoạn, đều do đỉnh tải Double 11 dẫn dắt: thương mại (IBM/Oracle/EMC, 2005–2009) → "De-IOE" sang mã nguồn mở với middleware TDDL và AliSQL (2010–2015) → tự phát triển X-DB (từ 2016).…
- 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…
- 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…
- The history of Postgres sharding Bài tóm tắt · PlanetScale · 2026
Vì sao MySQL đi trước: thời LAMP, nhiều công ty thành công dùng MySQL nên công cụ shard và online schema change (gh-ost, Vitess) phát triển sớm hơn.
- 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 .…
- Redesigning Workers KV for increased availability and faster performance Bài tóm tắt · Cloudflare · 2025
…/giây; kích thước trung vị 288 byte . Với object dưới 1 KB, database hiệu quả và rẻ hơn object storage. Dùng một distributed database đã chạy production (cũng là nền của R2 và Dura…
- 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ẻ…
- Stripe Công ty Thành viên
Khoảng 2.000 shard MongoDB với hơn 40 kiểu bố trí; năm 2026 Stripe thay tự sửa dạng plugin bằng tìm đường (BFS rồi Dijkstra) trên state machine của shard, mô phỏng bằng chính code Temporal, giảm 30% số lần gọi người…