قواعد البيانات في منصة IIoT: كيف تعمل Mail.ru Cloud Solutions مع بيتابايت من البيانات من أجهزة متعددة


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

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

  • حول متطلبات قاعدة البيانات الخاصة بنا والحل الشامل ونظرية CAP ؛
  • ما إذا كانت خادم قاعدة البيانات + التطبيق في نهج واحد هي رصاصة فضية ؛
  • حول تطور المنصة وقواعد البيانات المستخدمة فيها ؛
  • , Tarantool’ .

, @Databases Meetup by Mail.ru Cloud Solutions. , :



Mail.ru IoT Platform


منتجنا ، Mail.ru IoT Platform ، عبارة عن منصة قابلة للتطوير ومستقلة عن الأجهزة لبناء حلول لإنترنت الأشياء الصناعي. يسمح لك بجمع البيانات من مئات الآلاف من الأجهزة في وقت واحد ومعالجة هذا الدفق في الوضع شبه الحقيقي (مثل شبه الوقت الحقيقي) ، بما في ذلك استخدام القواعد المخصصة - النصوص البرمجية في Python أو Lua.

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


هذه هي الطريقة التي يبدو بها جهاز Mail.ru IoT Platform.

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

نموذج تارانتول: كيف بدأ كل شيء


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


مخطط نموذج تارانتول النموذجي

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

أهدافنا في تطوير منصة إنترنت الأشياء


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

نحن بحاجة إلى بناء منصة بالمقدمة التمهيدية التالية:

  1. قم بتوصيل مئات الآلاف من الأجهزة في وقت واحد.
  2. استقبال ملايين الأحداث في الثانية.
  3. معالجة الدفق في وضع الوقت الفعلي تقريبًا.
  4. تخزين البيانات الخام لعدة سنوات.
  5. أدوات لكل من تحليلات الدفق والتحليلات التاريخية.
  6. دعم النشر في مراكز البيانات المتعددة لتحقيق أقصى قدر من التعافي من الكوارث.

إيجابيات وسلبيات النموذج الأولي للمنصة


في وقت بدء التطوير النشط ، بدا النموذج الأولي على النحو التالي:

  • Tarantool ، الذي يستخدم كخادم قاعدة بيانات + تطبيق (خادم التطبيقات) ؛
  • يتم تخزين جميع البيانات في ذاكرة Tarantool ؛
  • تطبيق على Lua في نفس Tarantool ، والذي يؤدي وظائف استقبال البيانات ومعالجتها واستدعاء البرامج النصية للمستخدم على البيانات الواردة.

هذا النهج لبناء التطبيقات مزاياه :

  1. يوجد الكود والبيانات في مكان واحد ، مما يسمح لك بالعمل على البيانات مباشرة في ذاكرة التطبيق وإزالة التكاليف العامة لزيارات الشبكة النموذجية للتطبيقات التقليدية.
  2. يستخدم تارانتول JIT (فقط في مترجم الوقت) لـ Lua ، التي تقوم في وقت الترجمة بتجميع كود Lua في كود الآلة ، والذي يسمح بتشغيل نصوص Lua البسيطة بسرعة مماثلة لرمز C (40،000 RPS من قلب واحد - وهذا ليس الحد !).
  3. يعتمد Tarantool على تعدد المهام التعاوني ، أي أن كل استدعاء للإجراء المخزن يتم إطلاقه في الألياف الخاصة به ، وهو نظير من coroutine ، والذي يعطي تعزيزًا أكبر في الأداء في مهام عمليات الإدخال / الإخراج ، على سبيل المثال ، زيارات الشبكة.
  4. الاستخدام الفعال للموارد - يمكن لعدد قليل من الأدوات معالجة 40.000 طلب في الثانية من وحدة معالجة مركزية واحدة.

ولكن هناك عيوب كبيرة :

  1. نحتاج إلى تخزين البيانات الأولية من الأجهزة لعدة سنوات ، ولكن ليس لدينا مئات البيتابايتات من الذاكرة لـ Tarantool.
  2. نتيجة مباشرة للإضافة الأولى: رمز النظام الأساسي بأكمله هو الإجراءات المخزنة في قاعدة البيانات ، مما يعني أن أي تحديث لقاعدة التعليمات البرمجية للنظام الأساسي هو تحديث لقاعدة البيانات ، وهو أمر مؤلم للغاية.
  3. , . , Tarantool 24-32 (Tarantool ) . — Tarantool, .
  4. . - , Tarantool Lua , - , LuaJIT .

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

