معمولا استارت‌آپ‌ها از یه حدی که بزرگ‌تر میشن لازم دارن که دادههای سیستم‌شون رو تحلیل کنن که بتون تصمیمات بیزینسی رو بر اساس دادههای کاربراشون بگیرند و نه صرفا بر اساس حدس و گمان‌های خودشون.
در اول راه همیشه این تیم بکند هست که در سازمان مسئول فراهم کردن راهکاری برای تیم مدیریتی و بیزینس هست که بتونن دادههای تحلیلی مورد نیازشون رو داشته باشن.
یکی از راه‌هایی که خیلی مرسومه اضافه کردن داشبورد تحلیل به پنل ادمین (بکافیس) هست که برنامه نویس‌های بکند رو مجبور میکنه وقت زیادی از کارشون رو به نوشتن کوئری‌های پیچیده اختصاص بدن تا بتونن دادههای تحلیلی مورد نیاز رو ارائه بدن.
این کار معمولا در ابتدا با چند کوئری تحلیلی نسبتا ساده شروع میشه، مثلا:
- تعداد کل کاربران ثبت‌نامی امروز
- جمع مبلغ خرید به تفکیک روز
اما، فقط اندکی بعد کوئری ها خیلی پیچیده‌تر میشه و معمولا با کوئری زدن روی یک یا دو جدول دیتابیس هم بدست نمیاد، مثلا:
- لیست محصولات به همراه جمع کل مبلغ خریداری شده، به همراه تعداد کاربر منحصر به فردی که خرید انجام شده، به همراه تعداد شهرهای منحصر به فردی که این محصول رو سفارش دادند، به همراه میانگین مدت زمان ارسال هر محصول
شاید در نگاه اول درخواست عجیب و غریبی باشه، اما احتمالا با درخواست و کوئری های عجیب و غریب تر از این هم روبرو شده باشید و یا در آینده روبرو بشید.
تجربه‌ای که به صورت شخصی با این چالش داشتم به این صورت بوده که مجبور شدم کلی کوئری‌های کند عجیب و غریب بنویسم که یه حجم بسیار زیادی از دادههای دیتابیس رو شامل میشه و معمولا بهینه‌سازی این کوئری ها هم به این راحتی‌ها نیست.
اولین مشکلی که بوجود میاد اینه که این کوئری‌های پیچیده عملکرد دیتابیس رو برای کارهای حیاتی‌تر دچار اختلال میکنه و کاربران سرویس رو دچار مشکل میکنه. در ابتدایی‌ترین حالت، راه حلی که به ذهنمون میرسه اینه که دیتابیس replica داشته باشیم و همه کوئری‌های تحلیلی رو منتقل کنیم به دیتابیس replica که عملکرد سرویس اصل دچار اختلال و کندی نشه.
اما این پایان ماجرا نیست، اندکی بعد، با زیاد شدن حجم داده‌ها، عملا کوئری‌های نوشته شده به قدری کند میشن که دیگه قابل استفاده نیستن. بهینه کردن کوئری هم خیلی دردی رو دوا نمیکنه و شما هر طور هم که بخوای کوئری بزنی، باز اون حجم زیاد داده و اون کوئری‌های عجیب و غریب چالش برانگیز هستند.
راه حل مرسوم در اینطور مواقع چیه؟ دادههای دیتابیس رو باید duplicate کنیم. اما نه روی یک دیتابیس دیگه از همون جنس دیتابیس اصلی، بلکه duplicate کردن روی یک گونه متفاوت از دیتابیس که عملیات کوئری زدن رو ساده کنه.
در این مقاله، به خوبی اهمیت تفکیک و تفاوت‌های فنی دیتابیس‌های مناسب برای تراکنش (OLTP) و دیتابیس‌های مناسب برای تحلیل (OLAP) رو ذکر کرده.
به طور خلاصه بخوام بگم، در دیتابیس‌های مناسب برای تراکنش که معمولا دیتابیس اصلی ما میشه نحوه دسترسی به داده به این صورته که لازمه به صورت concurrent و همزمان چندین کاربر بتونن روی یک یا تعداد محدودی از رکوردهای دیتابیس تراکنشی رو اجرا کنند. مثلا رکورد پروفایل خودشون رو آپدیت کنند. در این گونه دیتابیس‌ها معمولا کاربران با حجم خیلی کمی از داده سر و کار دارند و عملیات write روی دادههای دیتابیس زیاد اتفاق میفته. اون هم به صورت همزمان و توسط تعداد زیادی کاربر. پس استفاده از دیتابیس‌های تراکنشی برای تضمین یکپارچگی داده لازمه. ساختار این‌گونه داده‌ها معمولا تشکیل شده از یک سری جدول normalize شده که از طریق primary key و foreign key با هم در ارتباط هستند که هم از duplicate شدن داده و زیاد شدن حجم داده‌ها کم بشه و هم یکپارچگی داده حفظ بشه.
در طرف مقابل دیتابیس‌های مناسب برای تحلیل معمولا داده‌ها رو بصورت denormalize شده دارن، حتی گاها یک OBT یا one-big-table دارند که همه‌داده‌های مربوط به جداول مختلف در یک جدول ذخیره میشه. مزیت بزرگ این کار راحت شدن کار تحلیلگران هست که می‌تونن با استفاده از کوئری های راحت تر، و در مدت زمان کوتاه‌تر، کوئری‌های پیچیده خودشون رو پیاده‌سازی کنن.
معمولا از دیتابیس‌های مبتنی بر row یا ردیف برای ذخیره دادههای OLTP استفاده می‌کنند، چون دادههای مرتبط با یک رکورد همه به صورت سریالی در قسمت مشخصی از دیسک ذخیره میشه. اما در طرف مقابل دادههای دیتابیس OLAP رو معمولا به صورت ستونی ذخیره می‌کنن، چون که برای تحلیل داده معمولا با یک رکورد خاص کار ندارند و نیازمندی‌ها معمولا انجام یک‌سری محاسبه روی کل مقادیر یک یا چند ستون هست، پس بهینه‌تر هست که داده‌ها بصورت ستونی ذخیره بشن.
توصیه می‌کنم متن کامل این مقاله رو مطالعه کنید.