الانتقال إلى المحتوى الرئيسي
الإجابة المختصرة هي “لا”. يُعد عبء عمل المفتاح-القيمة من أبرز الحالات التي لا يُنصح فيها باستخدام ClickHouse. فهو في النهاية نظام OLAP، بينما توجد العديد من أنظمة تخزين المفتاح-القيمة الممتازة الأخرى. ومع ذلك، قد تكون هناك حالات يظل فيها استخدام ClickHouse لاستعلامات شبيهة بالمفتاح-القيمة منطقيًا. يحدث هذا عادةً في بعض المنتجات منخفضة الميزانية، حيث يكون عبء العمل الأساسي تحليليًا بطبيعته ويلائم ClickHouse جيدًا، لكن توجد أيضًا عملية ثانوية تحتاج إلى نمط مفتاح-قيمة بمعدل طلبات ليس مرتفعًا جدًا ومن دون متطلبات صارمة لزمن الاستجابة. لو كانت لديك ميزانية غير محدودة، لكنت ثبّتَّ قاعدة بيانات مفتاح-قيمة ثانوية لهذا العبء الثانوي، لكن الواقع أن هناك تكلفة إضافية لصيانة نظام تخزين آخر (المراقبة، النسخ الاحتياطية، إلخ)، وقد يكون من الأفضل تجنبها. إذا قررت مخالفة التوصيات وتشغيل بعض الاستعلامات الشبيهة بالمفتاح-القيمة على ClickHouse، فإليك بعض النصائح:
  • السبب الرئيسي وراء ارتفاع تكلفة الاستعلامات المباشرة في ClickHouse هو الفهرس الأساسي المتناثر الخاص به في عائلة محركات الجداول MergeTree الرئيسية. فهذا الفهرس لا يمكنه الإشارة إلى كل صف بيانات على حدة، بل يشير إلى كل صف رقم N فقط، ويضطر النظام إلى الفحص بدءًا من الصف المجاور رقم N وصولًا إلى الصف المطلوب، مع قراءة بيانات زائدة في الطريق. في سيناريو المفتاح-القيمة، قد يكون من المفيد تقليل قيمة N باستخدام الإعداد index_granularity.
  • يحتفظ ClickHouse بكل عمود في مجموعة ملفات منفصلة، لذا يحتاج إلى المرور على كل هذه الملفات لتجميع صف كامل واحد. ويزداد عددها خطيًا مع عدد الأعمدة، لذلك قد يكون من المجدي في سيناريو المفتاح-القيمة تجنب استخدام عدد كبير من الأعمدة، ووضع كل بياناتك في عمود String واحد مُرمَّز بتنسيق تسلسلي مثل JSON أو Protobuf أو أي تنسيق آخر مناسب.
  • هناك نهج بديل يستخدم محرك الجداول Join بدلًا من جداول MergeTree العادية، ودالة joinGet لاسترجاع البيانات. يمكن أن يوفّر هذا أداء استعلامات أفضل، لكنه قد يسبب بعض المشكلات المتعلقة بسهولة الاستخدام والموثوقية. إليك مثال استخدام.
آخر تعديل في ٢٩ يونيو ٢٠٢٦