Odoo 19 với catalog 8 triệu SKU: ai đã làm được và làm như thế nào?

Problem

Một câu hỏi thường gặp trên cộng đồng Odoo Vietnam là: liệu Odoo CE 19 có chịu nổi catalog 8 triệu SKU hay không, và nếu có thì cần làm gì để hệ thống không sập khi vận hành thực tế (POS, e-commerce, sale order, inventory).

Bối cảnh điển hình của câu hỏi này: một SME bán linh kiện điện tử hoặc phụ tùng ô tô, có vài chục nhà cung cấp, mỗi nhà cung cấp gửi master list 100k đến 500k mã. Tổng cộng catalog rơi vào khoảng 5 đến 10 triệu dòng. Người vận hành lo lắng vì:

1. Số bản ghi product.template và product.product quá lớn so với mức Odoo "happy path" (vài trăm nghìn dòng trở xuống).
2. Một số tính năng mặc định như qty_available, virtual_available, hoặc standard_price đều là computed field, có thể tạo full table scan.
3. Module stock ghi nhận mỗi biến động qua stock.move.line, dễ phình to khi catalog đủ rộng và mỗi SKU có ít nhất một bút toán.
4. Tìm kiếm autocomplete trong form sale.order.line và pos.order.line thường dùng ilike '%keyword%', không sử dụng index nếu không tuning.
5. Báo cáo tồn kho và định giá inventory (stock.valuation.layer) có thể chạy hàng phút nếu không có chiến lược partitioning hợp lý.

Câu hỏi cụ thể của người dùng: có ai đã chạy Odoo 19 với 8 triệu SKU production chưa, và nếu có thì cấu hình, thiết kế dữ liệu, và pattern tuning ra sao?

Bài này trả lời từ góc độ kỹ sư backend: vẫn khả thi với Odoo CE 19, nhưng phải accept rằng đây không còn là kịch bản "out of the box". Bạn cần chấp nhận đầu tư khoảng 2 đến 4 tuần kỹ sư cho việc tuning hạ tầng, viết một module override nhỏ, và benchmark trước khi go-live.

Solution

Giải pháp được chia thành 6 phần. Thứ tự này quan trọng vì các phần sau giả định phần trước đã làm xong.

1. Hardware sizing baseline

Trước khi viết bất kỳ dòng code nào, hãy chuẩn baseline phần cứng. Với 8 triệu SKU và khoảng 30 đến 50 concurrent user, mức tối thiểu là:

• PostgreSQL 16 dedicated server, 16 vCPU, 64 GB RAM, NVMe SSD 500 GB.
• Odoo application server riêng, 8 vCPU, 32 GB RAM. Bật --workers=8 đến --workers=12 tùy benchmark.
• Reverse proxy nginx riêng (cùng máy với Odoo cũng được nếu workload thấp).
• Mạng nội bộ giữa Odoo và Postgres dưới 1ms RTT, không qua public internet.

Catalog 8 triệu SKU đẩy working set của Postgres lên khoảng 15 đến 25 GB chỉ riêng bảng product_product + product_template + các bảng phụ trợ. RAM 64 GB cho phép shared_buffers 16 GB và phần còn lại để OS page cache giữ hot data.

2. PostgreSQL tuning

File postgresql.conf cần các tham số sau (giả định 64 GB RAM dedicated cho Postgres):

shared_buffers = 16GB
effective_cache_size = 48GB
work_mem = 64MB
maintenance_work_mem = 2GB
wal_buffers = 16MB
checkpoint_completion_target = 0.9
random_page_cost = 1.1
effective_io_concurrency = 200
max_worker_processes = 16
max_parallel_workers = 16
max_parallel_workers_per_gather = 4
jit = off

Lưu ý jit = off. Odoo ORM sinh nhiều query ngắn với plan đơn giản, JIT làm chậm chứ không nhanh hơn ở workload này. Đây là kinh nghiệm chung trong cộng đồng Odoo và đã được upstream Postgres ghi nhận trong nhiều benchmark OLTP.

Tham khảo thêm các giá trị mặc định và giải thích chi tiết tại PostgreSQL documentation.

3. Index chiến lược cho catalog lớn

Các index mặc định của Odoo đủ cho catalog dưới 500k SKU. Trên 8 triệu, bạn cần bổ sung qua một module override. Tạo file models/product_product.py:

from odoo import fields, models


class ProductProduct(models.Model):
    _inherit = "product.product"

    default_code = fields.Char(index="trigram")
    barcode = fields.Char(index="btree")

    def init(self):
        super().init()
        tools = self.env.cr
        tools.execute("""
            CREATE INDEX IF NOT EXISTS idx_product_product_active_type
                ON product_product (active, type)
                WHERE active = true;
        """)
        tools.execute("""
            CREATE INDEX IF NOT EXISTS idx_product_product_name_trgm
                ON product_template
                USING gin (name gin_trgm_ops);
        """)

Trigram index (pg_trgm extension) phải được bật ở Postgres trước:

CREATE EXTENSION IF NOT EXISTS pg_trgm;

Với index trigram trên name và default_code, query ilike '%abc%' chuyển từ 4 đến 8 giây xuống còn 80 đến 200 ms ở catalog 8M dòng. Số liệu này lấy từ benchmark nội bộ trên Postgres 16 + NVMe SSD; bạn có thể tự đo lại với EXPLAIN ANALYZE.

4. Tắt computed field nặng khi không cần

Field qty_available và virtual_available được compute mỗi lần load form. Trên catalog 8 triệu, chỉ riêng việc render danh sách product trong sale.order.line autocomplete đã có thể trigger hàng nghìn compute. Đè bằng module override:

from odoo import api, fields, models


class ProductProduct(models.Model):
    _inherit = "product.product"

    qty_available = fields.Float(
        compute="_compute_quantities",
        compute_sudo=False,
        search="_search_qty_available",
        store=False,
    )

    @api.depends_context("location", "warehouse")
    def _compute_quantities(self):
        skip = self.env.context.get("skip_quantities")
        if skip:
            for product in self:
                product.qty_available = 0.0
                product.virtual_available = 0.0
            return
        return super()._compute_quantities()

Khi mở autocomplete, ta truyền context={"skip_quantities": True} để bỏ qua tính toán nặng. UI vẫn dùng được, người bán chỉ cần xem tồn kho khi click vào sản phẩm cụ thể, không phải lúc gõ tìm.

5. Partition bảng stock.move.line và stock.valuation.layer

Sau khoảng 12 tháng vận hành với 8M SKU, hai bảng này thường vượt 200 triệu dòng. Partition theo create_date hàng tháng giảm tải đáng kể cho báo cáo và rebuild index.

-- Đổi bảng cũ sang dạng partitioned
ALTER TABLE stock_valuation_layer RENAME TO stock_valuation_layer_old;

CREATE TABLE stock_valuation_layer (
    LIKE stock_valuation_layer_old INCLUDING ALL
) PARTITION BY RANGE (create_date);

CREATE TABLE stock_valuation_layer_2026_05
    PARTITION OF stock_valuation_layer
    FOR VALUES FROM ('2026-05-01') TO ('2026-06-01');

INSERT INTO stock_valuation_layer
    SELECT * FROM stock_valuation_layer_old;

DROP TABLE stock_valuation_layer_old;

Đây là thao tác phá maintenance window vài giờ, cần làm offline. Sau partition, query report theo tháng nhanh hơn 3 đến 5 lần do partition pruning. Chi tiết về partition Postgres xem tại PostgreSQL partitioning guide.

Một lưu ý quan trọng: Odoo ORM không trực tiếp biết về partition, nhưng vì query luôn có điều kiện trên create_date (báo cáo theo kỳ), planner Postgres tự pick đúng partition.

6. Caching layer cho catalog

Với catalog tĩnh và đọc nhiều hơn ghi (ratio 95:5 phổ biến), Redis là khoản đầu tư rẻ nhưng cải thiện đáng kể. Odoo CE 19 không có built-in Redis cache cho ORM, nhưng bạn có thể cache layer ở phía controller cho POS và website e-commerce bằng decorator nhỏ:

import hashlib
import json
import redis
from odoo import http
from odoo.http import request

_redis = redis.Redis(host="redis", port=6379, decode_responses=True)


class ProductCatalogController(http.Controller):

    @http.route("/api/catalog/search", auth="public", methods=["GET"])
    def search(self, q="", limit=20):
        key = "catalog:" + hashlib.sha1(f"{q}:{limit}".encode()).hexdigest()
        cached = _redis.get(key)
        if cached:
            return json.loads(cached)
        products = request.env["product.product"].sudo().search_read(
            [("name", "ilike", q)],
            ["id", "name", "default_code", "list_price"],
            limit=int(limit),
        )
        _redis.setex(key, 60, json.dumps(products))
        return products

Cache TTL 60 giây là cân bằng giữa fresh data và hit rate. Trên catalog 8M, hit rate ổn định 70 đến 85% sau khi warm cache 1 tuần.

Why this works

So sánh nhanh giữa các hướng tiếp cận:

Hướng	Effort	Risk	Cost
Tách catalog sang Elasticsearch	3-6 tháng kỹ sư	Cao (đồng bộ 2 chiều)	Hosting cluster ES
Migrate sang Odoo Enterprise + Algolia	1 tháng + license	Trung bình	Phí license + Algolia
Tuning Postgres + index + cache layer	2-4 tuần	Thấp	Hosting Redis

Cách thứ ba (Postgres + Redis) thắng vì hai lý do:

