CobbleDB: إعادة بناء تخزين بحث الذكاء الاصطناعي لتقليل زمن الانتقال والتكلفة

يفرض البحث الأصلي للذكاء الاصطناعي متطلبات مختلفة حول كيفية معالجة محتوى الويب وتخزينه وتقديمه. لتلبية هذه المتطلبات على نطاق واسع، قمنا بإعادة بناء المكدس بأكمله من الصفر لتحسين الأداء وتقليل التكلفة.

لقد بنينا الخاصة بنا بنية الزحف، والفهرسة، والترتيب، ونماذج التضمينات، و محركات الاستدلال لتشغيل معالجة فعالة وخدمة سريعة. نحن نوسع الآن هذا النهج ليشمل التخزين، النسيج الرابط الذي تكتب إليه المعالجة وتقرأ منه الخدمة.

وفرت قواعد البيانات المدارة مثل DynamoDB تخزينًا موثوقًا، لكن كان لدينا تحكم محدود في كيفية تخزين البيانات وتقديم القراءات، ونمت الأسعار القائمة على الاستخدام مع حجم الفهرس وحجم الاستعلام الخاص بنا. بشكل منفصل، قام خط المعالجة السابق الخاص بنا بربط معالجة المستندات مباشرة بقاعدة بيانات الخدمة، مما جعل من الصعب إدارة التحديثات بشكل مستقل عن القراءات الحية.

بمساعدة مجموعة جديدة من وكلاء البرمجة الداخلية، أعدنا بناء هذه الطبقة حول CobbleDB، وهو مخزن ساخن للمفتاح والقيمة، مدعومًا بـ Pillar لحالة المستند الدائمة والنشر، و Lorry للتحديثات المجمعة. يفصل إعادة التصميم معالجة المستندات عن استيعاب المخزن الساخن ويتيح لنا ضبط الخدمة لتناسب عبء العمل لدينا. تُظهر قياسات الإنتاج قبل وبعد زمن انتقال قراءة الدفعات أقل بنحو 5 أضعاف، ويقدر نموذج التكلفة الداخلي لدينا توفيرًا بنسبة 20% على الأقل مقارنة بـ DynamoDB.

البنية التحتية للتخزين للبحث الأصلي بالذكاء الاصطناعي

تم تصميم مجمع بحث كلاسيكي لقارئ بشري، وليس لنموذج لغوي. يغير هذا الاختلاف الدقة التي يحتاج النظام عندها إلى إعداد وتخزين وخدمة محتوى الويب.

لتحويل HTML الخام إلى محتوى جاهز للنموذج، يقوم خط معالجة المعالجة الخاص بنا بتنظيف كل صفحة، وتقسيمها إلى مقاطع متماسكة دلاليًا، وحساب تضميناتها، وتخزين المقاطع والتضمينات معًا في قاعدة البيانات. في وقت الاستعلام، يختار خط معالجة الخدمة النص الأكثر صلة بالاستعلام ويمرره إلى النموذج.

سير عمل متميزان

يجب أن تدعم طبقة التخزين بالتالي سير العمل باحتياجات مختلفة: استيعاب التحديثات من خط معالجة المعالجة وخدمة القراءات ذات زمن الانتقال المنخفض.

على جانب الكتابة، تصل صفحات جديدة باستمرار، وتتغير الصفحات الحالية، ويمكن أن تتطلب التغييرات في طرق التقطيع أو نماذج التضمينات إعادة معالجة أجزاء كبيرة من المتن. يجب أن تدمج طبقة التخزين هذه التحديثات في حالة المستند الدائمة، وتتبع الإصدارات الحالية، وتنشر التمثيلات الصحيحة للأنظمة اللاحقة، وتدعم عمليات ملء الفراغات الكبيرة دون تكرار مسار التدفق الكامل من الزحف الخام.

على النقيض من ذلك، تطلب قراءات وقت الاستعلام دفعات من مفاتيح الصفحات وتسترجع نص المقطع والتضمينات المقابلة للترتيب واختيار المقاطع. توجد هذه القراءات في المسار المؤدي إلى الإجابة النهائية، لذا يجب إكمالها بسرعة.

