🚀 جرب Zilliz Cloud، الـ Milvus المدارة بالكامل، مجاناً — تجربة أداء أسرع بـ 10 أضعاف! جرب الآن>>

milvus-logo
LFAI
  • Home
  • Blog
  • كيف تتم إدارة البيانات في ميلفوس

كيف تتم إدارة البيانات في ميلفوس

  • Engineering
November 08, 2019
Yihua Mo

المؤلف: ييهوا مو

التاريخ: 2019-11-08-2019

كيف تتم إدارة البيانات في ميلفوس

أولاً، بعض المفاهيم الأساسية لميلفوس:

  • الجدول: الجدول عبارة عن مجموعة بيانات من المتجهات، بحيث يكون لكل متجه معرف فريد. يمثل كل متجه ومعرفه صفًا من الجدول. يجب أن يكون لجميع المتجهات في الجدول نفس الأبعاد. فيما يلي مثال لجدول يحتوي على متجهات ذات 10 أبعاد:

table الجدول

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

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

لنفترض أن لدينا 100 مليون متجه مكون من 512 متجهًا من 512 بُعدًا، ونحتاج إلى إدراجها وإدارتها في Milvus للبحث الفعال عن المتجهات.

(1) إدراج المتجهات

دعونا نلقي نظرة على كيفية إدراج المتجهات في ملفوس.

نظرًا لأن كل متجه يستهلك مساحة 2 كيلوبايت، فإن الحد الأدنى لمساحة التخزين لـ 100 مليون متجه هو حوالي 200 جيجابايت، مما يجعل إدراج كل هذه المتجهات لمرة واحدة غير واقعي. يجب أن تكون هناك ملفات بيانات متعددة بدلاً من ملف واحد. أداء الإدراج هو أحد مؤشرات الأداء الرئيسية. يدعم Milvus الإدراج لمرة واحدة لمئات أو حتى عشرات الآلاف من المتجهات. على سبيل المثال، يستغرق الإدراج لمرة واحدة لـ 30 ألف متجه من 512 متجهًا لمرة واحدة بشكل عام ثانية واحدة فقط.

insert الإدراج

لا يتم تحميل كل إدراج متجه في القرص. حيث يحتفظ ميلفوس بمخزن مؤقت قابل للتغيير في ذاكرة وحدة المعالجة المركزية لكل جدول يتم إنشاؤه، حيث يمكن كتابة البيانات المدرجة بسرعة. وعندما تصل البيانات الموجودة في المخزن المؤقت القابل للتغيير إلى حجم معين، سيتم تصنيف هذه المساحة على أنها غير قابلة للتغيير. وفي الوقت نفسه، سيتم حجز مخزن مؤقت جديد قابل للتغيير. تتم كتابة البيانات في المخزن المؤقت غير القابل للتغيير على القرص بانتظام ويتم تحرير ذاكرة وحدة المعالجة المركزية المقابلة. تتشابه آلية الكتابة المنتظمة على القرص مع تلك المستخدمة في Elasticsearch، والتي تكتب البيانات المخزنة على القرص كل ثانية واحدة. بالإضافة إلى ذلك، يمكن للمستخدمين المطلعين على LevelDB/RocksDB رؤية بعض التشابه مع MemTable هنا.

أهداف آلية إدراج البيانات هي:

  • يجب أن يكون إدخال البيانات فعالاً.
  • يمكن استخدام البيانات المدرجة على الفور.
  • يجب ألا تكون ملفات البيانات مجزأة للغاية.

(2) ملف البيانات الخام

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

ملفات البيانات المجزأة ليست ملائمة للإدارة ولا يسهل الوصول إليها للبحث عن المتجهات. يقوم Milvus بدمج ملفات البيانات الصغيرة هذه باستمرار حتى يصل حجم الملف المدمج إلى حجم معين، على سبيل المثال، 1 جيجابايت. يمكن تكوين هذا الحجم المحدد في معلمة واجهة برمجة التطبيقات index_file_size في إنشاء الجدول. ولذلك، سيتم توزيع 100 مليون ناقل من 512 متجه من 512 بُعدًا وحفظها في حوالي 200 ملف بيانات.

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

هكذا تبدو الملفات التي تم الاستعلام عنها قبل الدمج:

rawdata1 rawdata1

الملفات التي تم الاستعلام عنها بعد الدمج:

rawdata2 rawdata2

(3) ملف الفهرس

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

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

indexfile ملف الفهرس

بشكل عام، يحتوي ملف الفهرس على معلومات أكثر من ملف البيانات الخام، ومع ذلك فإن أحجام الملفات أصغر بكثير حيث يتم تبسيط المتجهات وتكميمها أثناء عملية بناء الفهرس (لأنواع معينة من الفهارس).

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

يقوم برنامج Milvus تلقائياً ببناء فهرس للملفات التي يصل حجمها إلى 1 جيجابايت:

buildindex بناء الفهرس

اكتمل بناء الفهرس:

indexcomplete اكتمل بناء الفهرس

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

forcebuild فرض إنشاء الفهرس

بعد فرض بناء الفهرس للملف، يتم تحسين أداء البحث بشكل كبير.

indexfinal الفهرس النهائي

(4) البيانات الوصفية

كما ذكرنا سابقًا، يتم حفظ 100 مليون متجه مكون من 512 متجهًا في 200 ملف على القرص. عندما يتم بناء الفهرس لهذه المتجهات، سيكون هناك 200 ملف فهرس إضافي، مما يجعل العدد الإجمالي للملفات يصل إلى 400 ملف (بما في ذلك ملفات القرص وملفات الفهرس). هناك حاجة إلى آلية فعالة لإدارة البيانات الوصفية (حالات الملفات والمعلومات الأخرى) لهذه الملفات من أجل التحقق من حالات الملفات أو إزالتها أو إنشاء ملفات.

يعد استخدام قواعد بيانات OLTP لإدارة هذه المعلومات خيارًا جيدًا. يستخدم برنامج Milvus المستقل SQLite لإدارة البيانات الوصفية بينما في النشر الموزع، يستخدم برنامج Milvus MySQL. عند بدء تشغيل خادم Milvus، يتم إنشاء جدولين (وهما "الجداول" و "TableFiles") في SQLite/ MySQL على التوالي. تسجل "الجداول" معلومات الجدول وتسجل "ملفات الجدول" معلومات ملفات البيانات وملفات الفهرس.

كما هو موضح في المخطط الانسيابي أدناه، تحتوي "الجداول" على معلومات البيانات الوصفية مثل اسم الجدول (table_id)، والبعد المتجه (dimension)، وتاريخ إنشاء الجدول (create_on)، وحالة الجدول (state)، ونوع الفهرس (engine_type)، وعدد مجموعات المتجهات (nlist) وطريقة حساب المسافة (metric_type).

ويحتوي "TableFiles" على اسم الجدول الذي ينتمي إليه الملف (table_id)، ونوع فهرس الملف (نوع_المحرك)، واسم الملف (file_id)، ونوع الملف (file_type)، وحجم الملف (file_size)، وعدد الصفوف (row_count)، وتاريخ إنشاء الملف (create_on).

metadata البيانات الوصفية

باستخدام بيانات التعريف هذه، يمكن تنفيذ عمليات مختلفة. فيما يلي بعض الأمثلة:

  • لإنشاء جدول، يحتاج مدير التعريف فقط إلى تنفيذ عبارة SQL: INSERT INTO TABLES VALUES(1, 'table_2, 512, xxx, xxx, ...).
  • لتنفيذ بحث متجه على الجدول_2، سيقوم مدير Meta Manager بتنفيذ استعلام في SQLite/MySQL، وهو عبارة SQL فعلية: SELECT * FROM TableFiles WHERE table_id='table_2' لاسترداد معلومات ملف الجدول_2. ثم سيتم تحميل هذه الملفات في الذاكرة بواسطة برنامج جدولة الاستعلام لحساب البحث.
  • لا يُسمح بحذف جدول على الفور لأنه قد يكون هناك استعلامات يتم تنفيذها عليه. هذا هو السبب في وجود الحذف الناعم والحذف الصلب لجدول ما. عند حذف جدول، سيتم تصنيفه على أنه "حذف ناعم"، ولن يُسمح بإجراء أي استعلامات أو تغييرات أخرى عليه. ومع ذلك، تظل الاستعلامات التي كانت تعمل قبل الحذف مستمرة. فقط عند اكتمال جميع استعلامات ما قبل الحذف هذه، سيتم حذف الجدول مع بياناته الوصفية والملفات ذات الصلة بشكل نهائي.

(5) جدولة الاستعلام

يوضح الرسم البياني أدناه عملية البحث عن المتجهات في كل من وحدة المعالجة المركزية ووحدة معالجة الرسومات من خلال الاستعلام عن الملفات (ملفات البيانات الأولية وملفات الفهرس) التي يتم نسخها وحفظها في القرص وذاكرة وحدة المعالجة المركزية وذاكرة وحدة معالجة الرسومات لأعلىk أكثر المتجهات تشابهًا.

topkresult topkresult

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

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

لتقصير وقت البحث في الاستعلام الأول، يوفر Milvus تكوين جدول التحميل المسبق (preload_table) الذي يتيح التحميل المسبق التلقائي للجداول في ذاكرة وحدة المعالجة المركزية عند بدء تشغيل الخادم. بالنسبة لجدول يحتوي على 100 مليون متجه من 512 متجهًا من 512 بُعدًا، أي 200 جيجابايت، تكون سرعة البحث هي الأسرع إذا كانت ذاكرة وحدة المعالجة المركزية كافية لتخزين كل هذه البيانات. ومع ذلك، إذا كان الجدول يحتوي على ناقلات بمليار ناقلة، فلا مفر في بعض الأحيان من تحرير ذاكرة وحدة المعالجة المركزية/وحدة المعالجة المركزية لإضافة بيانات جديدة لم يتم الاستعلام عنها. حاليًا، نستخدم LRU (آخر ما تم استخدامه مؤخرًا) كاستراتيجية لاستبدال البيانات.

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

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

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

queryschedule جدولة الاستعلام

(6) مخفض النتائج

هناك معلمتان رئيسيتان تتعلقان بالبحث عن المتجهات: إحداهما هي "n" التي تعني n عدد المتجهات المستهدفة؛ والأخرى هي "k" التي تعني أعلى k من المتجهات الأكثر تشابهًا. نتائج البحث هي في الواقع عبارة عن مجموعات n من أزواج KVP (أزواج قيمة المفتاح)، كل منها يحتوي على k من أزواج قيمة المفتاح. نظرًا لأنه يجب تنفيذ الاستعلامات مقابل كل ملف على حدة، بغض النظر عن كونه ملف بيانات خام أو ملف فهرس، سيتم استرداد مجموعات n من مجموعات النتائج الأعلى k لكل ملف. يتم دمج كل مجموعات النتائج هذه للحصول على مجموعات النتائج الأعلى-ك من الجدول.

يوضح المثال أدناه كيفية دمج مجموعات النتائج وتقليلها للبحث المتجه مقابل جدول يحتوي على 4 ملفات فهرس (n=2، k=3). لاحظ أن كل مجموعة نتائج تحتوي على عمودين. يمثل العمود الأيسر معرف المتجه ويمثل العمود الأيمن المسافة الإقليدية.

result النتيجة

(7) التحسين المستقبلي

فيما يلي بعض الأفكار حول التحسينات الممكنة لإدارة البيانات.

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

الملخص

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

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started

Like the article? Spread the word

استمر في القراءة