Tìm kiếm
38 kết quả cho “Hot row”. Tìm không phân biệt dấu.
- 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:
- 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.
- From Batch Snapshots to Near-Real-Time Data Bài tóm tắt · Doximity · 2026
…c](https://technology.doximity.com/articles/from-batch-snapshots-to-near-real-time-data) Bối cảnh - Doximity đã có pipeline batch chép định kỳ snapshot của DB ứng dụng vào warehous…
- A Decade of Evolution of Alibaba's Databases - Part 1 Bài tóm tắt · Alibaba · 2019
…Nhờ đó họ scale out được, tự thêm tính năng vào kernel (vá hot row cho tồn kho , throttle SQL, thread pool), và triển khai active-active xuyên thành phố . 3. 2016 trở đi, tự phát…
- Rediscovering Transaction Processing From History and First Principles Bài tóm tắt · TigerBeetle · 2024
Năm 1985, Jim Gray đề xuất đo OLTP bằng TPS và gắn TPS với giá thành mỗi transaction. "Transaction" chuẩn của ông không phải SQL transaction mà là DebitCredit: ghi nợ một tài khoản, ghi sổ kép, trả lời terminal. Mỗi…
- Netflix Billing Migration to AWS — Part III Bài tóm tắt · Netflix · 2016
…u bằng công cụ bên thứ ba; dựng môi trường test từ EBS snapshot của replica nhiều lần; chạy cùng Sqoop/ETL báo cáo trên cả hai DB theo cửa sổ thời gian; đếm dòng sau khi tạm dừng l…
- Nebula as a Storage Platform to Build Airbnb's Search Backends Bài tóm tắt · Airbnb · 2016
…, nhận cập nhật realtime từ Kafka, thao tác hàng loạt (snapshot, compact, nạp feature tính offline, thay cả cột), chi phí vận hành thấp. Thay đổi chính - Nebula : kho dữ liệu versi…
- Behind the Pins: Building Analytics Bài tóm tắt · Pinterest · 2014
8/2014 Pinterest ra bản 2 của công cụ analytics cho doanh nghiệp (analytics theo domain, profile, audience; phân theo quốc gia, ứng dụng; impression, click, repin).
- 25% or 6 to 4: The 11/6/23 Authentication Outage Bài tóm tắt · Discord · 2023
…sẽ vận hành khác cụm lớn (tăng replication factor, hoặc cụm hot-standby ở region khác, cái sau làm phức tạp mô hình nhất quán của xác thực). Vì sao - "Chịu được mất một zone" chỉ đ…
- Real-Time Indexing for Billions of Vectors: How we built fast, fresh vector indexing at scale in CockroachDB Bài tóm tắt · Cockroach Labs · 2025
Search ngữ nghĩa quy về tìm vector gần nhau (embedding vài trăm tới vài nghìn chiều). Vector không có thứ tự tự nhiên nên index truyền thống không dùng được; ở quy mô lớn phải dùng index xấp xỉ (ANN).
- Migrating millions of lines of code to TypeScript Bài tóm tắt · Stripe · 2022
…Jest, Webpack, Metro), chỉ sinh .tsx để sửa hàng loạt snapshot Jest; tắt tạm vài rule ESLint viết cho parser Flow. Đội sản phẩm test tay vì end-to-end test ít (bắt được lỗi bản dị…
- Centrifuge: a reliable system for delivering billions of events per day Bài tóm tắt · Segment · 2018
…g TB dữ liệu như với queue (thứ tự trong Kafka do producer chốt). - Mô hình dữ liệu: bảng jobs (payload trung vị 5 KB, tối đa 750 KB; khoá chính KSUID, chỉ một index) và bảng job s…
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- 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.
- 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".
- 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…
- Stream processing Chủ đề Thành viên
Khi batch hằng ngày hay hằng giờ không còn đủ tươi (chi tiêu quảng cáo phải dừng đúng lúc chạm ngân sách, dashboard MRR không được trễ 24 giờ, alert phải bắn khi contest sắp đầy), hệ phải tính liên tục trên luồng sự…
- 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ả…
- 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:
- 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…
- 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.
- 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ố…
- 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.
- 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).…
- Data Inlining in DuckLake: Unlocking Streaming for Data Lakes Bài tóm tắt · DuckDB Labs · 2026
…èn: vào bảng inlined trong catalog, kèm row id , begin snapshot , end snapshot để giữ time travel. - Xoá dòng còn inline: chỉ đặt end snapshot . Xoá dòng đã nằm trong Parquet: ghi…
- Active-Active Shared-Nothing Database Architecture Bài tóm tắt · CapitalOne · 2020
…ung chính - AASN khác high availability: HA có thể đạt bằng hot standby ở vùng khác (active/passive). Theo tác giả, AASN thường bị nhầm với HA. - Active/passive và brown-out: khi f…
- Figma Công ty Thành viên
Năm 2017, đợt spam đầu tiên chứng minh giá trị của rate limiter tự viết . Năm 2019 cả Figma vẫn chạy trên một DB instance theo nguyên tắc KISS, và họ đã nói cần DB scale ngang . Ví dụ kinh điển của lộ trình Postgres.…
- 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à…
- GRIT: a Protocol for Distributed Transactions across Microservices Bài tóm tắt · eBay · 2019
…đóng vai WAL; LogPlayer áp vào storage; storage hỗ trợ snapshot theo LSN; triển khai trên hai AZ. Bài học cho SWE - Hai trường phái giao dịch xuyên service: hạ tầng lo (2PC, GRIT)…
- 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 ().
- The Chubby lock service for loosely-coupled distributed systems Bài tóm tắt · Google · 2006
Trước Chubby, phần lớn hệ ở Google bầu primary bằng cơ chế tự chế hoặc cần người can thiệp sau mỗi lần hỏng. Chubby được thiết kế làm dịch vụ khoá thô (coarse-grained), ví dụ để bầu primary, không phải khoá ngắn hạn…
- Jepsen Công ty Thành viên
Jepsen là dự án kiểm thử độc lập về tính an toàn của database và hệ phân tán, không phải một công ty kể về hệ của mình; báo cáo 6/2020 áp công cụ Elle lên PostgreSQL một node và tìm ra chế độ "serializable" khô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ừ…
- TigerBeetle Công ty Thành viên
TigerBeetle là database chỉ cho OLTP kiểu debit/credit. Bài 2026 (bản viết của một talk) lập luận rằng scale là khả năng sống sót, rằng sharding thua scale dọc khi có tranh chấp, và đề xuất "diagonal scaling":…
- Herding elephants: Lessons learned from sharding Postgres at Notion Bài tóm tắt · Notion · 2021
…replication không theo kịp lượng ghi vào block ở bước snapshot ban đầu. Họ chuẩn bị sẵn audit log ngược để quay về monolith. 2. Backfill: khoảng 3 ngày trên máy 96 CPU, so version…
- From Fragile to Agile: Automating the fight against Flaky Tests Bài tóm tắt · Reddit · 2024
…cảnh - Project iOS của Reddit có hơn 20.000 test unit/snapshot và 2.500 UI test (2024), tăng nhanh trong hai năm; flaky test tăng theo. - Tác hại theo bài: không biết lỗi là thật…
- We replaced Redis with MySQL for inventory reservations, and it scaled Bài tóm tắt · Shopify · 2026
Giữ hàng chống bán quá số lượng (oversell protection):