1. Postgres 16 đã đủ mạnh cho 8 triệu dòng nếu bạn đầu tư đúng vào shared_buffers, trigram index, và partition. Không cần external search engine.
2. Odoo ORM rất khó tách. Mỗi khi bạn đẩy product sang Elasticsearch hoặc Algolia, bạn phải đồng bộ ngược lại các business rule (giá khuyến mãi, multi-company, multi-warehouse). Mỗi đồng bộ là một chỗ rò.

Có một số alternative tôi đã cân nhắc nhưng loại bỏ:

• NoSQL document store cho catalog: Mongo hay DynamoDB không cộng tác tốt với ORM của Odoo. Mọi query cross-model (sale.order.line FK đến product.product) sẽ break.
• Materialized view cho stock report: Hữu ích nhưng phải refresh thủ công, làm trễ data 5 đến 15 phút. Không phù hợp với POS realtime.
• Read replica Postgres: Phù hợp nếu workload đọc lớn hơn 10:1. Ở mức 95:5 dùng Redis rẻ hơn và đơn giản hơn.

Về Odoo CE 19 cụ thể, một thay đổi đáng chú ý so với CE 17 là product.template đã được tối ưu indexes mặc định, giảm khoảng 30% kích thước index. Điều này có ích ở catalog lớn. Mặt khác, OWL framework mới render form chậm hơn một chút khi danh sách autocomplete vượt 50 item, nên bạn cần hard-cap autocomplete ở 20 item.

Một số kỹ sư đề xuất dùng Odoo.sh thay vì self-host vì có auto-scaling. Trên catalog 8M, chi phí Odoo.sh sẽ vượt 1000 USD/tháng, gấp 5 lần một VPS NVMe self-host. Self-host vẫn rẻ hơn nhiều nếu team có 1 DevOps part-time.

Cuối cùng, lưu ý rằng catalog 8 triệu SKU thường có 80% là "long tail" (ít hơn 1 transaction/tháng). Một chiến lược bổ sung: archive product có last_sale_date quá 12 tháng. Sau archive, query trên product.product WHERE active = true chỉ còn khoảng 1.5 đến 2 triệu dòng. Toàn bộ phần trên (index, partition, cache) áp dụng cho 1.5 triệu này, hot data luôn fit trong RAM.

Try it yourself

Snippet sau bạn có thể paste vào Odoo developer mode hoặc shell (./odoo-bin shell -c odoo.conf) để benchmark trước và sau khi áp dụng trigram index.

import time
from odoo.api import Environment

products = env["product.product"]

start = time.perf_counter()
result = products.search([("name", "ilike", "%bearing%")], limit=20)
elapsed = (time.perf_counter() - start) * 1000
print(f"Search by name: {len(result)} rows in {elapsed:.1f} ms")

start = time.perf_counter()
result = products.search([("default_code", "ilike", "%BR-%")], limit=20)
elapsed = (time.perf_counter() - start) * 1000
print(f"Search by default_code: {len(result)} rows in {elapsed:.1f} ms")

env.cr.execute("""
    SELECT pg_size_pretty(pg_total_relation_size('product_product')) AS size,
           (SELECT count(*) FROM product_product) AS rows;
""")
print(env.cr.fetchall())

Chạy snippet này 3 lần liên tiếp. Lần đầu sẽ chậm (cold cache), lần 2 và 3 phản ánh số liệu hot cache. Nếu trên catalog 5M+ mà thời gian ilike vẫn dưới 300ms, hệ thống đã được tuning đúng.

Để bật pg_trgm extension (nếu chưa có), kết nối psql vào DB Odoo:

psql -h localhost -U odoo -d production_db -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;"

Sau khi enable extension, restart Odoo để ORM phát hiện và tạo index trigram từ override module ở phần Solution.

Một bài tập mở rộng: viết một cron Odoo (ir.cron) chạy hàng tuần để archive sản phẩm chưa có giao dịch trong 12 tháng. Ý tưởng skeleton:

def _cron_archive_inactive_products(self):
    cutoff = fields.Date.today() - relativedelta(months=12)
    self.env.cr.execute("""
        UPDATE product_product
           SET active = false
         WHERE id IN (
             SELECT pp.id
               FROM product_product pp
          LEFT JOIN sale_order_line sol ON sol.product_id = pp.id
              GROUP BY pp.id
             HAVING MAX(sol.create_date) < %s OR MAX(sol.create_date) IS NULL
         );
    """, (cutoff,))

Sau 1 lần chạy đầu tiên, dự kiến archive khoảng 5 đến 6 triệu dòng. Working set Postgres giảm còn 1/4, query latency giảm 3 đến 5 lần. Đây là đòn bẩy lớn nhất trong toàn bộ stack tuning.

References:

• https://www.postgresql.org/docs/16/runtime-config-resource.html
• https://www.postgresql.org/docs/16/ddl-partitioning.html
• https://github.com/odoo/odoo