تتطلب هذه الأحمال للعمل تصميمات مختلفة. تستفيد المعالجة من طوابير الانتظار الدائمة والقدرة على تسليم التحديثات بكفاءة، وإعادة محاولة حالات الفشل، وتحديث السجلات الموجودة على نطاق واسع. تستفيد الخدمة من السجلات المحسوبة مسبقًا، والتخزين المؤقت الدافئ، والقراءات المجمعة السريعة مع الحد الأدنى من العمل في وقت الاستعلام. يمكن أن يتسبب الاقتران الوثيق بين الاثنين في تنافس أعمال الاسترداد والتحديثات الكبيرة مع القراءات الحساسة لزمن الانتقال.

أين تقصر قاعدة البيانات المدارة

منحنا DynamoDB تخزينًا عالي التوفر دون عبء تشغيل قاعدة بيانات موزعة. احتفظ جدول مخصص للصفحات المُعدة مسبقًا بالمقاطع والتضمينات لقراءات وقت الاستعلام، بينما تم تخزين محتوى الصفحة الكامل والبيانات التعريفية بشكل منفصل. ومع ذلك، مع نمو عبء العمل لدينا, أصبح هناك ثلاثة قيود مهمة.

ثانيًا، يفرض التسعير القائم على الاستخدام رسومًا على كل بايت يتم قراءته أو كتابته. يحتوي طلب واجهة برمجة تطبيقات البحث الواحد على 100-120 مفتاحًا تتوافق مع الصفحات التي نحتاج إلى جلبها. تقسم عملية استرجاع البيانات الطلب إلى دفعات أصغر من 10-20 مفتاح صفحة مع متوسط حجم عنصر يبلغ حوالي 50 كيلوبايت. استهلكت قراءة تلك السجلات بشكل متكرر سعة كبيرة، بينما ولدت عمليات الزحف المستمرة والتغييرات في نماذج التقطيع أو التضمينات المزيد من الكتابات. اعتمدت الاقتصاديات أيضًا على حجم وتكرار السجلات، وليس فقط عدد استدعاءات واجهة برمجة التطبيقات.

أولاً، تفتقر الخدمة المدارة إلى المرونة التي نحتاجها لتحسين الأداء. كانت العملية التي نحتاجها ضيقة: بالنظر إلى دفعة من معرفات الصفحات، قم بإرجاع محتوياتها المُعدة مسبقًا بسرعة. أردنا التحكم في الجهاز الذي يحمل القسم، وكمية الذاكرة المخصصة لذاكرته المؤقتة، والنسخة المتطابقة التي تتعامل مع الطلب. تهم هذه الضوابط لأن القراءة غير المؤقتة، أو القفزة عبر المناطق، أو النسخة المطابقة البطيئة يمكن أن تؤخر الدفعة بأكملها. تدير DynamoDB تخزينها وسلوك النسخ المتطابقة خلف واجهة برمجة التطبيقات. يمكننا تكوين الخدمة، لكن لم نتمكن من ضبط وضعها الداخلي، أو ذاكرات التخزين المؤقت لمحرك التخزين، أو سياسة اختيار النسخ المتطابقة حول عبء العمل لدينا.

ثالثًا، تم ربط المعالجة مباشرة بكتابات المخزن الساخن. كتب خط معالجة المعالجة السابق الخاص بنا كل صفحة مُعدة مسبقًا مباشرة إلى DynamoDB. وبالتالي، أصبحت مهمة إعادة المعالجة الكبيرة موجة من تحديثات المخزن الساخن الفردية، وكان على المعالجة استيعاب حدود الإنتاجية وسلوك إعادة المحاولة للمخزن الساخن. لم نتمكن من تشغيل MapReduce عبر قاعدة البيانات بأكملها في غضون 1-2 أيام لتجربة طريقة تقطيع جديدة، أو تغيير نموذج التضمينات الخاص بنا، أو إضافة حقل جديد. لم يكن هناك تدفق مستقل لتحديثات الصفحات المحفوظة التي يمكن لخدمة منفصلة تجميعها وتسليمها إلى المخزن الساخن بالسرعة التي تناسبها.

تطلب معالجة هذه القيود أكثر من مجرد استبدال قاعدة بيانات. احتجنا إلى فصل حالة المستند الدائمة وتسليم التحديثات عن تخزين وقت الاستعلام، ثم تحسين المخزن الساخن خصيصًا للقراءات المجمعة السريعة.