الآلام الرئيسية للنموذج الأولي الذي أردنا التخلص منه


بادئ ذي بدء ، أردنا علاج ألمين من نموذجنا الأولي:

  1. الابتعاد عن مفهوم خدمة قاعدة البيانات + التطبيق. أردنا تحديث رمز التطبيق بغض النظر عن مخزن البيانات.
  2. تبسيط التحجيم الديناميكي تحت الحمل. أردت الحصول على تحجيم أفقي سهل مستقل لأكبر عدد ممكن من الوظائف.

لحل هذه المشاكل ، اخترنا نهجًا مبتكرًا لم يتم اختباره بعد: بنية الخدمات الصغيرة وفصل الخدمات إلى قاعدة بيانات عديمة الحالة - تطبيقات وقاعدة بيانات.

لمزيد من تسهيل التشغيل والتحجيم الأفقي للخدمات عديمي الجنسية ، قمنا بحزمها واعتماد Kubernetes.


اكتشفنا خدمات عديمي الجنسية ، يبقى تحديد ما يجب فعله بالبيانات.

المتطلبات الأساسية لقاعدة البيانات لمنصة إنترنت الأشياء


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

  1. ACID- — , .
  2. — .
  3. — , near real-time.
  4. — - .
  5. — , .
  6. — ( !), .
  7. — , ( !).
  8. SQL — .

CAP-


قبل البدء في فرز جميع قواعد البيانات الموجودة في السوق للامتثال لمتطلباتنا ، قررنا التحقق من متطلباتنا للعقلانية باستخدام أداة معروفة إلى حد ما - نظريات CAP.

تقول نظرية CAP أن النظام الموزع يمكن أن يحتوي على اثنين من الخصائص الثلاثة التالية كحد أقصى:

  1. الاتساق (اتساق البيانات) - في جميع عقد الحوسبة في وقت واحد ، لا تتعارض البيانات مع بعضها البعض.
  2. التوفر - أي طلب لنظام موزع ينتهي بإجابة صحيحة ، ولكن بدون ضمان تطابق إجابات جميع العقد في النظام.
  3. تحمل التقسيم - حتى إذا لم يكن هناك اتصال بين العقد ، فإنها تستمر في العمل بشكل مستقل عن بعضها البعض.


على سبيل المثال ، نظام CA الكلاسيكي هو مجموعة PostgreSQL Master-Slave مع النسخ المتزامن ، ونظام AP الكلاسيكي هو Cassandra.

دعونا نعود إلى متطلباتنا ونصنفها باستخدام نظرية CAP:

  1. معاملات ACID والاتساق الصارم (أو على الأقل ليس الاتساق النهائي) هي C.
  2. القياس الأفقي للكتابة والقراءة بالإضافة إلى التوفر العالي هو A (متعدد الأساتذة).
  3. التسامح مع الخطأ هو P ، عندما يسقط مركز بيانات واحد ، يجب ألا تموت المنصة.


الخلاصة : يجب أن تحتوي قاعدة البيانات العالمية التي نحتاجها على جميع الخصائص الثلاثة من نظرية CAP ، مما يعني أنه لا توجد قاعدة بيانات عالمية لجميع متطلباتنا.

اختيار قاعدة بيانات للبيانات التي تعمل بها منصة إنترنت الأشياء


إذا لم تتمكن من اختيار قاعدة بيانات عالمية ، فقد قررنا تحديد أنواع البيانات التي ستعمل معها المنصة وتحديد قاعدة بيانات لكل نوع.

في التقريب الأول ، قمنا بتقسيم البيانات إلى نوعين:

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

اختيار قاعدة بيانات لبيانات التعريف


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

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

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

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


هذه هي الطريقة التي يبدو بها عرض الأجهزة في شكل هيكل شجرة.

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

