تحلیل داده‌های WooCommerce با DuckDB در یک Replica از MySQL

چرا مهم است

اگر با گزارش‌های WooCommerce کار می‌کنی، این آزمایش محدودیت اتصال مشترک آن و راهی برای جداکردن بار تحلیلی را نشان می‌دهد. عددهای فضای ذخیره‌سازی هم به همین مجموعه داده مربوط‌اند، نه هر فروشگاهی.

قبل از خواندن، این‌ها را بدان۴ مفهوم
OLTP

پردازش transaction‌های عملیاتی، مانند ثبت سفارش، که معمولاً با عملیات کوتاه روی تعداد محدودی رکورد سروکار دارد.

بیشتر درباره این مفهوم

OLAP

پردازش تحلیلی داده‌ها برای گزارش‌گیری؛ معمولاً شامل خواندن، گروه‌بندی و خلاصه‌کردن تعداد زیادی ردیف است.

بیشتر درباره این مفهوم

Replica

نسخه‌ای از database که تغییرات مبدأ را از طریق replication دریافت می‌کند و می‌تواند برای پردازش بارهای جداگانه به کار رود.

بیشتر درباره این مفهوم

Storage Engine

بخشی از database که شیوه ذخیره‌سازی و دسترسی به داده‌های جدول را مدیریت می‌کند.

بیشتر درباره این مفهوم

Percona در یک آزمایش با WooCommerce،؜ پردازش گزارش‌های تحلیلی را از database اصلی فروشگاه جدا می‌کند: transaction‌های فروشگاه روی InnoDB باقی می‌مانند و داده‌ها با asynchronous replication به یک Replica با DuckDB می‌روند. هدف این چیدمان، سپردن بار OLAP به Replica است، درحالی‌که database اصلی بار OLTP را پردازش می‌کند.

تفاوت اصلی به شیوه ذخیره‌سازی مربوط است. database‌های row-oriented داده‌های هر رکورد را کنار هم نگه می‌دارند؛ در مقابل، database‌های columnar مقدارهای هر ستون را پیوسته ذخیره می‌کنند تا خواندن فقط ستون‌های انتخاب‌شده ممکن باشد. InnoDB،؜ به‌عنوان Storage Engine پیش‌فرض MySQL،؜ برای OLTP مناسب است؛ اما query‌های OLAP با بررسی، گروه‌بندی و خلاصه‌کردن میلیون‌ها یا میلیاردها ردیف، الگوی متفاوتی دارند.

WooCommerce برای گزارش‌های داخلی خود مستقیماً سراغ جدول‌های زنده سفارش نمی‌رود. این محصول مجموعه‌ای از جدول‌های lookup با داده‌های خلاصه‌شده و denormalized نگه می‌دارد که در پس‌زمینه به‌روز می‌شوند. بنابراین گزارش‌ها به اطلاعات موجود در همین جدول‌ها محدود هستند. جدول wp_wc_order_stats ستون اصلی گزارش‌های درآمد و سفارش است و برای هر سفارش یک ردیف دارد.

در آزمایش Percona،؜ داده‌ها شامل ۴۰۰ هزار سفارش و ۵ هزار محصول بودند که با WooCommerce Smooth Generator بارگذاری شدند. هر دو database روی یک میزبان اجرا شدند: مبدأ با Percona Server for MySQL 8.0.46 و Replica با AliSQL 8.0.44-2،؜ شاخه Alibaba از MySQL که DuckDB را به‌عنوان Storage Engine در اختیار می‌گذارد. برای InnoDB Buffer Pool و محدودیت حافظه DuckDB،؜ مقدار ۴ GiB تنظیم شد.

در Replica،؜ گزینه force_innodb_to_duckdb فعال شد تا جدول‌هایی که از مسیر replication یا mysqldump ساخته می‌شوند، به‌جای InnoDB از DuckDB استفاده کنند. اندازه پوشه database در نسخه InnoDB برابر ۷٫۳ GiB بود؛ داده‌های نسخه DuckDB در ۶۰۱ MiB جا گرفتند. منبع این اختلاف را کاهش حدود ۱۲ برابری فضای دیسک توصیف می‌کند.

برای هدایت گزارش‌ها هم یک محدودیت وجود داشت: WooCommerce از اتصال مشترک WordPress یعنی $wpdb استفاده می‌کند و تنظیمی برای فرستادن گزارش‌ها به سروری دیگر ندارد. راهکار آزمایش، اجرای یک کپی دوم از همان WooCommerce بود که فقط DB_HOST آن به Replica اشاره می‌کرد؛ ترافیک تحلیلی به این کپی فرستاده می‌شد. بخش ارائه‌شده از منبع، نتیجه‌ای از مقایسه زمان اجرای گزارش‌ها ندارد.

نکته کلیدی

کاهش فضای دیسک را با کاهش زمان اجرای گزارش یکی نگیر؛ این بخش از منبع فقط برای اولی عدد دارد. برای دنبال‌کردن این چیدمان، به تبدیل Storage Engine در Replica و اتصال کپی دوم WooCommerce دقت کن.

خواندن مقاله اصلی (در زبانه‌ی جدید باز می‌شود)
برچسب‌ها (۸)