MergeTree

موتور MergeTree و سایر موتورهای این خانواده (*MergeTree) قوی ترین موتورهای جدول ClickHouse هستند.

موتورهای خانواده MergeTree برای درج حجم بسیار زیادی از داده ها در جدول طراحی شده اند. داده ها به سرعت قسمت به قسمت روی جدول نوشته می شوند، سپس قوانینی برای ادغام قطعات در پس زمینه اعمال می شود. این روش بسیار کارآمدتر از بازنویسی مداوم داده ها در ذخیره سازی در حین درج است.

داده های مرتب شده بر اساس کلید اصلی را ذخیره می کند.

این به شما امکان می‌دهد یک فهرست پراکنده کوچک ایجاد کنید که به یافتن سریع‌تر داده‌ها کمک می‌کند.

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

ClickHouse از عملیات خاصی با پارتیشن‌هایی پشتیبانی می‌كند كه كارآمدتر از عملیات عمومی روی داده‌های مشابه با نتیجه مشابه هستند. ClickHouse همچنین به طور خودکار داده های پارتیشن را که در آن کلید پارتیشن بندی در پرس و جو مشخص شده است، قطع می کند.

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

خانواده جداول ReplicatedMergeTree همانند سازی داده ها را فراهم می کند. برای اطلاعات بیشتر، Replication Data را ببینید.

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

در صورت لزوم می توانید روش نمونه گیری داده ها را در جدول تنظیم کنید.

موتور Merge به خانواده *MergeTree تعلق ندارد.

ایجاد یک جدول

برای توضیح پارامترها، توضیحات ایجاد پرس و جو را ببینید.

بندهای پرس و جو

موتور

ENGINE - نام و پارامترهای موتور. ENGINE = MergeTree() . موتور MergeTree پارامتری ندارد.

ORDER_BY

ORDER BY - کلید مرتب سازی.

چند نام ستون یا عبارات دلخواه. مثال: ORDER BY (CounterID، EventDate) .

اگر کلید اصلی به صراحت توسط عبارت PRIMARY KEY تعریف نشده باشد، ClickHouse از کلید مرتب سازی به عنوان کلید اصلی استفاده می کند.

اگر نیازی به مرتب سازی ندارید از دستور ORDER BY tuple() استفاده کنید. به انتخاب کلید اصلی مراجعه کنید.

پارتیشن توسط

PARTITION BY - کلید پارتیشن بندی. اختیاری. در بیشتر موارد به کلید پارتیشن نیازی ندارید و در بیشتر موارد دیگر به کلید پارتیشن بیشتر از ماهها نیاز ندارید. پارتیشن بندی سرعت پرس و جوها را افزایش نمی دهد (برخلاف عبارت ORDER BY). هرگز نباید از پارتیشن بندی خیلی دانه ای استفاده کنید. داده‌های خود را بر اساس شناسه‌ها یا نام‌های مشتری تقسیم نکنید (به جای آن، شناسه کلاینت را بسازید یا ستون اول را در عبارت ORDER BY نامگذاری کنید).

برای پارتیشن بندی بر اساس ماه، از عبارت toYYYYMM(date_column) استفاده کنید، جایی که date_column ستونی با تاریخ از نوع Date است. نام پارتیشن ها در اینجا دارای فرمت "YYYYMM" هستند.

کلید اولیه

کلید اصلی - کلید اصلی اگر با کلید مرتب‌سازی متفاوت باشد. اختیاری.

به طور پیش فرض کلید اصلی همان کلید مرتب سازی است (که توسط عبارت ORDER BY مشخص می شود). بنابراین در بیشتر موارد، تعیین یک عبارت PRIMARY KEY جداگانه ضروری نیست.

نمونه توسط

SAMPLE BY - عبارتی برای نمونه گیری. اختیاری.

اگر از یک عبارت نمونه استفاده می شود، کلید اصلی باید حاوی آن باشد. نتیجه یک عبارت نمونه باید یک عدد صحیح بدون علامت باشد. مثال: SAMPLE BY intHash32(UserID) ORDER BY (CounterID، EventDate، intHash32(UserID)) .

TTL - فهرستی از قوانینی که مدت زمان ذخیره سازی ردیف ها را مشخص می کند و منطق حرکت خودکار قطعات بین دیسک ها و حجم ها را تعریف می کند. اختیاری.

در نتیجه عبارت باید دارای یک ستون Date یا DateTime باشد. مثال:

نوع قانون DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'|GROUP BY عملی را مشخص می کند که در صورت رضایت عبارت (به زمان فعلی می رسد) با قسمت انجام شود: حذف ردیف های منقضی شده، انتقال بخشی (اگرعبارت برای همه ردیف‌های یک قسمت) به دیسک مشخص (TO DISK 'xxx' ) یا به حجم (TO VOLUME 'xxx') یا جمع‌آوری مقادیر در ردیف‌های منقضی شده برآورده می‌شود. نوع پیش‌فرض این قانون حذف (DELETE) است. فهرستی از قوانین متعدد را می توان مشخص کرد، اما نباید بیش از یک قانون DELETE وجود داشته باشد.

تنظیمات

پارامترهای اضافی که رفتار MergeTree را کنترل می کنند (اختیاری):

index_granularity

index_granularity - حداکثر تعداد ردیف های داده بین علائم یک شاخص. مقدار پیش فرض: 8192. به ذخیره سازی داده ها مراجعه کنید.

index_granularity_bytes

index_granularity_bytes - حداکثر اندازه دانه های داده بر حسب بایت. مقدار پیش فرض: 10 مگابایتبرای محدود کردن اندازه گرانول فقط بر اساس تعداد ردیف ها، روی 0 تنظیم کنید (توصیه نمی شود). ذخیره داده را ببینید.

min_index_granularity_bytes

min_index_granularity_bytes - حداقل اندازه مجاز دانه های داده بر حسب بایت. مقدار پیش فرض: 1024b. برای ایجاد حفاظت در برابر ایجاد تصادفی جداول با index_granularity_bytes بسیار کم. ذخیره داده را ببینید.

enable_mixed_granularity_parts​

enable_mixed_granularity_parts — انتقال برای کنترل اندازه دانه با تنظیم index_granularity_bytes را فعال یا غیرفعال می کند. قبل از نسخه 19. 11، فقط تنظیم index_granularity برای محدود کردن اندازه گرانول وجود داشت. تنظیم index_granularity_bytes عملکرد ClickHouse را هنگام انتخاب داده ها از جداول با ردیف های بزرگ (ده ها و صدها مگابایت) بهبود می بخشد. اگر جدول هایی با ردیف های بزرگ دارید، می توانید این تنظیم را برای جداول فعال کنید تا کارایی پرس و جوهای SELECT را بهبود بخشد.

use_minimalistic_part_header_in_zookeeper​

use_minimalistic_part_header_in_zookeeper - روش ذخیره سازی هدرهای قطعات داده در Zookeeper. اگر use_minimalistic_part_header_in_zookeeper = 1 ، سپس Zookeeper داده های کمتری را ذخیره می کند. برای اطلاعات بیشتر ، توضیحات تنظیم را در "پارامترهای پیکربندی سرور" مشاهده کنید.

min_merge_bytes_to_use_direct_io

min_merge_bytes_to_use_direct_io - حداقل حجم داده برای عملکرد ادغام که برای استفاده مستقیم از دسترسی مستقیم I/O به دیسک ذخیره سازی لازم است. هنگام ادغام قطعات داده ، Clickhouse حجم کل ذخیره تمام داده های ادغام شده را محاسبه می کند. اگر حجم بیش از min_merge_bytes_to_use_direct_io بایت است ، با استفاده از رابط مستقیم I/O (گزینه O_DIRECT) ، داده ها را می خواند و داده ها را به دیسک ذخیره سازی می نویسد. اگر min_merge_bytes_to_use_direct_io = 0 ، سپس مستقیم I/O غیرفعال است. مقدار پیش فرض: 10 * 1024 * 1024 * 1024 بایت.

merge_with_ttl_timeout

merge_with_ttl_timeout - حداقل تأخیر در ثانیه قبل از تکرار ادغام با حذف TTL. مقدار پیش فرض: 14400 ثانیه (4 ساعت).

merge_with_reecompression_ttl_timeout

merge_with_reecompression_ttl_timeout - حداقل تأخیر در ثانیه قبل از تکرار ادغام با TTL Recompression. مقدار پیش فرض: 14400 ثانیه (4 ساعت).

try_fetch_recompressed_part_timeout

try_fetch_recompressed_part_timeout - زمان (در ثانیه) قبل از شروع ادغام با بازخوانی. در این مدت Clickhouse سعی می کند بخشی از ماکت را که این ادغام را با استفاده مجدد از آن اختصاص داده است ، دریافت کند. مقدار پیش فرض: 7200 ثانیه (2 ساعت).

