Tìm kiếm
40 kết quả cho “hai data center”. Tìm không phân biệt dấu.
- The Great Unracking: Saying goodbye to the servers at our physical datacenter Bài tóm tắt · Stack Overflow · 2025
…ta center ở New Jersey quyết định đóng cửa, Stack Overflow phải rời đi trước 7/2025. Site public chuyển lên Google Cloud; Teams đã lên Azure từ 2023. Thay đổi chính - 2/7/2025: thá…
- Instagration Pt. 2: Scaling our infrastructure to multiple data centers Bài tóm tắt · Instagram · 2015
…lên 3 data center ở Mỹ. Ý chính: phân biệt dữ liệu global (phải replicate) và dữ liệu local (ví dụ job async chỉ dùng trong vùng). - Storage: PostgreSQL và Cassandra replicate xuyê…
- How we modified our infrastructure to deploy an EU data center Bài tóm tắt · Asana · 2020
…field hay dùng của master shard sang domain DB , hiếm khi phải gọi master shard. - Ràng buộc mới: mỗi session chỉ truy cập master shard và đúng một domain shard , nên một session…
- The great adventure of migrating Allegro infrastructure to new Data Center - DC5 Bài tóm tắt · Allegro · 2016
…mới để chuyển hơn 2.000 VM; - chỉ còn một hypervisor; - bỏ hai disk array đã chạy 8 năm. - Hậu cần: kiểm kê vật lý từng thiết bị; 30 chuyến xe, mỗi tuần 2 lần; thiết bị chở tới hô…
- 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.
- How Facebook deals with PCIe faults to keep our data centers running reliably Bài tóm tắt · Meta · 2021
…có công cụ tự động; tính tốc độ mong đợi từ khả năng của cả hai đầu link và so với hiện tại. Phần lớn sửa được bằng cắm lại linh kiện, nên thử trước khi đánh dấu hỏng. - Quy trình…
- Apache Hudi at Uber: Engineering for Trillion-Record-Scale Data Lake Operations Bài tóm tắt · Uber · 2026
…ủa Uber thì khác: dữ liệu thay đổi (vòng đời chuyến, trạng thái đơn, thuộc tính thiết bị), stream có tỉ lệ update cao, và cần xử lý tăng dần thay vì tính lại cả bảng. Uber tự làm H…
- Automating Periodic Data Transfer from an Operational Database to a Data Warehouse Bài tóm tắt · Allegro · 2024
…tabase-to-a-data-warehouse.html) Bài mô tả giải pháp ở mức khái niệm ("cần chỉnh theo nhu cầu"), không kèm số liệu production. Bối cảnh - Chạy truy vấn phân tích nặng trên DB vận h…
- Scaling data access by moving an exabyte of data to Google Cloud Bài tóm tắt · Twitter · 2022
…làm" không scale ; một framework cấu hình hoá biến việc mất hai tuần thành việc mất một giờ. Cùng tinh thần . - Hybrid hợp lý: phần serving vẫn on-prem, phần phân tích lên cloud. C…
- Open sourcing Brooklin: Near real-time data streaming at scale Bài tóm tắt · LinkedIn · 2019
…rorMaker (KMM) : mỗi cụm KMM chỉ nối một cặp cụm Kafka nên phải vận hành hàng chục tới hàng trăm cụm KMM; lỗi một partition làm hỏng cả pipeline; lệnh flush đồng bộ có thể làm pipe…
- Scaling Datastores at Slack with Vitess Bài tóm tắt · Slack · 2020
…outing nằm trong monolith "webapp". Mỗi shard có ≥2 MySQL ở hai data center, active-active (cả hai nhận ghi), replicate bất đồng bộ. - Ưu điểm: availability cao (lỗi thì thử bên ki…
- How Uber Scaled Data Replication to Move Petabytes Every Day Bài tóm tắt · Uber · 2026
…: lượng nhân bản mỗi ngày từ 250 TB lên 1 PB trong một quý. Hai nguyên nhân: năm 2022 Uber chuyển data lake sang active-passive để tiết kiệm, data center chính sinh 90% dữ liệu và…
- Three Basecamp outages. One week. What happened? Bài tóm tắt · Basecamp · 2020
…- Basecamp 3 và vài dịch vụ hỗ trợ (login, billing) chạy ở hai data center on-prem dư thừa, nối bằng hai đường mạng độc lập; nhiều ứng dụng khác của họ chạy trên cloud. Thay đổi c…
- GitHub Enterprise Cloud with data residency: How we built the next evolution of GitHub Enterprise using GitHub Bài tóm tắt · GitHub · 2024
…; dùng vùng của Azure thay vì tự xây data center. Kiến trúc hai bên gần giống nhau để giảm độ phức tạp, rủi ro và chi phí phát triển. - Một pipeline cho mọi target: vẫn mô hình dep…
- Twitter Sparrow tackles data storage challenges of scale Bài tóm tắt · Twitter · 2022
…rồi ghi liên tục vào BigQuery và Cloud Storage. - Pipeline phải phục vụ cả stream (dữ liệu tươi) lẫn dữ liệu lịch sử (báo cáo dài kỳ, vốn batch đơn giản và rẻ hơn). - Độ trễ từ hàn…
- A Brief History of Scaling LinkedIn Bài tóm tắt · LinkedIn · 2015
…ale riêng, gọi qua Java RPC. Search (Lucene) là service thứ hai, nhận dữ liệu từ graph. - Replica đọc: DB profile bị Leo dồn tải. Đầu tiên scale dọc (thêm CPU, RAM), sau đó thêm re…
- Image Migration to Google Cloud Platform Bài tóm tắt · trivago · 2024
…, đổi PHP sang Python, thêm pipeline sinh ID ảnh mới nhưng phải giữ bảng ánh xạ ID cũ ↔ mới vì vài team còn dùng ID cũ. Kết quả là ba phần phải nuôi: pipeline ở data center, pipeli…
- Disaster Recovery for Databases: High-availability Architecture of PolarDB-X Bài tóm tắt · Alibaba · 2026
…i rủi ro và bảng đánh đổi giữa các kiểu replication. Khung khái niệm - Bốn mức rủi ro : process (OOM, segfault; xác suất cao, ảnh hưởng một service) → máy (kernel panic, hỏng đĩa)…
- How Coinbase built a governed platform for internal operations Bài tóm tắt · Coinbase · 2026
…kend; team sản phẩm tự mở rộng được mà platform team không phải duyệt từng tính năng. - Umbrella service "Control Center": một điểm vào trước nhiều backend theo domain. Lớp chung l…
- The data platform cluster operator service for Hadoop cluster management Bài tóm tắt · Twitter · 2023
…hử nhánh khác khi task lỗi. Engine callback cập nhật trạng thái job; nếu DCO không sẵn lúc callback thì có tiến trình poll định kỳ trạng thái plan. - Thư viện hadoop-admin chứa log…
- The Story of Apollo – Amazon's Deployment Engine Bài tóm tắt · Amazon · 2014
…ce. Team ra tính năng nhanh hơn, nhưng deploy thành nút cổ chai : các bước tay làm chậm release và gây lỗi do con người. - Nhiều team tự tự động hoá deploy, nhưng việc này khó hơn…
- Netflix Billing Migration to AWS Bài tóm tắt · Netflix · 2016
…. - Ràng buộc: không downtime cho luồng người dùng; hệ mới phải scale theo số thành viên tăng nhanh; là hệ SOX nên mọi công cụ migration phải tuân quy trình kiểm toán; không được l…
- Meta's Infrastructure Evolution and the Advent of AI Bài tóm tắt · Meta · 2025
…tự xây DC ở Prineville và Forest City. - Nhiều DC kéo theo hai bài toán: - đưa user tới DC: xây edge , đặt máy cạnh từng ISP, peering; đến nay có hàng trăm POP; - nhân bản toàn bộ…
- Stack Overflow: The Hardware - 2016 Edition Bài tóm tắt · Stack Overflow · 2016
…), dữ liệu có tạm thời không (SSD không tụ rẻ hơn); - RAM: phải mua bao nhiêu và có thể dùng bao nhiêu; - CPU: ít nhân nhanh hay nhiều nhân chậm, có tranh chấp L3 không; - DR có cầ…
- From 3TB to 100GB: A Cost-Saving Journey in Database Maintenance Bài tóm tắt · Allegro · 2023
…e, dung lượng tối đa là 1 TB; dữ liệu tăng lên 3 TB , buộc phải lên 12 vCore vì Azure gắn dung lượng với CPU/RAM. Chi phí khoảng vài nghìn euro mỗi tháng. - So sánh: 3 TB trên Azur…
- Độ 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.
- Introducing Espresso - LinkedIn's hot new distributed document store Bài tóm tắt · LinkedIn · 2015
…m: từ state model (mỗi partition một master, n slave, không hai replica cùng node) tính IdealState rồi phát transition. Node chết thì ephemeral node ZooKeeper mất, slave được nâng…
- Business-Driven Upgrade of Alibaba Group: The Evolution of Dubbo 3.0 Bài tóm tắt · Alibaba · 2021
…h; phần lớn là thiết kế và lộ trình, ít số liệu đo. Kết quả hai năm sau (Dubbo3 thay hẳn HSF2) ở . Mọi số liệu theo Alibaba. Bối cảnh - Cuối 2020 Alibaba đặt mục tiêu hợp nhất công…
- 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.
- Catching bugs on the client-side: how we developed our error tracking system Bài tóm tắt · Bumble · 2020
…ng, hay gỡ tính năng hỏng khỏi bản phát hành. - Trước đó có hai hệ: HockeyApp cho crash native, và một hệ tự viết bằng PHP (2014) cho lỗi JS: MySQL, một bảng cho mỗi phiên bản ứng…
- How LinkedIn extended ClickHouse from distributed tracing to metric discovery and analytics Bài tóm tắt · ClickHouse · 2026
…p (ClickHouse) kể lại hệ thống của khách hàng LinkedIn, qua hai talk của kỹ sư LinkedIn. Company ghi là ClickHouse theo sheet; nội dung là của LinkedIn, mọi nhận định là "theo Link…
- 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ả…
- 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…
- 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…
- 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…
- Incident Report: July 2, 2026 — US East Services Outage Bài tóm tắt · Railway · 2026
…uter Mỹ: đa số đường đi hồi phục. 2. Ngắt thêm nhà mạng thứ hai ở một zone US East (vì đường về của nó vẫn đi qua nhà mạng hỏng). Không ai biết đó là nhà mạng cuối cùng còn cấp def…
- 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:
- Xác thực và phân quyền (authn/authz) Chủ đề Thành viên
Ở monolith, mỗi dữ liệu thường chỉ có một đường vào, nên kiểm tra quyền nằm ngay đó: một hàm hasaccess?, một API mỗi resource. Khi hệ thống tách thành nhiều service, nhiều client, nhiều loại token, cả hai nửa đều vỡ:
- 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:
- 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: