في أبريل ، اجتمع مهندسو Avito للتجمعات عبر الإنترنت مع Alexey Milovidov ، المطور الرئيسي لـ ClickHouse ، و Kirill Shvakov ، مطور Golang من Integros. ناقشنا كيف نستخدم نظام إدارة قواعد البيانات والصعوبات التي نواجهها.
بناءً على الاجتماع ، قمنا بتجميع مقال مع إجابات الخبراء على أسئلة الجمهور وأسئلة الجمهور حول النسخ الاحتياطية وإعادة مشاركة البيانات والقواميس الخارجية وبرنامج تشغيل Golang وتحديثات إصدار ClickHouse. يمكن أن يكون مفيدًا للمطورين الذين يعملون بالفعل بنشاط مع Yandex DBMS ويهتمون بحاضره ومستقبله. إجابات أليكسي ميلوفيدوف بشكل افتراضي ، ما لم يذكر خلاف ذلك.
احذر ، هناك الكثير من النص تحت القص. نأمل أن يساعدك المحتوى مع الأسئلة على التنقل.
محتوى
إذا كنت لا ترغب في قراءة النص ، يمكنك مشاهدة تسجيل التجمعات . الطوابع الزمنية موجودة في التعليق الأول أسفل الفيديو.
يتم تحديث ClickHouse باستمرار ، لكن بياناتنا ليست كذلك. ماذا نفعل معها؟
يتم تحديث ClickHouse باستمرار ، ولا يتم تحديث بياناتنا التي تمت معالجتها عن طريق التحسين النهائي وهي في نسخة احتياطية.
لنفترض أن لدينا مشكلة ما وأن البيانات ضاعت. قررنا الاستعادة ، واتضح أن الأقسام القديمة التي يتم تخزينها في خوادم النسخ الاحتياطي مختلفة تمامًا عن إصدار ClickHouse المستخدم حاليًا. ماذا تفعل في مثل هذه الحالة ، وهل هذا ممكن؟
الوضع الذي قمت فيه باستعادة البيانات من نسخة احتياطية بالتنسيق القديم ، ولكن في الإصدار الجديد غير متصلة ، أمر مستحيل. نتأكد من أن تنسيق البيانات في ClickHouse يظل متوافقًا دائمًا مع الإصدارات السابقة. يعد هذا أكثر أهمية من التوافق مع الإصدارات السابقة في الوظائف إذا تغير سلوك بعض الوظائف التي نادرًا ما تستخدم. البيانات المخزنة على القرص ، يجب أن يكون الإصدار الجديد من ClickHouse قادرًا دائمًا على القراءة. هذا هو القانون.
ما هي أفضل الممارسات الحالية لنسخ البيانات احتياطيًا من ClickHouse؟
كيفية عمل نسخ احتياطية ، مع الأخذ في الاعتبار أننا قمنا بتحسين العمليات النهائية ، وقاعدة بيانات ضخمة من التيرابايت ، وبيانات تم تحديثها ، لنقل ، للأيام الثلاثة الماضية ، ومن ثم لم تحدث أي إجراءات لهم؟
يمكننا وضع الحل الخاص بنا معًا والكتابة على الرأس: جمع هذه النسخ الاحتياطية بطريقة كذا وكذا. ربما لا تحتاج إلى عكاز أي شيء والدراجة اخترعت منذ زمن بعيد؟
لنبدأ بأفضل الممارسات. ينصح زملائي دائمًا بالرد على الأسئلة حول النسخ الاحتياطية لتذكيرهم بخدمة Yandex.Cloud ، حيث تم حل هذه المهمة بالفعل. لذا استخدمه إذا أمكن.
لا يوجد حل كامل ، مائة بالمائة مضمّن في ClickHouse ، للنسخ الاحتياطي. هناك بعض الفراغات التي يمكنك استخدامها. للحصول على حل كامل ، سيتعين عليك إما إجراء بعض التعديلات يدويًا أو عمل أغلفة على شكل نصوص.
سأبدأ بأبسط الحلول وسأنهي بأكثر الحلول تعقيدًا ، اعتمادًا على كمية البيانات وحجم الكتلة. كلما كبرت الكتلة ، كلما أصبح الحل أكثر صعوبة.
إذا احتل جدول البيانات بضعة غيغابايت فقط ، فيمكن إجراء النسخ الاحتياطي على النحو التالي:
- احفظ تعريف الجداول ، أي البيانات الوصفية - عرض إنشاء الجدول.
- قم بعمل تفريغ باستخدام عميل ClickHouse - حدد * من الجدول إلى ملف. بشكل افتراضي ، ستتلقى ملفًا بتنسيق TabSeparated. إذا كنت تريد أن تكون أكثر فاعلية ، يمكنك استخدام التنسيق الأصلي.
إذا كانت كمية البيانات أكبر ، فستستغرق عملية النسخ الاحتياطي مزيدًا من الوقت ومساحة كبيرة. هذا يسمى النسخ الاحتياطي المنطقي ، وهو غير مرتبط بتنسيق بيانات ClickHouse. إذا كان الأمر كذلك ، فبإمكانك عند الضرورة أخذ نسخة احتياطية وتحميلها إلى MySQL لاستردادها.
للحالات الأكثر تقدمًا ، لدى ClickHouse قدرة مضمنة على إنشاء لقطة من الأقسام في نظام الملفات المحلي. هذه الميزة متاحة عند الطلب. تغيير قسم تجميد الجدول. أو ببساطة تغيير تجميد الجدول هي لقطة من الجدول بأكمله.
سيتم إنشاء اللقطة بشكل متسق لجدول واحد على جزء واحد ، أي أنه من المستحيل إنشاء لقطة متسقة للمجموعة بأكملها بهذه الطريقة. لكن بالنسبة لمعظم المهام ، لا توجد مثل هذه الحاجة ، ويكفي تنفيذ طلب على كل جزء والحصول على لقطة متسقة. تم إنشاؤه في شكل روابط صلبة وبالتالي لا يشغل مساحة إضافية. ثم تقوم بنسخ هذه اللقطة إلى خادم النسخ الاحتياطي أو التخزين الذي تستخدمه للنسخ الاحتياطية.
استعادة مثل هذه النسخة الاحتياطية سهلة للغاية. أولاً ، تقوم بإنشاء جداول وفقًا لتعريفات الجدول الموجودة. بعد ذلك ، انسخ لقطات القسم المحفوظة إلى Directory-Detached لهذه الجداول وقم بتشغيل الاستعلام إرفاق قسم. هذا الحل مناسب تمامًا لأخطر كميات البيانات.
في بعض الأحيان تحتاج إلى شيء أكثر برودة - في الحالات التي يكون لديك فيها عشرات أو حتى مئات من التيرابايت على كل خادم ومئات من الخوادم. يوجد حل هنا تجسست عليه من زملائي في Yandex.Metrica. لا أوصي به للجميع - اقرأه وقرر بنفسك ما إذا كان مناسبًا أم لا.
تحتاج أولاً إلى إنشاء عدة خوادم بأرفف كبيرة للقرص. بعد ذلك ، قم برفع العديد من خوادم ClickHouse على هذه الخوادم وتكوينها بحيث تعمل كنسخة متماثلة أخرى لنفس الأجزاء. ثم استخدم نظام الملفات على هذه الخوادم أو بعض الأدوات التي تتيح لك إنشاء لقطات. هناك خياران هنا. الخيار الأول هو لقطات LVM ، والخيار الثاني هو ZFS على Linux.
بعد ذلك ، كل يوم تحتاج إلى إنشاء لقطة ، سوف تكذب وتحتل بعض المساحة. بطبيعة الحال ، إذا تغيرت البيانات ، فإن مقدار المساحة سيزداد بمرور الوقت. يمكنك الحصول على هذه اللقطة في أي وقت واستعادة البيانات ، وهذا قرار غريب. بالإضافة إلى ذلك ، ما زلت بحاجة إلى تقييد هذه النسخ المتماثلة في التكوين بحيث لا يحاولون أن يصبحوا قادة.
هل سيكون من الممكن تنظيم تراكم متراكم للنسخ المتماثلة في الأعمدة؟
أنت تخطط هذا العام لعمل أعمدة في ClickHouse. هل سيكون من الممكن تنظيم تراكم متراكم للنسخ المتماثلة فيها؟ نود استخدامه لحماية أنفسنا من السيناريوهات السلبية مع التغييرات والتغييرات الأخرى.
هل من الممكن القيام بنوع من التراجع عن التغييرات؟ على سبيل المثال ، في عمود موجود ، خذ وقل ذلك حتى هذه اللحظة ، قم بتطبيق التغييرات ، ومن هذه اللحظة فصاعدًا ، توقف عن تطبيق التغييرات؟
إذا وصل أمر ما إلى مجموعتنا وكسره ، فعندئذٍ لدينا نسخة طبق الأصل مشروطة بفارق ساعة ، حيث يمكننا القول أننا لنستخدمها في الوقت الحالي ، لكننا لن نطبق التغييرات فيها خلال الدقائق العشر الماضية؟
بادئ ذي بدء ، حول تراكم النسخ المتماثلة المتحكم فيه. كان هناك مثل هذا الطلب من المستخدمين ، وقمنا بإنشاء مشكلة على Github مع طلب: "إذا احتاج شخص ما إلى هذا ، ضع إعجابًا ، ضع قلبًا". لا أحد يراهن ، وتم إغلاق القضية. ومع ذلك ، يمكنك بالفعل الحصول على هذه الفرصة عن طريق إعداد ClickHouse. صحيح ، بدءًا من الإصدار 20.3 فقط.
ClickHouse يدمج باستمرار البيانات في الخلفية - دمج. عند إجراء الدمج ، يتم استبدال بعض مجموعات البيانات بقطعة أكبر. في الوقت نفسه ، تظل أجزاء البيانات التي كانت من قبل على القرص لبعض الوقت.
أولاً ، يستمر تخزينها طالما أن هناك استعلامات محددة تستخدمها ، وذلك لضمان عدم حظر العملية. تتم قراءة الطلبات المحددة بهدوء من الأجزاء القديمة.
ثانيًا ، هناك أيضًا حد زمني - توجد قطع البيانات القديمة على القرص لمدة ثماني دقائق. يمكن تخصيص هذه الدقائق الثماني وتحويلها إلى يوم واحد. سيكلف ذلك مساحة القرص: اعتمادًا على تدفق البيانات ، سيتضح أنه خلال اليوم الأخير لن تتضاعف البيانات فحسب ، بل يمكن أن تصبح أكثر بخمس مرات. ولكن في حالة وجود مشكلة خطيرة ، يمكنك إيقاف خادم ClickHouse والتعامل مع كل شيء.
السؤال الآن هو كيف يحمي هذا من التغييرات. الأمر يستحق البحث بشكل أعمق هنا ، لأنه في الإصدارات القديمة من ClickHouse ، عمل البديل بطريقة أدت ببساطة إلى تغيير القطع بشكل مباشر. يوجد جزء من البيانات مع بعض الملفات ، ونفعل ، على سبيل المثال ، تغيير عمود الإسقاط. ثم تتم إزالة هذا العمود فعليًا من جميع الأجزاء.
ولكن منذ الإصدار 20.3 ، تم تغيير آلية التغيير تمامًا ، والآن أصبحت أجزاء البيانات ثابتة دائمًا. إنها لا تتغير على الإطلاق - تعمل التغييرات الآن بنفس الطريقة التي تعمل بها عمليات الدمج. بدلاً من تغيير قطعة في مكانها ، نقوم بإنشاء قطعة جديدة. في المجموعة الجديدة ، تصبح الملفات التي لم تتغير روابط صلبة ، وإذا حذفنا عمودًا ، فسيكون ببساطة مفقودًا في المجموعة الجديدة. سيتم حذف القطعة القديمة بشكل افتراضي بعد ثماني دقائق ، وهنا يمكنك تعديل الإعدادات المذكورة أعلاه.
الشيء نفسه ينطبق على التغييرات مثل الطفرات. عندما تفعل تغيير الحذف أو تغيير التحديث، لا يغير القطعة ، بل يخلق قطعة جديدة. ثم يحذف القديم.
ماذا لو تغير هيكل الجدول؟
كيف يتم رفع النسخة الاحتياطية التي تم إجراؤها بالمخطط القديم؟ والسؤال الثاني عن حالة اللقطات وأدوات نظام الملفات. هل Btrfs مناسب هنا بدلاً من ZFS على Linux LVM؟
اذا فعلت إرفاق قسم أقسام ذات هيكل مختلف ، ثم سيخبرك ClickHouse أن هذا غير ممكن. الحل هو هذا. الأول هو إنشاء جدول مؤقت من نوع MergeTree مع الهيكل القديم ، وإرفاق البيانات هناك باستخدام إرفاق ، وإصدار استعلام بديل. ثم يمكنك إما نسخ هذه البيانات أو نقلها وإرفاقها مرة أخرى ، أو استخدام الاستعلام تغيير قسم نقل الجدول.
الآن السؤال الثاني هو ما إذا كان من الممكن استخدام Btrfs. بالنسبة للمبتدئين ، إذا كان لديك LVM ، فإن لقطات LVM كافية ، ويمكن أن يكون نظام الملفات ext4 ، فلا يهم. مع Btrts ، كل هذا يتوقف على تجربتك معها. هذا نظام ملفات ناضج ، ولكن لا تزال هناك بعض الشكوك حول كيفية عمل كل شيء عمليًا في سيناريو معين. لا أوصي باستخدام هذا إلا إذا كان لديك Btrfs في الإنتاج.
ما هي أفضل الممارسات الحالية لإعادة مشاركة البيانات؟
إن مسألة إعادة المشاركة معقدة ومتعددة الأوجه. هنا يمكنك الإجابة على عدة خيارات في وقت واحد. يمكنك الدخول من جانب واحد وقول هذا - لا يوجد خيار إعادة مشاركة مضمّن في ClickHouse. لكنني أخشى أن هذه الإجابة لن تناسب أي شخص. لذلك ، يمكنك الانتقال من الجانب الآخر والقول أن ClickHouse لديها العديد من الطرق لإعادة فحص البيانات.
إذا نفدت مساحة الكتلة أو لا يمكنها معالجة الحمل ، يمكنك إضافة خوادم جديدة. لكن هذه الخوادم فارغة بشكل افتراضي ، ولا توجد بيانات عليها ، ولا يوجد تحميل. تحتاج إلى تحويل البيانات بحيث تنتشر بالتساوي على الكتلة الجديدة الأكبر حجمًا.
الطريقة الأولى للقيام بذلك هي نسخ جزء من الأقسام إلى خوادم جديدة باستخدام الاستعلام تغيير قسم جلب الجدول. على سبيل المثال ، لديك أقسام حسب الأشهر ، وتستغرق الشهر الأول من عام 2017 ونسخه إلى خادم جديد ، ثم نسخ الشهر الثالث إلى خادم جديد آخر. وهكذا تفعل حتى تصبح أكثر أو أقل.
يمكن إجراء الترحيل فقط لتلك الأقسام التي لا تتغير أثناء التسجيل. بالنسبة للأقسام الحديثة ، يجب تعطيل الكتابة ، لأن نقلها ليس ذريًا. خلاف ذلك ، سوف ينتهي بك الأمر مع التكرارات أو الفجوات في البيانات. ومع ذلك ، فإن هذه الطريقة عملية وتعمل بفعالية كبيرة. تنتقل الأقسام المضغوطة الجاهزة عبر الشبكة ، أي أن البيانات لا يتم ضغطها أو إعادة تشفيرها.
هذه الطريقة لها عيب واحد ، وتعتمد على مخطط التجزئة ، سواء كنت قد تعهدت بمخطط التجزئة هذا ، وما هو مفتاح التجزئة الذي لديك. في المثال الخاص بك لحالة المقاييس ، يكون مفتاح التجزئة هو تجزئة المسار. عند تحديد جدول موزع ، فإنه ينتقل إلى جميع أجزاء الكتلة مرة واحدة ويأخذ البيانات من هناك.
هذا يعني أنه لا يهمك حقًا البيانات التي ينتهي بها الأمر على أي جزء. الشيء الرئيسي هو أن البيانات الموجودة على طول مسار واحد تنتهي في جزء واحد ، ولكن أي منها ليس مهمًا. في هذه الحالة ، يعد نقل الأقسام الجاهزة أمرًا مثاليًا ، لأنه مع الاستعلامات المحددة ، ستتلقى أيضًا بيانات كاملة - قبل إعادة النشر وبعدها ، لا يهم المخطط حقًا.
لكن هناك حالات أكثر تعقيدًا. إذا كنت تعتمد على مستوى منطق التطبيق على مخطط تجزئة خاص ، فإن هذا العميل موجود في جزء كذا وكذا ، ويمكن إرسال الطلب على الفور هناك ، وليس إلى الجدول الموزع. أم أنك تستخدم إصدارًا حديثًا إلى حد ما من ClickHouse وقمت بتمكين الإعداد تحسين تخطي الأجزاء غير المستخدمة. في هذه الحالة ، أثناء استعلام التحديد ، سيتم تحليل التعبير الموجود في القسم حيث سيتم حساب الأجزاء التي سيتم الانتقال إليها وفقًا لمخطط التجزئة. يعمل هذا بشرط أن تتحلل البيانات تمامًا وفقًا لمخطط التجزئة هذا. إذا قمت بتحويلها يدويًا ، فقد تتغير المراسلات.
إذن هذه هي الطريقة الأولى. وانا انتظر اجابتك هل هي الطريقة المناسبة ام امضي قدما.
فلاديمير كولوبايف ، مسؤول النظام الرئيسي في Avito: أليكسي ، الطريقة التي ذكرتها لا تتناسب بشكل جيد عندما تحتاج إلى توزيع الحمل ، بما في ذلك القراءة. يمكننا أن نأخذ قسمًا شهريًا ويمكننا نقل الشهر السابق إلى عقدة أخرى ، ولكن عندما يأتي طلب لهذه البيانات ، سنقوم بتحميلها فقط. لكني أرغب في تحميل المجموعة بأكملها ، لأنه ، بخلاف ذلك ، ستتم معالجة حمل القراءة بالكامل لبعض الوقت بواسطة جزأين.
أليكسي ميلوفيدوف: الإجابة هنا غريبة - نعم ، إنها سيئة ، لكنها يمكن أن تنجح. سأشرح بالضبط كيف. يجدر النظر في سيناريو التحميل الذي يأتي مع بياناتك. إذا كانت هذه بيانات مراقبة ، فمن شبه المؤكد أن الغالبية العظمى من الطلبات لبيانات حديثة.
لقد قمت بتثبيت خوادم جديدة ، وقمت بترحيل أقسام قديمة ، ولكنك قمت أيضًا بتغيير طريقة كتابة البيانات الحديثة. وسيتم نشر البيانات الجديدة في جميع أنحاء الكتلة. وبالتالي ، بعد خمس دقائق ، سيتم تحميل الطلبات الخاصة بالدقائق الخمس الأخيرة بالتساوي ، وبعد يوم واحد ، سيتم تحميل الكتلة بالتساوي. وطلبات الشهر السابق ، للأسف ، ستذهب فقط إلى جزء من خوادم الكتلة.
لكن في كثير من الأحيان لن يكون لديك طلبات لشهر فبراير 2019. على الأرجح ، إذا انتقلت الطلبات إلى عام 2019 ، فستكون لعام 2019 بأكمله - لفترة زمنية كبيرة ، وليس لبعض النطاق الصغير. وستكون هذه الطلبات أيضًا قادرة على تحميل الكتلة بالتساوي. لكن بشكل عام ، ملاحظتك صحيحة تمامًا وهي أن هذا حل مخصص لا ينشر البيانات بالتساوي تمامًا.
لدي بضع نقاط أخرى للإجابة على السؤال. يدور أحدها حول كيفية إنشاء مخطط التجزئة في البداية بحيث يكون هناك ألم أقل من إعادة المشاركة. ليس هذا ممكنا دائما.
على سبيل المثال ، لديك بيانات مراقبة. تتزايد بيانات المراقبة لثلاثة أسباب. الأول هو تراكم البيانات التاريخية. والثاني هو نمو حركة المرور. والثالث زيادة في عدد الأشياء الخاضعة للمراقبة. هناك خدمات مصغرة ومقاييس جديدة يجب حفظها.
من الممكن أن تكون أكبر زيادة بسبب السبب الثالث - هذه زيادة في استخدام المراقبة. وفي هذه الحالة ، يجدر النظر في طبيعة الحمل ، ما هي الطلبات الرئيسية للاختيار. من المرجح أن تتبع استعلامات التحديد الرئيسية بعض المجموعات الفرعية من المقاييس.
على سبيل المثال ، استخدام وحدة المعالجة المركزية على بعض الخوادم بواسطة بعض الخدمات. اتضح أن هناك بعض المجموعات الفرعية من المفاتيح التي تحصل من خلالها على هذه البيانات. ومن المرجح أن يكون الطلب نفسه لهذه البيانات بسيطًا جدًا ويعمل في عشرات المللي ثانية. تستخدم لخدمات المراقبة ، للوحات العدادات. آمل أن أفهم هذا بشكل صحيح.
فلاديمير كولوبييف: الحقيقة هي أننا كثيرًا ما نلجأ إلى البيانات التاريخية ، لأننا نقارن الوضع الحالي بالموقع التاريخي في الوقت الفعلي. ومن المهم بالنسبة لنا الوصول السريع إلى كمية كبيرة من البيانات ، ويقوم ClickHouse بعمل رائع بهذا.
أنت محق تمامًا ، معظم طلبات القراءة التي نواجهها في اليوم الأخير ، مثل أي نظام مراقبة. ولكن في الوقت نفسه ، فإن العبء على البيانات التاريخية كبير جدًا أيضًا. إنه في الغالب من نظام تنبيه يعمل كل ثلاثين ثانية ويخبر ClickHouse ، "أعطني بيانات الأسابيع الستة الماضية. والآن قم ببناء بعض المتوسط المتحرك منهم ، ودعنا نقارن القيمة الحالية بالقيمة التاريخية.
أود أن أقول إنه لمثل هذه الطلبات الجديدة جدًا ، لدينا جدول صغير آخر نخزن فيه بيانات لمدة يومين فقط ، وتنتقل الطلبات الرئيسية إليه. نحن نرسل فقط استعلامات تاريخية كبيرة إلى جدول مقسم كبير.
أليكسي ميلوفيدوف: لسوء الحظ ، اتضح أنه غير قابل للتطبيق بشكل جيد على السيناريو الخاص بك ، لكنني سأصف مخططين سيئين ومعقدين للتجزئة لا يلزم استخدامهما ، ولكن يتم استخدامهما في خدمة أصدقائي.
هناك مجموعة رئيسية مع أحداث Yandex.Metrics. الأحداث هي مشاهدات الصفحة والنقرات والانتقالات. تذهب معظم الطلبات إلى موقع ويب محدد. تفتح خدمة Yandex.Metrica ، ولديك موقع ويب - avito.ru ، انتقل إلى التقرير ، ويتم تقديم طلب لموقع الويب الخاص بك.
لكن هناك طلبات أخرى - تحليلية وعالمية ، يقدمها محللون داخليون. فقط في هذه الحالة ، لاحظت أن المحللين الداخليين يقدمون طلبات لخدمات Yandex فقط. ولكن مع ذلك ، حتى خدمات Yandex تحتل حصة كبيرة من جميع البيانات. هذه طلبات ليست لعدادات محددة ، ولكن لتصفية أوسع.
كيف تنظم البيانات بحيث يعمل كل شيء بكفاءة لعداد واحد ، والاستعلامات العالمية أيضًا؟ تكمن صعوبة أخرى في حقيقة أن عدد الطلبات في ClickHouse for the Metrics يصل إلى عدة آلاف في الثانية. في الوقت نفسه ، لا يتعامل خادم ClickHouse مع الطلبات غير التافهة ، على سبيل المثال ، عدة آلاف في الثانية.
حجم الكتلة هو ستمائة وشيء الخوادم. إذا قمت ببساطة بتمديد جدول موزع فوق هذه المجموعة وأرسلت عدة آلاف من الطلبات هناك ، فسيصبح الأمر أسوأ من إرسالها إلى خادم واحد. من ناحية أخرى ، فإن خيار توزيع البيانات بالتساوي ، ونذهب ونطلب من جميع الخوادم ، يتم رفضه على الفور.
هناك خيار معاكس تماما. تخيل لو قمنا بتقسيم البيانات حسب الموقع ، وانتقل طلب موقع واحد إلى جزء واحد. الآن ستتمكن المجموعة من سحب عشرة آلاف طلب في الثانية ، ولكن في جزء واحد سيعمل طلب واحد ببطء شديد. لن يتسع نطاقه بعد الآن في النطاق الترددي. خاصة إذا كان موقع avito.ru. لن أكشف سرًا إذا قلت أن Avito هو أحد أكثر المواقع زيارة في Runet. ومعالجتها على قطعة واحدة سيكون جنونًا.
لذلك ، يتم ترتيب مخطط التجزئة بطريقة أكثر تعقيدًا. يتم تقسيم الكتلة بأكملها إلى عدد من المجموعات ، والتي نسميها الطبقات. يوجد داخل كل مجموعة من عشرة إلى عدة عشرات من القطع. هناك XNUMX مجموعة من هذا القبيل في المجموع.
كيف يقيس كل هذا الحجم؟ عدد المجموعات لا يتغير - كما كان قبل تسعة وثلاثين عاما ، لا يزال كما هو. لكن داخل كل منها ، نزيد تدريجياً عدد الأجزاء مع تراكم البيانات. ومخطط التجزئة ككل هو - التقسيم إلى هذه المجموعات يمر من خلال مواقع الويب ، ومن أجل فهم أي موقع موجود على أي مجموعة ، يتم استخدام قاعدة تعريف منفصلة في MySQL بشكل عام. موقع واحد - في مجموعة واحدة. وداخلها ، تتم عملية التجزئة وفقًا لمعرفات الزوار.
عند التسجيل ، نقوم بتقسيمها على باقي معرف الزائر. ولكن عند إضافة جزء جديد ، يتغير مخطط التجزئة ، نستمر في الانقسام ، ولكن مع باقي القسمة على رقم آخر. هذا يعني أن زائرًا واحدًا موجود بالفعل على عدة خوادم ، ولا يمكنك المراهنة عليه. يتم ذلك فقط لضمان ضغط البيانات بشكل أفضل. وعند الاستعلام ، نذهب إلى الجدول الموزع ، الذي ينظر في الكتلة ويصل إلى عشرات الخوادم. هذا مخطط غبي.
لكن قصتي ستكون غير مكتملة إذا لم أقل أننا تخلينا عن هذا المخطط. في المخطط الجديد ، قمنا بتغيير كل شيء ونسخنا جميع البيانات باستخدام clickhouse-copier.
في المخطط الجديد ، يتم تقسيم جميع المواقع إلى فئتين - كبيرة وصغيرة. لا أعرف كيف تم اختيار العتبة هناك ، ولكن نتيجة لذلك ، اتضح أن المواقع الكبيرة مسجلة على مجموعة واحدة ، حيث يوجد 120 جزءًا مع ثلاث نسخ متماثلة في كل منها - أي 360 خادمًا. ومخطط التجزئة بحيث يذهب أي طلب إلى جميع الأجزاء دفعة واحدة. إذا فتحت الآن أي صفحة تقرير لـ avito.ru في Yandex.Metrica ، فسيذهب الطلب إلى 120 خادمًا. هناك عدد قليل من المواقع الكبيرة في Runet. والطلبات ليست ألف في الثانية ، بل حتى أقل من مائة. يتم مضغ كل هذا بهدوء بواسطة الجدول الموزع ، حيث يقوم كل واحد منهم بمعالجة 120 خادمًا.
والمجموعة الثانية مخصصة للمواقع الصغيرة. فيما يلي مخطط تجزئة حسب معرف الموقع ، وينتقل كل طلب إلى جزء واحد بالضبط.
ClickHouse لديه أداة ناسخة clickhouse. هل يمكنك التحدث عنها؟
يجب أن أقول على الفور أن هذا الحل أكثر تعقيدًا وأقل إنتاجية إلى حد ما. الميزة هي أنها تلطيخ البيانات تمامًا وفقًا للمخطط الذي تحدده. لكن عيب الأداة هو أنها لا تتعافى على الإطلاق. يقوم بنسخ البيانات من مخطط كتلة واحد إلى مخطط كتلة آخر.
هذا يعني أنه لكي تعمل ، يجب أن يكون لديك مجموعتان. يمكن أن تكون موجودة على نفس الخوادم ، ولكن ، مع ذلك ، لن يتم نقل البيانات بشكل متزايد ، ولكن سيتم نسخها.
على سبيل المثال ، كان هناك أربعة خوادم ، والآن هناك ثمانية. يمكنك إنشاء جدول موزع جديد على جميع الخوادم ، والجداول المحلية الجديدة ، وتشغيل آلة نسخ النقر ، مع تحديد مخطط العمل الذي يجب قراءته من هناك ، وقبول مخطط التجزئة الجديد ، ونقل البيانات هناك. وستحتاج إلى مساحة أكبر بمقدار مرة ونصف على الخوادم القديمة مما لديك الآن ، لأن البيانات القديمة يجب أن تظل عليها ، وسيظهر نصف نفس البيانات القديمة فوقها. إذا كنت تعتقد مسبقًا أن البيانات بحاجة إلى إعادة تجميع وهناك مساحة ، فهذه الطريقة مناسبة.
كيف يعمل clickhouse-copier بالداخل؟ يقسم كل العمل إلى مجموعة من المهام لمعالجة قسم واحد من جدول واحد على جزء واحد. يمكن تشغيل كل هذه المهام بشكل متوازٍ ، ويمكن لآلة النقر فوق الناسخة تشغيل مثيلات متعددة على أجهزة مختلفة ، ولكن ما تفعله لقسم واحد ليس أكثر من تحديد إدراج. تتم قراءة البيانات ، وفك ضغطها ، وإعادة تقسيمها ، ثم ضغطها مرة أخرى ، وكتابتها في مكان ما ، وإعادة فرزها. هذا قرار أكثر صعوبة.
كان لديك شيء تجريبي يسمى إعادة المشاركة. ماذا معها؟
في عام 2017 ، كان لديك شيء تجريبي يسمى إعادة المشاركة. حتى أن هناك خيارًا في ClickHouse. أنا أفهم أنها لم تقلع. هل يمكنك معرفة سبب حدوث ذلك؟ يبدو أنه وثيق الصلة بالموضوع.
تكمن المشكلة برمتها في أنك إذا كنت بحاجة إلى إعادة ضبط البيانات في مكانها الصحيح ، فستكون هناك حاجة إلى مزامنة معقدة للغاية للقيام بذلك بشكل ذري. عندما بدأنا في النظر في كيفية عمل هذا المزامنة ، أصبح من الواضح أن هناك مشاكل أساسية. وهذه المشاكل الأساسية ليست نظرية فقط ، ولكنها بدأت على الفور في إظهار نفسها في الممارسة العملية في شكل شيء يمكن تفسيره بكل بساطة - لا شيء يعمل.
هل من الممكن دمج جميع أجزاء البيانات معًا قبل الانتقال إلى الأقراص البطيئة؟
سؤال حول TTL مع خيار الانتقال إلى قرص بطيء في سياق عمليات الدمج. هل هناك طريقة أخرى غير cron لدمج جميع الأجزاء في جزء واحد قبل الانتقال إلى الأقراص البطيئة؟
الإجابة على سؤال ما إذا كان من الممكن لصق جميع القطع تلقائيًا بطريقة أو بأخرى في قطعة واحدة قبل نقلها هو لا. يبدو لي أن هذا ليس ضروريا. لا يمكنك دمج جميع الأجزاء في جزء واحد ، ولكن يمكنك الاعتماد ببساطة على حقيقة أنه سيتم نقلها إلى أقراص بطيئة تلقائيًا.
لدينا معياران لقواعد النقل. الأول هو أنه يملأ. إذا كان مستوى التخزين الحالي يحتوي على أقل من نسبة مئوية معينة من المساحة الخالية ، فإننا نختار قطعة واحدة وننقلها إلى وحدة تخزين أبطأ. أو بالأحرى ، ليس أبطأ ، ولكن التالي - كيف تقوم بإعداده.
المعيار الثاني هو الحجم. يتحدث عن نقل القطع الكبيرة. يمكنك ضبط العتبة بناءً على المساحة الخالية على قرص سريع وسيتم ترحيل البيانات تلقائيًا.
كيف تنتقل إلى إصدارات جديدة من ClickHouse إذا لم تكن هناك طريقة للتحقق من التوافق مقدمًا؟
هذا الموضوع يناقش بانتظام مع الأخذ في الاعتبار الإصدارات المختلفة ، وحتى الآن. ما مدى أمان الترقية من الإصدار 19.11 إلى الإصدار 19.16 ، وعلى سبيل المثال ، من الإصدار 19.16 إلى 20.3. ما هي أفضل طريقة للانتقال إلى الإصدارات الجديدة دون التمكن من التحقق من التوافق في وضع الحماية مقدمًا؟
هناك بعض القواعد الذهبية هنا. أولاً - . إنه كبير ، لكن هناك نقاط منفصلة حول التغييرات غير المتوافقة مع الإصدارات السابقة. لا تعامل هذه العناصر كعلم أحمر. عادةً ما تكون هذه حالات عدم توافق بسيطة تتعلق ببعض وظائف الحافة التي ربما لا تستخدمها.
ثانيًا ، إذا لم تكن هناك طريقة للتحقق من التوافق في وضع الحماية ، وتريد الترقية على الفور في الإنتاج ، فإن التوصية هي أنك لست بحاجة إلى القيام بذلك. قم أولاً بإنشاء صندوق رمل واختباره. إذا لم تكن هناك بيئة اختبار ، فمن المحتمل ألا يكون لديك شركة كبيرة جدًا ، مما يعني أنه يمكنك نسخ بعض البيانات إلى الكمبيوتر المحمول الخاص بك والتأكد من أن كل شيء يعمل بشكل صحيح عليه. يمكنك حتى إحضار بعض النسخ المتماثلة محليًا على جهازك. أو يمكنك رفع إصدار جديد في مكان قريب وتحميل بعض البيانات هناك - أي إنشاء بيئة اختبار مرتجلة.
هناك قاعدة أخرى تتمثل في عدم التحديث في غضون أسبوع بعد إصدار الإصدار بسبب اكتشاف الأخطاء في الإنتاج والإصلاحات السريعة اللاحقة. دعونا نفهم ترقيم إصدار ClickHouse حتى لا يتم الخلط.
يوجد نسخة 20.3.4. الرقم 20 يشير إلى سنة التصنيع - 2020. من وجهة نظر ما بداخله هذا لا يهم ، لذلك لن ننتبه إليه. علاوة على ذلك - 20.3. الرقم الثاني - في هذه الحالة 3 - نزيد في كل مرة نصدر فيها إصدارًا مع بعض الوظائف الجديدة. إذا أردنا إضافة بعض الميزات إلى ClickHouse ، فيجب علينا زيادة هذا الرقم. أي في الإصدار 20.4 ، سيعمل ClickHouse بشكل أفضل. الرقم الثالث هو 20.3.4. هنا 4 هو عدد إصدارات التصحيح التي لم نضف فيها ميزات جديدة ، لكننا أصلحنا بعض الأخطاء. و 4 تعني أننا فعلناها أربع مرات.
لا تعتقد أنه شيء فظيع. عادة يمكن للمستخدم تثبيت أحدث إصدار وسيعمل دون أي مشاكل مع الجهوزية في السنة. لكن تخيل أنه في بعض الوظائف الخاصة بمعالجة الصور النقطية ، والتي أضافها رفاقنا الصينيون ، عند تمرير وسيطات غير صحيحة ، يتعطل الخادم. يجب أن نصلح هذا. سنصدر إصدار تصحيح جديد وسيصبح ClickHouse أكثر استقرارًا.
إذا كان لديك ClickHouse تعمل في الإنتاج ، وتم إصدار إصدار جديد من ClickHouse مع ميزات إضافية - على سبيل المثال ، 20.4.1 هو الأول ، فلا تتعجل في وضعه في الإنتاج في اليوم الأول. لماذا هي بحاجة على الإطلاق؟ إذا كنت لا تستخدم ClickHouse حتى الآن ، فيمكنك تثبيته ، وعلى الأرجح ، سيكون كل شيء على ما يرام. ولكن إذا كان ClickHouse يعمل بالفعل بشكل مستقر ، فتابع التصحيحات والتحديثات - ما هي المشاكل التي نصلحها.
كيريل شفاكوف: أريد أن أضيف القليل عن بيئات الاختبار. الجميع خائفون جدًا من بيئات الاختبار ولسبب ما يعتقد أنه إذا كان لديك مجموعة ClickHouse كبيرة جدًا ، فيجب ألا تكون بيئة الاختبار أصغر أو أصغر بعشر مرات على الأقل. الأمر ليس كذلك على الإطلاق.
أستطيع أن أقول من خلال المثال الخاص بي. لدي مشروع وهناك ClickHouse. بيئة الاختبار الخاصة بنا هي آلة افتراضية صغيرة في Hetzner مقابل عشرين يورو ، حيث يتم نشر كل شيء على الإطلاق. للقيام بذلك ، لدينا أتمتة كاملة في Ansible ، وبالتالي ، من حيث المبدأ ، لا يوجد فرق بين مكان التدوير - على خوادم حديدية أو مجرد نشرها في أجهزة افتراضية.
ماذا يمكن ان يفعل؟ سيكون من الجيد تقديم مثال في وثائق ClickHouse حول كيفية نشر مجموعة صغيرة بمفردك - في Docker ، في LXC ، ربما تنشئ كتاب لعب Ansible ، لأن الأشخاص المختلفين لديهم عمليات نشر مختلفة. هذا سيجعل الكثير من الأشياء أسهل. عندما تأخذ مجموعة وتنشرها في خمس دقائق ، يكون من الأسهل بكثير محاولة اكتشاف شيء ما. إنها أكثر ملاءمة بهذه الطريقة ، لأن طرح نسخة لم تختبرها في الإنتاج يعد طريقًا إلى اللامكان. أحيانًا يعمل وأحيانًا لا يعمل. ولذا فإن الأمل في النجاح أمر سيء.
مكسيم كوتياكوف ، كبير مهندسي الواجهة الخلفية أفيتو: سأضيف القليل عن بيئات الاختبار من سلسلة من المشاكل للشركات الكبيرة. لدينا مجموعة قبول ClickHouse كاملة ، وفقًا لمخططات البيانات والإعدادات ، نسخة طبق الأصل مما هو قيد الإنتاج. يتم نشر هذه المجموعة في حاويات فاسدة إلى حد ما مع الحد الأدنى من الموارد. نكتب هناك نسبة معينة من بيانات الإنتاج ، حيث توجد فرصة لتكرار التدفق في كافكا. تتم مزامنة كل شيء وقياسه هناك - من حيث السعة والتدفق ، ومن الناحية النظرية ، عندما تكون الأشياء الأخرى متساوية ، يجب أن يتصرف مثل الإنتاج من حيث المقاييس. يتم أولاً وضع كل شيء يمكن أن يكون قابلاً للانفجار على هذا الحامل ويتم غمره هناك لعدة أيام حتى يصبح جاهزًا. لكن بالطبع ، هذا الحل مكلف وثقيل وبتكاليف دعم غير صفرية.
أليكسي ميلوفيدوف: سأخبرك كيف تبدو بيئة الاختبار لأصدقائنا من Yandex.Metrica. يحتوي أحد المجموعات على 600 خادم أو نحو ذلك ، والآخر يحتوي على 360 خادمًا ، وهناك مجموعة ثالثة والعديد من العناقيد. بيئة الاختبار لواحد منهم عبارة عن جزأين فقط مع نسختين متماثلتين في كل منهما. لماذا شريحتين؟ أن لا تكون وحيدا. والنسخ المقلدة أيضًا. فقط بعض الحد الأدنى للمبلغ الذي يمكنك تحمله.
تتيح لك بيئة الاختبار هذه التحقق من صحة الطلبات وما إذا كان هناك شيء معطل بشكل كبير. لكن غالبًا ما تنشأ مشكلات ذات طبيعة مختلفة تمامًا ، عندما يعمل كل شيء ، ولكن هناك بعض التغييرات الصغيرة مع الحمل.
سأعطيك مثالا. قررنا تثبيت نسخة جديدة من ClickHouse. تم وضعه في بيئة اختبار ، وتم اجتياز الاختبارات الآلية في Yandex.Metrica نفسها ، والتي تقارن البيانات الموجودة في الإصدار القديم والجديد ، والتي تعمل على خط الأنابيب بالكامل. وبالطبع ، الاختبارات الخضراء لـ CI. خلاف ذلك ، لم نكن لنقترح هذا الإصدار.
كل شيء على ما يرام. نبدأ في الدخول في الإنتاج. أتلقى رسالة مفادها أن الحمل قد زاد عدة مرات على الرسوم البيانية. نحن نتراجع عن الإصدار. ألقي نظرة على الرسم البياني وأرى: زاد الحمل بالفعل عدة مرات أثناء الطرح ، وانخفض مرة أخرى عند طرحه. ثم بدأنا في التراجع عن الإصدار. وزاد الحمل بنفس الطريقة وسقط عائدًا بنفس الطريقة. لذا فإن الاستنتاج هو - لقد زاد الحمل فيما يتعلق بالحساب ، فلا شيء يثير الدهشة.
ثم كان من الصعب إقناع الزملاء بتثبيت الإصدار الجديد بعد كل شيء. أقول: "لا بأس ، انطلق. ابق أصابعك متقاطعة ، كل شيء سيعمل. زاد الحمل الآن على المخططات ، لكن كل شيء على ما يرام. يتمسك." بشكل عام ، قمنا بهذا ، وهذا كل شيء - تم نشر النسخة على موقع الإنتاج. ولكن مع كل عملية حسابية تقريبًا ، تظهر مشكلات مماثلة.
من المفترض أن يؤدي قتل الاستعلام إلى قتل الاستعلامات ، لكنه لا يفعل ذلك. لماذا؟
جاء إلي أحد المستخدمين ، نوعًا ما من المحللين ، وقام بإنشاء طلب معين ، والذي وضع مجموعة ClickHouse الخاصة بي. بعض العقدة أو مجموعة كاملة ، اعتمادًا على النسخة المتماثلة أو الجزء الذي دخل فيه الطلب. أرى أن جميع موارد وحدة المعالجة المركزية على هذا الخادم موجودة في الرف ، وكل شيء أحمر. في الوقت نفسه ، تستجيب ClickHouse نفسها للطلبات. وأنا أكتب: "أرني قائمة العمليات التي طلبتها ولدت هذا الجنون من فضلك".
أجد هذا الطلب وأكتب اقتله. وأرى أنه لا شيء يحدث. الخادم الخاص بي موجود في الرف ، ثم يعطيني ClickHouse بعض الأوامر ، ويظهر أن الخادم على قيد الحياة ، وكل شيء على ما يرام. ولكن لدي تدهور في جميع طلبات المستخدم ، ويبدأ التدهور عن طريق الإدخال في ClickHouse ، ولا يعمل استعلام القتل الخاص بي. لماذا؟ اعتقدت أنه من المفترض أن يقتل الاستعلام عن الاستعلامات ، لكنه لا يفعل ذلك.
الآن ستكون هناك إجابة غريبة إلى حد ما. النقطة المهمة هي أن قتل الاستعلام لا يقتل الاستعلامات.
يضع طلب البحث Kill مربع اختيار صغيرًا يسمى "أريد أن يُقتل هذا الاستعلام". والطلب نفسه ، عند معالجة كل كتلة ، ينظر إلى هذه العلامة. إذا تم تعيينه ، يتوقف الطلب عن العمل. اتضح أن لا أحد يقتل الطلب ، يجب عليه هو نفسه التحقق من كل شيء والتوقف. وينبغي أن يعمل هذا في جميع الحالات التي يكون فيها الطلب في حالة معالجة الكتلة. سيقوم بمعالجة الكتلة التالية من البيانات ، والتحقق من العلم ، والتوقف.
هذا لا يعمل في الحالات التي يتم فيها حظر الطلب في بعض العمليات. صحيح ، هذه ليست حالتك على الأرجح ، لأنه ، وفقًا لك ، يستخدم مجموعة من موارد الخادم. من الممكن ألا ينجح ذلك في حالة الفرز الخارجي وفي بعض التفاصيل الأخرى. لكن بشكل عام ، لا ينبغي أن يكون هذا ، هذا خطأ. والشيء الوحيد الذي يمكنني أن أنصح به هو تحديث ClickHouse.
كيف تحسب وقت الاستجابة تحت عبء القراءة؟
يوجد جدول يخزن تجميعات العناصر - عدادات مختلفة. عدد الخطوط حوالي مائة مليون. هل من الممكن الاعتماد على وقت استجابة يمكن التنبؤ به إذا صببت 1K RPS على 1K عنصر؟
إذا حكمنا من خلال السياق ، فإننا نتحدث عن عبء القراءة ، لأنه لا توجد مشاكل في الكتابة - يمكن إدراج ما لا يقل عن ألف ، على الأقل مائة ألف ، وأحيانًا عدة ملايين من السطور.
طلبات القراءة مختلفة جدًا. في التحديد 1 ، يمكن أن يؤدي ClickHouse حوالي عشرات الآلاف من الطلبات في الثانية ، لذلك حتى الطلبات الخاصة بمفتاح واحد ستتطلب بالفعل بعض الموارد. وستكون استعلامات النقاط هذه أكثر صعوبة مما هي عليه في بعض قواعد بيانات القيمة الرئيسية ، لأنه من الضروري قراءة كتلة البيانات حسب الفهرس لكل قراءة. لا يعالج فهرسنا كل سجل ، بل كل نطاق. بمعنى ، يجب عليك قراءة النطاق بالكامل - هذه 8192 سطرًا افتراضيًا. ويجب عليك فك ضغط كتلة البيانات المضغوطة من 64 كيلوبايت إلى 1 ميجابايت. عادةً ما تستغرق استعلامات النقاط هذه بضعة أجزاء من الألف من الثانية. لكن هذا هو الخيار الأسهل.
لنجرب بعض العمليات الحسابية البسيطة. إذا قمت بضرب بضع ميلي ثانية في ألف ، فستحصل على بضع ثوانٍ. كما لو كان من المستحيل الاحتفاظ بألف طلب في الثانية ، لكن في الواقع هذا ممكن ، لأن لدينا العديد من نوى المعالج. لذلك ، من حيث المبدأ ، يمكن أحيانًا الاحتفاظ بـ 1000 RPS ClickHouse ، ولكن بناءً على الطلبات القصيرة ، أي طلبات النقاط.
إذا كنت بحاجة إلى توسيع نطاق مجموعة ClickHouse من خلال عدد الطلبات البسيطة ، فأنا أوصي بأبسط شيء - زيادة عدد النسخ المتماثلة وإرسال الطلبات إلى نسخة متماثلة عشوائية. إذا كانت النسخة المتماثلة تحتوي على خمسمائة طلب في الثانية ، وهذا أمر واقعي تمامًا ، فستحتوي ثلاث نسخ متماثلة على ألف ونصف.
في بعض الأحيان ، بالطبع ، يمكنك أيضًا تكوين ClickHouse لأقصى عدد من قراءات النقاط. ما هو المطلوب لهذا؟ الأول هو تقليل دقة الفهرس. في الوقت نفسه ، لا ينبغي تخفيضه إلى واحد ، ولكن على أساس أن عدد السجلات في الفهرس سيكون عدة ملايين أو عشرات الملايين لكل خادم. إذا كان الجدول يحتوي على مائة مليون صف ، فيمكن تعيين 64 على أنها دقة.
يمكنك تقليل حجم الكتلة المضغوطة. هناك إعدادات لهذا. حجم كتلة الضغط الأدنى, الحد الأقصى لحجم كتلة الضغط. يمكنك تقليلها ، وإعادة تحميل البيانات ، وبعد ذلك ستكون استعلامات النقطة أسرع. ولكن مع ذلك ، فإن ClickHouse ليست قاعدة بيانات ذات قيمة مفتاح. عدد كبير من الطلبات الصغيرة هو تحميل مضاد للنمط.
كيريل شفاكوف: سأقدم المشورة في حالة وجود محاسبين عاديين. هذا موقف قياسي إلى حد ما عند تخزين نوع من العداد في ClickHouse. لدي مستخدم ، إنه من بلد كذا وكذا ، حقل ثالث آخر ، وأحتاج إلى زيادة شيء ما بشكل تدريجي. خذ MySQL ، اصنع مفتاحًا فريدًا - في MySQL هو مفتاح مكرر ، وفي PostgreSQL هناك تعارض - وأضف علامة الجمع. هذا سوف يعمل بشكل أفضل
عندما يكون لديك القليل من البيانات ، فلا فائدة من استخدام ClickHouse. هناك قواعد بيانات منتظمة ، وهم يقومون بعمل جيد.
ما الذي يجب تعديله في ClickHouse بحيث يتم تخزين المزيد من البيانات في ذاكرة التخزين المؤقت؟
دعنا نتخيل الموقف - تحتوي الخوادم على 256 جيجابايت من ذاكرة الوصول العشوائي ، في الروتين اليومي ، يستغرق ClickHouse حوالي 60-80 جيجابايت ، في الذروة - حتى 130. ما يمكن تمكينه وتعديله بحيث يكون المزيد من البيانات في ذاكرة التخزين المؤقت ، وبالتالي ، هناك عدد أقل من الرحلات إلى القرص؟
كقاعدة عامة ، تقوم ذاكرة التخزين المؤقت للصفحة الخاصة بنظام التشغيل بعمل جيد لهذه المهمة. إذا فتحت الجزء العلوي للتو ، فابحث هناك مؤقتًا أو مجانيًا - كما يوضح أيضًا مقدار ذاكرة التخزين المؤقت - يمكنك حينئذٍ أن ترى أنه يتم استخدام كل الذاكرة الفارغة لذاكرة التخزين المؤقت. وعند قراءة هذه البيانات لن تتم قراءتها من القرص بل من ذاكرة الوصول العشوائي. في الوقت نفسه ، يمكنني القول أن ذاكرة التخزين المؤقت تُستخدم بشكل فعال ، لأن البيانات المضغوطة هي التي يتم تخزينها مؤقتًا.
ومع ذلك ، إذا كنت ترغب في تسريع بعض الاستعلامات البسيطة بشكل أكبر ، فمن الممكن تمكين ذاكرة التخزين المؤقت في البيانات التي تم فك ضغطها داخل ClickHouse. تسمى ذاكرة التخزين المؤقت غير المضغوطة. في ملف التكوين config.xml ، اضبط حجم ذاكرة التخزين المؤقت غير المضغوطة على القيمة التي تحتاجها - أنصح بما لا يزيد عن نصف ذاكرة الوصول العشوائي المجانية ، لأن الباقي سينتقل إلى ذاكرة التخزين المؤقت للصفحة.
بالإضافة إلى ذلك ، هناك نوعان من إعدادات مستوى الطلب. الإعداد الأول - استخدام ذاكرة التخزين المؤقت غير المضغوطة - يشمل استخدامه. يوصى بتمكينه لجميع الطلبات ، باستثناء الطلبات الثقيلة ، والتي يمكنها قراءة جميع البيانات ومسح ذاكرة التخزين المؤقت هذه. والإعداد الثاني يشبه الحد الأقصى لعدد الأسطر لاستخدام ذاكرة التخزين المؤقت. يقوم تلقائيًا بتقييد الطلبات الكبيرة بحيث تتجاوز ذاكرة التخزين المؤقت.
كيف يمكنني تكوين storage_configuration للتخزين في RAM؟
في وثائق ClickHouse الجديدة ، قرأت القسم المتعلق . في الوصف يوجد مثال مع SSD سريع.
أتساءل كيف يمكنك تكوين نفس حجم الذاكرة الساخنة. وسؤال آخر. كيف يعمل التحديد مع تنظيم البيانات هذا ، هل سيقرأ المجموعة بأكملها أم المجموعة الموجودة على القرص فقط ، وهل يتم ضغط هذه البيانات في الذاكرة؟ وكيف يعمل القسم المسبق على مثل هذه المنظمة للبيانات؟
يؤثر هذا الإعداد على تخزين أجزاء من البيانات ، ولا يتغير تنسيقها بأي شكل من الأشكال.
دعونا نلقي نظرة فاحصة.
يمكنك إعداد تخزين البيانات في ذاكرة الوصول العشوائي. كل ما تم تكوينه للقرص هو مساره. تقوم بإنشاء قسم tmpfs يتم تثبيته على مسار ما في نظام الملفات. حدد هذا المسار كمسار تخزين البيانات لأهم قسم ، وتبدأ أجزاء من البيانات في الوصول وتكتب هناك ، كل شيء على ما يرام.
لكني لا أوصي بالقيام بذلك بسبب انخفاض الموثوقية ، على الرغم من أنه إذا كان لديك ثلاث نسخ متماثلة على الأقل في مراكز بيانات مختلفة ، فيمكنك ذلك. إذا كان الأمر كذلك ، فستتم استعادة البيانات. تخيل أنه تم إيقاف تشغيل الخادم فجأة وإعادة تشغيله. تم تثبيت المقطع مرة أخرى ، ولكن هناك فراغ. عند بدء التشغيل ، يرى خادم ClickHouse أن هذه الأجزاء مفقودة ، على الرغم من أنه وفقًا لبيانات ZooKeeper الوصفية ، يجب أن تكون كذلك. يبحث في النسخ المتماثلة الموجودة عليها ويطلبها ويقوم بتنزيلها. وبالتالي ، سيتم استعادة البيانات.
بهذا المعنى ، لا يختلف تخزين البيانات في ذاكرة الوصول العشوائي اختلافًا جوهريًا عن تخزينها على القرص ، لأنه عندما تتم كتابة البيانات على القرص ، فإنها تقع أيضًا أولاً في ذاكرة التخزين المؤقت للصفحة وتتم كتابتها فعليًا لاحقًا. يعتمد ذلك على كيفية تركيب نظام الملفات. ولكن فقط في حالة ، سأقول أن ClickHouse لا fsync عند الإدراج.
في هذه الحالة ، يتم تخزين البيانات الموجودة في ذاكرة الوصول العشوائي بنفس تنسيق القرص تمامًا. يحدد استعلام التحديد الأجزاء المراد قراءتها بنفس الطريقة ، ويحدد نطاقات البيانات المطلوبة في الأجزاء ويقرأها. ويعمل في مكان سابق بنفس الطريقة تمامًا ، بغض النظر عما إذا كانت البيانات موجودة في ذاكرة الوصول العشوائي أو على القرص.
ما هو عدد القيم الفريدة التي تعتبر ذات تأثير أساسي منخفض؟
إن انخفاض عدد العناصر أمر صعب. يقوم بتجميع قواميس البيانات ، لكنها محلية. أولاً ، القواميس مختلفة لكل قطعة ، وثانيًا ، حتى داخل قطعة واحدة يمكن أن تكون مختلفة لكل نطاق. عندما يصل عدد القيم الفريدة إلى عتبة - مليون ، على ما أعتقد - يتم وضع القاموس جانباً ببساطة ويتم إنشاء واحدة جديدة.
الجواب بشكل عام: لكل نطاق محلي - على سبيل المثال ، لكل يوم - في مكان ما يصل إلى مليون قيمة فريدة ، تكون العلاقة الأساسية المنخفضة فعالة. بعد ذلك ، سيكون هناك فقط ارتداد ، حيث سيتم استخدام العديد من القواميس المختلفة ، وليس قواميس واحدة فقط. سيعمل بنفس الطريقة التي يعمل بها عمود عادي من نوع السلسلة ، ربما أقل كفاءة بقليل ، لكن لن يكون هناك تدهور خطير في الأداء.
ما هي أفضل الممارسات للبحث عن نص كامل في جدول مكون من خمسة مليارات صف؟
هناك إجابات مختلفة. الأول هو أن نقول أن ClickHouse ليس محرك بحث نص كامل. هناك أنظمة خاصة لهذا ، على سبيل المثال ، и . ومع ذلك ، أرى المزيد والمزيد من الأشخاص الذين يقولون إنهم ينتقلون من Elasticsearch إلى ClickHouse.
لماذا يحدث هذا؟ يفسرون ذلك من خلال حقيقة أن Elasticsearch توقف عن التعامل مع الحمل على بعض الأحجام ، بدءًا من فهارس البناء. تصبح الفهارس مرهقة للغاية ، وإذا قمت ببساطة بنقل البيانات إلى ClickHouse ، فقد اتضح أنه يتم تخزينها عدة مرات بشكل أكثر كفاءة من حيث الحجم. في الوقت نفسه ، غالبًا ما لم تكن استعلامات البحث على هذا النحو بحيث كان من الضروري العثور على عبارة ما في كمية البيانات بأكملها ، مع الأخذ في الاعتبار التشكل ، ولكن مختلفة تمامًا. على سبيل المثال ، للعثور على الساعات القليلة الماضية في السجلات لبعض البايتات اللاحقة.
في هذه الحالة ، تقوم بإنشاء فهرس في ClickHouse ، وهو الحقل الأول الذي سيكون فيه التاريخ مع الوقت. وسيكون أكبر اقتطاع للبيانات هو النطاق الزمني بالضبط. ضمن النطاق الزمني المحدد ، كقاعدة عامة ، من الممكن بالفعل إجراء بحث عن نص كامل حتى باستخدام طريقة القوة الغاشمة باستخدام مثل. عبارة Like في ClickHouse هي أكثر الجمل التي يمكنك العثور عليها فاعلية. إذا وجدت واحدة أفضل ، أخبرني.
ولكن لا يزال ، مثل الفحص الكامل. ويمكن أن يكون الفحص الكامل بطيئًا ليس فقط على وحدة المعالجة المركزية ، ولكن أيضًا على القرص. إذا كان لديك فجأة تيرابايت واحد من البيانات في اليوم ، وكنت تبحث عن كلمة واحدة في اليوم ، فسيتعين عليك مسح تيرابايت ضوئيًا. ومن المحتمل أن يكون على محركات أقراص ثابتة عادية ، ونتيجة لذلك سيتم تحميلها بطريقة لن تدخل هذا الخادم عبر SSH.
في هذه الحالة ، أنا مستعد لتقديم خدعة أخرى صغيرة. إنه من فئة التجريبية - قد تنجح ، أو قد لا تنجح. يحتوي ClickHouse على فهارس نص كامل في شكل مرشحات trigram bloom. لقد جرب زملاؤنا في Arenadata بالفعل هذه الفهارس ، وغالبًا ما تعمل تمامًا على النحو المنشود.
من أجل استخدامها بشكل صحيح ، يجب أن يكون لديك فهم جيد لكيفية عملها بالضبط: ما هو مرشح الزهر ثلاثي الزوايا وكيفية اختيار حجمه. أستطيع أن أقول إنهم سيساعدون في الاستفسارات حول بعض العبارات النادرة ، السلاسل الفرعية التي نادرًا ما توجد في البيانات. في هذه الحالة ، سيتم تحديد النطاقات الفرعية بواسطة الفهارس ، وستتم قراءة بيانات أقل.
أضاف ClickHouse مؤخرًا المزيد من الميزات المتقدمة للبحث عن نص كامل. هذا ، أولاً ، هو البحث عن مجموعة من السلاسل الفرعية دفعة واحدة في مسار واحد ، بما في ذلك الخيارات الحساسة لحالة الأحرف أو غير الحساسة لحالة الأحرف أو UTF-8 المدعومة أو ASCII فقط. اختر الأكثر كفاءة الذي تحتاجه.
كان هناك أيضًا بحث عن عدة تعبيرات نمطية في مسار واحد. لا تحتاج إلى كتابة X مثل سلسلة فرعية أو X مثل سلسلة فرعية أخرى. اكتب على الفور ، وكل شيء يتم بكفاءة قدر الإمكان.
ثالثًا ، يوجد الآن بحث تقريبي عن regexps وبحث تقريبي عن السلاسل الفرعية. إذا كتب شخص ما كلمة بها خطأ إملائي ، فسيتم البحث عنها عن الحد الأقصى من التطابق.
ما هي أفضل طريقة لتنظيم الوصول إلى ClickHouse لعدد كبير من المستخدمين؟
أخبرنا عن أفضل السبل لتنظيم الوصول لعدد كبير من المستهلكين والمحللين. كيف يتم تشكيل قائمة انتظار ، وتحديد أولويات الاستعلامات المتزامنة القصوى ، وما هي الأدوات؟
إذا كانت الكتلة كبيرة بما يكفي ، فسيكون الحل الجيد هو رفع خادمين آخرين ، والذي سيصبح نقطة دخول للمحللين. أي ، لا تدع المحللين في أجزاء عنقودية محددة ، ولكن ببساطة قم بإنشاء خادمين فارغين ، بدون بيانات ، وقم بالفعل بتعيين حقوق الوصول عليهما. في نفس الوقت ، يتم نقل إعدادات المستخدم إلى الخوادم البعيدة أثناء الطلبات الموزعة. أي أنك تقوم بتهيئة كل شيء على هذين الخادمين ، والإعدادات لها تأثير على المجموعة بأكملها.
من حيث المبدأ ، هذه الخوادم بدون بيانات ، لكن حجم ذاكرة الوصول العشوائي عليها مهم جدًا لتنفيذ الطلبات. يمكن أيضًا استخدام القرص للبيانات المؤقتة إذا تم تمكين التجميع الخارجي أو الفرز الخارجي.
من المهم إلقاء نظرة على الإعدادات المرتبطة بكل الحدود الممكنة. إذا انتقلت الآن إلى مجموعة Yandex.Metrics كمحلل وقمت بتعيين استعلام حدد العد من الزيارات، فسيتم إعطائي على الفور استثناءً من أنه لا يمكنني تلبية الطلب. الحد الأقصى لعدد الصفوف التي يُسمح لي بمسحها ضوئيًا هو مائة مليار ، وهناك خمسون تريليون في المجموع على الكتلة في جدول واحد. هذا هو القيد الأول.
لنفترض أنني قمت بإزالة الحد الأقصى لعدد الصفوف ، وقمت بتشغيل الاستعلام مرة أخرى. ثم سأرى الاستثناء التالي - الإعداد ممكّن مؤشر القوة حسب التاريخ. لا يمكنني تشغيل الاستعلام إذا لم أحدد نطاقًا زمنيًا. لا يتعين عليك الاعتماد على المحللين لإدخاله يدويًا. حالة نموذجية - يتم كتابة النطاق الزمني حيث يكون تاريخ الحدث بين أسبوع. وبعد ذلك لم يحددوا قوسًا هناك ، وبدلاً من ذلك ، اتضح أنه أو - أو تطابق عنوان URL. إذا لم يكن هناك حد ، فسيتم الزحف إلى عمود عنوان URL وإهدار الكثير من الموارد.
بالإضافة إلى ذلك ، يحتوي ClickHouse على إعدادين للأولوية. لسوء الحظ ، هم بدائيون للغاية. واحد يسمى ببساطة الأولوية. إذا تم تنفيذ الطلبات ذات الأولوية ≠ 0 ، وتم تنفيذ الطلبات التي لها بعض الأولوية ، ولكن تم تنفيذ طلب ذي قيمة أولوية أقل ، مما يعني أولوية أعلى ، عندئذٍ يكون الطلب ذو قيمة الأولوية أكبر من ، مما يعني أولوية أقل ، تم تعليقه ببساطة ولن يعمل على الإطلاق خلال هذا الوقت.
هذا إعداد تقريبي للغاية ولا يناسب المواقف التي يوجد فيها حمل ثابت على الكتلة. ولكن إذا كانت لديك طلبات موجزة قصيرة مهمة ، وكانت المجموعة في الغالب خاملة ، فإن هذا الإعداد سيفي بالغرض.
يتم استدعاء إعداد الأولوية التالي أولوية مؤشر ترابط نظام التشغيل. إنه يعرض ببساطة جميع سلاسل تنفيذ الطلبات للقيمة اللطيفة لجدولة Linux. إنه يعمل بشكل جيد ، لكنه لا يزال يعمل. إذا قمت بتعيين الحد الأدنى لقيمة لطيفة - إنها القيمة الأكبر ، وبالتالي أدنى أولوية - وقمت بتعيين -19 للطلبات ذات الأولوية العالية ، فستستهلك وحدة المعالجة المركزية الطلبات ذات الأولوية المنخفضة حوالي أربع مرات أقل من الطلبات ذات الأولوية العالية.
تحتاج أيضًا إلى تعيين الحد الأقصى لوقت تنفيذ الاستعلام - على سبيل المثال ، خمس دقائق. الحد الأدنى لسرعة تنفيذ الطلب هو أروع شيء. كان هذا الإعداد موجودًا منذ فترة طويلة ، وهو مطلوب ليس فقط للتأكيد على أن ClickHouse لا يبطئ ، ولكن لإجباره.
تخيل أنك تقوم بالإعداد: إذا كان الاستعلام يعالج أقل من مليون صف في الثانية ، فلا يمكنك القيام بذلك. هذا يسيء إلى سمعتنا الطيبة وقاعدة بياناتنا الجيدة. دعونا فقط نحظره. هناك بالفعل نوعان من الإعدادات. واحد يسمى سرعة تنفيذ دقيقة - بالأسطر في الثانية ، والثاني يسمى timeout قبل التحقق من أدنى سرعة للتنفيذ - خمسة عشر ثانية افتراضيًا. أي خمس عشرة ثانية ممكنة ، وبعد ذلك ، إذا كان ذلك بطيئًا ، فقم فقط بإلقاء استثناء - قم بإلغاء الطلب.
تحتاج أيضًا إلى إعداد الحصص. ClickHouse لديه ميزة حصة مضمنة تحسب استهلاك الموارد. ولكن ، للأسف ، لا تقم بتثبيت الموارد مثل وحدة المعالجة المركزية ، والأقراص ، ولكن الموارد المنطقية - عدد الطلبات المعالجة ، والأسطر والبايت التي تمت قراءتها. ويمكنك إعداد ، على سبيل المثال ، بحد أقصى مائة طلب في غضون خمس دقائق وألف طلب في الساعة.
لماذا هو مهم؟ لأن بعض طلبات التحليلات سيتم تنفيذها يدويًا مباشرةً من عميل ClickHouse. وسيكون كل شيء على ما يرام. ولكن إذا كان لديك محللون متقدمون في شركتك ، فسوف يكتبون نصًا ، وقد يكون هناك خطأ في البرنامج النصي. وسيؤدي هذا الخطأ إلى تنفيذ الطلب في حلقة لا نهائية. هذا ما يجب حمايته.
هل يمكن إعطاء نتائج طلب واحد لعشرة عملاء؟
لدينا العديد من المستخدمين الذين يرغبون في إرسال طلبات كبيرة جدًا في نفس الوقت. الطلب كبير ، من حيث المبدأ يتم تنفيذه بسرعة ، ولكن نظرًا لوجود العديد من هذه الطلبات في نفس الوقت ، يصبح الأمر مؤلمًا للغاية. هل يمكن تنفيذ نفس الطلب الذي وصل عشر مرات متتالية مرة واحدة وإعطاء النتيجة لعشرة عملاء؟
المشكلة هي أنه ليس لدينا نتائج ذاكرة التخزين المؤقت أو ذاكرة التخزين المؤقت للبيانات الوسيطة. هناك ذاكرة تخزين مؤقت للصفحة لنظام التشغيل ، والتي ستسمح لك بعدم قراءة البيانات من القرص مرة أخرى ، ولكن ، للأسف ، ستظل البيانات غير مضغوطة ، وإلغاء التسلسل ، وإعادة المعالجة.
أود أن أتجنب هذا بطريقة ما ، إما عن طريق التخزين المؤقت للبيانات الوسيطة ، أو عن طريق اصطفاف استعلامات مماثلة في نوع من قائمة الانتظار وإضافة ذاكرة تخزين مؤقت للنتائج. الآن لدينا طلب سحب واحد قيد التطوير ، والذي يضيف ذاكرة تخزين مؤقت للطلب ، ولكن فقط للطلبات الفرعية في قسمي in and Join - أي أن الحل أقل جودة.
ومع ذلك ، لدينا مثل هذا الوضع. من الأمثلة المتعارف عليها بشكل خاص الطلبات ذات الصفحات الفاصلة للصفحات. يوجد تقرير به عدة صفحات ويوجد حد للطلب 10. ثم نفس الشيء ولكن بحد 10,10. ثم صفحة أخرى. والسؤال هو ، لماذا نحسبها كلها في كل مرة؟ لكن الآن لا يوجد حل ، ولا توجد طريقة لتجنبه.
يوجد حل بديل يتم وضعه كملف جانبي بجوار ClickHouse - .
كيريل شفاكوف: ClickHouse Proxy له محدد معدل مضمن وذاكرة تخزين نتائج مضمنة. تم إجراء الكثير من الإعدادات هناك ، لأنه تم حل مهمة مماثلة. يسمح لك الوكيل بتقييد الطلبات عن طريق وضعها في قائمة الانتظار ، وتكوين مدة بقاء ذاكرة التخزين المؤقت للطلب. إذا كانت الطلبات متطابقة بالفعل ، فسيقوم الوكيل بتقديمها عدة مرات ، وسيذهب إلى ClickHouse مرة واحدة فقط.
يحتوي Nginx أيضًا على ذاكرة تخزين مؤقت في الإصدار المجاني وسيعمل ذلك أيضًا. يحتوي Nginx أيضًا على إعدادات بحيث إذا وردت الطلبات في نفس الوقت ، فإنها ستوقف الآخرين حتى يكتمل أحدها. ولكن في ClickHouse Proxy يتم تحسين الإعدادات بشكل كبير. تم إعداده خصيصًا لـ ClickHouse ، خصيصًا لهذه الطلبات ، لذا فهو أكثر ملاءمة. حسنًا ، من السهل الإعداد.
ماذا عن العمليات غير المتزامنة ووجهات النظر المحققة؟
هناك مشكلة تتمثل في أن العمليات مع المحرك البديل غير متزامنة - تتم كتابة البيانات أولاً ، ثم تنهار. إذا كان الجهاز اللوحي الذي تم تجسيده مع بعض الركام موجودًا أسفل الجهاز اللوحي ، فسيتم كتابة نسخ مكررة إليه. وإذا لم يكن هناك منطق معقد ، فسيتم تكرار البيانات. ما الذي يمكن عمله حيال ذلك؟
هناك حل واضح - لتنفيذ مشغل على فئة matview معينة أثناء عملية الانهيار غير المتزامن. هل هناك أي خطط "رصاصة فضية" لتنفيذ هذه الوظيفة؟
يجدر بنا فهم كيفية عمل إلغاء البيانات المكررة. ما أنا على وشك قوله لا يتعلق بالسؤال ، لكن الأمر يستحق التذكر في حالة حدوثه.
عند الإدراج في جدول منسوخ ، يتم إلغاء تكرار الكتل المدرجة بالكامل. إذا قمت بإعادة إدخال نفس الكتلة التي تحتوي على نفس العدد من نفس الصفوف بنفس الترتيب ، فسيتم إلغاء تكرار البيانات. ستحصل على "موافق" ردًا على الإدخال ، ولكن سيتم بالفعل كتابة دفعة واحدة من البيانات ولن تتكرر.
هذا ضروري من أجل اليقين. إذا حصلت على "موافق" أثناء الإدراج ، فهذا يعني أنه تم إدخال بياناتك. إذا تلقيت خطأ من ClickHouse ، فلن يتم إدراجها ، وتحتاج إلى تكرار الإدراج. ولكن إذا انقطع الاتصال أثناء الإدراج ، فأنت لا تعرف ما إذا كانت البيانات قد تم إدخالها أم لا. الخيار الوحيد هو تكرار الإدراج مرة أخرى. إذا تم بالفعل إدراج البيانات وقمت بإعادة إدخالها ، فهناك حظر إلغاء تكرار. هناك حاجة لتجنب التكرارات.
ومن المهم أيضًا كيف تعمل من أجل وجهات النظر الواقعية. إذا تم إلغاء تكرار البيانات عند إدراجها في الجدول الرئيسي ، فلن تنتقل إلى العرض الفعلي أيضًا.
الآن حول السؤال. وضعك أكثر تعقيدًا لأنك تكتب نسخًا مكررة من السطور الفردية. هذا يعني أنه لا يتم تكرار الحزمة بأكملها ، ولكن هناك خطوط محددة ، وتنهار في الخلفية. في الواقع ، ستنهار البيانات في الجدول الرئيسي ، وستنتقل البيانات غير المنهارة إلى العرض الفعلي ، ولن يحدث شيء لوجهات النظر المحققة أثناء الدمج. لأن العرض المحقق ليس أكثر من مشغل على الإدراج. لا شيء آخر يحدث لها أثناء العمليات الأخرى.
ولا يمكنني أن أكون سعيدًا هنا. من الضروري فقط البحث عن حل محدد لهذه الحالة. على سبيل المثال ، هل من الممكن استبداله بطريقة واقعية ، وربما تعمل طريقة إلغاء البيانات المكررة بنفس الطريقة. لكن لسوء الحظ ، ليس دائمًا. إذا كان مجمعًا ، فلن يعمل.
كيريل شفاكوف: كان لدينا أيضًا بناء عظام في وقت واحد. كانت هناك مشكلة في وجود مرات ظهور للإعلان ، وهناك بعض البيانات التي يمكننا عرضها في الوقت الفعلي - هذه مجرد مرات ظهور. نادرًا ما يتم تكرارها ، ولكن إذا حدث ذلك ، فسنقوم بتفكيكها على أي حال. وكانت هناك أشياء لا يمكن تكرارها - النقرات وهذه القصة بأكملها. لكنني أردت أيضًا أن أعرضهم على الفور تقريبًا.
كيف تم تحقيق وجهات النظر؟ كانت هناك آراء حيث تمت كتابتها مباشرة - هناك سجل في البيانات الأولية ، وهو مكتوب في طرق العرض. هناك ، في مرحلة ما ، البيانات ليست صحيحة تمامًا ، فهي مكررة ، وما إلى ذلك. وهناك الجزء الثاني من الجدول ، حيث تبدو تمامًا مثل الآراء الفعلية ، أي أنها متشابهة تمامًا في الهيكل. من حين لآخر ، نقوم بإعادة حساب البيانات ، ونحصي البيانات بدون تكرارات ، والكتابة على تلك الجداول.
لقد مررنا بواجهة برمجة التطبيقات - لن يعمل هذا في ClickHouse يدويًا. وتبدو واجهة برمجة التطبيقات (API): عندما يكون لدي تاريخ آخر إضافة إلى الجدول ، حيث يتم ضمان أن البيانات الصحيحة قد تم احتسابها بالفعل ، وتقوم بتقديم طلب إلى جدول وإلى جدول آخر. من أحد الطلبات يتم تحديد مقدار معين من الوقت ، ومن الآخر يحصل على ما لم يتم حسابه بعد. وهو يعمل ، ولكن ليس عن طريق ClickHouse واحد.
إذا كان لديك نوع من API - للمحللين ، للمستخدمين - إذن ، من حيث المبدأ ، يعد هذا خيارًا. أنت تحسب دائما ، تحسب دائما. يمكن القيام بذلك مرة واحدة في اليوم أو في وقت آخر. أنت تختار بنفسك النطاق الذي لا تحتاجه وليس حرجًا.
ClickHouse لديه الكثير من السجلات. كيف يمكنني رؤية كل ما يحدث للخادم في لحظة؟
يحتوي ClickHouse على عدد كبير جدًا من السجلات المختلفة ، وهذا الرقم آخذ في الازدياد. في الإصدارات الجديدة ، يتم تمكين بعضها افتراضيًا ، في الإصدارات القديمة يجب تمكينها عند التحديث. ومع ذلك ، هناك المزيد والمزيد منهم. أود أن أرى أخيرًا ما يحدث الآن مع الخادم الخاص بي ، ربما على لوحة معلومات موجزة.
هل لديك في فريق ClickHouse ، أو في فرق أصدقائك ، الذين يدعمون بعض وظائف لوحات المعلومات الجاهزة التي تعرض هذه السجلات كمنتج نهائي؟ في النهاية ، يعد مجرد إلقاء نظرة على السجلات في ClickHouse أمرًا رائعًا. لكنه سيكون رائعًا جدًا إذا تم إعداده بالفعل على شكل لوحة أجهزة القياس. سأكون منتشيا في هذا.
توجد لوحات معلومات ، على الرغم من أنها غير موحدة. لدينا حوالي 60 فريقًا في شركتنا يستخدمون ClickHouse ، والأغرب من ذلك أن العديد منهم لديهم لوحات معلومات صنعوها بأنفسهم ، ومختلفة قليلاً. تستخدم بعض الفرق التثبيت الداخلي لـ Yandex.Cloud. هناك بعض التقارير الجاهزة ، وإن لم تكن كلها ضرورية. البعض الآخر لهم.
زملائي من Metrica لديهم لوحة القيادة الخاصة بهم في Grafana ، ولدي لوحة التحكم الخاصة بهم في المجموعة الخاصة بهم. أنا أبحث في أشياء مثل ذاكرة التخزين المؤقت التي تم ضربها لذاكرة التخزين المؤقت. والأكثر صعوبة هو أننا نستخدم أدوات مختلفة. لقد أنشأت لوحة القيادة الخاصة بي على أداة قديمة جدًا تسمى Graphite-web. إنه قبيح تمامًا. وما زلت أستخدمه بهذه الطريقة ، على الرغم من أن Grafana ربما تكون أكثر ملاءمة وأجمل.
الشيء الأساسي في لوحات المعلومات هو نفسه. هذه مقاييس النظام للمجموعة: وحدة المعالجة المركزية ، والذاكرة ، والقرص ، والشبكة. البعض الآخر هو عدد الطلبات المتزامنة ، وعدد عمليات الدمج المتزامنة ، وعدد الطلبات في الثانية ، والحد الأقصى لعدد القطع لأقسام جدول MergeTree ، وتأخر النسخ المتماثل ، وحجم قائمة انتظار النسخ المتماثل ، وعدد الصفوف المدرجة في الثانية ، عدد الكتل التي تم إدخالها في الثانية. هذا كل ما يتم الحصول عليه ليس من السجلات ، ولكن من المقاييس.
فلاديمير كولوبييف: أليكسي ، أود أن أصحح قليلاً. هناك غرافانا. لدى Grafana مصدر بيانات وهو ClickHouse. وهذا يعني أنه يمكنني تقديم طلبات من Grafana مباشرة إلى ClickHouse. ClickHouse لديه جدول مع سجلات ، هو نفسه بالنسبة للجميع. نتيجة لذلك ، أريد الوصول إلى جدول السجل هذا في Grafana والاطلاع على الطلبات التي يطبقها خادمي. سيكون من الرائع أن يكون لديك لوحة القيادة هذه.
دراجتها بنفسي. لكن لدي سؤال - إذا كان كل شيء موحدًا ، ويستخدم الجميع Grafana ، فلماذا لا تمتلك Yandex لوحة القيادة الرسمية هذه؟
كيريل شفاكوف: في الواقع ، مصدر البيانات الذي يدعم ClickHouse الآن Altinity. وأريد فقط أن أعطي متجهًا لمكان الحفر ومن يدفع. يمكنك أن تسألهم ، لأن Yandex لا يزال يصنع ClickHouse ، وليس القصة من حوله. Altinity هي الشركة الرئيسية التي تروج حاليًا لـ ClickHouse. لن يتخلوا عنه ، لكنهم سيدعمونه. لأنه من حيث المبدأ ، من أجل تحميل لوحة معلومات على موقع Grafana ، ما عليك سوى التسجيل وتحميلها - لا توجد مشاكل معينة.
أليكسي ميلوفيدوف: خلال العام الماضي ، أضاف ClickHouse الكثير من ميزات تحديد سمات الاستعلام. هناك مقاييس لكل طلب استخدام الموارد. ومؤخراً ، تمت إضافة ملف تعريف استعلام ذي مستوى أدنى لمعرفة أين يقضي الاستعلام كل مللي ثانية. ولكن لاستخدام هذه الوظيفة ، يجب أن أفتح عميل وحدة التحكم وأكتب استعلامًا ما زلت أنساه. لقد حفظتها في مكان ما ودائمًا ما أنسى أين بالضبط.
أتمنى لو كانت هناك أداة تقول فقط - إليك استفساراتك الثقيلة ، مجمعة حسب فئة الاستعلام. قمت بالنقر فوق أحدها ، وكانوا يقولون لي أنه ثقيل لذلك. الآن لا يوجد مثل هذا الحل. ومن الغريب حقًا أنه عندما يسألني الناس: "أخبرني ، هل هناك أي لوحات تحكم جاهزة لغرافانا؟" من كوستيان. لا أعرف ما هو ، لم أستخدمه بنفسي ".
كيفية التأثير على merdzhi بحيث لا يقع الخادم في OOM؟
لدي جدول ، لا يوجد سوى قسم واحد في الجدول ، وهو ReplacingMergeTree. لقد كنت أكتب البيانات إليها منذ أربع سنوات. اضطررت إلى إجراء تغيير فيه وحذف بعض البيانات.
لقد قمت بذلك ، وأثناء معالجة هذا الطلب ، تم التهام كل الذاكرة الموجودة على جميع الخوادم في المجموعة ، وذهبت جميع الخوادم في المجموعة إلى OOM معًا. ثم قاموا جميعًا معًا ، وبدأوا في دمج نفس العملية ، كتلة البيانات هذه ، وسقطوا مرة أخرى في OOM. ثم نهضوا مرة أخرى وسقطوا مرة أخرى. وهذا الشيء لم يتوقف.
ثم اتضح أن هذا في الواقع خطأ قام الرجال بإصلاحه. هذا رائع جدا ، شكرا جزيلا لك. لكن البقايا بقيت. والآن ، عندما أفكر في الحاجة إلى إجراء عملية دمج معينة في الجدول ، لدي سؤال - لماذا لا يمكنني إجراء عمليات الدمج هذه والتأثير عليها بطريقة ما؟ على سبيل المثال ، حددها بمقدار ذاكرة الوصول العشوائي المطلوبة ، أو ، من حيث المبدأ ، بعددها ، والتي ستعالج هذا الجدول المحدد.
لدي جدول يسمى "المقاييس" ، يرجى معالجته لي في دفقين. لا حاجة لإنتاج عشر أو خمس عمليات دمج على التوازي ، قم بذلك على مرحلتين. أعتقد أن لدي ذاكرة كافية من جزأين ، لكن قد لا يكون ذلك كافياً لمعالجة العشر. لماذا يبقى الخوف؟ نظرًا لأن الجدول ينمو ، وسأواجه يومًا ما موقفًا ، من حيث المبدأ ، لم يعد ناتجًا عن خطأ ، ولكن نظرًا لحقيقة أن البيانات ستتغير بكمية كبيرة لدرجة أنني ببساطة لا أملك ذاكرة كافية عليها الخادم. وبعد ذلك سوف يقع الخادم في OOM أثناء الدمج. علاوة على ذلك ، يمكنني إلغاء الطفرة ، لكن الدمج انتهى.
كما تعلم ، عند الدمج ، لن يقع الخادم في OOM ، لأنه عند الدمج ، يتم استخدام مقدار ذاكرة الوصول العشوائي (RAM) فقط لنطاق بيانات صغير واحد. لذلك سيكون كل شيء على ما يرام بغض النظر عن كمية البيانات.
فلاديمير كولوبييف: بخير. هذه اللحظة هي أنه بعد أن أجرينا إصلاحًا للأخطاء ، قمت بتنزيل إصدار جديد لنفسي ، وعلى طاولة أخرى ، أصغر حجمًا ، حيث يوجد الكثير من الأقسام ، قمت بإجراء عملية مماثلة. وأثناء الدمج ، تم حرق حوالي 100 جيجابايت من ذاكرة الوصول العشوائي على الخادم. كان لدي 150 مشغولاً ، وأكلت 100 ، وكانت هناك نافذة بسعة 50 غيغابايت متبقية ، لذلك لم أقع في OOM.
ما الذي يحميني حاليًا من الوقوع في OOM إذا كانت تستهلك بالفعل 100 جيجابايت من ذاكرة الوصول العشوائي؟ ماذا تفعل في حالة نفاد ذاكرة الوصول العشوائي على المرزة فجأة؟
أليكسي ميلوفيدوف: هناك مثل هذه المشكلة أن استهلاك ذاكرة الوصول العشوائي لا يقتصر على Merdzhi. والمشكلة الثانية هي أنه إذا تم تعيين عملية دمج ، فيجب تنفيذها ، لأنها مكتوبة في سجل النسخ المتماثل. سجل النسخ المتماثل هو الإجراءات اللازمة لإحضار النسخة المتماثلة إلى حالة متسقة. إذا لم تقم بمعالجات يدوية من أن سجل النسخ المتماثل هذا سوف يتراجع ، يجب أن يتم تنفيذ الدمج بطريقة أو بأخرى.
بالطبع ، لن يكون من غير الضروري أن يكون هناك قيود على ذاكرة الوصول العشوائي ، والتي "فقط في حالة" تحمي من OOM. لن يساعد ذلك في تشغيل الدمج ، سيبدأ مرة أخرى ، ويصل إلى حد ما ، ويطرح استثناءًا ، ثم يبدأ مرة أخرى - لن يأتي أي شيء جيد منه. لكن من حيث المبدأ ، سيكون من المفيد إدخال هذا القيد.
كيف سيتم تطوير برنامج تشغيل Golang لـ ClickHouse؟
برنامج تشغيل Golang الذي كتبه Kirill Shvakov مدعوم رسميًا الآن من قبل فريق ClickHouse. هو ، هو الآن كبير وحقيقي.
ملاحظة صغيرة. هناك مستودع رائع ومحبوب للأشكال العادية من النظام اللانهائي - هذا هو Vertica. لديهم أيضًا برنامج تشغيل Python الرسمي الخاص بهم ، والذي يتم صيانته بواسطة مطوري Vertica. وحدث عدة مرات أن إصدارات التخزين وإصدارات برنامج التشغيل افترقت فجأة ، وتوقف السائق عن العمل في مرحلة ما. والنقطة الثانية. يبدو لي أن دعم هذا السائق الرسمي يتم صيانته من خلال نظام "الحلمة" - تكتب مشكلة لهم ، وتظل معلقة إلى الأبد.
لدي سؤالان. يعد برنامج تشغيل Kirill's Golang طريقة افتراضية تقريبًا للتواصل من Golang باستخدام ClickHouse. ما لم يتواصل شخص ما عبر واجهة http ، لأنه يحبه كثيرًا. كيف سيتم تطوير هذا السائق؟ هل ستتم مزامنتها مع بعض التغييرات الفاصلة في المستودع نفسه؟ وما هي الإجراءات المتبعة للنظر في الموضوع؟
كيريل شفاكوف: الأول هو كيف يتم ترتيب كل شيء بشكل بيروقراطي. لم تتم مناقشة هذه النقطة ، لذلك ليس لدي ما أجيب عنه.
للإجابة على السؤال حول المشكلة ، نحتاج إلى القليل من تاريخ السائق. عملت في شركة لديها الكثير من البيانات. لقد كانت عبارة عن قرص إعلان يحتوي على عدد كبير من الأحداث التي يجب تخزينها في مكان ما. وفي وقت ما ظهر ClickHouse. لقد سكبنا البيانات فيه ، وفي البداية كان كل شيء على ما يرام ، ولكن بعد ذلك سقط ClickHouse. في ذلك الوقت ، قررنا أننا لسنا بحاجة إليه.
بعد عام ، عدنا إلى فكرة استخدام ClickHouse ، وكنا بحاجة إلى كتابة البيانات بطريقة ما هناك. كان الإدخال هذا - الحديد ضعيف جدًا ، هناك القليل من الموارد. لكننا عملنا دائمًا بهذه الطريقة ، وبالتالي نظرنا نحو البروتوكول الأصلي.
نظرًا لأننا كنا نعمل على Go ، كان من الواضح أننا بحاجة إلى سائق Go. لقد قمت بذلك بدوام كامل تقريبًا - لقد كانت مهمة عملي. حتى نقطة معينة ، طرحناها ، ومن حيث المبدأ ، لم يتوقع أحد أن يستخدمها شخص آخر غيرنا. ثم جاء CloudFlare مع نفس المشكلة بالضبط ، ولفترة من الوقت عملنا معهم بسلاسة كبيرة ، لأن لديهم نفس المهام. وقد فعلنا ذلك في ClickHouse نفسها وفي برنامج التشغيل.
في مرحلة ما ، توقفت ببساطة عن القيام بذلك ، لأن نشاطي فيما يتعلق بـ ClickHouse والعمل قد تغير قليلاً. لذلك لم يتم إغلاق القضايا. بشكل دوري ، يلتزم الأشخاص الذين يحتاجون إلى شيء ما في المستودع. ثم ألقي نظرة على طلب السحب وأحيانًا أقوم بتعديل شيء ما بنفسي ، لكن هذا نادرًا ما يحدث.
اريد العودة الى السائق. قبل بضع سنوات ، عندما بدأ هذا الأمر برمته ، كان ClickHouse مختلفًا أيضًا وبميزات مختلفة. الآن هناك فهم لكيفية إعادة تشكيل السائق بحيث يكون جيدًا. إذا حدث هذا ، فسيكون الإصدار 2 غير متوافق على أي حال بسبب العكازات المتراكمة.
لا أعرف كيف أرتب هذا. ليس لدي الكثير من الوقت بنفسي. إذا أنهى بعض الأشخاص السائق ، يمكنني مساعدتهم وإخبارهم بما يجب عليهم فعله. لكن مشاركة Yandex النشطة في تطوير المشروع لم تتم مناقشتها بأي شكل من الأشكال.
أليكسي ميلوفيدوف: في الواقع ، لا توجد بيروقراطية حول هؤلاء السائقين حتى الآن. الشيء الوحيد هو أنه تم نقلهم إلى مؤسسة رسمية ، أي أن هذا المحرك معترف به على أنه الحل الافتراضي الرسمي لـ Go. هناك بعض السائقين الآخرين ، لكنهم يأتون بشكل منفصل.
ليس لدينا أي تطوير لهذه السائقين في الداخل. السؤال هو ما إذا كان بإمكاننا توظيف فرد ، ليس خصيصًا لهذا السائق ، ولكن من أجل تطوير جميع السائقين المجتمعيين ، أو هل يمكننا العثور على شخص ما في الخارج.
لم يتم رفع القاموس الخارجي بعد إعادة التشغيل مع تمكين lazy_load. ما يجب القيام به؟
لقد تم تمكين إعداد lazy_load ، وبعد إعادة تشغيل الخادم ، لا يرتفع القاموس نفسه. يتم رفعه فقط بعد وصول المستخدم إلى هذا القاموس. ويحدث خطأ في المكالمة الأولى. هل من الممكن تحميل القواميس تلقائيًا بطريقة ما باستخدام ClickHouse ، أم أنك تحتاج دائمًا إلى التحكم في جاهزيتها بنفسك حتى لا يتلقى المستخدمون أخطاء؟
ربما لدينا نسخة قديمة من ClickHouse ، لذلك لم يتم تحميل القاموس تلقائيًا. هل من الممكن ذلك؟
أولاً ، يمكن فرض تحميل القواميس باستخدام الاستعلام نظام إعادة تحميل القواميس. ثانيًا ، حول الخطأ - إذا تم تحميل القاموس بالفعل ، فستعمل الاستعلامات على البيانات التي تم تحميلها. إذا لم يتم تحميل القاموس بعد ، فسيتم تحميله في وقت الطلب مباشرة.
بالنسبة للقواميس الثقيلة ، هذا ليس مناسبًا جدًا. على سبيل المثال ، تحتاج إلى جلب مليون صف من MySQL. يقوم شخص ما بتحديد بسيط ، ولكن هذا التحديد سينتظر نفس المليون صف. هناك حلان هنا. الأول هو إيقاف تشغيل lazy_load. والثاني هو عندما يرتفع الخادم ، قبل تشغيل الحمل عليه ، قم بذلك قاموس إعادة تحميل النظام أو نفذ استعلامًا يستخدم قاموسًا. ثم سيتم تحميل القاموس. تحتاج إلى التحكم في توفر القواميس مع تمكين إعداد lazy_load ، لأن ClickHouse لا يقوم بسحبها تلقائيًا.
الإجابة على السؤال الأخير إما أن الإصدار قديم ، أو يحتاج إلى تصحيح.
ماذا عن حقيقة أن نظام إعادة تحميل القواميس لا يقوم بتحميل أي من القواميس العديدة إذا تعطل أحدها على الأقل بسبب خطأ؟
هناك سؤال آخر حول نظام إعادة تحميل القواميس. لدينا قواميسان - أحدهما غير محمّل والثاني محمل. لا تقوم قواميس إعادة تحميل النظام في هذه الحالة بتحميل أي قاموس ، وعليك تحميل قاموس محدد من نقطة إلى نقطة باسمه باستخدام قاموس إعادة تحميل النظام. هل هذا متعلق بإصدار ClickHouse أيضًا؟
اريد من فضلك. لقد تغير هذا السلوك. لذلك ، إذا قمت بتحديث ClickHouse ، فسوف يتغير أيضًا. إذا لم تكن راضيًا عن السلوك الحالي نظام إعادة تحميل القواميسوتحديثه ونأمل أن يتغير للأفضل.
هل توجد طريقة لتهيئة التفاصيل في تهيئة ClickHouse ، ولكن لا توجد طريقة لتهيئة الأخطاء؟
السؤال التالي يدور حول الأخطاء المتعلقة بالقاموس ، وبالتحديد التفاصيل. لقد سجلنا تفاصيل الاتصال في ClickHouse config إلى القاموس ، وفي حالة حدوث خطأ ، نتلقى هذه التفاصيل وكلمة المرور ردًا على ذلك.
لقد قمنا بحل هذا الخطأ عن طريق إضافة تفاصيل إلى تكوين برنامج تشغيل ODBC. هل هناك طريقة ما لتهيئة التفاصيل في تهيئة ClickHouse ، ولكن ليس لإظهار هذه التفاصيل حول الأخطاء؟
هنا ، الحل هو تحديد بيانات الاعتماد هذه في odbc.ini ، وفي ClickHouse نفسه ، حدد فقط اسم مصدر بيانات ODBC. لن يحدث هذا لمصادر القاموس الأخرى - لا للقاموس الذي يحتوي على MySQL ولا بالنسبة للبقية ، يجب ألا ترى كلمة المرور في رسالة الخطأ. بالنسبة لـ ODBC ، سأبحث أيضًا - إذا كان هناك شيء من هذا القبيل ، فأنت تحتاج فقط إلى إزالته.
المكافأة: خلفيات لـ Zuma من اللقاءات
من خلال النقر على الصورة للقراء الأكثر إصرارًا ، سيتم فتح الخلفيات الإضافية من التجمعات. إخماد النيران مع تمائم Avito التكنولوجية ، والتشاور مع الزملاء من غرفة مسؤول النظام أو نادي الكمبيوتر في المدرسة القديمة ، وإقامة يومية تحت الجسر على خلفية الكتابة على الجدران.
المصدر: www.habr.com