من أجل التنفيذ الكامل لأشجار العلامات ، يجب أن تستوفي قاعدة البيانات المحتملة المتطلبات التالية:

  1. دعم الأشجار بعرض وعمق تعسفيين.
  2. تعديل عناصر الشجرة في معاملات ACID.
  3. أداء عالي عند اجتياز شجرة.

يمكن لقواعد البيانات العلائقية الكلاسيكية التعامل مع الأشجار الصغيرة بشكل جيد ، لكنها لا تفعل ذلك أيضًا مع الأشجار التعسفية.

حل ممكن. استخدم قاعدتي بيانات - قاعدة بيانات رسم بياني لتخزين شجرة وقاعدة بيانات ارتباطية لتخزين بقية المعلومات الوصفية.

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

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


حل ممكن ولكن ليس جيدًا جدًا مع قاعدتي بيانات


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

قبل المتابعة ، أود أن أقدم تعريفًا غير قياسي لـ Tarantool: لا يعد Tarantool قاعدة بيانات ، بل مجموعة من الأساسيات لبناء قاعدة بيانات لحالتك الخاصة.

البدائيات المتاحة من خارج منطقة الجزاء:

  • مسافة - تناظرية للجداول في قاعدة البيانات لتخزين البيانات.
  • معاملات ACID كاملة.
  • النسخ المتماثل غير متزامن باستخدام سجلات WAL.
  • أداة تقسيم تدعم إعادة المشاركة التلقائية.
  • Superfast LuaJIT للإجراءات المخزنة.
  • مكتبة قياسية كبيرة.
  • مدير حزم LuaRocks مع المزيد من الحزم.

كان حل CA لدينا قاعدة بيانات علائقية + الرسم البياني على أساس Tarantool. لقد جمعنا مستودع المعلومات الوصفية للحلم بناءً على بدائل تارانتول:

  • مساحة لتخزين البيانات.
  • معاملات ACID - كانت متاحة.
  • النسخ المتزامن غير المتزامن - كان متوفرا.
  • العلاقات - تتم على الإجراءات المخزنة.
  • الأشجار - مصنوعة أيضًا في الإجراءات المخزنة.

إن تركيب الكتلة الذي لدينا هو كلاسيكي لهذه الأنظمة - واحد رئيسي للكتابة والعديد من Slive مع النسخ المتزامن غير المتزامن للتحجيم للقراءة.

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

اختيار قاعدة بيانات للبيانات من الأجهزة


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

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

أي أننا في إطار نظرية CAP نحتاج إلى نظام AP.

متطلبات إضافية. كان لدينا بعض المتطلبات الإضافية لتحديد مكان تخزين الكميات الضخمة من البيانات:

  1. السلاسل الزمنية - البيانات من أجهزة الاستشعار هي السلاسل الزمنية ، أردت الحصول على قاعدة متخصصة.
  2. المصدر المفتوح - مزايا رمز المصدر المفتوح لا تحتاج إلى تعليقات.
  3. الكتلة الحرة هي آفة شائعة بين قواعد البيانات الجديدة.
  4. ضغط جيد - نظرًا لكمية البيانات وبشكل عام توحيدها ، أردت ضغط البيانات المخزنة بكفاءة.
  5. عملية ناجحة - أردنا أن نبدأ في قاعدة بيانات يستغلها بالفعل شخص نشط بالفعل بالقرب من حمولاتنا من أجل تقليل المخاطر.

قرارنا . يناسب ClickHouse حصريًا متطلباتنا - قاعدة بيانات قائمة على الأعمدة من السلاسل الزمنية مع النسخ المتماثل ، متعدد الوسائط ، المشاركة ، دعم SQL ومجموعة مجانية. علاوة على ذلك ، لدى Mail.ru سنوات عديدة من الخبرة الناجحة في تشغيل واحدة من أكبر مجموعات ClickHouse في حجم التخزين.

ولكن بغض النظر عن مدى جودة ClickHouse ، ولدينا مشاكل معها.

مشاكل قواعد البيانات لهذه الأجهزة وحلها


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

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


لذلك تعاملنا مع الأداء الضعيف للتسجيل.

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

وهذا أمر مهم للعديد من الخوارزميات التي تستجيب للبيانات من أجهزة الاستشعار في الوقت الحقيقي.

