Database

← Chương trước: Phần 2 — Xử lý tải đột biến: Event-Driven & Kafka (2026) | Mục lục Series | Chương tiếp theo: Phần 4 — Vận hành: SRE & Chaos Engineering (2026) → Answer-first: PayPay chuyển đổi tầng dữ liệu từ Amazon Aurora sang TiDB (Distributed SQL) để giải quyết giới hạn mở rộng ghi và loại bỏ nhu cầu sharding thủ công, đạt khả năng co giãn ngang với độ trễ thấp và tuân thủ chuẩn ACID. ...

Answer-first: Nâng cấp Magento 2.4.5 lên 2.4.8 giải quyết bài toán End-of-Life của MySQL 8.0 trên AWS RDS, tương thích hoàn toàn PHP 8.4 và OpenSearch 2.19. Chiến lược nhảy cóc (Leapfrog) cùng kiến trúc Blue/Green Deployment giảm thiểu downtime về dưới 15 phút, loại bỏ nguy cơ phụ phí Extended Support từ AWS. 1. Quả Bom “Nợ Kỹ Thuật” Mang Tên Cổ Tức Đám Mây Trong thế giới E-commerce B2B và B2C quy mô lớn, nếu hệ thống của bạn vẫn đang chạy Magento 2.4.5 ở thời điểm hiện tại, bạn đang ngồi trên một quả bom nổ chậm mang tên Technical Debt (Nợ kỹ thuật). Ngòi nổ của quả bom này không nằm ở bản thân mã nguồn Magento, mà nằm ở hệ sinh thái hạ tầng bên dưới: ...

MySQL Scalability & Sharding: Vitess vs TiDB (10k+ TPS) Answer-first: Scaling MySQL requires a phased architectural progression: optimizing InnoDB buffer pools (100–500 TPS), implementing ProxySQL read/write splitting (500–3,000 TPS), and migrating to horizontal sharding or TiDB Distributed SQL (3,000–10,000+ TPS). TiDB serves as the premier MySQL sharding alternative, eliminating manual application-level partitioning through stateless SQL compute nodes and Raft-replicated distributed TiKV storage. MySQL scalability is the ability to increase database throughput — reads per second, writes per second, or data volume — without rewriting your application. The critical distinction: read scaling (adding replicas) and write scaling (sharding or distributed SQL) require completely different architectural approaches. Choosing the wrong path creates technical debt that takes months to unwind. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Khi Primary-Replica Read-Scaling chạm trần tải ghi, mở rộng ngang MySQL (Write-Scaling) được thực thi qua Vitess (Middleware-level với VTGate/VTTablet trong suốt, zero-downtime resharding) hoặc GORM Sharding (App-level trong Go qua SQL AST rewrite). Chọn Vitess cho kiến trúc polyglot quy mô lớn; chọn GORM Sharding cho Go stack tinh gọn. Khi ứng dụng của bạn vươn mình chạm ngưỡng hàng triệu người dùng, một cỗ máy database đơn độc (single database instance) sớm muộn gì cũng trở thành nút thắt cổ chai lớn nhất trong toàn bộ kiến trúc. Để giải quyết bài toán này, việc mở rộng quy mô cơ sở dữ liệu MySQL (MySQL database scaling) là điều bắt buộc. Bạn có thể tham khảo Mở Rộng DB Cho Microservices (Scale DB for Microservices) khi áp dụng các kỹ thuật Horizontal Scaling (Mở rộng ngang). Khám phá thêm tại series High Concurrency Systems. ...

MySQL Sharding Alternatives: Vitess vs TiDB Guide Answer-first: TiDB is the leading open-source MySQL sharding alternative, replacing fragile application-level sharding logic (Vitess, GORM Sharding) with an auto-partitioned Distributed SQL architecture. By distributing 96MB Raft Regions across TiKV storage nodes and utilizing the Percolator distributed transaction protocol, TiDB delivers horizontal write scaling, cross-node ACID transactions, and zero-downtime online DDL while maintaining 100% MySQL wire compatibility. Scaling a relational database is one of the most demanding challenges in system design. As applications grow from thousands to millions of active users, the database ceases to be a simple storage engine and becomes the primary bottleneck of the entire system architecture. In this technical guide, we explore the architectural progression of scaling MySQL—beginning with replication topologies, stepping through the complexities and operational hazards of manual database sharding (including proxy middleware like Vitess), and evaluating NewSQL alternatives, specifically the distributed architecture of TiDB. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Trích xuất dữ liệu từ mô hình EAV Magento 2 yêu cầu kỹ thuật flatten bằng SQL query đa tầng kết hợp store-scope fallback (COALESCE) và pipeline streaming Node.js với backpressure. Thiết kế đảm bảo tính lũy đẳng (idempotent upsert), Dead-Letter Queue và zero-OOM khi nạp hàng triệu bản ghi. Khi dọn nhà rời khỏi Magento 2, chướng ngại vật đầu tiên luôn luôn là cái database schema. Magento chẳng thèm lưu dữ liệu thành các hàng phẳng phiu sạch sẽ — nó xài một mô hình gọi là Entity-Attribute-Value (EAV), băm vằm dữ liệu rải rác ra hàng chục cái bảng khác nhau kèm theo tính năng kế thừa theo cấp độ store (store-scope inheritance). Việc hiểu được mớ bòng bong này trước khi cắm đầu vào viết SQL sẽ cứu rỗi bạn vài ngày thanh xuân. ...