Writ_final_mark

write_final_mark - نوشتن علامت فهرست نهایی را در انتهای قسمت داده (بعد از آخرین بایت) فعال یا غیرفعال می کند. مقدار پیش فرض: 1. آن را خاموش نکنید.

merge_max_block_size

merge_max_block_size - حداکثر تعداد ردیف در بلوک برای عملیات ادغام. مقدار پیش فرض: 8192.

انباره

min_bytes_for_wide_part

min_bytes_for_wide_part ، min_rows_for_wide_part - حداقل تعداد بایت/ردیف در یک قسمت داده که می تواند در قالب گسترده ذخیره شود. شما می توانید یکی ، هر دو یا هیچ یک از این تنظیمات را تنظیم کنید. به ذخیره سازی داده ها مراجعه کنید.

max_parts_in_total

max_parts_in_total - حداکثر تعداد قطعات در تمام پارتیشن ها.

max_compress_block_size

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

min_compress_block_size

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

max_partitions_to_read

MAX_PARTITIONS_TO_READ - حداکثر تعداد پارتیشن هایی را که می توان در یک پرس و جو به آنها دسترسی داشت ، محدود می کند. همچنین می توانید تنظیمات max_partitions_to_read را در تنظیمات جهانی مشخص کنید.

مثال تنظیم بخش ها

در مثال ، ما پارتیشن بندی را بر اساس ماه تعیین می کنیم.

ما همچنین عبارتی را برای نمونه گیری به عنوان هش توسط شناسه کاربر تنظیم کردیم. این به شما امکان می دهد تا داده های موجود در جدول را برای هر Counterid و EventDate شبه کنید. اگر هنگام انتخاب داده یک بند نمونه را تعریف کنید ، Clickhouse یک نمونه داده به طور مساوی Pseudorandom را برای زیر مجموعه ای از کاربران باز می گرداند.

تنظیم index_granulary می تواند حذف شود زیرا 8192 مقدار پیش فرض است.

روش کاهش یافته برای ایجاد یک جدول

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

پارامترهای تبلیغاتی ()

• تاریخ ستون-نام ستونی از نوع تاریخ. Clickhouse به طور خودکار پارتیشن ها را بر اساس این ستون ایجاد می کند. نام های پارتیشن در قالب "yyyymm" است.
• نمونه برداری_ بیان - عبارتی برای نمونه برداری.
• (اولیه ، کلید) - کلید اصلی. نوع: tuple ()
• index_granularity - دانه بندی یک شاخص. تعداد ردیف های داده بین "علائم" یک فهرست. مقدار 8192 برای اکثر کارها مناسب است.

مثال

موتور Mergetree به همان روشی که در مثال بالا برای روش تنظیمات اصلی موتور پیکربندی شده است ، پیکربندی شده است.

ذخیره داده ها

یک جدول شامل قطعات داده طبقه بندی شده بر اساس کلید اصلی است.

هنگامی که داده ها در یک جدول درج می شوند ، قطعات داده جداگانه ایجاد می شوند و هر یک از آنها به صورت واژگانی توسط کلید اصلی طبقه بندی می شوند. به عنوان مثال ، اگر کلید اصلی (Counterid ، Date) باشد ، داده های موجود در قسمت توسط CounterID طبقه بندی می شوند و در هر CounterID ، تا تاریخ سفارش می شود.

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

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

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

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

اندازه گرانول توسط تنظیمات index_granulary و index_granularity_bytes موتور جدول محدود شده است. بسته به اندازه ردیف ها ، تعداد ردیف های موجود در یک گرانول در محدوده [1 ، index_granulary] قرار دارد. اگر اندازه یک ردیف واحد بیشتر از مقدار تنظیم باشد ، اندازه یک گرانول می تواند از index_granularity_bytes فراتر رود. در این حالت ، اندازه گرانول با اندازه ردیف برابر است.

کلیدها و فهرست های اولیه در نمایش داده شد

به عنوان نمونه ، کلید اصلی (counterid ، date) را بگیرید. در این حالت ، مرتب سازی و شاخص را می توان به شرح زیر نشان داد:

اگر پرس و جو داده مشخص شود:

• Counterid در ('A' ، 'H') ، سرور داده ها را در محدوده علائم [0 ، 3) و [6 ، 8) می خواند.
• counterid در ("A" ، "H") و تاریخ = 3 ، سرور داده ها را در محدوده علائم [1 ، 3) و [7 ، 8) می خواند.
• تاریخ = 3 ، سرور داده ها را در محدوده علائم می خواند [1 ، 10].

مثالهای بالا نشان می دهد که استفاده از یک شاخص همیشه مؤثرتر از یک اسکن کامل است.

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

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

Clickhouse به یک کلید اصلی منحصر به فرد نیاز ندارد. می توانید چندین ردیف را با همان کلید اصلی وارد کنید.

شما می توانید از عبارات دارای نرمال قابل تهی در کلید اصلی و سفارش توسط بندها استفاده کنید اما به شدت دلسرد می شود. برای اجازه دادن به این ویژگی ، تنظیمات Allow_Nullable_Key را روشن کنید. اصل nulls_last برای مقادیر تهی در بند توسط بند اعمال می شود.

انتخاب کلید اصلی

تعداد ستون های موجود در کلید اصلی به صراحت محدود نیست. بسته به ساختار داده ، می توانید ستون های بیشتر یا کمتر را در کلید اصلی قرار دهید. این ممکن است:

عملکرد یک شاخص را بهبود بخشید.

اگر کلید اصلی (A ، B) باشد ، در صورت برآورده شدن شرایط زیر ، اضافه کردن ستون دیگر C عملکرد را بهبود می بخشد:

• نمایش داده شدگان با شرط در ستون C وجود دارد.
• دامنه داده های طولانی (چندین برابر بیشتر از index_granulary) با مقادیر یکسان برای (A ، B) متداول است. به عبارت دیگر ، هنگام افزودن ستون دیگری به شما امکان می دهد تا از محدوده داده های بسیار طولانی پرش کنید.

فشرده سازی داده ها را بهبود بخشید.

Clickhouse داده ها را بر اساس کلید اصلی انواع ، بنابراین هرچه قوام بالاتر باشد ، فشرده سازی نیز بهتر می شود.

منطق اضافی را هنگام ادغام قطعات داده در موتورهای CollapsingMergetree و SummingMergetree ارائه دهید.

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

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

می توانید با استفاده از Syntax Tuple () یک جدول بدون کلید اصلی ایجاد کنید. در این حالت ، Clickhouse داده ها را به ترتیب درج ذخیره می کند. اگر می خواهید هنگام درج داده ها با درج ، سفارش داده را ذخیره کنید. Queries را انتخاب کنید ، max_insert_threads = 1 را تنظیم کنید.

برای انتخاب داده ها به ترتیب اولیه ، از نمایش داده های انتخاب تک رشته ای استفاده کنید.

انتخاب یک کلید اصلی که با کلید مرتب سازی متفاوت است

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

این ویژگی هنگام استفاده از موتورهای جدول SummingMergetree و AggregatingMergetree مفید است. در یک مورد مشترک هنگام استفاده از این موتورها ، جدول دارای دو نوع ستون است: ابعاد و اقدامات. نمایش داده شدگان معمولی مقادیر کل ستون های اندازه گیری با گروه دلخواه توسط و فیلتر کردن با ابعاد. از آنجا که SummingMergetree و AggregatingMergetree ردیف های جمع شده با همان مقدار کلید مرتب سازی ، طبیعی است که تمام ابعاد را به آن اضافه کنید. در نتیجه ، عبارت کلیدی شامل یک لیست طولانی از ستون ها است و این لیست باید اغلب با ابعاد تازه اضافه شده به روز شود.

در این حالت منطقی است که فقط چند ستون را در کلید اصلی قرار دهید که اسکن های محدوده کارآمد را ارائه می دهد و ستون های ابعاد باقیمانده را به کلید مرتب سازی برقی اضافه می کند.

Alter of the Sorting Key یک عمل سبک وزن است زیرا وقتی یک ستون جدید به طور همزمان به جدول و به کلید مرتب سازی اضافه می شود ، قطعات داده موجود نیازی به تغییر ندارند. از آنجا که کلید مرتب سازی قدیمی پیشوند کلید مرتب سازی جدید است و هیچ داده ای در ستون تازه اضافه شده وجود ندارد ، داده ها در لحظه اصلاح جدول توسط کلیدهای مرتب سازی قدیمی و جدید طبقه بندی می شوند.

استفاده از فهرست ها و پارتیشن ها در نمایش داده شد

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

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