مطالعه بیشتر

نحوه سریع‌تر کردن بارگذاری داشبوردهای خود.

سریع‌تر کردن داشبوردها

نحوه سریع‌تر کردن بارگذاری داشبوردهای خود.

وقتی به عملکرد داشبورد می‌رسد، اساساً چهار راه برای سریع‌تر کردن بارگذاری داشبوردها وجود دارد:

درخواست داده کمتر.
Cache کردن پاسخ‌ها به سؤال‌ها.
سازماندهی داده برای پیش‌بینی سؤال‌های رایج.
پرسیدن سؤال‌های کارآمد.

آنچه در ادامه می‌آید برخی راهنمایی‌های کلی برای نحوه سریع‌تر کردن بارگذاری داشبوردهای شما است. بخش عمده این راهنمایی روی آن bullet سوم متمرکز می‌شود، یا نحوه سازماندهی داده برای پیش‌بینی رایج‌ترین سؤال‌هایی که داده برای پاسخ دادن به آن‌ها استفاده می‌شود.

هشدارهای معمول درباره بهینه‌سازی زودرس که ریشه همه شر است اعمال می‌شود. توصیه ما فرض می‌کند که شما برای مدتی داده خود را کاوش کرده‌اید، و از بینش‌هایی که داده ارائه می‌دهد منافع مادی به دست می‌آورید. فقط پس از آن باید بپرسید، "چگونه این داشبورد را سریع‌تر بارگذاری کنم؟"

درخواست داده کمتر

این نکته تقریباً آنقدر واضح است که اغلب نادیده گرفته می‌شود، اما باید اولین مکان برای شروع باشد. آیا واقعاً به داده‌ای که پرس‌وجو می‌کنید نیاز دارید؟ و حتی اگر به همه آن داده نیاز دارید، چقدر مکرر به آن نیاز دارید؟

می‌توانید زمان زیادی را با محدود کردن داده‌ای که پرس‌وجو می‌کنید صرفه‌جویی کنید، مثل شامل کردن یک فیلتر پیش‌فرض روی یک داشبورد. به خصوص به داده‌های spanning زمان و فضا توجه کنید: آیا واقعاً نیاز دارید هر روز به داده‌های سه‌ماهه گذشته نگاه کنید؟ یا آیا واقعاً به هر تراکنش برای هر کشور نیاز دارید؟

و حتی اگر نیاز دارید آن اطلاعات را بدانید، آیا هر روز به آن نیاز دارید؟ آیا می‌توانید آن سؤال را به داشبورد دیگری relocate کنید که معمولاً فقط هفتگی یا ماهانه بررسی می‌شود؟

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

Cache کردن پاسخ‌ها به سؤال‌ها

نیازی به انتظار برای داده ندارید اگر از قبل load شده است. مدیران می‌توانند متابیس را برای cache کردن نتایج پرس‌وجو تنظیم کنند، که پاسخ‌ها به سؤال‌ها را ذخیره می‌کند. اگر مجموعه‌ای از داشبوردها دارید که همه وقتی کامپیوترهای خود را اولین بار صبح باز می‌کنند اجرا می‌کنند، آن داشبورد را از قبل اجرا کنید، و سؤال‌ها در آن داشبورد از نتایج ذخیره شده برای اجراهای بعدی استفاده می‌کنند تا در ثانیه‌ها load شوند. مشتریان گزینه refresh کردن داده را خواهند داشت، اما معمولاً این غیرضروری است، چون اغلب مشتریان فقط نیاز دارند داده از روز قبل و قبل از آن را بررسی کنند.

مدیران می‌توانند قوانین caching را در تب Performance از پنل Admin پیکربندی کنند. می‌توانید انتخاب کنید cache را برای تعدادی ساعت نگه دارید، از یک schedule تنظیم شده برای invalidate کردن cache استفاده کنید، یا از زمان اجرای متوسط یک پرس‌وجو برای تعیین مدت زمان cache کردن نتایج آن استفاده کنید.

در طرح‌های Pro و Enterprise همچنین می‌توانید سیاست‌های caching خاص برای داشبوردها و سؤال‌های فردی تنظیم کنید.

می‌توانید از تحلیل‌های استفاده متابیس برای تعیین زمان معمول اجرای مشتریان از سؤال‌های مختلف استفاده کنید، سپس یک اسکریپت با استفاده از API متابیس برای اجرای برنامه‌نویسی این سؤال‌ها (در نتیجه cache کردن نتایج آن‌ها) از قبل ایجاد کنید. به این ترتیب، وقتی مشتریان وارد می‌شوند و به داشبوردهای خود navigate می‌کنند، نتایج در ثانیه‌ها load می‌شوند. حتی بدون انجام آن مرحله اضافی "pre-warming"، وقتی اولین شخص شما آن پرس‌وجوی کند را load می‌کند، برای بقیه مشتریان شما cache می‌شود.

سازماندهی داده برای پیش‌بینی سؤال‌های رایج

بهترین کار بعدی که می‌توانید انجام دهید سازماندهی داده خود به گونه‌ای است که سؤال‌هایی که پرسیده می‌شوند را پیش‌بینی کند، که بازیابی آن داده را برای پایگاه داده شما آسان‌تر می‌کند.

ایندکس کردن ستون‌های مکرراً پرس‌وجو شده.
replicate کردن پایگاه داده خود.
denormalize کردن داده.
materialize کردن viewها: ایجاد جداول جدید برای ذخیره نتایج پرس‌وجو.
تجمیع داده از قبل با جداول خلاصه.
کشیدن داده از JSON و قرار دادن کلیدهای آن در ستون‌ها.
در نظر گرفتن یک پایگاه داده خاص برای تحلیل.

همه به جز آن بخش آخر زیر فرض می‌کند از یک پایگاه داده رابطه‌ای سنتی مثل PostgreSQL یا MySQL استفاده می‌کنید. آن بخش آخر درباره انتقال به یک نوع کاملاً متفاوت پایگاه داده tune شده به خصوص برای handle کردن تحلیل است، و باید آخرین راه‌حل شما باشد، به خصوص برای استارتاپ‌ها.

ایندکس کردن ستون‌های مکرراً پرس‌وجو شده

افزودن ایندکس‌ها به پایگاه داده شما می‌تواند عملکرد پرس‌وجو را به طور قابل توجهی بهبود بخشد. اما همانطور که منطقی نیست همه چیز را در یک کتاب ایندکس کنیم، ایندکس‌ها مقداری overhead دارند، پس باید به طور استراتژیک استفاده شوند.

نحوه استفاده استراتژیک از ایندکس‌ها؟ بیشتر جداول پرس‌وجو شده خود، و ستون‌های معمولاً پرس‌وجو شده در آن جداول را پیدا کنید. می‌توانید پایگاه داده فردی خود را برای دریافت این فراداده مشورت کنید. به عنوان مثال، PostgreSQL فراداده روی اعداد و عملکرد پرس‌وجو از طریق ماژول pg_stat_statements خود ارائه می‌دهد.

به یاد داشته باشید کار ساده پرسیدن از کاربران متابیس خود که کدام سؤال‌ها و داشبوردها برای آن‌ها مهم است، و اگر "کندی" را تجربه می‌کنند انجام دهید. فیلدهایی که اغلب نیاز به ایندکس دارند یا مبتنی بر زمان یا مبتنی بر id هستند—به timestampها روی داده رویداد، یا IDها روی داده دسته‌ای فکر کنید.

به طور جایگزین، در طرح‌های Pro و Enterprise، می‌توانید از تحلیل‌های استفاده متابیس استفاده کنید، که دیدن اینکه چه کسی کدام پرس‌وجوها را اجرا می‌کند، چقدر مکرر، و چقدر طول کشید آن پرس‌وجوها رکوردها را برگردانند را آسان می‌کند.

وقتی جداول و ستون‌هایی که می‌خواهید ایندکس کنید را شناسایی کردید، مستندات پایگاه داده خود را برای یادگیری نحوه تنظیم ایندکس‌ها (مثلاً، در اینجا ایندکس کردن در PostgreSQL) مشورت کنید.

ایندکس‌ها آسان برای تنظیم (و take down) هستند. در اینجا فرمت پایه برای یک statement CREATE INDEX:

CREATE INDEX index_name ON table_name (column_name)

به عنوان مثال:

CREATE INDEX orders_id_index ON orders (id)

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

replicate کردن پایگاه داده خود

اگر از یک پایگاه داده برای handle کردن هم عملیات (مثلاً، تراکنش‌های برنامه مثل ثبت سفارش، به‌روزرسانی اطلاعات پروفایل، و غیره) و هم برای تحلیل (مثلاً، برای پرس‌وجوهایی که داشبوردهای متابیس را power می‌کنند) استفاده می‌کنید، ایجاد یک replica از آن پایگاه داده production برای استفاده به عنوان یک پایگاه داده فقط-تحلیل را در نظر بگیرید. متابیس را به آن replica متصل کنید، replica را هر شب به‌روزرسانی کنید، و بگذارید تحلیل‌گران شما پرس‌وجو کنند. پرس‌وجوهای long-running تحلیل‌گران با عملیات روزمره پایگاه داده production شما تداخل نخواهند داشت، و برعکس.

خارج از سریع‌تر کردن داشبوردهای شما، نگه داشتن یک پایگاه داده replica برای تحلیل داده یک روش خوب برای دنبال کردن است تا از تأثیر پرس‌وجوهای تحلیلی potentially long-running روی محیط production خود جلوگیری کنید.

