Tìm kiếm
40 kết quả cho “master shard”. Tìm không phân biệt dấu.
- Sharding Pinterest: How we scaled our MySQL fleet Bài tóm tắt · Pinterest · 2015
…rash với họ). - Bắt đầu 8 server EC2, mỗi server một MySQL, master-master sang máy backup; production chỉ đọc/ghi master ("đừng bao giờ đọc slave trong production"). - 4.096 shard…
- 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.
- Sharding Cash Bài tóm tắt · Square · 2018
…, giữ đồng bộ bằng replay binlog, rồi MigrateServedFrom ... MASTER chuyển traffic master. Lúc đó lệnh không đảo ngược được nếu không mất dữ liệu (về sau Vitess đã cho đảo ngược). D…
- Cloud Native MySQL Sharding with Vitess and Kubernetes Bài tóm tắt · Vitess · 2015
…g dòng giữa bản gốc và bản chép. 4. Lệnh migrate: tắt ghi ở master cũ, chờ master mới nhận nốt sự kiện, bật ghi ở master mới; theo bài thường chỉ khoảng một giây không ghi được. 5.…
- Geosharded Recommendations Part 2: Architecture Bài tóm tắt · Tinder · 2019
…mỗi host tốn thêm năng lực ghi và RAM. - Kiến trúc cuối: 3 master node; một ASG chỉ gồm coordinating node (nhận mọi request), một ASG gồm data node. Mỗi data node giữ ngẫu nhiên 4…
- How we modified our infrastructure to deploy an EU data center Bài tóm tắt · Asana · 2020
…rọn trong một database, mỗi DB chứa nhiều domain), cộng một master shard lưu user và quan hệ thành viên domain. Mọi DB và service ở một vùng AWS tại Mỹ; service được viết với giả đ…
- Avoiding Double Payments in a Distributed Payments System Bài tóm tắt · Airbnb · 2019
…empotency 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 : P…
- Scaling Pinterest - From 0 To 10s Of Billions Of Page Views A Month In Two Years Bài tóm tắt · Pinterest · 2013
…ự báo 5 năm: 8 máy vật lý × 512 DB, mọi DB có mọi bảng. Mỗi master chạy multi-master với một bản ở AZ khác. Khi một DB nặng lên: dựng slave, đổi ánh xạ trong code, vài phút ghi vẫn…
- How We Replaced Our Data Pipeline With Zero Downtime Bài tóm tắt · Twilio · 2014
…đọc trước, ghi sau; - tránh trùng AUTO INCREMENT khi cả hai master cùng nhận ghi: shard0 sinh số lẻ, shard1 số chẵn ( auto increment offset / increment ), rồi cắt replication; - xo…
- Working with PostgreSQL Bài tóm tắt · Zerodha · 2021
…dù đã có lớp cache phía trước. - Nhiều năm chỉ chạy một cặp master-replica (32 core, 64 GB RAM) chứa hàng tỷ dòng, tới khi dữ liệu tăng vọt; chuyển sang nhiều shard đầu năm 2020. T…
- YouTube Architecture Bài tóm tắt · YouTube · 2007
…nhỏ, cache nhiều tầng xuyên colo). - Database: một server → master + nhiều read slave → partition → shard theo user . Slave đơn luồng tụt sau master; tạm thời tách hai cụm: pool ph…
- 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:
- 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.
- 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:
- 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:
- 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,…
- 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".
- Độ 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.
- 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:
- 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…
- 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:
- 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…
- 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.
- 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.
- 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…
- 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…
- Evaluating MySQL Parallel Replication Part 3: Benchmarks in Production Bài tóm tắt · Booking.com · 2015
…n" (Jean-François Gagné); phần trước: (cơ chế, intermediate master) → ; phần tiếp: . Các annex "Under the Hood" không ingest. Sheet trỏ tới annex của phần 4. Đọc qua trình duyệt (M…
- Pinterest Công ty Thành viên
Năm 2015 Pinterest sinh sẵn nội dung cho mọi user và lưu trong HBase, cách đã đưa họ tới 100 triệu MAU nhưng tốn lưu trữ và khó thử nghiệm. Họ xây 9 hệ thống C++/RocksDB để sinh feed lúc đọc . Phía dưới là tầng cache…
- How We Partitioned Airbnb's Main Database in Two Weeks Bài tóm tắt · Airbnb · 2015
…cation của MySQL thay cho code migrate: tạo replica message-master từ master chính, gắn replica tầng hai message-replica , rồi promote message-master thành master độc lập (tính năn…
- Booking.com Công ty Thành viên
Booking.com scale đọc bằng hàng nghìn slave MySQL (2014). Crash-safe replication của MySQL 5.6 tải lại binlog từ master sau mỗi lần khởi động, đè lên card mạng của master; họ đặt Binlog Server cục bộ trên slave để phụ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…
- Asana Công ty Thành viên
Phần mềm quản lý công việc; hai nguồn trong wiki đều về lớp dữ liệu. Asana shard theo domain (tenant) từ 2015, nhưng một phần dữ liệu dùng chung cho mọi workspace vẫn nằm trong một MySQL trên RDS. Mùa hè 2019, ba lần…
- Scaling Our Geo-Search Service For 10x Load Bài tóm tắt · Gojek · 2022
…p . Thay đổi chính - Tách đọc/ghi trên Redis Cluster (multi-master, mỗi master một shard, nhiều replica). Lọc geo chạy bằng Lua EVAL , nhưng EVAL không được coi là lệnh chỉ đọc nên…
- Introducing Espresso - LinkedIn's hot new distributed document store Bài tóm tắt · LinkedIn · 2015
…DBA; cấp thêm shard là việc tay; failover giữa data center (master/slave) cần DBA và có downtime; phần cứng và license đắt. - Năm 2011 team Distributed Data Systems chốt yêu cầu: s…
- 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 .…
- How We Built a Logging Stack at Grab Bài tóm tắt · Grab · 2019
…ible. Ban đầu mỗi node làm cả bốn vai (ingest, coordinator, master, data) và dùng ingest node thay Logstash cho đơn giản; nhìn lại thì vai trò trộn lẫn làm khó điều tra (mất master…
- MemSQL Architecture - The Fast (MVCC, InMem, LockFree, CodeGen) And Familiar (SQL) Bài tóm tắt · MemSQL · 2012
…hần log còn lại. Chỉ ghi tuần tự. - Replication: theo dòng, master/nhiều slave, đồng bộ hoặc bất đồng bộ (vài ms trễ). Thêm slave online bằng cách gửi snapshot rồi replay log, khớp…
- New Tweets per second record, and how! Bài tóm tắt · Twitter · 2013
…blic API). - Tweet lưu trên MySQL shard theo thời gian, một master : hot spot đọc/ghi, phải tạo DB mới ngày càng nhanh. - "Ném máy vào vấn đề"; code bị hy sinh tính dễ đọc để lấy h…
- Why Uber Engineering Switched from Postgres to MySQL Bài tóm tắt · Uber · 2016
…nhiều ở các bản sau. - Hạ tầng lúc đó: colocation ở bờ Tây (master + replica), thêm bờ Đông cho disaster recovery. Thay đổi chính (năm hạn chế Uber nêu về Postgres) 1. Write amplif…
- YouTube Công ty Thành viên
Nguồn duy nhất trong wiki là bản tóm tắt của HighScalability (2007) cho một talk của YouTube, nguồn thứ cấp với số liệu 2006–2007: 100 triệu lượt xem/ngày với một nhóm rất nhỏ, vòng lặp tìm và sửa nút thắt nhiều lần mỗi…