ehsan rafee
ehsan rafee
خواندن ۲ دقیقه·۵ سال پیش

استفاده از OLAP Cube

OLAP Cube
OLAP Cube

خیلی خودمونی و از تجربه شخصی خودم می نویسم.

مشکل چی بود؟

مشکل اول این بود که حجم دیتا بسیار زیاد بود

مشکل دوم این بود که برای آماده کردن خروجی، محاسبات خیلی سنگینی باید انجام میشد که دیتای میلیونی درش دخیل بود.

مشکل سوم چندین لایه محسابه که همه لایه ها از پایین به بالا از خروجی محاسبه لایه قبلی + محاسبه خود لایه به دست میومد.

اولین راه چاره: redis

مدتی از redis استفاده کردم، همونطور که احتمالا میدونید به طور خیلی ساده redis یک دیتابیس key/value هستش که دیتای خودش رو داخل ram نگه میداره و بسیار بسیار سرعت بالایی داره(البته تنظیمات برای ذخیره داخل دیسک هم داره ولی با ساختار خودش).

کارساز بود ولی مشکلاتی هم داشت، اولین مشکل این که وقتی دیتا تغییر میکرد باید کل پروسه محاسبه رو تکرار میکردیم، که خیلی بار سنگینی روی سرور میزاشت، البته که میشد سطرهای درگیر رو دوباره محاسبه کرد ولی باز تعدادشون خیلی زیاد بود و باز هم بار سنگینی متحمل میشدیم، بماند که محاسبه سطر های درگیر توی محاسبه چقدر چالش داشت!

دومین راه چاره: data werhosing

پس از بررسی های بسیار، کلا به این نتیجه رسیدیم راه چاره ما نیست! کلا بیخیال، توضیح هم نمیدم در موردش، خیلی بحثش مفصله.(شاید مقاله ای دیگر :-)

سومین راه چاره: OLAP Cube

اول این که این تکنیک چیه؟

به شکل ساده اگر بخام توضیح بدم یک یا چند جدول هستش توی دیتابیس که هر کدومشون چند وجه داره(توضیح میدم).

سنت ها و راه حل های مدرن

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

سوال اینجا است که چرا؟

همه میدونیم که relation بار سنگینی داره پس تا جای ممکن حذفش میکنیم. چرا افزونگی ایجاد میکنیم؟ چون میخایم روابط رو به حداقل برسونیم و با بهینه ترین query به دیتای نهایی برسیم. البته که این همه ماجرا نیست!

محاسباتی اگر وجود داره باید انجام بشه و در کنار دیتای خام قرار بگیره، این کار باعث میشه تا حد امکان performance سیستم بالا بره و حجم محاسبات کم و بار محاسبات به طور درستی تقسیم بشه، و حداقل سطر های ممکن update بشن.

تا اینجا متوجه شدیم که کار به این سادگی ها نیست!

چند پرسش خیلی مهم وجود داره که موقع طراحی و تحلیل باید بهشون پاسخ بدید.

نقاط ورود دیتا کجا است؟

کجا باید محاسبه انجام بشه؟

کدوم سطرها باید دوباره محاسبه بشه؟

جدول من چند وجه داره؟

چه خروجی هایی از این جدول انتظار دارم بگیرم؟

بعد از پاسخ دقیق به این پرسش ها میشه به تحلیل cube پرداخت و دست به طراحی زد.


هدف صرفا معرفی این تکنیک بود، از آنجایی که وقتی با big data درگیر هستید و محاسبات پیچیده چند لایه ای، ذکر مثال بسیار سخته، پس به معرفی این تکنیک بسنده میکنم و بعدا مقاله رو کامل تر خواهم کرد.

اگر پرسشی هست با اشتیاق در خدمت شما هستم. پیشاپیش از کمک شما برای تکمیل این مطلب سپاسگزارم.

olapcube
برنامه نویس - موزیسین - طبیعت گرد ehsan-rafee.ir
شاید از این پست‌ها خوشتان بیاید