درک شاخص های پرش از داده های Clickhouse

بسیاری از عوامل بر عملکرد پرس و جو Clickhouse تأثیر می گذارد. عنصر مهم در اکثر سناریوها این است که آیا Clickhouse می تواند هنگام ارزیابی پرس و جو در جایی که شرط بند است ، از کلید اصلی استفاده کند. بر این اساس ، انتخاب یک کلید اصلی که در مورد رایج ترین الگوهای پرس و جو اعمال می شود ، برای طراحی جدول مؤثر ضروری است.

Neverthels ، مهم نیست که چقدر کلید اصلی را با دقت تنظیم کرده است ، به ناچار موارد استفاده از پرس و جو وجود خواهد داشت که نمی توانند از آن استفاده کنند. کاربران معمولاً برای داده های نوع سری زمانی به Clickhouse متکی هستند ، اما آنها اغلب مایل به تجزیه و تحلیل همان داده ها با توجه به سایر ابعاد تجاری ، مانند شناسه مشتری ، URL وب سایت یا شماره محصول هستند. در این حالت ، عملکرد پرس و جو می تواند به طور قابل توجهی بدتر باشد زیرا ممکن است یک اسکن کامل از هر مقدار ستون لازم باشد تا شرایط بند را اعمال کند. در حالی که Clickhouse هنوز هم در این شرایط نسبتاً سریع است ، ارزیابی میلیون ها یا میلیاردها ارزش فردی باعث می شود که نمایش داده شدگان "غیر شاخص" بسیار آهسته تر از موارد مبتنی بر کلید اصلی انجام شود.

در یک پایگاه داده رابطه ای سنتی ، یک رویکرد برای این مشکل اتصال یک یا چند شاخص "ثانویه" به یک جدول است. این یک ساختار درخت B است که به پایگاه داده اجازه می دهد تا به جای زمان O (n) (یک اسکن جدول) ، تمام ردیف های تطبیق موجود در دیسک را در زمان O (log (n)) پیدا کند ، جایی که n تعداد ردیف ها است. با این حال ، این نوع شاخص ثانویه برای Clickhouse (یا سایر پایگاه داده های ستون گرا) کار نمی کند زیرا هیچ ردیف جداگانه ای در دیسک وجود ندارد تا به شاخص اضافه شود.

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

عمل اصلی

کاربران فقط می توانند از شاخص های پرش از داده ها در خانواده Mergetree جداول استفاده کنند. هر پرش از داده ها چهار آرگومان اصلی دارد:

• نام فهرستاز نام فهرست برای ایجاد پرونده فهرست در هر پارتیشن استفاده می شود. همچنین ، هنگام رها کردن یا تحقق شاخص ، به عنوان یک پارامتر مورد نیاز است.
• بیان فهرستاز بیان شاخص برای محاسبه مجموعه مقادیر ذخیره شده در فهرست استفاده می شود. این می تواند ترکیبی از ستون ها ، اپراتورهای ساده و/یا زیر مجموعه توابع تعیین شده توسط نوع شاخص باشد.
• نوع. نوع شاخص محاسبه ای را که تعیین می کند از خواندن و ارزیابی هر بلوک شاخص امکان پذیر است ، کنترل می کند.
• دانه دانه بودن. هر بلوک شاخص از گرانول های دانه ای تشکیل شده است. به عنوان مثال ، اگر دانه بندی شاخص جدول اولیه 8192 ردیف باشد ، و دانه بندی شاخص 4 است ، هر "بلوک" فهرست بندی شده 32768 ردیف خواهد بود.

هنگامی که یک کاربر یک شاخص پرش از داده ایجاد می کند ، در هر فهرست قسمت داده برای جدول دو پرونده اضافی وجود خواهد داشت.

• SKP idx . idx ، که حاوی مقادیر بیان شده است
• SKP IDX . MRK2 ، که شامل جبران های مربوطه در پرونده های ستون داده مرتبط است.

