التوسع والحدود

storh تخزين يعطي الأولوية للملفات، وليس محرك استعلامات علائقيًا. وهذه حدوده العملية، مع أرقام مرجعية من الاختبارات المعيارية (50k سجل، Apple M1 Pro):

• الوصول المباشر غير محدود عمليًا ما دام نظام الملفات قادرًا على التعامل مع عدد الملفات وتستخدم المجموعة تجزئة ذيل UUID. تستغرق القراءة المباشرة بضع ميكروثوانٍ؛ أما الكتابة الدائمة لسجل واحد فتتقيد بعمليات fsync، بمعدل بضعة آلاف في الثانية.
• تعمل عمليات مسح السجل المجزأ والقراءة بالمؤشر وقراءة النطاق الزمني بسلاسة حتى نحو 1M سجل، عند تهيئة أحجام الأجزاء بما يناسب عبء العمل. تنفذ عمليات الإلحاق المجمعة عشرات الآلاف من السجلات في الثانية؛ وتعيد استعادة النهاية المبتورة تشغيل مئات الآلاف من السجلات في الثانية عند إعادة الفتح.
• تُلحق عمليات الصف أحداثًا مضغوطة بسجل دائم واحد، لذا تتجنب إضافة المهام واستلامها وإكمالها وإعادتها إلى الصف وحذفها دوّامة إنشاء ملف لكل مهمة. وتوزع عمليتا الاستلام والإكمال بالجملة كلفة الأقفال وfsync على دفعات كاملة.
• يتباطأ مسح الحقول ملفًا بملف في DocStore بعد نحو 10k سجل، لأن كل مسح مطابق يجب أن يمر على الملفات واحدًا تلو الآخر. عرّف فهارس للحقول التي تصفيها؛ إذ تستجيب استعلامات المساواة المفهرسة في نحو ميلي ثانية بغض النظر عن حجم المجموعة.
• لا يناسب storh الاستعلامات العلائقية غير المحددة مسبقًا أو عمليات الربط أو التصفية الكثيفة بالفهرسة الثانوية أو المسح التحليلي لحقول كثيرة. انقل المجموعات إلى نسخة SQL المتطابقة عند الحاجة إلى أنماط القراءة هذه؛ واحتفظ بالنظام المرجعي في قاعدة بيانات حقيقية عند الحاجة إلى معاملات تشمل عدة سجلات.

استخدم DocStore عندما تسود القراءات المباشرة، وSegmentedLog عندما يسود الإلحاق والقراءة المرتبة، وQueue لتوزيع العمل الدائم البسيط. راجع اختيار محرك لمقارنة الجانبين.