#olap

Trying DuckDB for Magento Analytics: An Experiment with One Million Orders

A hands-on experiment tests the MariaDB DuckDB storage engine as an analytical layer for a Magento shop with one million orders and two million order items. Keeping Magento's operational tables on InnoDB while running the full Orders Report against DuckDB snapshots dropped combined query time from 18.464s (InnoDB only) to 8.267s (orders on DuckDB, items still InnoDB) to 0.292s (both tables on DuckDB) — a 63.2x speedup. The author notes the snapshot load itself took 34.5 seconds, discusses why a warmed COUNT(*) comparison is misleading, sketches a snapshot/ETL architecture separating transactional and analytical storage, and lists limitations plus a roadmap including testing synchronous dual writes across InnoDB and DuckDB in one transaction.

DuckDB Speed on MySQL with dbtrail, Without a New Storage Engine

Hai bài viết gần đây trên blog Percona mô tả cách sao chép dữ liệu từ InnoDB vào một engine DuckDB và cách mở rộng engine DuckDB‑MySQL lên tới 500 GB mà không cần xây dựng storage engine mới. Nguyên nhân kỹ thuật là sử dụng dbtrail để ánh xạ bảng MySQL thành các tệp Parquet mà DuckDB đọc trực tiếp, tận dụng khả năng thực thi vectorized và định dạng cột của DuckDB. Kết quả là các truy vấn phân tích chạy nhanh hơn đáng kể – trong các thử nghiệmแสดง giảm latency từ giây xuống dưới một giây cho tập dữ liệu 500 GB – trong khi vẫn duy trì khả năng ghi MySQL bình thường. Điều này cho thấy việc tích hợp một engine OLAP hiện có như DuckDB qua lớp sao chép có thể mang lại hiệu suất tương đương với việc phát triển storage engine riêng, mà không gây phức tạp vận hành. Bài học cho lập trình viên là khi cần tăng tốc truy vấn lớn trên MySQL, hãy xem xét sử dụng công cụ sao chép như dbtrail để đưa dữ liệu vào DuckDB thay vì đầu tư vào việc xây dựng engine lưu trữ mới.

Bài viết này cho thấy cách DuckDB tăng tốc MySQL mà không cần storage engine mới.

Databend Cluster Key Best Practices: Choosing Columns, Key Order, and Granularity

Analytics, Search, AI, Python Sandbox — unified in Rust. Native on S3.

Bài viết này giúp bạn tối ưu hóa hiệu suất truy vấn và hiệu quả lưu trữ khi thiết kế key trong Databend Cluster.

Giving DuckDB a Server With Quack

DuckDB là hệ thống OLAP nhúng trong tiến trình, không có khả năng truy cập qua mạng mặc định. Quack là một lớp bọc server được phát triển để cho phép kết nối DuckDB qua giao thức TCP/HTTP, biến cơ sở dữ liệu nhúng thành dịch vụ có thể truy cập từ xa. Khi bài viết được viết, Quack vẫn đang ở giai đoạn beta, nghĩa là tính năng còn chưa ổn định và có thể thay đổi. Việc sử dụng Quack cho phép nhiều client truy cập cùng một phiên bản DuckDB, giảm nhu cầu sao chép dữ liệu và đơn giản hoá tích hợp với công cụ BI. Tuy nhiên, vì còn ở beta, các nhà phát triển cần kiểm tra kỹ về hiệu suất và độ tin cậy trước khi đưa vào môi trường sản xuất.

Quack giúp biến DuckDB thành một cơ sở dữ liệu OLAP có server, mở rộng khả năng xử lý phân tán cho ứng dụng của bạn.

Rebuilding Postgres for 300x faster analytics: batching, operator fusion, and SIMD

pgrust 0.2 cải thiện hiệu suất truy vấn phân tích lên 300 lần so với Postgres nhờ ba tối ưu hóa: batching (xử lý 1024 phần tử/lần thay vì từng dòng), operator fusion (kết hợp scan và aggregation thành một node) và SIMD (sử dụng ARM NEON để xử lý 8 float/chu kỳ). Các cải tiến này nâng tốc độ từ 1.3s xuống còn 135ms, góp phần vào hiệu suất tổng thể vượt trội so với ClickHouse.

Nếu bạn đang tìm cách tối ưu hóa hiệu suất cho các ứng dụng phân tích dữ liệu trên PostgreSQL, bài viết này sẽ giúp bạn hiểu rõ cách áp dụng batching, operator fusion và SIMD trong Rust để đạt được tăng tốc 300 lần so với phiên bản gốc, giúp bạn áp dụng các kỹ thuật tiên tiến ngay trong dự án của mình.

Why Coinbase and Pinterest Chose StarRocks: Lakehouse-Native Design and Fast Joins at Terabyte Scale

StarRocks được các kỹ sư dữ liệu tại Coinbase, Pinterest và Fresha ưa chuộng nhờ hiệu suất OLAP cao, hỗ trợ phân tích tức thì trên dữ liệu terabyte nhờ tính năng join phân tán nhanh (colocated join groups) và kiến trúc hybrid hot/cold. Các công ty này ghi nhận cải thiện đáng kể về độ trễ truy vấn (giảm 50% tại Pinterest, đạt dưới 100ms tại Fresha) và tiết kiệm tài nguyên, mặc dù StarRocks đòi hỏi mô hình dữ liệu cẩn thận và có cộng đồng nhỏ hơn so với ClickHouse.

Nếu bạn đang xây dựng hệ thống phân tích lớn trên dữ liệu terabyte, hiểu cách StarRocks tối ưu hóa join phân tán bằng cách đồng bộ hóa nhóm join (colocated) sẽ giúp bạn tránh những rắc rối về latency và chi phí hạ tầng khi so sánh với các giải pháp truyền thống.