denormalize کردن داده

در برخی موارد، ممکن است منطقی باشد denormalize برخی از جداول خود (یعنی، ترکیب چندین جدول به یک جدول بزرگ‌تر با ستون‌های بیشتر). در نهایت مقداری داده redundant ذخیره می‌کنید (مثل شامل کردن اطلاعات کاربر هر بار که کاربر سفارش می‌دهد)، اما تحلیل‌گران مجبور نیستند چندین جدول را join کنند تا داده مورد نیاز برای پاسخ دادن به سؤال‌های خود را دریافت کنند.

materialize کردن viewها: ایجاد جداول جدید برای ذخیره نتایج پرس‌وجو

با viewهای materialized، داده خام، denormalized خود را در جداول آن‌ها نگه می‌دارید، و جداول جدید (معمولاً در ساعات off) ایجاد می‌کنید تا نتایج پرس‌وجو را ذخیره کنید که داده از چندین جدول را به روشی که سؤال‌هایی که تحلیل‌گران می‌پرسند را پیش‌بینی می‌کند ترکیب می‌کند.

به عنوان مثال، ممکن است اطلاعات سفارش و محصول را در جداول مختلف ذخیره کنید. می‌توانید، یک بار در شب، یک view materialized ایجاد (یا به‌روزرسانی) کنید که ستون‌های مکرراً پرس‌وجو شده از هر دو آن جداول را ترکیب می‌کند، و آن view materialized را به سؤال‌های خود در متابیس متصل کنید. اگر از یک پایگاه داده برای هم production و هم تحلیل استفاده می‌کنید، علاوه بر حذف فرآیند join مورد نیاز برای ترکیب آن داده، پرس‌وجوهای شما مجبور نیستند با readها و writeهای production روی آن جداول رقابت کنند.

تفاوت بین یک view materialized و یک عبارت جدول مشترک (CTE، گاهی اوقات view نامیده می‌شود)، این است که view materialized نتایج خود را در پایگاه داده ذخیره می‌کند (و بنابراین می‌تواند ایندکس شود). CTEها اساساً subqueryها هستند، و هر بار محاسبه می‌شوند. ممکن است cache شوند، اما در پایگاه داده ذخیره نمی‌شوند.

viewهای materialized، با این حال، منابع را در پایگاه داده شما مصرف می‌کنند، و باید view را به صورت دستی به‌روزرسانی کنید (refresh materialized view [name]).

تجمیع داده از قبل با جداول خلاصه

ایده در اینجا استفاده از viewهای materialized—یا حتی یک مجموعه جداگانه از جداول—برای ایجاد جداول خلاصه که محاسبه را به حداقل می‌رسانند است. بگویید جداولی با یک میلیون ردیف دارید، و می‌خواهید داده را در چندین ستون تجمیع کنید. می‌توانید یک view materialized بر اساس تجمیع‌های یک یا چند جدول ایجاد کنید، که محاسبه اولیه (زمان‌بر) را انجام می‌دهد. به جای اینکه یک داشبورد داده خام را چندین بار در طول یک روز پرس‌وجو و محاسبه کند، می‌توانید به جای آن سؤال‌هایی ایجاد کنید که آن جدول خلاصه را پرس‌وجو می‌کنند تا داده محاسبه شده شب قبل را دریافت کنند.

به عنوان مثال، می‌توانید یک جدول سفارشات داشته باشید که شامل همه جدول سفارشات است، و یک جدول خلاصه سفارشات که هر شب به‌روزرسانی می‌شود و rollupها و سایر داده‌های تجمیع شده، مثل کل سفارشات در هر هفته، ماه، و غیره را ذخیره می‌کند. اگر شخصی می‌خواهد سفارشات فردی استفاده شده برای محاسبه آن تجمیع را مشاهده کند، می‌توانید از مقاصد سفارشی برای لینک کردن کاربران به یک سؤال یا داشبورد که *داده خام را پرس‌وجو می‌کند استفاده کنید.

کشیدن داده از JSON و قرار دادن کلیدهای آن در ستون‌ها

اغلب می‌بینیم سازمان‌ها اشیاء JSON را در یک ستون واحد از یک پایگاه داده رابطه‌ای مثل MySQL یا PostgreSQL ذخیره می‌کنند. معمولاً، این سازمان‌ها payloadهای JSON را از نرم‌افزار تحلیل رویداد مثل Segment، یا Amplitude ذخیره می‌کنند.

