mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-12-12 17:32:32 +00:00
72 lines
8.0 KiB
Markdown
72 lines
8.0 KiB
Markdown
|
---
|
|||
|
|
machine_translated: true
|
|||
|
|
machine_translated_rev: d734a8e46ddd7465886ba4133bff743c55190626
|
|||
|
|
toc_priority: 45
|
|||
|
|
toc_title: "\u0628\u0627\u0641\u0631"
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# بافر {#buffer}
|
|||
|
|
|
|||
|
|
بافر داده ها به نوشتن در رم, دوره گرگرفتگی به جدول دیگر. در طول عملیات به عنوان خوانده شده, داده ها از بافر و جدول دیگر به طور همزمان به عنوان خوانده شده.
|
|||
|
|
|
|||
|
|
``` sql
|
|||
|
|
Buffer(database, table, num_layers, min_time, max_time, min_rows, max_rows, min_bytes, max_bytes)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
پارامترهای موتور:
|
|||
|
|
|
|||
|
|
- `database` – Database name. Instead of the database name, you can use a constant expression that returns a string.
|
|||
|
|
- `table` – Table to flush data to.
|
|||
|
|
- `num_layers` – Parallelism layer. Physically, the table will be represented as `num_layers` از بافر مستقل. مقدار توصیه شده: 16.
|
|||
|
|
- `min_time`, `max_time`, `min_rows`, `max_rows`, `min_bytes` و `max_bytes` – Conditions for flushing data from the buffer.
|
|||
|
|
|
|||
|
|
داده ها از بافر سرخ و نوشته شده به جدول مقصد اگر همه `min*` شرایط و یا حداقل یک `max*` شرایط ملاقات کرد.
|
|||
|
|
|
|||
|
|
- `min_time`, `max_time` – Condition for the time in seconds from the moment of the first write to the buffer.
|
|||
|
|
- `min_rows`, `max_rows` – Condition for the number of rows in the buffer.
|
|||
|
|
- `min_bytes`, `max_bytes` – Condition for the number of bytes in the buffer.
|
|||
|
|
|
|||
|
|
در طول عملیات نوشتن داده ها به یک `num_layers` تعداد بافر تصادفی. یا, اگر بخش داده ها برای وارد کردن به اندازه کافی بزرگ است (بیشتر از `max_rows` یا `max_bytes`), این است که به طور مستقیم به جدول مقصد نوشته شده, حذف بافر.
|
|||
|
|
|
|||
|
|
شرایط برای گرگرفتگی داده ها به طور جداگانه برای هر یک از محاسبه `num_layers` بافر. برای مثال اگر `num_layers = 16` و `max_bytes = 100000000`, حداکثر مصرف رم است 1.6 گیگابایت.
|
|||
|
|
|
|||
|
|
مثال:
|
|||
|
|
|
|||
|
|
``` sql
|
|||
|
|
CREATE TABLE merge.hits_buffer AS merge.hits ENGINE = Buffer(merge, hits, 16, 10, 100, 10000, 1000000, 10000000, 100000000)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
ایجاد یک ‘merge.hits\_buffer’ جدول با ساختار مشابه ‘merge.hits’ و با استفاده از موتور بافر. هنگام نوشتن به این جدول, داده ها در رم بافر و بعد به نوشته ‘merge.hits’ جدول 16 بافر ایجاد می کند. اگر 100 ثانیه گذشت یا یک میلیون ردیف نوشته شده یا 100 مگابایت از داده ها نوشته شده است داده ها در هر یک از فوران است; یا اگر به طور همزمان 10 ثانیه گذشت و 10000 ردیف و 10 مگابایت داده ها نوشته شده است. مثلا, اگر فقط یک ردیف نوشته شده است, بعد از 100 ثانیه سرخ خواهد شد, مهم نیست که چه. اما اگر بسیاری از ردیف نوشته شده است, داده خواهد شد هر چه زودتر سرخ.
|
|||
|
|
|
|||
|
|
هنگامی که سرور متوقف شده است, با جدول قطره و یا جدا جدول, داده های بافر نیز به جدول مقصد سرخ.
|
|||
|
|
|
|||
|
|
شما می توانید رشته های خالی را در علامت نقل قول واحد برای پایگاه داده و نام جدول تنظیم کنید. این نشان می دهد عدم وجود یک جدول مقصد. در این مورد, زمانی که شرایط خیط و پیت کردن داده رسیده است, بافر است که به سادگی پاک. این ممکن است برای نگه داشتن یک پنجره داده ها در حافظه مفید باشد.
|
|||
|
|
|
|||
|
|
هنگام خواندن از یک جدول بافر, داده ها هر دو از بافر و از جدول مقصد پردازش (اگر وجود دارد).
|
|||
|
|
توجه داشته باشید که جداول بافر یک شاخص را پشتیبانی نمی کند. به عبارت دیگر, داده ها در بافر به طور کامل اسکن, که ممکن است کند برای بافر بزرگ. (برای داده ها در یک جدول تابع, شاخص است که پشتیبانی استفاده خواهد شد.)
|
|||
|
|
|
|||
|
|
اگر مجموعه ای از ستون ها در جدول بافر می کند مجموعه ای از ستون ها در یک جدول تابع مطابقت ندارد, یک زیر مجموعه از ستون که در هر دو جدول وجود دارد قرار داده شده است.
|
|||
|
|
|
|||
|
|
اگر انواع برای یکی از ستون ها در جدول بافر و یک جدول تابع مطابقت ندارد, یک پیام خطا در ورود به سیستم سرور وارد شده و بافر پاک شده است.
|
|||
|
|
همین اتفاق می افتد اگر جدول تابع وجود ندارد زمانی که بافر سرخ است.
|
|||
|
|
|
|||
|
|
اگر شما نیاز به اجرا را تغییر دهید برای یک جدول تابع و جدول بافر, توصیه می کنیم برای اولین بار حذف جدول بافر, در حال اجرا را تغییر دهید برای جدول تابع, سپس ایجاد جدول بافر دوباره.
|
|||
|
|
|
|||
|
|
اگر سرور غیر طبیعی راه اندازی مجدد, داده ها در بافر از دست داده است.
|
|||
|
|
|
|||
|
|
نهایی و نمونه به درستی برای جداول بافر کار نمی کند. این شرایط به جدول مقصد منتقل می شود, اما برای پردازش داده ها در بافر استفاده نمی شود. اگر این ویژگی های مورد نیاز توصیه می کنیم تنها با استفاده از جدول بافر برای نوشتن, در حالی که خواندن از جدول مقصد.
|
|||
|
|
|
|||
|
|
هنگام اضافه کردن داده ها به یک بافر, یکی از بافر قفل شده است. این باعث تاخیر اگر یک عملیات به عنوان خوانده شده است به طور همزمان از جدول انجام.
|
|||
|
|
|
|||
|
|
داده هایی که به یک جدول بافر قرار داده شده ممکن است در نهایت در جدول تابع در جهت های مختلف و در بلوک های مختلف. به خاطر همین, یک جدول بافر دشوار است به استفاده از برای نوشتن به یک سقوط به درستی. برای جلوگیری از مشکلات, شما می توانید مجموعه ‘num\_layers’ به 1.
|
|||
|
|
|
|||
|
|
اگر جدول مقصد تکرار شده است, برخی از ویژگی های مورد انتظار از جداول تکرار از دست داده در هنگام نوشتن به یک جدول بافر. تغییرات تصادفی به منظور از سطر و اندازه قطعات داده باعث تقسیم بندی داده ها به ترک کار, به این معنی که ممکن است به یک قابل اعتماد ‘exactly once’ ارسال به جداول تکرار.
|
|||
|
|
|
|||
|
|
با توجه به این معایب, ما فقط می توانیم با استفاده از یک جدول بافر در موارد نادر توصیه.
|
|||
|
|
|
|||
|
|
جدول بافر استفاده شده است که بیش از حد بسیاری از درج از تعداد زیادی از سرور بیش از یک واحد از زمان دریافت و داده ها را نمی توان قبل از درج بافر, که به معنی درج می توانید به اندازه کافی سریع اجرا کنید.
|
|||
|
|
|
|||
|
|
توجه داشته باشید که این کار حس برای وارد کردن داده ها یک ردیف در یک زمان را ندارد, حتی برای جداول بافر. این تنها تولید خواهد شد سرعت چند هزار ردیف در هر ثانیه در حالی که قرار دادن بلوک های بزرگتر از داده ها می تواند تولید بیش از یک میلیون ردیف در هر ثانیه (نگاه کنید به بخش “Performance”).
|
|||
|
|
|
|||
|
|
[مقاله اصلی](https://clickhouse.tech/docs/en/operations/table_engines/buffer/) <!--hide-->
|