Posted inDatabase

Thiết kế Cơ sở dữ liệu Thương mại điện tử: Xử lý Biến thể Sản phẩm mà không gặp ác mộng ‘God Table’

Database tutorial - IT technology blog
Database tutorial - IT technology blog

Ác mộng mang tên bảng ‘Một kích cỡ cho tất cả’

Cửa hàng áo thun của bạn đang phát triển mạnh. Ban đầu, bảng products khá gọn nhẹ với các cột đơn giản như color và size. Nhưng ngay khi khách hàng quyết định bán Laptop cao cấp, schema bắt đầu đổ vỡ. Đột nhiên, color trở nên vô nghĩa, và bạn phải cuống cuồng thêm các cột RAM, CPU, và SSD_Capacity.

Đến lúc bạn thêm Mật ong hữu cơ hay Máy khoan điện vào danh mục, bạn sẽ đối mặt với một ‘God Table’. Đây là một “con quái vật” khổng lồ với 150 cột, trong đó 95% các ô là NULL ở bất kỳ hàng nào. Truy vấn thực thể này là một thảm họa về hiệu năng. Ngay cả một lệnh SELECT * đơn giản cũng có thể khiến ứng dụng chậm như rùa bò vì database engine phải vật lộn với kích thước hàng quá lớn.

Tại sao các Relational Schema lại cảm thấy cứng nhắc đến vậy

Cơ sở dữ liệu quan hệ (Relational database) phát triển dựa trên tính dự đoán được. Chúng kỳ vọng mọi hàng trong một bảng đều tuân theo cùng một bản thiết kế. Tuy nhiên, dữ liệu thương mại điện tử vốn dĩ lộn xộn và có cấu trúc bán tuần tự. Trong khi một sản phẩm ‘Cha’ (Parent) chung chung có tên và thương hiệu, thì các ‘Biến thể’ (Variants) cụ thể—như Laptop màu Midnight Blue, RAM 16GB—lại yêu cầu các bộ thuộc tính riêng biệt.

Việc ép các chi tiết động này vào một SQL schema tĩnh thường dẫn đến ba vấn đề đau đầu chính:

  • Thời gian chết để bảo trì (Maintenance Downtime): Chạy lệnh ALTER TABLE trên một bảng có 5 triệu hàng có thể khóa cơ sở dữ liệu của bạn trong nhiều phút, khiến cửa hàng ngừng hoạt động.
  • Lãng phí lưu trữ: Việc đánh index một cột như ‘Trọng lượng vải’ khi nó chỉ áp dụng cho 2% kho hàng là một sự lãng phí bộ nhớ và Disk I/O khủng khiếp.
  • Thể dục dụng cụ với SQL (SQL Gymnastics): Hãy thử viết một truy vấn để tìm “Laptop có RAM 16GB VÀ Áo thun xanh size XL.” Mã nguồn kết quả thường là một mớ hỗn độn các subquery (truy vấn con) chồng chéo.

So sánh ba giải pháp chính

Tôi đã dành nhiều năm để mở rộng danh mục sản phẩm trên MySQL và PostgreSQL. Hầu hết các đội ngũ thường hướng tới một trong ba mô hình kiến trúc sau, mỗi mô hình đều có những ưu và nhược điểm riêng.

1. Mô hình EAV (Entity-Attribute-Value)

Đây là cách tiếp cận cổ điển được các nền tảng như Magento sử dụng. Thay vì thêm cột theo chiều ngang, bạn phát triển dữ liệu theo chiều dọc.

-- Bản thân sản phẩm
CREATE TABLE products (id INT, name TEXT);

-- Định nghĩa thuộc tính (ví dụ: "RAM")
CREATE TABLE attributes (id INT, name TEXT);

-- Giá trị cụ thể (ví dụ: "32GB")
CREATE TABLE product_attribute_values (
    product_id INT,
    attribute_id INT,
    value TEXT
);

Ưu điểm: Bạn có sự linh hoạt vô hạn. Bạn có thể thêm thuộc tính ‘Thời lượng pin’ cho danh mục flycam mới trong vài giây mà không cần chạm vào schema.
Nhược điểm: Hiệu năng giảm mạnh khi quy mô lớn. Để hiển thị một sản phẩm có 10 thuộc tính, bạn phải thực hiện 10 phép join. Trên một trang web có 100.000 sản phẩm, thời gian tải trang của bạn có khả năng sẽ vọt quá ngưỡng 2 giây.

2. Cách tiếp cận tài liệu JSONB

Nếu bạn đang sử dụng PostgreSQL, JSONB thường là lựa chọn trung gian thông minh nhất. Bạn giữ các trường cốt lõi như SKU và Price trong các cột tiêu chuẩn nhưng đưa các thuộc tính biến đổi vào một blob JSON nhị phân.

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name TEXT,
    base_price DECIMAL,
    attributes JSONB -- Lưu trữ {"RAM": "16GB", "Màn hình": "15-inch"}
);