اگرچه برخی پایگاه‌های داده می‌توانند JSON را ایندکس کنند (PostgreSQL می‌تواند binaryهای JSON را ایندکس کند، به عنوان مثال)، هنوز باید هر بار شیء JSON کامل را grab کنید، حتی اگر فقط به یک جفت کلید-مقدار در شیء علاقه‌مند هستید. به جای آن، استخراج هر فیلد از این اشیاء JSON و map کردن آن کلیدها به ستون‌ها در یک جدول را در نظر بگیرید.

در نظر گرفتن یک پایگاه داده بهینه شده برای تحلیل

اگر همه موارد بالا را انجام داده‌اید، و طول زمان بارگذاری داشبوردهای شما هنوز با توانایی شما برای تصمیم‌گیری به موقع تداخل دارد، باید استفاده از یک پایگاه داده که به طور خاص برای fielding پرس‌وجوهای تحلیلی ساختار یافته است را در نظر بگیرید. این پایگاه‌های داده به عنوان پایگاه‌های داده پردازش تحلیل آنلاین (OLAP) (گاهی اوقات data warehouse نامیده می‌شوند) شناخته می‌شوند.

پایگاه‌های داده رابطه‌ای سنتی مثل PostgreSQL و MySQL برای پردازش تراکنش طراحی شده‌اند، و به عنوان پایگاه‌های داده پردازش تراکنش آنلاین (OLTP) دسته‌بندی می‌شوند. این پایگاه‌های داده برای استفاده به عنوان پایگاه‌های داده عملیاتی، مثل ذخیره داده برای برنامه‌های وب یا موبایل بهتر مناسب هستند. آن‌ها در handle کردن سناریوی زیر کاملاً خوب هستند: کسی یک نظر متفکرانه، مرتبط، و اصلاً تحریک‌آمیز به وب‌سایت شما ارسال می‌کند، برنامه شما یک درخواست POST به بک‌اند شما fire می‌کند، که نظر و فراداده را به پایگاه داده شما برای ذخیره‌سازی route می‌کند. پایگاه‌های داده OLTP می‌توانند حجم‌های زیادی از تراکنش‌های همزمان مثل پست‌های نظر، checkoutهای سبد خرید، به‌روزرسانی‌های bio پروفایل، و غیره را handle کنند.

تفاوت اصلی بین سیستم‌های OLAP و OLTP این است که پایگاه‌های داده OLAP پرس‌وجوهای تحلیلی مثل sumها، تجمیع‌ها، و سایر عملیات تحلیلی روی مقادیر زیاد داده، و همچنین importهای bulk (از طریق یک ETL) را بهینه می‌کنند، در حالی که پایگاه‌های داده OLTP باید readهای بزرگ از پایگاه داده را با انواع دیگر تراکنش متعادل کنند: insertهای کوچک، به‌روزرسانی‌ها، و deleteها.

OLAPها معمولاً از ذخیره‌سازی ستونی استفاده می‌کنند. در حالی که پایگاه‌های داده رابطه‌ای سنتی (OLTP) داده را بر اساس ردیف ذخیره می‌کنند، پایگاه‌های داده‌ای که از ذخیره‌سازی ستونی استفاده می‌کنند (غیرقابل تعجب) داده را بر اساس ستون ذخیره می‌کنند. این استراتژی ذخیره‌سازی ستونی به پایگاه‌های داده OLAP یک مزیت هنگام خواندن داده می‌دهد، چون پرس‌وجوها مجبور نیستند از ردیف‌های نامربوط غربال کنند. داده در این پایگاه‌های داده معمولاً در جداول fact و dimension سازماندهی می‌شود، با جداول fact (اغلب عظیم) که رویدادها را house می‌کنند. هر رویداد شامل لیستی از attributeها و ارجاعات کلید خارجی به جداول dimension است، که شامل اطلاعات درباره آن رویدادها است: چه کسی درگیر بود، چه اتفاقی افتاد، اطلاعات محصول، و غیره.

متابیس چندین data warehouse محبوب را پشتیبانی می‌کند: Google BigQuery، Amazon Redshift، Snowflake، و Apache Druid (که در تحلیل‌های real-time تخصص دارد). متابیس همچنین Presto را پشتیبانی می‌کند، که یک موتور پرس‌وجو است که می‌تواند با انواع مختلف datastore، از جمله Amazon S3 جفت شود.

همانطور که شروع به استفاده از متابیس می‌کنید، خیلی نگران data store زیربنایی نباشید. اما همانطور که داده شما رشد می‌کند، و adoption متابیس رشد می‌کند، مراقب شاخص‌هایی باشید که ممکن است بخواهید استفاده از یک data warehouse را بررسی کنید. Redshift، به عنوان مثال، می‌تواند petabyteهای داده را پرس‌وجو کند، و scale کند تا داده تاریخی را در Amazon S3 پرس‌وجو کند. و Snowflake به شما اجازه می‌دهد منابع compute خود را به طور پویا scale کنید همانطور که سازمان شما رشد می‌کند.