فصل حالة المستند، وتسليم التحديثات، والخدمة

تعين البنية الجديدة كل مسؤولية لمكون مختلف. تحافظ Pillar على حالة مستند دائمة وتقرر ما يجب نشره. تقوم Lorry بتحويل تلك الصادرات إلى دفعات مقسمة. تقوم CobbleDB باستيعاب الدفعات وخدمة السجلات المُعدة مسبقًا حسب مفتاح الصفحة.

تكبير

CobbleDB: مسار القراءة القابل للتعديل

CobbleDB هو المخزن الساخن الخاص بنا والمحسن لخدمة السجلات المُعدة مسبقًا في وقت الاستعلام. وهو مخزن مفتاح-قيمة موزَّع: المفاتيح هي معرفات الصفحات (عناوين URL المُجزأة)، والقيم هي التمثيل المعالج للصفحة (مقاطعها المُقطعة مسبقًا وتضمينات المتجهات لكل قطعة).

التغيير الهام هو تحكمنا في تكوين التخزين.

يتم تقسيم البيانات وتوزيعها عبر عقد البيانات. يضمن هذا التنسيق الموزع أن قاعدة البيانات يمكنها التوسع أفقيًا لاستيعاب مجموعة هائلة من الصفحات المعالجة. يحتوي كل قسم على ثلاث نُسخ مطابقة على ثلاث عقد مختلفة؛ وإذا أصبحت نسخة واحدة غير متاحة، يمكن للنسخ الأخرى الاستمرار في خدمة القراءات.

يتم تعيين مجموعة فرعية من الأقسام لكل عقدة بيانات. تخزن العقدة بياناتها باستخدام RocksDB، وهو محرك تخزين مفتاح-قيمة مدمج ومفتوح المصدر مناسب تمامًا لأحمال العمل كثيفة القراءة المدعومة بالاستيعاب على دفعات.

يمكن تقديم البيانات المؤقتة من الذاكرة، بينما تستخدم القراءات غير المؤقتة تخزين NVMe المحلي. يمنحنا هذا طريقة مباشرة لضبط التوازن بين الذاكرة والقرص لعبء العمل المرصود، بدلاً من قبول سياسة التخزين المؤقت الداخلية للخدمة المدارة.

يقوم موجه استعلام بلا حالة بتجزئة المفاتيح إلى أقسام وتوجيه الطلبات إلى العقد بالتوازي. تتضمن البنية أيضًا خدمة بيانات تعريف مدعومة بـ PostgreSQL وتخزين كائنات دائم.

يدعم هذا التصميم أنماط القراءة التي يتطلبها عبء العمل لدينا. بعد أن يمر الاستعلام عبر الاسترجاع والترتيب للحصول على مجموعة مرشحة من الصفحات ذات الصلة، يتم الاستعلام عن المخزن الساخن بشكل مجمع محتوى تلك الصفحات. تصل طلبات القراءة هذه إلى الموجه ويتم توجيهها إلى عقدة بيانات مقابلة. يعطي الموجه الأولوية لإرسال الطلبات إلى عقدة في نفس منطقة التوفر لتقليل زمن الانتقال عبر المناطق، إن أمكن. يمكن لكل عقدة بيانات جلب محتويات الصفحة باستخدام MultiGet، وهي واجهة برمجة تطبيقات للقراءة على دفعات في RocksDB مصممة لجلب مفاتيح متعددة في وقت واحد بزمن انتقال منخفض. إذا كانت الاستجابة بطيئة من العقدة، يمكن للنظام أيضًا الاستعلام عن نسخة قسم أخرى على عقدة مختلفة، مما يحسن زمن انتقال الذيل.

يمكننا أيضًا تجنب تنفيذ الميزات الشائعة التي لا يتطلبها سير العمل لدينا. على سبيل المثال، توفر معظم قواعد البيانات ضمانات الاتساق ودعم المعاملات، لكن المخزن الساخن لدينا لا يتطلب معاملات أو نُسخًا متطابقة متزامنة. من المقبول أن يكون هناك فارق زمني قصير بين كتابة المستند وتوفره للقراءات، ومن المقبول أيضًا أن تقوم نسخة مطابقة واحدة باستيعاب البيانات بشكل أسرع من أخرى. إن حذف الميزات التي لا نحتاجها يقلل من النفقات العامة وتكلفة نظامنا.

تكبير

Pillar و Lorry: مسار الكتابة الدائم

تتتبع طبقة تخزين منفصلة كل ما نقوم الزحف إليه ومعالجته، حيث تدمج التحديثات في حالة المستندات ذات الإصدارات وتنشر التمثيلات الضرورية في CobbleDB وفهرس البحث. لقد أنشأنا Pillar، وهي طبقة حالة المستندات والنشر الخاصة بنا، لهذا الغرض.

Pillar مدعومة بواسطة YTsaurus. وهي تخزن مكونات الصفحة (مثل البيانات التعريفية، والقطع، والتضمينات) في عائلات جداول YTsaurus منفصلة. كما أنها تتتبع إصدارات القطع والتضمينات، مما يسمح لتمثيلات متعددة بالتعايش دون الكتابة فوق بعضها البعض بحيث يمكن للنماذج الأساسية أن تتغير. نظرًا لأن Pillar و YTsaurus تستخدمان تخزين HDD رخيصًا، يمكننا تخزين مستندات أكثر بكثير مما خزناه سابقًا في DynamoDB.

تتعقب Pillar المجموعات الفرعية، أو المجموعات المعرفة بالسياسة من الصفحات مثل الصفحات الحديثة أو صفحات القيمة العالية. يحدد عضوية المجموعات الفرعية التحديثات التي يجب تمريرها إلى المكونات اللاحقة مثل CobbleDB. تستخدم CobbleDB تخزين NVMe أكثر تكلفة، لذلك نحن نصدّر فقط المستندات التي نريد بالفعل استخدامها في نتائج البحث. عندما يتم تحديث محتويات الصفحة، أو إذا تمت إضافة أو إزالة من مجموعة فرعية، تكون Pillar مسؤولة عن وضع عمل التصدير المقابل في قائمة الانتظار.

تغطي معاملات YTsaurus الذرية الحالة، ونوايا التصدير، والإدخال المستهلك لضمان الدقة. لكي تكتمل المعاملة بنجاح، يجب على النظام تحديث الحالة الدائمة، ووضع علامة على الإدخال بأنه تمت المحاسبة عليه، وتنسيق جميع الصادرات المطلوبة؛ وإذا تم إجهاض المعاملة، فلا يتم إجراء أي تغيير في أي طبقة.

تتوقع CobbleDB تجميع التحديثات وفقًا للقسم. يتم تحويل صادرات Pillar إلى هذا التنسيق بواسطة خدمة بلا حالة نسميها Lorry. وتتمثل مهمتها الوحيدة في قراءة سجلات التصدير من طابور دائم محاذاة للقسم، وتجميعها في ملفات دفعية لكل قسم، وتسليمها إلى CobbleDB.

بين Lorry و Cobble، يقوم بروتوكول إضافي بفصل مستوى البيانات (S3) عن مستوى التحكم. تكتب Lorry الدفعة إلى S3 تحت معرف فريد وتسجل الدفعة داخل Cobble. تستعلم نُسخ أقسام Cobble بشكل مستقل عن الدفعة أو واجهة برمجة تطبيقات مستوى التحكم لدفعة S3 التالية للاستيعاب وتطبيق تحديثات الدفعات بشكل غير متزامن بالترتيب الزمني. هذا يعني أن العقدة البطيئة أو التي تتعافى يمكنها اللحاق بالركب بالسرعة التي تناسبها، بدلاً من إبطاء بقية النظام.

تكبير

يفصل المسار الجديد معاملة المعالجة الفورية عن استيعاب المخزن الساخن ويوفر مسارًا قابلاً لإعادة التشغيل للتحديثات الإضافية وإعادة الإنشاء المجمعة. يضمن تقسيم العمل هذا ألا تتداخل التحديثات على حالة المستند الدائمة مع زمن انتقال مسار القراءة.

التحقق

أسرع بـ 5 أضعاف

بعد ترحيل المخزن الساخن، انخفض متوسط زمن انتقال القراءة على دفعة من 31.4 مللي ثانية إلى 5.60 مللي ثانية. وانخفض المؤشر p90 من 56.7 مللي ثانية إلى 9.77 مللي ثانية، وانخفض المؤشر p99 من 123 مللي ثانية إلى 24.2 مللي ثانية. تتراوح النسب من 5.08× إلى 5.80×، مع وجود تحسينات في كل من الطلبات النموذجية والذيل.

