ویژگیا Materialized view در کاساندرا

ویژگی ویژیگی نما های از پیش تولید شده در نسخه 3.0 کاساندرا و نسخه های بعدی از آن اضافه شده است. materialized view جدولی است که از داده­ های جدول دیگری با کلید اصلی و مشخصه­ های جدید ایجاد می­شود. اما  materialized view چه قابلیت هایی را برای ما ایجاد میکند؟

از دردسرهای کاساندرا برای کاربران تازه کار، این است که کاساندرا یک پایگاه داده مبتنی بر درخواست است یعنی بر اساس کوئری های SQL که برروی داده های در آینده اجرا خواهیم کرد، میبایست داده ها را ذخیره می کنیم. از طرفی نحوه بازیابی داده ها نیز، کاملا بسته به کلید اصلی (یا کلید پارتیشن) آن جدول دارد و روی فیلدهای غیر کلید، نمی توان پرسوجو و جستجو انجام داد. این نقطه ضعف موجب میشود که برای یک جدول خاص با کوئری های متفاوت،‌ گاهی مجبور می شویم چندین جدول درست کنیم که داده های یکسانی را ذخیره می کنند منتها هر کدام در یک کیلد اصلی متفاوت دارند و برای یک کوئری خاص ایجاد شده اند و البته با سریعترین زمان ممکن به ما پاسخ می دهند ولی منابع ذخیره سازی ما را به شدت اشغال میکنند.

در کاساندرا، پرس­وجوها با استفاده از تعریف کلید اصلی، قابلیت اجرا پیدا میکنند. به عبارتی اگر بخش where در عبارت select در هر پرس­وجویی براساس کلیدهای اصلی متفاوتی باشد، در نسخه های پیش از 3.0، به اجبار میبایست یکی از دو راهکار زیر برای اجرای درخواست پرسوجو انتخاب شود:

(1) ایجاد یک جدول جدید با کلیدهای اصلی متفاوت که قابلیت پاسخ به درخواست پرسوجوی مورد نظر را برای ما ایجاد کن.

(2) استفاده از اندیس ثانویه برای فیلد مورد نظر که به این طریق قابلیت پاسخ به درخواست پرسوجوی مورد نظر را برای ما ایجاد کند.

برای مثال با فرض درخواست زیر (درخواست 1):

جدول  user1 با کلید­ پارتیشن user_id و کلید­ خوشه­ بندی birthday می­تواند به پرس­وجوی (درخواست 1) بطور بهینه پاسخ دهد:

اکنون برای پاسخ به پرس­وجو زیر (درخواست 2):

راهکار اول: ایجاد جدول جدید

می­توان جدولی جدید با کلید پارتیشن usr_id و کلیدهای خوشه ­بندی name و birthday ایجاد کرد:

  • نقاط قوت این روش:
    • کاساندرا می­تواند بصورت بهینه به هر دو پرس­وجوی پاسخ دهد (برای پاسخ به هر کدام از پرس­وجوها دقیقا به جدول های متناظر هر کدام  رجوع می­کند).
  • نقاط ضعف این روش:
    •  درج و بهنگام ­سازی برای داده های یکسان، باید برای دو جدول اعمال شوند.
    •  داده های یکسان، در دو جدول تکرار می­شوند که البته با توجه به حصول کارایی بالا، می­توان از این ضعف، چشم­پوشی کرد.

راهکار دوم: اسفاده از ایندکس ثانویه

می­توان بر روی ستون­ name در جدول user1، اندیس ثانویه اعمال نمود:

اکنون کاساندرا می­تواند بدون اعمال ALLOW FILTERING به پرس­وجوی (درخواست 2)، پاسخ دهد.

  • نقاط قوت این روش:
    • دیگر نیازی به ایجاد جدولی دیگر نیست و درنتیجه درج و بهنگام ­سازی، تنها در یک جدول (جدول user1) اعمال می­شوند.
  • نقاط ضعف این روش:
    • امکان ایجاد شاخص در یک جدول، در نسخه های قبلی کاساندرا به آن اضافه شد و تاحدود زیادی مشکل فوق را حل می کرد اما به ازای هر نیاز جدید ، باید ایندکس جدید زده میشد یا جدولی جدید ساخته میشد و ساختار برنامه ها هم به تبع آن، گاهی نیازمند تغییر می شد .
    •   کاساندرا برای پاسخ به پرس­وجوی (درخواست 2)، اگر فیلد user_id ذکر نشده باشد مجبور است تمام نودها را جستجو کند.
    •   در این­گونه از پرس­وجوها که ALLOW FILTERING لازم است، به موجب همین نیاز کاساندرا مجبور است ابتدا تمام نتایج را انتخاب و سپس سطرهایی که مرتبط با birthday و name ) نیستند را پالایش یا حذف می­کند. که این عمل حذف کردن کار پر هزینه ای شناخته می شود.

راهکار سوم: استفاده ویژیگی نما های از پیش تولید شده materialized view

اما در نسخه­ های سری 3.0 کاساندرا، می­توان از قابلیت materialized view بهره برد. این ویژگی در نسخه 3.0 کاساندرا و نسخه های بعدی از آن اضافه شده است. materialized view جدولی است که از داده­ های جدول دیگری با کلید اصلی و مشخصه­ های جدید ایجاد می­شود.

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

نما های از پیش تولید شده یا Materialized view
نما های از پیش تولید شده یا Materialized view

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

  • نقاط قوت این روش:
    • با هر درج اطلاعات در جدول اصلی، این نماها هم به طور خودکار آپدیت شوند و نگرانی قدیمی بودن این نماها وجود ندارد.
    • دیگر نیاز به تعریف جدول های مختلف با ساختار یکسان برای یک موجودیت نخواهد بود.
    • سرعت اجرا در مقایسه با استفاده از قابلیت ALLOW FILTERING بهبود پیدا میکند.
    • نتایج از قبل محاسبه شده هستند.
نما های از پیش تولید شده یا Materialized view

مدیریت سرور پشتیبانی و مشاوره – ثبت دامنه

نوشته های مشابه