الانتقال إلى المحتوى الرئيسي
يخزّن البيانات مؤقتًا في RAM، ثم يُفرّغها دوريًا إلى جدول آخر. أثناء عملية القراءة، تُقرأ البيانات من المخزن المؤقت ومن الجدول الآخر في الوقت نفسه.
البديل الموصى به لمحرك الجدول Buffer هو تمكين عمليات الإدراج غير المتزامنة.
Buffer(database, table, num_layers, min_time, max_time, min_rows, max_rows, min_bytes, max_bytes [,flush_time [,flush_rows [,flush_bytes]]])

معلمات المحرّك

database

database – اسم قاعدة البيانات. يمكنك استخدام currentDatabase() أو أي تعبير ثابت آخر يُرجِع سلسلة نصية.

table

table – الجدول الذي ستُفرَّغ إليه البيانات.

num_layers

num_layers – طبقة التوازي. فعليًا، سيُمثَّل الجدول على شكل num_layers من المخازن المؤقتة المستقلة.

min_time, max_time, min_rows, max_rows, min_bytes, and max_bytes

شروط تفريغ البيانات من المخزن المؤقت.

المعلمات الاختيارية للمحرّك

flush_time, flush_rows, and flush_bytes

شروط تفريغ البيانات من المخزن المؤقت في الخلفية (يعني حذفها أو ضبطها على القيمة صفر عدم وجود أي معلمات flush*). تُفرَّغ البيانات من المخزن المؤقت وتُكتب إلى جدول الوجهة إذا تحققت جميع شروط min* أو تحقق شرط واحد على الأقل من شروط max*. كذلك، إذا تحقق شرط واحد على الأقل من شروط flush*، تبدأ عملية تفريغ في الخلفية. ويختلف هذا عن max* لأن flush* يتيح لك ضبط عمليات التفريغ في الخلفية بشكل منفصل لتجنب إضافة كمون إلى استعلامات INSERT على جداول Buffer.

min_time, max_time, and flush_time

شرط للمدة، بالثواني، منذ لحظة أول كتابة في المخزن المؤقت.

min_rows, max_rows, and flush_rows

شرط يتعلق بعدد الصفوف في المخزن المؤقت.

min_bytes, max_bytes, and flush_bytes

شرط يتعلق بعدد البايتات في المخزن المؤقت. أثناء عملية الكتابة، تُدرَج البيانات في مخزن مؤقت عشوائي واحد أو أكثر (يُضبط باستخدام num_layers). أو إذا كان جزء البيانات المراد إدخاله كبيرًا بما يكفي (أكبر من max_rows أو max_bytes)، فتُكتب البيانات مباشرةً إلى الجدول الوجهة مع تجاوز المخزن المؤقت. تُحتسب شروط تفريغ البيانات بشكل منفصل لكل واحد من المخازن المؤقتة ضمن num_layers. على سبيل المثال، إذا كان num_layers = 16 و max_bytes = 100000000، فإن الحد الأقصى لاستهلاك ذاكرة RAM هو 1.6 GB. مثال:
CREATE TABLE merge.hits_buffer AS merge.hits ENGINE = Buffer(merge, hits, 1, 10, 100, 10000, 1000000, 10000000, 100000000)
إنشاء جدول merge.hits_buffer بالبنية نفسها لجدول merge.hits باستخدام المحرّك Buffer. عند الكتابة إلى هذا الجدول، تُخزَّن البيانات مؤقتًا في RAM ثم تُكتب لاحقًا إلى جدول ‘merge.hits’. يُنشأ مخزن مؤقت واحد، وتُفرَّغ البيانات إذا تحقق أحد الشروط التالية:
  • انقضت 100 ثانية منذ آخر عملية تفريغ (max_time) أو
  • تمت كتابة مليون صف (max_rows) أو
  • تمت كتابة 100 ميغابايت من البيانات (max_bytes) أو
  • انقضت 10 ثوانٍ (min_time) وتمت كتابة 10,000 صف (min_rows) و10 ميغابايت (min_bytes) من البيانات
على سبيل المثال، إذا تمت كتابة صف واحد فقط، فسيُفرَّغ بعد 100 ثانية مهما كان الأمر. أما إذا كُتب عدد كبير من الصفوف، فستُفرَّغ البيانات في وقت أقرب. عند إيقاف الخادم، أو عند استخدام DROP TABLE أو DETACH TABLE، تُفرَّغ أيضًا البيانات المخزنة مؤقتًا إلى جدول الوجهة. يمكنك تعيين سلاسل فارغة بين علامتَي اقتباس مفردتَين لاسم قاعدة البيانات واسم الجدول. يشير ذلك إلى عدم وجود جدول وجهة. في هذه الحالة، عند تحقق شروط تفريغ البيانات، يُمسح المخزن المؤقت ببساطة. وقد يكون ذلك مفيدًا للاحتفاظ بنافذة من البيانات في الذاكرة. عند القراءة من جدول Buffer، تُعالَج البيانات من كلٍّ من المخزن المؤقت وجدول الوجهة (إن وُجد). لاحظ أن جدول Buffer لا يدعم فهرسًا. وبعبارة أخرى، تُفحَص البيانات الموجودة في المخزن المؤقت بالكامل، وقد يكون ذلك بطيئًا مع المخازن المؤقتة الكبيرة. (أما البيانات الموجودة في جدول تابع، فسيُستخدم الفهرس الذي يدعمه.) إذا كانت مجموعة الأعمدة في جدول Buffer لا تطابق مجموعة الأعمدة في جدول تابع، فستُدرج مجموعة فرعية من الأعمدة الموجودة في كلا الجدولين. إذا لم تتطابق أنواع أحد الأعمدة بين جدول Buffer والجدول التابع، فستُسجَّل رسالة خطأ في سجل الخادم، ثم يُمسح المخزن المؤقت. ويحدث الأمر نفسه إذا لم يكن الجدول التابع موجودًا عند تفريغ المخزن المؤقت.
سيؤدي تشغيل ALTER على جدول Buffer في الإصدارات الصادرة قبل 26 أكتوبر 2021 إلى حدوث الخطأ Block structure mismatch (انظر #15117 و#30565)، لذا فإن حذف جدول Buffer ثم إعادة إنشائه هو الخيار الوحيد. تحقّق من إصلاح هذا الخطأ في الإصدار الذي تستخدمه قبل محاولة تشغيل ALTER على جدول Buffer.
إذا أُعيد تشغيل الخادم بصورة غير طبيعية، فستُفقد البيانات الموجودة في المخزن المؤقت. لا يعمل FINAL وSAMPLE بشكل صحيح مع جداول Buffer. تُمرَّر هذه الشروط إلى جدول الوجهة، لكنها لا تُستخدم لمعالجة البيانات الموجودة في المخزن المؤقت. وإذا كانت هذه الميزات مطلوبة، فنوصي باستخدام جدول Buffer للكتابة فقط، مع القراءة من جدول الوجهة. عند إضافة البيانات إلى جدول Buffer، يُقفَل أحد المخازن المؤقتة. وقد يؤدي ذلك إلى تأخير إذا كانت تُجرى في الوقت نفسه عملية قراءة من الجدول. قد تنتهي البيانات التي تُدرج في جدول Buffer في الجدول التابع بترتيب مختلف وضمن كتل مختلفة. ولهذا السبب، يصعب استخدام جدول Buffer للكتابة إلى CollapsingMergeTree بصورة صحيحة. ولتجنب المشكلات، يمكنك تعيين num_layers إلى 1. إذا كان جدول الوجهة مكرّرًا، فستفقد بعض الخصائص المتوقعة للجداول المكرّرة عند الكتابة إلى جدول Buffer. وتؤدي التغييرات العشوائية في ترتيب الصفوف وأحجام أجزاء البيانات إلى توقف إزالة التكرار عن العمل، ما يعني أنه لا يمكن الحصول على كتابة موثوقة من نوع ‘مرة واحدة بالضبط’ إلى الجداول المكرّرة. وبسبب هذه العيوب، لا يمكننا التوصية باستخدام جدول Buffer إلا في حالات نادرة. يُستخدم جدول Buffer عند ورود عدد كبير جدًا من عمليات INSERT من عدد كبير من الخوادم خلال وحدة زمنية، وعندما يتعذر تخزين البيانات مؤقتًا قبل الإدراج، ما يعني أن عمليات INSERT لا يمكن أن تعمل بالسرعة الكافية. لاحظ أنه لا جدوى من إدراج البيانات صفًا واحدًا في كل مرة، حتى في جداول Buffer. فهذا لن يحقق سوى سرعة لا تتجاوز بضعة آلاف من الصفوف في الثانية، بينما يمكن أن يؤدي إدراج كتل أكبر من البيانات إلى أكثر من مليون صف في الثانية.
آخر تعديل في ٢٩ يونيو ٢٠٢٦