Tìm kiếm
40 kết quả cho “node partition”. Tìm không phân biệt dấu.
- Scaling LinkedIn's Hadoop YARN cluster beyond 10,000 nodes Bài tóm tắt · LinkedIn · 2021
…g/2021/scaling-linkedin-s-hadoop-yarn-cluster-beyond-10-000-nodes) Bối cảnh - Cụm Hadoop gấp đôi mỗi năm ; cụm lớn nhất khoảng 10.000 node năm 2021. HDFS (một NameNode giữ mọi meta…
- 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:
- Scaling Kubernetes to 7,500 nodes Bài tóm tắt · OpenAI · 2021
…gốc](https://openai.com/research/scaling-kubernetes-to-7500-nodes) Phần tiếp của . Bối cảnh - Một cụm duy nhất 7.500 node , chọn vì hạ tầng đơn giản cho phép team nghiên cứu scale…
- FollowFeed: LinkedIn's Feed Made Faster and Smarter Bài tóm tắt · LinkedIn · 2016
…L gồm cả lọc lẫn relevance, broker fan-out tới mọi searcher node rồi gộp top N. - Lý do thay Sensei (theo LinkedIn): phải giữ toàn bộ inverted index trong RAM nên chi phí phần cứng…
- Introducing Espresso - LinkedIn's hot new distributed document store Bài tóm tắt · LinkedIn · 2015
…istributed Data Systems chốt yêu cầu: scale ngang bằng thêm node, đọc-sau-ghi + đọc eventual, secondary index luôn khớp dữ liệu, transaction trong một partition, tự chịu lỗi máy, s…
- 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
…rver (mỗi máy ~1 triệu điện thoại), ~250 server multimedia; node DB 512 GB RAM, node thường 64 GB; hơn 11.000 core chạy Erlang. Thay đổi chính so với 2012 - Bỏ mục tiêu tối đa kết…
- Building a New Rust Driver for ScyllaDB's DynamoDB API – with 58% More Throughput Bài tóm tắt · ScyllaDB · 2026
…ác với ScyllaDB. Benchmark do chính họ chạy trên cụm nhỏ (3 node i3.xlarge); mọi con số là theo ScyllaDB. Bối cảnh - Alternator là API tương thích DynamoDB của ScyllaDB. Dev Rust t…
- 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
…cho index trong CockroachDB: không có điều phối trung tâm (node nào cũng đọc/ghi được); không có cấu trúc lớn trong RAM (trạng thái nằm ở storage, không phải "làm ấm" khi khởi độn…
- How Discord Stores Trillions of Messages Bài tóm tắt · Discord · 2023
…es) Bối cảnh - Tiếp nối . Cụm cassandra-messages tăng từ 12 node (2017) lên 177 node, hàng nghìn tỷ tin nhắn (đầu 2022). - Hệ thống "high-toil": on-call bị gọi liên tục, latency kh…
- Building Self-driving Kafka clusters using open source components Bài tóm tắt · Slack · 2022
…ối đa. Quy mô (2022): khoảng 0,7 PB trên 10 cụm , hàng trăm node, hàng triệu message/giây, 6,5 Gbps lúc cao điểm; chi phí chủ yếu là phần cứng và mạng . Thay đổi chính - Provision…
- Working with PostgreSQL Bài tóm tắt · Zerodha · 2021
…iao dịch) tự host trên EC2: hàng trăm tỷ dòng, gần 20 TB, 4 node shard (2021). HA bằng failover replica đơn giản; backup bằng snapshot đĩa AWS. - Workload đặc biệt: 99% lượt ghi di…
- Ideal isn't real: Stress testing CockroachDB's resilience Bài tóm tắt · Cockroach Labs · 2025
…roughput, latency, tỉ lệ lỗi qua từng giai đoạn. Cụm thử 15 node, nhiều region, bản 25.1. Thay đổi chính (các giai đoạn và cơ chế được nêu) - Baseline: chỉ có tải TPC-C (mỗi giao d…
- Wix Inbox Journey: 3 Approaches for Zero Downtime Database Migration Bài tóm tắt · Wix · 2021
…không đều về traffic lẫn dung lượng, nên tạo hot spot , có node crash; - mẫu truy cập mới không dùng đủ khoá chính, buộc phải thêm secondary index rồi materialized view; - rất ít…
- How GitHub Docs' new search works Bài tóm tắt · GitHub · 2023
…s.github.com trước đây là index trong bộ nhớ của tiến trình Node.js (Express): cào hết văn bản (tiêu đề, heading, breadcrumb, nội dung), lưu ngay trong repo Git, sinh sẵn index ser…
- Lessons learned from running GraphQL at scale Bài tóm tắt · Dream11 · 2021
Dream11 từ 300.000 người dùng (2015) lên hơn 110 triệu (2021), chuyển sang microservice. Khi số service tăng, frontend khó tự gom dữ liệu từ nhiều service, nên năm 2017 dựng một tầng GraphQL (Express.js) đứng trước toàn…
- 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.
- 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:
- 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…
- 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:
- 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.
- 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".
- 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…
- Độ 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.
- 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…
- 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:
- 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:
- 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ì…
- 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.
- 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.
- 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…
- 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…
- Vector search và index ANN Chủ đề Thành viên
Search ngữ nghĩa, gợi ý và RAG quy về tìm các vector (embedding vài trăm tới vài nghìn chiều) gần một vector query. Vector không có thứ tự tự nhiên, nên B-tree hay inverted index không dùng được; ở quy mô lớn phải 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ố…
- 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ự…
- Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) Chủ đề Thành viên
Một quỹ định lượng hay công ty market making sống bằng vòng nghiên cứu: đặt giả thuyết → lấy dữ liệu → tạo feature → train model hay dựng tín hiệu → backtest/mô phỏng → đưa vào giao dịch thật → lặp lại. Theo Optiver, độ…
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi replica…
- From Chaos to Control: Addressing Shard Distribution Challenges in M3DB with Subclusters Bài tóm tắt · Uber · 2026
…ỗi shard có RF bản sao; một thuật toán placement quyết định node nào giữ shard nào. - Thuật toán cũ chỉ có một ràng buộc cứng: hai bản sao của một shard không được nằm cùng một iso…