Ưu điểm: Phát triển cực kỳ nhanh. PostgreSQL cũng hỗ trợ GIN index, cho phép bạn tìm kiếm bên trong blob JSON gần như nhanh bằng một cột thông thường.
Nhược điểm: Bạn mất đi tính toàn vẹn dữ liệu (data integrity) nghiêm ngặt. Không có gì ngăn cản một lập trình viên vô tình lưu giá sản phẩm dưới dạng chuỗi như “$19.99” thay vì một giá trị số.

3. Class Table Inheritance (Mô hình lai)

Cách này bao gồm một bảng products cơ sở được liên kết với các bảng riêng cho từng danh mục như electronics_details hoặc apparel_details. Nó giữ cho dữ liệu của bạn sạch sẽ và được định kiểu (typed) nghiêm ngặt. Tuy nhiên, chi phí quản lý sẽ trở thành một cơn ác mộng khi bạn phát triển từ 5 danh mục lên 500 danh mục.

Tiêu chuẩn vàng: Schema 5 bảng có khả năng mở rộng

Đối với các sàn thương mại điện tử quy mô lớn, nơi độ chính xác của kho hàng là không thể thương lượng, tôi khuyên dùng một cấu trúc chuẩn hóa (normalized). Cấu trúc này tách biệt ‘khái niệm’ về một sản phẩm khỏi ‘mặt hàng’ thực tế mà khách hàng cho vào giỏ hàng. Nó cân bằng giữa tính nghiêm ngặt và sự linh hoạt cần thiết để lọc sản phẩm.

Bước 1: Sản phẩm Cha

Bảng products lưu trữ dữ liệu không bao giờ thay đổi giữa các biến thể.

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    brand_id INT,
    category_id INT
);

Bước 2: Biến thể có thể mua được

Bảng product_variants là ‘Con’. Đây là nơi lưu trữ tồn kho vật lý. Nếu một chiếc áo có 3 màu và 3 kích cỡ, bạn sẽ có 9 hàng ở đây.

CREATE TABLE product_variants (
    id SERIAL PRIMARY KEY,
    product_id INT REFERENCES products(id),
    sku VARCHAR(100) UNIQUE NOT NULL,
    price DECIMAL(12, 2) NOT NULL,
    stock_quantity INT DEFAULT 0
);

Bước 3: Ánh xạ linh hoạt

Để định nghĩa điều gì làm nên sự độc đáo của một biến thể, hãy sử dụng mối quan hệ many-to-many (nhiều-nhiều). Điều này giúp tránh hoàn toàn tình trạng ‘Địa ngục cột’ (Column Hell).

CREATE TABLE attributes (id SERIAL PRIMARY KEY, name VARCHAR(50)); -- "Màu sắc"
CREATE TABLE attribute_values (id SERIAL PRIMARY KEY, attribute_id INT, value VARCHAR(50)); -- "Xanh Navy"

CREATE TABLE variant_attribute_map (
    variant_id INT REFERENCES product_variants(id),
    attribute_value_id INT REFERENCES attribute_values(id),
    PRIMARY KEY (variant_id, attribute_value_id)
);

Tại sao mô hình này vượt trội hơn các đối thủ

Cấu trúc này được xây dựng để đạt tốc độ và độ chính xác. Nếu bạn cần cập nhật tên của một màu từ ‘Navy’ thành ‘Midnight Blue’, bạn chỉ cần thay đổi một hàng trong bảng attribute_values. Mọi sản phẩm liên quan sẽ được cập nhật ngay lập tức. Không trùng lặp dữ liệu, không có các chuỗi ký tự lộn xộn, và không gây khóa bảng diện rộng.

Mẹo từ chuyên gia: Đừng Join trong mọi lần tải trang

Mặc dù dữ liệu chuẩn hóa rất tốt cho việc lưu trữ, nhưng nó có thể nặng nề cho frontend. Để giữ cho trang web của bạn nhanh nhạy, hãy sử dụng chiến lược hai hướng:

  1. Đánh Index chiến lược: Luôn đặt index trên các khóa ngoại (foreign keys) và các cột SKU.
  2. Read-Model Caching: Khi một sản phẩm được cập nhật, hãy tính toán trước một bản ‘snapshot’ JSON của các biến thể và lưu trữ nó trong Redis. Trang chi tiết sản phẩm của bạn nên truy xuất key duy nhất này thay vì chạy 5 phép join SQL phức tạp mỗi khi người dùng click vào một liên kết.

Lời kết

Hãy lựa chọn sự đánh đổi một cách khôn ngoan. Nếu bạn đang xây dựng một MVP nhỏ với chỉ khoảng 100 mặt hàng, **cách tiếp cận JSONB** sẽ giúp bạn đưa sản phẩm ra thị trường trong thời gian kỷ lục. Nhưng nếu bạn đang xây dựng một sàn thương mại điện tử lớn tiếp theo, hãy bắt đầu với **mô hình 5 bảng chuẩn hóa**. Việc cache một cơ sở dữ liệu sạch sẽ dễ dàng hơn nhiều so với việc sửa chữa một đống hỗn độn JSON bị hỏng và không nhất quán khi bạn đạt đến con số một triệu khách hàng.

Share:
Tags: