Skip to main content
هذا الدليل جزء من مجموعة من الخلاصات المستمدة من لقاءات المجتمع. ولمزيد من الحلول العملية والرؤى الواقعية، يمكنك التصفح حسب المشكلة المحددة. هل تحتاج إلى نصائح حول استكشاف مشكلة وإصلاحها في بيئة الإنتاج؟ اطّلع على دليل المجتمع رؤى استكشاف الأخطاء وإصلاحها. تُظهر هذه القصص كيف حققت الشركات نجاحًا باستخدام ClickHouse في حالات استخدام متنوعة، بل إن بعضها تحدّى التصنيفات التقليدية لقواعد البيانات وأثبت أن الأداة “غير المناسبة” قد تصبح أحيانًا الحل المناسب تمامًا.

​
ClickHouse كآلية لتقييد المعدل

عندما احتاجت Craigslist إلى إضافة تقييد معدل من المستوى الأول لحماية مستخدميها، واجهت القرار نفسه الذي يواجهه كل فريق هندسي: هل تلتزم بالمألوف وتستخدم Redis، أم تجرّب شيئًا مختلفًا؟ كان Brad Lhotsky، الذي كان يعمل في Craigslist، يعلم أن Redis هو الخيار القياسي — فكل دليل عملي ومثال تقريبًا على تقييد المعدل على الإنترنت يستخدم Redis لسبب وجيه. فهو يوفّر بدائيات غنية لعمليات تقييد المعدل، وأنماطًا راسخة، وسجلًا مثبتًا. لكن تجربة Craigslist مع Redis لم تكن تشبه الأمثلة المثالية. “تجربتنا مع Redis ليست كما تراها في الأفلام… واجهنا الكثير من مشكلات الصيانة الغريبة؛ نعيد تشغيل عقدة في عنقود Redis، فتحدث قفزة في زمن الاستجابة تصل إلى الواجهة الأمامية.” وبالنسبة إلى فريق صغير يقدّر بساطة الصيانة، كانت هذه المتاعب التشغيلية تتحول إلى مشكلة حقيقية. لذلك، عندما طُرحت على Brad متطلبات تقييد المعدل، اختار نهجًا مختلفًا: “سألت مديري: ما رأيك في هذه الفكرة؟ ربما أستطيع تجربة ذلك باستخدام ClickHouse؟” كانت الفكرة غير تقليدية — استخدام قاعدة بيانات تحليلية لحل مشكلة تُعالَج عادةً في طبقة التخزين المؤقت — لكنها لبّت متطلباتهم الأساسية: التعطل مع السماح للطلبات بالمرور، وعدم إضافة أي عبء على زمن الاستجابة، وأن تكون سهلة الصيانة لفريق صغير. اعتمد الحل على بنيتهم التحتية الحالية، إذ كانت سجلات الوصول تتدفق بالفعل إلى ClickHouse عبر Kafka. وبدلًا من تشغيل عنقود Redis منفصل وصيانته، أصبح بإمكانهم تحليل أنماط الطلبات مباشرةً من بيانات سجل الوصول وحقن قواعد تقييد المعدل في واجهة برمجة تطبيقات ACL الحالية لديهم. وقد عنى هذا النهج زمن استجابة أعلى قليلًا من Redis، الذي “يُعد نوعًا ما تحايلًا لأنه يجهّز مجموعة البيانات تلك مسبقًا” بدلًا من تنفيذ استعلامات تجميع في الوقت الفعلي، لكن الاستعلامات كانت لا تزال تكتمل في أقل من 100 ملّي ثانية. النتائج الرئيسية:
  • تحسّن كبير مقارنةً ببنية Redis التحتية
  • ألغت TTL المدمجة للتنظيف التلقائي الأعباء الإضافية للصيانة
  • أتاحت مرونة SQL وضع قواعد تقييد معدل معقدة تتجاوز العدادات البسيطة
  • استفادوا من مسار البيانات الحالي بدلًا من الحاجة إلى بنية تحتية منفصلة

​
ClickHouse لتحليلات العملاء

عندما احتاجت ServiceNow إلى ترقية منصة تحليلات الأجهزة المحمولة لديها، واجهت سؤالًا بسيطًا: “لماذا نستبدل شيئًا يعمل؟” كان Amir Vaza من ServiceNow يعلم أن نظامهم الحالي موثوق، لكن متطلبات العملاء بدأت تتجاوز قدراته. وشرح Amir ذلك قائلًا: “إن الدافع إلى استبدال نموذج قائم وموثوق يأتي في الواقع من عالم المنتجات.” كانت ServiceNow تقدم تحليلات الأجهزة المحمولة كجزء من حلها للويب والأجهزة المحمولة وروبوتات الدردشة، لكن العملاء أرادوا مرونة تحليلية تتجاوز البيانات المجمّعة مسبقًا. كان نظامهم السابق يستخدم نحو 30 جدولًا مختلفًا تتضمن بيانات مجمّعة مسبقًا ومقسّمة بحسب أبعاد ثابتة: التطبيق، وإصدار التطبيق، والمنصة. أما بالنسبة إلى الخصائص المخصّصة—أزواج المفتاح والقيمة التي يمكن للعملاء إرسالها—فقد أنشأوا عدّادات منفصلة لكل مجموعة. وقد أتاح هذا النهج أداءً سريعًا للوحة المعلومات، لكنه جاء مع قيد كبير. وكما أشار Amir: “رغم أن هذا ممتاز لتقسيم القيم بسرعة، فقد ذكرت أن هذا القيد يؤدي إلى فقدان كبير في السياق التحليلي.” لم يكن بإمكان العملاء إجراء تحليل معقّد لرحلة العميل أو طرح أسئلة مثل “كم عدد الجلسات التي بدأت بعبارة البحث ‘research RSA token’” ثم تحليل ما فعله هؤلاء المستخدمون بعد ذلك. فقد كانت البنية المجمّعة مسبقًا تدمر السياق التسلسلي اللازم للتحليل متعدد الخطوات، كما أن كل بُعد تحليلي جديد كان يتطلب جهدًا هندسيًا إضافيًا للتجميع المسبق والتخزين. لذلك، عندما اتضحت هذه القيود، انتقلت ServiceNow إلى ClickHouse وتخلّصت تمامًا من قيود الحساب المسبق هذه. فبدلًا من حساب كل متغير مسبقًا، حوّلت البيانات الوصفية إلى نقاط بيانات وأدرجت كل شيء مباشرةً في ClickHouse. واستخدمت قائمة انتظار async insert في ClickHouse، التي وصفها Amir بأنها “مذهلة فعلًا،” للتعامل بكفاءة مع إدخال البيانات. وقد أتاح هذا النهج للعملاء إنشاء شرائحهم الخاصة، وتقسيم البيانات بحرية عبر أي أبعاد، وإجراء تحليل معقّد لرحلة العميل لم يكن ممكنًا من قبل. النتائج الرئيسية:
  • تقسيم ديناميكي عبر أي أبعاد من دون حساب مسبق
  • أصبح تحليل رحلة العميل المعقّد ممكنًا
  • صار بإمكان العملاء إنشاء شرائحهم الخاصة وتقسيم البيانات بحرية
  • لم تعد هناك اختناقات هندسية أمام المتطلبات التحليلية الجديدة

​
مقاطع فيديو

تُظهر هذه القصص كيف يمكن أن يؤدي التشكيك في المسلّمات التقليدية حول قواعد البيانات إلى حلول رائدة تعيد تعريف ما هو ممكن باستخدام قواعد البيانات التحليلية.
آخر تعديل في ٣ يوليو ٢٠٢٦