Allow Filtering در پایگاه داده ی کاساندرا
امروزه تولید کننده های پایگاه داده های غیر رابطه ای (nosql) در حال تلاش برای اضافه کردن قابلیت هایی برای افزایش توانمندی های خود هستن.از اندیس‌ها میتوان برای بهبود عملکرد پایگاه‌داده استفاده کرد. اندیس‌ها به سرویس‌دهنده پایگاه‌داده اجازه می‌دهد تا سطرهای خاص را سریع‌تر از حالت بدون اندیس بیابد.
اما نکته اینجاست: از دردسرهای کاساندرا برای کاربران تازه کار، این است که کاساندرا یک پایگاه داده مبتنی بر درخواست است یعنی بر اساس کوئری های که برروی داده های در آینده اجرا خواهیم کرد، میبایست داده ها را ذخیره می کنیم. از طرفی نحوه بازیابی داده ها نیز، کاملا بسته به کلید اصلی یا کلید پارتیشن آن جدول دارد و روی فیلدهای غیر کلید، نمی توان پرسوجو و جستجو انجام داد.
این نقطه ضعف موجب میشود که برای یک جدول خاص با کوئری های متفاوت، گاهی مجبور می شویم چندین جدول درست کنیم که داده های یکسانی را ذخیره می کنند منتها هر کدام در یک کیلد اصی متفاوت دارند و برای یک کوئری خاص ایجاد شده اند و یا اینکه از ایندکس ثانویه استفاده کنیم ولی باید بدانیم که این روش ها منابع ذخیره سازی ما را به شدت اشغال میکنند.
در پست های گذشته در رابطه با خاصیت نماهای از پیش تولید شده یا Materialized view در کاساندرا که جایگزینی برای ایندکس ثانویه بود مطالبی ارائه شد. همچنین انواع ایندکس گذاری در پایگاه داده و قابلیت نمایه گذاری SASI جهت فعال نمودن inverted index در کاساندرا مورد بررسی قرار گرفت. در این مبحث به قابلیت پالایش داده ها کساندرا میپردازیم. قابلیت پالایش داده ها از کساندرا 3.6 برای بهره برداری بهتر از کاساندرا به این پایگاه داده اضافه شد. با قابلیت Allow Filtering از کساندرا 3.6 به بعد بدون استفاده از ایندکس ثانویه میتوان در جدول مورد نظر، درخواست پرسوجوی (where) بر روی هر فیلدی انجام داد بدون آنکه در شرط کلید پارتیشن یا کلید اصلی ذکر شود. همچنین بعد انجام ایندکس ثانویه میتوان در جدول مورد نظر، درخواست پرسوجوی (where) بر روی هر فیلدی که ایندکس ثانویه شده، بدون آنکه در شرط کلید پارتیشن یا کلید اصلی ذکر شود، انجام داد.
نکته: استفاده از قابلیت Allow Filtering بر روی نتایج خیلی بزرگ مناسب نیست.
نکته: استفاده از قابلیت Allow Filtering بر روی داده های هایی که به واسطه استفاده از Allow Filtering تعداد زیادی از آنها حذف میشود. هزینه زیادی دارد و یک استفاده صحیح از Allow Filtering نیست.
نکته: استفاده از قابلیت Allow Filtering در اصل فیلتر زدن بر روی نتیجه داده های select است به عبارتی گویا یک درخواست دوم بر روی درخواست اول انجام میشود.
نکته: استفاده از قابلیت Allow Filtering در اصل فیلتر زدن بر روی نتیجه داده های select است که در سمت استفاده کننده از درخواست پردازش میشود به عیارتی سربار این عمل بر روی کامپیوتر مصرف کننده از این دستور است. (البته تا جایی که متوجه شدم بعدا اگر وقت کردم بررسی میکنم و این نکته را اصلاح میکنم)
حال به کدهای زیر توجه کنید تا محل استفاده درست از Allow Filtering را به درستی بیاموزید.
|
1 2 3 4 5 6 7 8 9 10 11 |
CREATE TABLE temperature ( weatherstation_id text, event_time timestamp, temperature text, PRIMARY KEY (weatherstation_id,event_time) ); |
OK Request;
|
SELECT * FROM temperature WHERE weatherstation_id in (‘1234ABCD’,‘5678EFGH’); |
OK Request;
|
SELECT * FROM temperature WHERE event_time in (‘2013-04-03 06:00’,‘2013-04-03 07:00’); |
Bad Request: Cannot use IN operator on column not part of the partition key
|
SELECT * FROM temperature WHERE event_time in (‘2013-04-03 06:00’,‘2013-04-03 07:00’) ALLOW FILTERING; |
OK Request;
|
SELECT * FROM temperature WHERE weatherstation_id in (‘1234ABCD’,‘5678EFGH’) AND event_time in (‘2013-04-03 06:00’,‘2013-04-03 07:00’); |
OK Request;
|
cqlsh:test> SELECT * FROM temperature WHERE temperature in (’32F’,’33F’); |
Bad Request: Cannot use IN operator on column not part of the partition key
|
cqlsh:test> SELECT * FROM temperature WHERE temperature in (’32F’,’33F’) ALLOW FILTERING; |
OK Request;
|
cqlsh:test> create index on temperature (temperature); cqlsh:test> SELECT * FROM temperature WHERE temperature in (’32F’,’33F’); |
OK Request;
آدرس منبع:
http://mechanics.flite.com/blog/2014/01/08/the-in-operator-in-cassandra-cql/
مدیریت سرور پشتیبانی و مشاوره – ثبت دامنه