تكبير

تستمد هذه الأرقام من القراءات المجمعة، حيث يطلب كل استعلام تقريبًا 10-15 مفتاحًا. يبلغ متوسط حجم عنصر حمولة البيانات 50 كيلوبايت. تم الاستعلام عن كلا النظامين بحوالي 200 ألف طلب في الثانية (rps)، على الرغم من أننا قمنا أيضًا بتشغيل اختبارات الحمل تصل إلى 500 ألف طلب في الثانية دون أي تدهور.

لعزل مساهمة CobbleDB، تم الحفاظ على ثبات جميع الجوانب الأخرى للإعداد. ومع ذلك، يظل هذا مقارنة رصدية قبل وبعد؛ فقد خدمت الأنظمة حركة مرور الإنتاج الحية في أوقات مختلفة بدلاً من نفس الطلبات في ظل ظروف خاضعة للرقابة. لذلك قمنا أيضًا بقياس أداء كلا النظامين على معيار اصطناعي. تقريبًا للطلبات التي لوحظت في الإنتاج، قمنا بالاستعلام عن كليهما بدفعات من 10-15 مفتاحًا وقيم تتراوح من 100 بايت إلى 100 كيلوبايت.

تكبير

تواجه DynamoDB صعوبات في هذا السياق لأن مسار القراءة المدار الخاص بها لا يمكن تعديله للقراءات المجمعة بهذا الحجم. في المقطور، تم تحسين CobbleDB خصيصًا لهذا الإعداد، حيث ندير عمليات الوضع والتخزين المؤقت وعناصر التحكم في النسخ المتطابقة. فهو يقوم بتجميع المفاتيح حسب القسم، وينفذ القراءات بالتوازي ضد نُسخ الأقسام المتطابقة، ويمكنه التحوط من القراءات البطيئة ضد نُسخ أخرى. توضح نتائجنا أن خيارات التصميم هذه تترجم إلى قراءات أسرع في بيئة إنتاج.

أرخص بنسبة 20%

CobbleDB هي أيضًا أرخص بكثير من DynamoDB. بالإضافة إلى التخزين، تفرض DynamoDB أيضًا رسومًا على كل بايت يتم قراءته أو كتابته. على نطاق المتن وحركة مرور الخدمة الخاصة بنا، تصبح هذه الرسوم القائمة على الاستخدام جزءًا كبيرًا من التكلفة الإجمالية. تستهلك التحديثات المستمرة سعة الكتابة، بينما تستهلك كل دفعة من الصفحات المُعدة مسبقًا التي يتم جلبها للاستعلام سعة القراءة.

لقد حسبنا توفير التكاليف بناءً على التقديرات الداخلية لحجم التخزين، ووحدات سعة الكتابة، ووحدات سعة القراءة. في كل مستوى التزام، تعتبر CobbleDB أرخص بنسبة 20% على الأقل من DynamoDB. من المرجح أن تكون التوفيرات الحقيقية أعلى من ذلك، لأن هذه النتائج لا تأخذ في الاعتبار توفير النسخ الاحتياطي المحتمل من الضغط.

كيف ساعدتنا مجموعة من عملاء الذكاء الاصطناعي في بنائه

لم يكن بناء CobbleDB والبنية التحتية المحيطة بها أمرًا بسيطًا بأي حال من الأحوال. قاعدة البيانات الأساسية لـ CobbleDB وحدها تضم حوالي 40,000 سطر من Rust، وتطلب الترحيل أيضًا عملًا مكثفًا للتحقق من الدقة وسلوك الفشل على نطاق الإنتاج، ودمج CobbleDB مع كل من مسارات المعالجة والخدمة، والانتقال بأمان بحركة المرور الحية.

عجّلنا هذا الجهد باستخدام نظام داخلي يشغّل سربًا من عوامل البرمجة. صُمم النظام ليكون شديد الديمومة؛ إذ يحتفظ بأهداف المشروع والمخاطر النشطة وتاريخ المستودع والقرارات السابقة عبر الجلسات.

