Tìm kiếm
40 kết quả cho “SQL Server on VM”. Tìm không phân biệt dấu.
- Stack Overflow: The Hardware - 2016 Edition Bài tóm tắt · Stack Overflow · 2016
…ài 3: . Bài này là phụ lục phần cứng để đọc các con số như "SQL 5–10% CPU". Bối cảnh Các bài khác trong series hay nói kiểu "SQL Server chỉ dùng 5–10% CPU". Bài này trả lời câu hỏi…
- Sitar-agent: Building a reliable dynamic configuration sidecar at scale Bài tóm tắt · Airbnb · 2026
…bỏ qua phần cũ. Server vẫn stateless. - Kho local Sparkey → SQLite: Sparkey thiết kế cho ghi một lần đọc nhiều, không có điều phối đọc/ghi đa luồng (phải khoá cả file khi ghi), mỗi…
- Journey to the cloud part II: Migrating Stack Overflow for Teams to Azure Bài tóm tắt · Stack Overflow · 2023
…chậm một API. Sửa bằng cấu hình cho phép nhiều alias hơn. - SQL Server: on-prem là một availability group trải hai data center (4 node; đọc chỉ-đọc từ secondary cùng region, DR ở r…
- Moving the public Stack Overflow sites to the cloud: Part 1 Bài tóm tắt · Stack Overflow · 2025
…change) chạy trên máy chủ vật lý từ đầu: một máy → thêm máy SQL → data center (2010) → thêm CDN. Theo bài, các tối ưu hiệu năng đã cản trở cách làm hiện đại như service độc lập và…
- Unlocking Horizontal Scalability in Our Web Serving Tier Bài tóm tắt · Airbnb · 2016
…erver, nói chuyện với 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ố…
- Stack Overflow: How We Do Deployment - 2016 Edition Bài tóm tắt · Stack Overflow · 2016
…: xoá khỏi code, deploy, rồi mới drop. Không đổi tên object SQL trên production; - gần như không bao giờ rollback : viết migration mới để sửa (roll forward). - Đổi mà không làm vỡ:…
- Flava DBaaS deep dive: From architecture to migration and beyond Bài tóm tắt · LINE (LY Corp) · 2026
…; cần công cụ cho developer tự làm theo UI: đã có DMB cho MySQL, mục tiêu đủ mọi DBMS khoảng Q2/2026. - Hướng tới: serverless DBaaS đa tenant (TiDB-compatible MySQL, OpenSearch) để…
- 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".
- 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:
- 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…
- 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…
- Độ 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.
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- Hudson River Trading Công ty Thành viên
Công ty giao dịch thuật toán (HRT), phần lớn hạ tầng on-premises, nhiều site trên thế giới. Năm 2021 họ scale Prometheus bằng shard chỉ ingest cộng query node đọc remote, vì federation mất khả năng tổng hợp ad-hoc trên…
- Chat Service Architecture: Servers Bài tóm tắt · Riot Games · 2015
…bảng định tuyến; người nhận offline thì lưu vào kho bền (MySQL ở shard cũ, Riak ở shard mới), online thì gửi bằng message passing của Erlang. - REST nội bộ (Cowboy, Swagger) phục…
- New Tweets per second record, and how! Bài tóm tắt · Twitter · 2013
…từ kết nối DB tới render và public 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…
- Evolution of our platform architecture Bài tóm tắt · Allegro · 2015
…3 developer, vài trăm user, dữ liệu lưu trong file, chưa có SQL. Đến 2015 công ty có hàng chục team, hàng trăm lập trình viên. Bài kể bốn giai đoạn, mỗi giai đoạn có ưu và nhược do…
- The Great Unracking: Saying goodbye to the servers at our physical datacenter Bài tóm tắt · Stack Overflow · 2025
…p KVM, 2 cáp 10G (thêm 2 cáp 10G cho máy cần băng thông như SQL), 2 cáp nguồn ở hai mạch điện khác nhau. - Không giữ máy nào: vì bảo mật và PII của user, mọi thứ bị nghiền hoặc tiê…
- How Discord Stores Trillions of Messages Bài tóm tắt · Discord · 2023
…trong một buổi chiều (đọc theo token range, checkpoint bằng SQLite), ước tính còn 9 ngày , tốc độ tới 3,2 triệu tin/giây. Nhờ vậy bỏ được phương án cắt theo thời gian phức tạp. - K…
- Macaroons Escalated Quickly Bài tóm tắt · Fly.io · 2024
…ly vật lý , gọi qua HTTP, kết quả cache được, dữ liệu trên SQLite phân tán bằng LiteFS nên nhanh ở mọi nơi; token OAuth2 cũ chỉ nhanh ở Ashburn) khỏi "clearing" caveat (làm ở đâu…
- 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:
- 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…
- 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…
- A Decade of Evolution of Alibaba's Databases - Part 1 Bài tóm tắt · Alibaba · 2019
…2015, mã nguồn mở ("De-IOE"): middleware phân tán TDDL , AliSQL (nhánh MySQL), server x86 và SSD thay cho IOE. Nhờ đó họ scale out được, tự thêm tính năng vào kernel (vá hot row ch…
- What it takes to run Stack Overflow Bài tóm tắt · Stack Overflow · 2013
…rong đó 36 triệu page load; gửi đi khoảng 1 TB; - 334 triệu SQL query (chỉ từ HTTP request), 412 triệu Redis hit, 3,6 triệu request tới tag engine; - tổng thời gian: SQL 155 giờ, R…
- Carving The Scheduler Out Of Our Orchestrator Bài tóm tắt · Fly.io · 2023
…ion không chia sẻ trạng thái. Bức tranh toàn hệ là một view SQLite do Corrosion sinh (gossip SWIM, viết bằng Rust): theo Fly.io, khi mỗi máy tự là nguồn sự thật thì đây là bài toá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.
- 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.
- 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…
- 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.
- 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ẻ…
- 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:
- 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ố…
- 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…
- 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…
- Bảo mật hạ tầng và quản lý secret Chủ đề Thành viên
Khi hệ thống lớn lên, số credential (mật khẩu DB, API key, SSH key, token, cookie phiên) tăng theo số service, pipeline, nhà cung cấp, và chúng rải vào code, cấu hình, hệ build, log. Các nguồn trong wiki cho thấy kẻ tấn…
- 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…