اگر بخشی از شرایط فیلتر بند جایی که در هنگام اجرای پرس و جو و خواندن پرونده های ستون مربوطه با بیان شاخص Skip مطابقت دارد ، Clickhouse از داده های پرونده فهرست استفاده می کند تا مشخص شود که آیا هر بلوک مربوطه باید پردازش شود یا می توان از آن دور شد (با فرض این موضوعاین بلوک قبلاً با استفاده از کلید اصلی حذف نشده است). برای استفاده از یک مثال بسیار ساده ، جدول زیر را که با داده های قابل پیش بینی بارگذاری شده است در نظر بگیرید.

هنگام اجرای یک پرس و جو ساده که از کلید اصلی استفاده نمی کند ، تمام 100 میلیون مدخل در ستون My_Value اسکن می شوند:

اکنون یک فهرست پرش بسیار اساسی اضافه کنید:

به طور معمول شاخص های پرش فقط روی داده های تازه درج شده اعمال می شوند ، بنابراین فقط اضافه کردن این فهرست بر پرس و جو فوق تأثیر نمی گذارد.

برای فهرست بندی داده های موجود در حال حاضر ، از این عبارت استفاده کنید:

پرس و جو را با فهرست تازه ایجاد شده دوباره ارسال کنید:

به جای پردازش 100 میلیون ردیف 800 مگابایت ، Clickhouse فقط 32768 ردیف 360 کیلوبایت را خوانده و تجزیه و تحلیل کرده است - چهار گرانول 8192 ردیف.

به شکل بصری تر ، اینگونه است که 4096 ردیف با My_Value 125 خوانده و انتخاب شده و چگونه ردیف های زیر بدون خواندن از دیسک رد می شوند:

کاربران می توانند با فعال کردن ردیابی هنگام اجرای نمایش داده ها ، به اطلاعات دقیق در مورد استفاده از فهرست Skip دسترسی پیدا کنند. از Clickhouse-Client ، SEND_LOGS_LEVEL را تنظیم کنید:

این کار اطلاعات اشکال زدایی مفیدی را هنگام تلاش برای تنظیم شاخص های پرس و جو SQL و جدول ارائه می دهد. از مثال بالا ، گزارش اشکال زدایی نشان می دهد که شاخص پرش همه به جز دو گرانول کاهش یافته است:

انواع شاخص پرش

ممتاز

این نوع شاخص سبک وزن نیازی به پارامتری ندارد. این حداقل و حداکثر مقادیر بیان شاخص را برای هر بلوک ذخیره می کند (اگر عبارت یک Tuple باشد ، به طور جداگانه مقادیر را برای هر یک از اعضای عنصر Tuple ذخیره می کند). این نوع برای ستون هایی که تمایل به مرتب سازی بر اساس ارزش دارند ایده آل است. این نوع شاخص معمولاً کمترین هزینه در هنگام پردازش پرس و جو است.

این نوع شاخص فقط به درستی با یک بیان مقیاس یا tuple کار می کند - این شاخص هرگز به عباراتی اعمال نمی شود که یک آرایه یا نوع داده نقشه را برگردانده اند.

این نوع شاخص سبک وزن یک پارامتر واحد از max_size از مقدار تعیین شده در هر بلوک را می پذیرد (0 تعداد نامحدودی از مقادیر گسسته را مجاز می کند). این مجموعه حاوی تمام مقادیر موجود در بلوک است (یا اگر تعداد مقادیر بیش از max_size باشد خالی است). این نوع شاخص به خوبی با ستون هایی با کاردینال بودن کم در هر مجموعه از گرانول ها (در اصل ، "جمع شده با هم") کار می کند اما به طور کلی کاردینال بالاتر است.

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

انواع فیلتر شکوفه

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

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

سه نوع شاخص پرش داده بر اساس فیلترهای Bloom وجود دارد:

Bloom_filter اساسی که یک پارامتر اختیاری واحد از نرخ مجاز "مثبت کاذب" بین 0 تا 1 می گیرد (در صورت نامشخص ، از 025 استفاده می شود).

tokenbf_v1 تخصصی. این سه پارامتر طول می کشد ، همه مربوط به تنظیم فیلتر شکوفه مورد استفاده است: (1) اندازه فیلتر در بایت (فیلترهای بزرگتر دارای مثبت کاذب کمتری هستند ، با هزینه ای در ذخیره سازی) ، (2) تعداد توابع هش اعمال شده (دوباره ،فیلترهای هش بیشتر باعث کاهش مثبت کاذب) و (3) دانه برای عملکردهای هش فیلتر شکوفه می شوند. برای جزئیات بیشتر در مورد چگونگی تأثیر این پارامترها بر عملکرد فیلتر شکوفه ، ماشین حساب را در اینجا مشاهده کنید. این شاخص فقط با داده های رشته ، ثابت و نقشه کار می کند. بیان ورودی به توالی های شخصیت جدا شده توسط کاراکترهای غیر آلفانوم تقسیم می شود. به عنوان مثال ، مقدار ستون این کاندیدای جستجوی "متن کامل" است که شامل نشانه هایی خواهد بود که این یک نامزد برای جستجوی متن کامل است. این در نظر گرفته شده برای استفاده در موارد مشابه ، برابر ، در ، Hastoken () و جستجوهای مشابه برای کلمات و مقادیر دیگر در رشته های طولانی تر است. به عنوان مثال ، یک استفاده احتمالی ممکن است در جستجوی تعداد کمی از نام کلاس یا شماره خط در یک ستون از خطوط ورود به سیستم برنامه رایگان باشد.

NGRAMBF_V1 تخصصی. این شاخص همانند شاخص توکن است. قبل از تنظیمات فیلتر Bloom ، یک پارامتر اضافی طول می کشد ، اندازه Ngrams برای فهرست بندی. NGRAM یک رشته کاراکتر از طول n از هر کاراکتر است ، بنابراین رشته یک رشته کوتاه با اندازه Ngram 4 به صورت فهرست بندی می شود:

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

توابع شاخص پرش

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

• داده ها درج شده و شاخص به عنوان یک عبارت عملکردی (با نتیجه عبارت ذخیره شده در پرونده های شاخص) تعریف می شود ، یا
• پرس و جو پردازش می شود و بیان برای مقادیر شاخص ذخیره شده اعمال می شود تا مشخص شود که آیا این بلوک را حذف می کند.

هر نوع شاخص SKIP روی زیر مجموعه ای از توابع Clickhouse موجود متناسب با اجرای فهرست ذکر شده در اینجا کار می کند. به طور کلی ، شاخص های مجموعه و شاخص های مبتنی بر فیلتر شکوفه (نوع دیگری از شاخص مجموعه) هر دو بدون هماهنگ هستند و بنابراین با دامنه کار نمی کنند. در مقابل ، شاخص های Minmax به ویژه با دامنه ها کار می کنند زیرا تعیین اینکه آیا محدوده محدوده بسیار سریع است. اثربخشی توابع مربوط به مسابقات جزئی مانند ، startswith ، endswith و Hastoken به نوع شاخص مورد استفاده ، بیان شاخص و شکل خاص داده ها بستگی دارد.

تنظیمات فهرست پرش

دو تنظیم در دسترس وجود دارد که در مورد شاخص های پرش اعمال می شود.

• use_skip_indexes (0 یا 1 ، پیش فرض 1). همه نمایش داده ها نمی توانند به طور مؤثر از شاخص های پرش استفاده کنند. اگر احتمالاً یک وضعیت فیلتر خاص شامل بیشتر گرانول ها باشد ، استفاده از شاخص پرش از داده ها هزینه غیر ضروری و گاه قابل توجهی را متحمل می شود. مقدار 0 را برای پرس و جو که بعید است از هرگونه شاخص پرش بهره مند شوند ، روی 0 تنظیم کنید.
• force_data_skipping_indexes (لیست جدا شده کاما از نام فهرست). از این تنظیم می توان برای جلوگیری از برخی از انواع پرس و جوهای ناکارآمد استفاده کرد. در شرایطی که پرس و جو یک جدول بسیار گران است مگر اینکه از شاخص پرش استفاده شود ، با استفاده از این تنظیم با یک یا چند نام فهرست ، استثنائی را برای هر پرس و جو که از فهرست ذکر شده استفاده نمی کند ، باز می گرداند. این امر مانع از استفاده از پرس و جوهای ضعیف از منابع سرور می شود.

از بهترین روشها پرش کنید

شاخص های پرش بصری نیستند ، به خصوص برای کاربرانی که به شاخص های مبتنی بر ردیف ثانویه از قلمرو RDMS یا شاخص های معکوس از فروشگاه های اسناد عادت کرده اند. برای به دست آوردن هرگونه مزایایی ، استفاده از شاخص پرش از داده های Clickhouse باید از خواندن کافی گرانول برای جبران هزینه محاسبه شاخص جلوگیری کند. از نظر انتقادی ، اگر یک مقدار حتی یک بار در یک بلوک شاخص رخ دهد ، به این معنی است که کل بلوک باید در حافظه خوانده شود و ارزیابی شود و هزینه شاخص بی نیاز بوده است.

توزیع داده های زیر را در نظر بگیرید:

فرض کنید اصلی/سفارش بر اساس کلید Timestamp است و یک فهرست در Visitor_ID وجود دارد. پرس و جو زیر را در نظر بگیرید:

Timestamp ، url را از جدول که در آن بازدید کننده_ید = 1001 انتخاب کنید انتخاب کنید

یک شاخص ثانویه سنتی با این نوع توزیع داده ها بسیار سودمند خواهد بود. به جای خواندن هر 32678 ردیف برای یافتن 5 ردیف با Visitor_ID درخواست شده ، شاخص ثانویه فقط پنج مکان ردیف را شامل می شود و فقط آن پنج ردیف از دیسک خوانده می شوند. برعکس دقیقاً برای شاخص پرش از داده های Clickhouse صادق است. تمام 32678 مقادیر موجود در ستون VISITOR_ID بدون در نظر گرفتن نوع شاخص پرش آزمایش می شوند.

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

در بیشتر موارد ، یک شاخص پرش مفید نیاز به یک همبستگی قوی بین کلید اصلی و ستون/بیان غیرقانونی هدفمند دارد. اگر هیچ ارتباطی وجود نداشته باشد (مانند نمودار فوق) ، احتمال اینکه شرایط فیلتر حداقل توسط یکی از ردیف های موجود در بلوک چند هزار مقدار برآورده شود ، زیاد است و تعداد کمی از بلوک ها رد می شوند. در محدودیت ، اگر طیف وسیعی از مقادیر برای کلید اصلی (مانند زمان روز) به شدت با مقادیر موجود در ستون شاخص بالقوه (مانند سن بیننده تلویزیون) همراه باشد ، احتمالاً یک نوع شاخص Minmax مفید خواهد بود. توجه داشته باشید که ممکن است در هنگام وارد کردن داده ها ، یا با درج ستون های اضافی در مرتب سازی/ترتیب توسط کلید ، یا درج های دسته ای به گونه ای که مقادیر مرتبط با کلید اصلی درج گروه بندی می شوند ، این همبستگی را افزایش دهید. به عنوان مثال ، تمام وقایع برای یک سایت خاص می توانند توسط فرآیند Instind گروه بندی و در کنار هم قرار گیرند ، حتی اگر کلید اصلی یک جدول زمانی باشد که حاوی رویدادهایی از تعداد زیادی از سایت ها باشد. این منجر به بسیاری از گرانول ها می شود که فقط دارای چند شناسه سایت هستند ، بنابراین می توان هنگام جستجو توسط یک مقدار خاص سایت_id ، بلوک های زیادی را رد کرد.

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

در نهایت، بهترین تمرین کلیدی، تست، تست، تست است. باز هم، برخلاف نمایه های ثانویه b-tree یا نمایه های معکوس برای جستجوی اسناد، رفتار فهرست پرش داده ها به راحتی قابل پیش بینی نیست. افزودن آنها به یک جدول هزینه قابل توجهی را هم برای دریافت داده و هم برای جستجوهایی که به هر دلیلی از شاخص سود نمی برند، متحمل می شود. آنها باید همیشه بر روی نوع داده های دنیای واقعی آزمایش شوند و آزمایش باید شامل تغییرات نوع، اندازه دانه بندی و سایر پارامترها باشد. آزمایش اغلب الگوها و مشکلاتی را آشکار می کند که تنها از طریق آزمایش های فکری آشکار نیستند.