Không có một cơ sở dữ liệu duy nhất phù hợp cho mọi việc của một website TMĐT có catalog lớn. Cách làm phổ biến và bền vững là dùng database quan hệ (MySQL hoặc PostgreSQL) làm nguồn dữ liệu chính cho sản phẩm, đơn hàng và tồn kho; thêm bộ nhớ đệm như Redis cho dữ liệu đọc nhiều; và dùng công cụ tìm kiếm như Elasticsearch hoặc OpenSearch cho tìm kiếm và lọc sản phẩm.
Bài viết so sánh các lựa chọn database phổ biến, đưa ra kiến trúc dữ liệu tham chiếu và cách thiết kế catalog hàng triệu sản phẩm vẫn truy vấn nhanh.
Tóm tắt nhanh
- Đơn hàng, thanh toán, tồn kho cần tính toàn vẹn giao dịch: dùng database quan hệ.
- PostgreSQL mạnh về dữ liệu thuộc tính linh hoạt (JSONB); MySQL phổ biến nhất với WooCommerce, Magento và có hệ sinh thái lớn.
- Website TMĐT đọc nhiều hơn ghi rất nhiều: read replica và bộ nhớ đệm cho hiệu quả lớn nhất.
- Tìm kiếm và lọc sản phẩm ở quy mô lớn nên chuyển sang công cụ tìm kiếm chuyên dụng.
Dữ liệu thương mại điện tử có gì đặc biệt?
Dữ liệu TMĐT có 4 đặc điểm quyết định cách chọn database:
- Đọc nhiều hơn ghi rất nhiều. Mỗi đơn hàng thường đi kèm hàng chục đến hàng trăm lượt xem trang sản phẩm, danh mục và tìm kiếm.
- Thuộc tính sản phẩm biến đổi theo danh mục. Áo có size, màu, chất liệu; điện thoại có RAM, bộ nhớ, màn hình. Một cấu trúc bảng cố định khó đáp ứng.
- Giao dịch cần chính xác tuyệt đối. Đơn hàng, thanh toán, trừ kho phải tuân thủ tính toàn vẹn (ACID): không được mất đơn hay trừ kho hai lần.
- Tải tăng vọt theo chiến dịch. Giờ mở flash sale, số truy vấn có thể gấp nhiều lần ngày thường trong vài phút.
MySQL, PostgreSQL hay NoSQL cho e-commerce?
Với phần lớn hệ thống TMĐT, MySQL và PostgreSQL đều là lựa chọn tốt làm database chính. NoSQL phù hợp cho một số phần dữ liệu cụ thể, hiếm khi thay thế hoàn toàn database quan hệ.
| Tiêu chí | MySQL | PostgreSQL | NoSQL tài liệu (ví dụ MongoDB) |
|---|---|---|---|
| Giao dịch, tính toàn vẹn | Tốt (InnoDB) | Rất tốt | Có hỗ trợ giao dịch, nhưng mô hình dữ liệu khác |
| Thuộc tính sản phẩm linh hoạt | Kiểu JSON, cần cột sinh để đánh chỉ mục | JSONB có chỉ mục GIN, truy vấn linh hoạt | Rất linh hoạt, schema tự do |
| Truy vấn phức tạp, báo cáo | Tốt | Rất tốt (CTE, window function, nhiều loại chỉ mục) | Hạn chế hơn với truy vấn liên kết nhiều bảng |
| Nền tảng TMĐT phổ biến | WooCommerce, Magento, PrestaShop dùng mặc định | Nhiều hệ thống tự phát triển, một số framework hiện đại | Ít nền tảng TMĐT dùng làm database chính |
| Phù hợp nhất cho | Website dùng nền tảng có sẵn, đội ngũ quen MySQL | Hệ thống tự phát triển, catalog nhiều thuộc tính, báo cáo phức tạp | Nhật ký hoạt động, nội dung phi cấu trúc, hồ sơ người dùng linh hoạt |
Kết luận thực tế: nếu dùng WooCommerce hay Magento, hãy dùng MySQL. Nếu tự xây hệ thống với catalog nhiều thuộc tính, PostgreSQL thường là lựa chọn mạnh hơn. Sun Database hỗ trợ cả MySQL và PostgreSQL dưới dạng dịch vụ được quản lý.
Kiến trúc dữ liệu nhiều lớp cho website TMĐT
Mỗi loại truy vấn được phục vụ bởi công cụ phù hợp nhất, trong đó database quan hệ luôn là nguồn sự thật.
[ẢNH 1 — Kiến trúc dữ liệu nhiều lớp cho TMĐT]
Lớp
Công cụ
Dữ liệu và truy vấn
Nguồn sự thật
MySQL / PostgreSQL (Sun Database)
Sản phẩm, biến thể, giá, tồn kho, đơn hàng, khách hàng
Bản sao đọc
Read replica của Sun Database
Trang sản phẩm, danh mục, báo cáo — không ghi
Bộ nhớ đệm
Redis
Phiên đăng nhập, giỏ hàng, trang sản phẩm hot, bộ đếm flash sale
Tìm kiếm
Elasticsearch / OpenSearch
Tìm kiếm toàn văn, lọc theo thuộc tính, gợi ý từ khóa
Luồng sự kiện
Sun Kafka Highway
Đồng bộ thay đổi từ database sang chỉ mục tìm kiếm, bộ nhớ đệm
Lưu trữ file
Sun S3
Ảnh, video sản phẩm — không lưu file trong database
Nguyên tắc quan trọng: không lưu ảnh trong database, và không để trang tìm kiếm dùng câu lệnh LIKE '%từ khóa%' trên bảng hàng triệu dòng.
Thiết kế catalog hàng triệu sản phẩm
Catalog lớn chạy nhanh hay chậm phụ thuộc chủ yếu vào cách tổ chức bảng và chỉ mục, không phải vào cấu hình máy chủ.
Tách sản phẩm và biến thể
Một sản phẩm (áo thun cổ tròn) có nhiều biến thể (SKU) theo size và màu. Giá và tồn kho gắn với biến thể, còn mô tả và ảnh gắn với sản phẩm. Tách hai bảng giúp tránh lặp dữ liệu và cập nhật tồn kho nhanh hơn.
Lưu thuộc tính linh hoạt bằng JSONB thay vì EAV
Mô hình EAV (mỗi thuộc tính là một dòng) linh hoạt nhưng khiến truy vấn lọc rất chậm khi catalog lớn. Với PostgreSQL, lưu thuộc tính trong cột JSONB có chỉ mục GIN là cách cân bằng tốt:
CREATE TABLE products (
id BIGSERIAL PRIMARY KEY,
category_id INT NOT NULL,
name TEXT NOT NULL,
brand TEXT,
attributes JSONB NOT NULL DEFAULT '{}', -- {"chat_lieu": "cotton", "xuat_xu": "VN"}
status SMALLINT NOT NULL DEFAULT 1,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE TABLE variants (
sku VARCHAR(64) PRIMARY KEY,
product_id BIGINT NOT NULL REFERENCES products(id),
options JSONB NOT NULL, -- {"size": "M", "mau": "trang"}
price NUMERIC(12,0) NOT NULL, -- VNĐ
stock INT NOT NULL DEFAULT 0
);
CREATE INDEX idx_products_category ON products (category_id, status, updated_at DESC);
CREATE INDEX idx_products_attrs ON products USING GIN (attributes);
CREATE INDEX idx_variants_product ON variants (product_id);Phân trang bằng keyset thay vì OFFSET
Trang danh mục dùng OFFSET 100000 sẽ chậm dần khi người dùng (hoặc bot) lật sâu, vì database phải đọc và bỏ qua toàn bộ dòng phía trước. Phân trang keyset dùng giá trị của dòng cuối trang trước làm mốc (WHERE updated_at < :moc ORDER BY updated_at DESC LIMIT 40), giữ tốc độ ổn định ở mọi trang.
Read replica: tách đọc và ghi cho tải đọc lớn
Read replica là bản sao chỉ đọc của database chính, được đồng bộ liên tục. Ứng dụng gửi truy vấn ghi (đặt hàng, trừ kho) tới database chính và gửi truy vấn đọc (xem sản phẩm, danh mục, báo cáo) tới các bản sao.
[ẢNH 2 — Database chính và các read replica]
Lưu ý quan trọng: bản sao có độ trễ đồng bộ, thường dưới một giây nhưng có thể tăng khi tải cao. Vì vậy các truy vấn cần dữ liệu mới nhất — kiểm tra tồn kho lúc thanh toán, xem đơn vừa đặt — phải đọc từ database chính. Chỉ chuyển sang bản sao những truy vấn chấp nhận được dữ liệu trễ vài giây.
7 cách tối ưu database cho website TMĐT
- Bật slow query log và xử lý 10 truy vấn chậm nhất mỗi tháng — thường giải quyết phần lớn vấn đề hiệu năng.
- Đánh chỉ mục theo cách truy vấn thật, đặc biệt chỉ mục ghép cho bộ lọc danh mục + trạng thái + sắp xếp.
- Dùng connection pooling để hàng trăm tiến trình ứng dụng không mở hàng trăm kết nối tới database.
- Đưa dữ liệu đọc nhiều vào Redis (trang sản phẩm hot, cây danh mục) với thời gian hết hạn ngắn.
- Chuyển tìm kiếm và lọc nhiều thuộc tính sang Elasticsearch hoặc OpenSearch khi catalog vượt vài trăm nghìn sản phẩm.
- Chia bảng lớn theo thời gian (partition) cho bảng đơn hàng, nhật ký: truy vấn gần đây nhanh hơn, dữ liệu cũ dễ lưu trữ.
- Lưu trữ đơn hàng cũ sang bảng hoặc kho riêng sau 12–24 tháng để bảng hoạt động luôn gọn.
Với hệ thống tách thành nhiều dịch vụ, mỗi dịch vụ nên sở hữu database riêng — xem kiến trúc microservices cho sàn TMĐT. Ví dụ thiết kế bảng tồn kho chống bán vượt có trong bài cloud cho seller Lazada.
Managed database là gì và vì sao nên dùng?
Managed database là cơ sở dữ liệu do nhà cung cấp cloud vận hành: cài đặt, sao lưu tự động, vá lỗi bảo mật, theo dõi và tạo bản sao đọc. Doanh nghiệp chỉ cần quản lý dữ liệu và truy vấn.
| Việc cần làm | Tự cài database trên máy chủ | Managed database (Sun Database) |
|---|---|---|
| Cài đặt, cấu hình ban đầu | Tự làm | Khởi tạo trong vài phút |
| Sao lưu, khôi phục theo thời điểm | Tự viết kịch bản, tự kiểm tra | Tự động |
| Vá lỗi, nâng phiên bản | Tự làm, dễ trì hoãn | Nhà cung cấp hỗ trợ |
| Tạo read replica | Cấu hình replication thủ công | Vài thao tác |
| Giám sát | Tự dựng công cụ | Có sẵn chỉ số và cảnh báo |
Với đội kỹ thuật nhỏ, managed database giúp giảm đáng kể rủi ro mất dữ liệu và thời gian vận hành. Hướng dẫn khởi tạo có tại tài liệu Sun Database; đơn giá tại Bảng giá dịch vụ cloud Sunteco. Quay lại hướng dẫn giải pháp cloud thương mại điện tử để xem bức tranh tổng thể.
Câu hỏi thường gặp về database cho e-commerce
Nên dùng MySQL hay PostgreSQL cho TMĐT?
Nếu dùng nền tảng có sẵn như WooCommerce, Magento, hãy dùng MySQL vì đây là lựa chọn mặc định. Nếu tự xây hệ thống với catalog nhiều thuộc tính và báo cáo phức tạp, PostgreSQL thường mạnh hơn nhờ JSONB và khả năng truy vấn nâng cao.
Database nào xử lý được catalog hàng triệu sản phẩm?
Cả MySQL và PostgreSQL đều xử lý tốt hàng triệu sản phẩm nếu thiết kế bảng và chỉ mục đúng, dùng read replica cho tải đọc và chuyển tìm kiếm sang công cụ chuyên dụng như Elasticsearch hoặc OpenSearch.
Managed database là gì?
Managed database là cơ sở dữ liệu do nhà cung cấp cloud vận hành: tự sao lưu, vá lỗi, theo dõi và hỗ trợ tạo bản sao đọc. Doanh nghiệp chỉ cần tập trung vào dữ liệu và ứng dụng thay vì quản trị máy chủ database.
Website TMĐT có cần NoSQL không?
Phần lớn không cần NoSQL làm database chính. NoSQL hữu ích cho một số phần như nhật ký hoạt động, hồ sơ người dùng linh hoạt; còn đơn hàng, thanh toán, tồn kho nên ở database quan hệ để đảm bảo tính toàn vẹn.
Read replica là gì?
Read replica là bản sao chỉ đọc của database chính, đồng bộ liên tục. Nó gánh các truy vấn đọc như xem sản phẩm, danh mục, báo cáo, giúp database chính dành tài nguyên cho đặt hàng và trừ kho.
Khởi tạo Sun Database cho hệ thống bán hàng
Sun Database là MySQL/PostgreSQL được quản lý, sao lưu tự động, hỗ trợ read replica, đặt tại Việt Nam và tính giá VNĐ.