لقد خصصنا مجموعة من هذه العوامل الاستباقية، التي تعمل على مدار الساعة، لمشروع CobbleDB. كانت مهمتهم الأولى بناء نموذج دقيق للعمل الجاري بالفعل. فحصوا قناة المشروع والسلاسل النشطة، وربطوا البنود العالقة بـ pull requests الخاصة بها ومالكيها، وأنتجوا عرضًا محدثًا لحالة النظام والخطوات التالية. ومن هناك، عملوا عبر عدة أجزاء من حلقة الهندسة:

• تمت مراجعة الكود وتغييرات البنية التحتية.
• أبرزت العوائق التي كان من السهل تفويتها، بما في ذلك افتراضات الاستعادة غير الآمنة، والمراجع القديمة للبناء، والتكوينات التي ستفشل وقت التشغيل.
• إعداد إصلاحات مركزة، واختبارات، وتغييرات المراقبة، والوثائق التشغيلية.
• تتبع بوابات CI والمراجعة والبنية التحتية مع الحفاظ على تصرفات الإنتاج مملوكة للبشر صراحةً.
• عمليات طرح مراقبة وتمارين النسخ الاحتياطي أو الاستعادة، ثم مقارنة حالة النظام المرصودة مع معايير نجاح عملية الطرح.
• الحفاظ على تقارير المشروع حتى يتمكن المهندسون من رؤية ما تم شحنه، وما ظل محظورًا، وأين لا يزال الحكم البشري مطلوبًا.

لا يزال المهندسون يحددون البنية المعمارية، ويراجعون التغييرات الجوهرية، ويجيزون عمليات الإنتاج. وتولّت العوامل قدرًا كبيرًا من الفحص المستمر والمتابعة بين تلك القرارات. وقد أتاح ذلك لفريق صغير أن يدفع المشروع بكفاءة — فقد بُنيت البنية التحتية الأساسية لـ CobbleDB بواسطة مهندسين بشريين اثنين ومئات من عوامل الذكاء الاصطناعي خلال شهرين.

خاتمة

CobbleDB ليست قاعدة بيانات للأغراض العامة؛ بل تم تصميمها خصيصًا لعبء العمل المحدد لدينا المتمثل في القراءات المجمعة المتكررة لسجلات الصفحات المُعدة مسبقًا، والتي تغذيها خطوط معالجة غير متزامنة. من خلال فصل الحالة الدائمة، وتسليم التحديثات، وخدمة وقت الاستعلام، يمكننا تحسين كل مسؤولية بشكل مستقل دون إجبار واجهة قاعدة بيانات واحدة على استيعاب كل منها أو دفع أعمال الصيانة إلى مسار الاستعلام المباشر. أدى الترحيل إلى CobbleDB إلى تحسين زمن الانتقال المتوسط والذيل بشكل كبير مع تقليل تكاليف البنية التحتية.

بينما نواصل تطوير البنية التحتية الأصلية للذكاء الاصطناعي داخل الشركة، يمكننا تحسين الأداء والتكلفة بطرق لا تكون ممكنة عندما نكون مرتبطين بتنفيذ الأطراف الثالثة ونماذج التسعير الخاصة بهم. تدفع وكلاء الذكاء الاصطناعي الأقوياء الحسابات أكثر فأكثر لصالح البناء بدلاً من الشراء.

نخطط لإتاحة CobbleDB كمصدر مفتوح قريبًا، حتى تتمكن الفرق الأخرى التي تبني أنظمة بحث أصلية للذكاء الاصطناعي من الاستفادة من طبقة التخزين نفسها التي تجعل البحث أسرع وأقل تكلفة داخل منتجاتنا.

اقتباس

@online{perplexity2026Cobbledb,
  author = {{Perplexity} and Alexandr Yarats and Marco Montagna and Aleksei Bykov and Alexey Gusev and Ali Abdullaev and Amir Mokhammed-Ali and Andrey Zosimov and Denis Kremko and Gleb Vishnevsky and Micah Zirn and Phi Hoang and Claire Beamer and Jeremy Yang and Jerry Ma and Denis Yarats},
  title = {{CobbleDB: Rebuilding AI search storage for lower latency and cost}},
  date = {2026-09-14},
  url = {https://www.perplexity.ai/hub/blog/cobbledb}
}