اقرأ مشكلة الأداء. تحليلات الدفق لمعالجة البيانات في الوقت الحقيقي تحتاج باستمرار إلى معلومات من قاعدة البيانات - هذه عشرات الآلاف من الاستعلامات الصغيرة. في المتوسط ​​، تحتوي عقدة ClickHouse واحدة على حوالي مائة استفسار تحليلي في نفس الوقت ؛ تم إنشاؤها للاستعلامات التحليلية الثقيلة غير المتكررة لمعالجة كميات كبيرة من البيانات. بالطبع ، هذا غير مناسب لحساب الاتجاهات في تدفق البيانات من مئات الآلاف من أجهزة الاستشعار.


مع عدد كبير من طلبات ClickHouse لا يعمل بشكل جيد.

حل المشكلة . قررنا وضع ذاكرة تخزين مؤقت أمام ClickHouse ، والتي ستحتوي على البيانات الساخنة الأكثر طلبًا خلال الـ 24 ساعة الماضية.

البيانات خلال الـ 24 ساعة الماضية ليست بيانات لمدة عام ، ولكن أيضًا كمية كبيرة جدًا من البيانات ، لذلك ، نحتاج أيضًا إلى نظام AP مع تحجيم أفقي للقراءة والكتابة ، ولكن مع التركيز على الأداء لتسجيل الأحداث الفردية وللتعدد قراءة. كما يتطلب أيضًا توفرًا عاليًا وتحليلات السلاسل الزمنية والمثابرة و TTL المضمنة.

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

  1. المثابرة - هي (WAL-logs + snapshots).
  2. الأداء - هناك كل البيانات الموجودة في الذاكرة.
  3. تحجيم - هناك تكرار + تقسيم.
  4. توافر عالية - هناك.
  5. أدوات تحليل السلاسل الزمنية (التجميع ، التجميع ، إلخ) - المصنوعة على الإجراءات المخزنة.
  6. TTL - يتم إجراؤه على الإجراءات المخزنة باستخدام ألياف خلفية واحدة (coroutine).

اتضح أنه حل ملائم ومنتج - يحتوي أحد الأمثلة على 10000 RPCs للقراءة ، بما في ذلك الاستعلامات التحليلية لما يصل إلى عشرات الآلاف من الاستعلامات.

هنا العمارة الناتجة:


البنية النهائية: ClickHouse كقاعدة بيانات تحليلية وذاكرة تخزين مؤقت Tarantool تقوم بتخزين البيانات في 24 ساعة

نوع البيانات الجديد - الحالة وتخزينها


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

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

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

أي أنه بالنسبة لقاعدة البيانات التي يتم تخزين الحالة فيها ، يعد القياس الأفقي للقراءة والكتابة والتوافر العالي والتسامح مع الأخطاء أمرًا مهمًا ، بينما يلزم الاتساق على مستوى القيم / المستندات. يمكنك الاعتماد على الاتساق العام ومعاملات ACID.

يمكن أن يكون الحل المناسب هو أي قيمة رئيسية أو قاعدة بيانات للمستندات: مجموعة Redis مظللة أو MongoDB أو مرة أخرى Tarantool.

إيجابيات تارانتول:

  1. هذه هي الطريقة الأكثر شيوعًا لاستخدام Tarantool.
  2. التحجيم الأفقي - هناك نسخ غير متزامن + تقسيم.
  3. الاتساق على مستوى المستند - هو.

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

كيفية اختيار قاعدة بيانات لمنصة إنترنت الأشياء


  1. لا توجد قاعدة بيانات عالمية.
  2. لكل نوع من البيانات قاعدة بيانات خاصة به هي الأنسب له.
  3. في بعض الأحيان قد لا تكون قاعدة البيانات التي تحتاجها متاحة في السوق.
  4. Tarantool مناسب كأساس لقاعدة بيانات متخصصة.

تم إجراء هذا الحديث لأول مرة في Meets by Mail.ru Cloud Solutions. مشاهدة الفيديو من العروض الأخرى، والاشتراك في الإعلانات الحدث برقية حوالي Kubernetes في المجموعة Mail.ru .


ماذا تقرأ :

  1. ما قاعدة البيانات للاختيار للمشروع ، حتى لا تختار مرة أخرى .
  2. أكثر من Ceph: حظر التخزين في سحابة MCS .


All Articles