semadb
v2.0.2
لا توجد قاعدة بيانات / بحث هجينة متعددة المؤشرات
SEMADB عبارة عن مؤشر متعدد المؤشرات ، متعددة المستندات ، ومحرك المتجه المستند إلى المستندات / محرك البحث. تم تصميمه لتقديم واجهة برمجة تطبيقات JSON واضحة وسهلة الاستخدام. تم بناء المكونات الأصلية لـ SEMADB لمشروع إدارة المعرفة في Semafind قبل تطويره إلى مشروع مستقل. الهدف من ذلك هو توفير محرك بحث بسيط وحديث وفعال يمكن استخدامه في مجموعة متنوعة من التطبيقات.
تبحث عن حل مستضاف؟ يتوفر Semadb Cloud Beta على Rapidapi.
للبدء من المصدر ، يرجى اتباع التعليمات لتثبيت GO. هذا هو التبعية الوحيدة المطلوبة لتشغيل SEMADB. نحاول الحفاظ على SEMADB قدر الإمكان ومحدثة مع أحدث إصدارات GO.
يقرأ SEMADB جميع التكوين من ملف yaml ، وهناك بعض الأمثلة الواردة في مجلد config . يمكنك تشغيل خادم واحد باستخدام:
SEMADB_CONFIG=./config/singleServer.yaml go run ./إذا كنت تستخدم VS Code كمحررك ، فهناك بالفعل مهام ما قبل الصنع التي تفعل الشيء نفسه ولكن أيضًا قم بتشغيل مجموعة محليًا أيضًا في وضع التصحيح.
بعد أن يكون لديك خادم يعمل ، يمكنك استخدام ملف العينات لرؤية بعض طلبات المثال التي يمكن تقديمها إلى الخادم. لتحقيق أقصى استفادة منه ، قم بتثبيت امتداد عميل REST والذي سيسمح لك بتقديم الطلبات مباشرة في المحرر وإظهار النتائج.
يمكنك تشغيل أحدث إصدار من SEMADB باستخدام صورة حاوية المستودع التالية:
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 ghcr.io/semafind/semadb:main
# If using podman
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 ghcr.io/semafind/semadb:mainوالتي سوف تدير الفرع الرئيسي. هناك أيضًا إصدارات موسومة لإصدارات محددة. راجع سجل الحاويات للمستودع المستقر والإنتاج الإصدارات الجاهزة.
يمكنك إنشاء صورة الحاوية وتشغيلها محليًا باستخدام:
docker build -t semadb ./
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 semadb
# If using podman
podman build -t semadb ./
# The :Z argument relabels to access: see https://github.com/containers/podman/issues/3683
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 semadb ثبات البيانات: يقوم SEMADB بتخزين البيانات في دليل على القرص المحدد في ملف التكوين كـ rootDir . بشكل افتراضي ، يكون دليل البيانات هو ./data و semadb قابل للتنفيذ في / العطاء /data كنقطة التثبيت في الحاوية.
يرجى ملاحظة أنه عند استخدام Docker ، قد يلزم تعديل اسم المضيف وقائمة القائمة البيضاء لـ IPS وفقًا لتكوين شبكة Docker. ترك اسم المضيف كسلسلة فارغة وإعداد القائمة البيضاء على '*' يفتح SEMADB على كل اتصال كما هو الحال في تكوين singleServer.yaml .
المساهمات مرحب بها! يرجى قراءة ملف دليل المساهمة لمزيد من المعلومات. يحتوي الدليل المساهم أيضًا على معلومات حول بنية SEMADB وكيفية البدء في التطوير.
تعتمد خوارزمية البحث في المتجهات الأساسية لـ SEMADB على الأوراق البحثية الممتازة التالية:
تتبع مؤشرات أخرى مثل السلسلة أو النص نهج الفهرس المقلوب. الفهرس المقلوب هو بنية بيانات تخزن رسم الخرائط من المحتوى ، مثل الكلمات أو الأرقام ، إلى مواقعه في ملف قاعدة البيانات ، أو في مستند أو مجموعة من المستندات. الغرض من الفهرس المقلوب هو السماح برحلات النص السريع الكامل ، وبحث بادئة السلسلة ، والبحث في نطاق عدد صحيح ، إلخ.
SEMADB مع قيم التكوين الافتراضية على محطة عمل Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz مع CPU @ 3.40 جيجا هرتز مع ذاكرة الوصول العشوائي 16 جيجابايت يحقق استدعاء جيد عبر المعايير القياسية ، على غرار النتائج المبلغ عنها:
| V1 | V2 | V2-PQ | V2-BQ | |||||
|---|---|---|---|---|---|---|---|---|
| مجموعة البيانات | يتذكر | QPs | يتذكر | QPs | يتذكر | QPs | يتذكر | QPs |
| قفاز-100 angular | 0.924 | 973.6 | 0.853 | 773.9 | 0.526 | 628.6 | ||
| dbpedia-openai-100k-angular | 0.990 | 519.9 | 0.920 | 240.8 | 0.766 | 978.6 | ||
| قفاز 25-angular | 0.999 | 1130.3 | 0.992 | 914.4 | 0.989 | 805.8 | ||
| MNIST-784-Euclidean | 0.999 | 1898.6 | 0.999 | 1267.4 | 0.928 | 571.6 | 0.667 | 2369.7 |
| NYTimes-256-angular | 0.903 | 1020.6 | 0.891 | 786.7 | 0.438 | 983.6 | ||
| SIFT-128-Euclidean | 0.999 | 1537.7 | 0.991 | 1272.9 | 0.696 | 967.4 |
يتم الحصول على النتائج باستخدام علامات آن. تستخدم الاستعلامات في الثانية (QPS) كاملة في ذاكرة التخزين المؤقت للذاكرة مع مؤشر ترابط واحد مماثل للطرق الأخرى ولكن ليس مؤشرا جيدا على الأداء الكلي. سيكون خط الأنابيب الكامل أبطأ بسبب الرحلة الشاملة للطلب هو النفقات العامة لمعالجة HTTP ، وترميز ، وفك تشفير الاستعلام ، والتحليل ، والتحقق من الصحة ، وتوجيه الكتلة ، ومكالمات الإجراءات عن بُعد ، وتحميل البيانات من القرص ، إلخ. هذا يعتمد أيضًا على الأجهزة ، وخاصة SSD مقابل الأقراص الصلبة. ومع ذلك ، فإن الأداء الخام لخوارزمية البحث داخل شارد واحد ، من الناحية النظرية ، يشبه الأداء الذي تم الإبلاغ عنه في الأوراق البحثية.
الإصدار 1 (V1) هو تنفيذ بحث ناقلات النقي الأصلي لـ SEMADB. الإصدار 2 (V2) هو تنفيذ Search Multi-Index ، Hybrid ، Endword ETC الذي يحتوي على أعلى بكثير من فك تشفير البيانات ، وإرسال البيانات إلى مؤشرات واستخدام الكميات. يستخدم الإصدار 2 مع تقدير المنتج (V2-PQ) والكمية الثنائية (V2-BQ) طرق القياس الكمي المعني لتقليل استخدام الذاكرة. نتوقع أن يكون الاستدعاء أقل لأن أساليب القياس الكمي ضيلة والبحث تقريبي.
يمكن أن يكون يبدأ القرص البارد بطيئًا حقًا. في الجزء السفلي من السلسلة يجلس القرص حيث يتم تخزين جميع البيانات. هناك نوعان من التخزين المؤقت في اللعب: ذاكرة التخزين المؤقت في الذاكرة وذاكرة التخزين المؤقت لملف نظام التشغيل. إن ذاكرة التخزين المؤقت لنظام التشغيل ليست في سيطرتنا ويتم تعبئتها عند قراءة الملفات أو كتابتها. عند تقديم طلب ، يتم اجتياز الرسم البياني للفهرس ويتم تحميل النقاط من القرص إلى ذاكرة التخزين المؤقت لنظام التشغيل وفك تشفيرها في مجموعة من النقاط في الذاكرة. غالبًا ما تقوم عملية البحث بقراءات عشوائية من القرص لأنه يعبر الرسم البياني التشابه ؛ وبالتالي ، أثناء بداية البرد ، يمكن أن يستغرق الأمر وقتًا طويلاً (ثانية ، 10 ثوانٍ أو أكثر) حسب الأجهزة. يوصى بشدة بأقراص الحالة الصلبة (SSD) لهذا السبب لأنها تخدم قراءات عشوائية بشكل أفضل. بالنسبة لعمليات نشر التطبيق الفردية ، فإن هذا ليس مصدر قلق كبير لأننا نتوقع أن يتم تخزين جزء من البيانات / الفهرس إما في الذاكرة أو بواسطة نظام التشغيل أثناء التشغيل. البديل هو استخدام تخطيط تخزين موجه نحو الرسم البياني المخصص على القرص بحيث تتوافق الكتل / الصفحات بشكل أفضل مع جيران العقد في الرسم البياني للتشابه.
التحجيم الأفقي التلقائي : يمكن ضبط عدد الخوادم في SEMADB ولكنه يتزامن فقط على بدء التشغيل. سوف ينتقل التجزئة Rendezvous المستخدمة كمية 1/N من البيانات إلى الخادم الجديد أو نقل بيانات الخادم التي تمت إزالتها إلى البيانات المتبقية. نظرًا لأن هذا يحدث فقط عند بدء التشغيل ، فهو أكثر توجهاً نحو توسيع نطاق النشر لأعلى أو لأسفل مقدمًا بدلاً من الحمل المباشر. من الصعب أداء القياس التلقائي المباشر بأمان أثناء تشغيل قاعدة البيانات بسبب ظروف السباق عبر الخوادم. بعض المزالق هي: يجب التعامل مع الخادم المتخلف في تكوين البيانات إلى الخوادم القديمة ، في حين أن نقل البيانات يجب أن تتم معالجة طلبات المستخدم ، يجب أن تصل أي بيانات خاطئة في النهاية إلى الخادم الصحيح ، ويجب أن يتعافى النظام من سيناريو تقسيم الدماغ إذا تم تقسيم الشبكة. تتضمن العديد من قواعد البيانات الموزعة آلات إضافية تضيف تعقيدًا كبيرًا لمواجهة هذه المفاتيح ذات الإصدار ، وساعات المتجهات وما إلى ذلك. في الوقت الحالي ، يمكنك ضبط الخوادم وإعادة تشغيل المجموعة لإعادة توزيع البيانات.
لا توجد كتابة عالية التوفر : تم تحسين SEMADB للبحث عن أعباء العمل الثقيلة. تتطلب عمليات التجميع والنقطة جميع المعنيين (الخوادم التي تم توزيعها للبيانات) للمشاركة. في مسار البحث ، يمكن التسامح مع حالات الفشل لأنها عملية بحث عشوائية وقطرات عرضية في الأداء بسبب شظايا غير متوفرة يمكن أن تكون مقبولة. نقوم بإخراج الحفاظ على نظام صحي عبر فشل الخادم المادي إلى أداة تزامن الحاويات مثل Kubernetes. نحن نفترض أنه سيتم الحفاظ على حالة SEMADB التي تم تكوينها بنشاط ونتيجة لذلك لا تحتوي على أي اكتشاف نظير أو خوارزميات إجماع في التصميم. هذا اختيار التصميم يبسط مرة أخرى بنية SEMADB والإيدز مع التطور السريع. وشملت التصميمات الأصلية آليات الإجماع مثل الطوافة والنظام الموزع ذاتيًا تمامًا مع اكتشاف الأقران ، ولكن هذا كان يعتبر مبالغة.
هناك العديد من مشاريع البحث في ناقلات مفتوحة المصدر ومحرك البحث هناك. قد يكون من المفيد مقارنة SEMADB مع بعضهم لمعرفة ما إذا كان أحدهم يناسب حالة الاستخدام بشكل أفضل:
