قاعدة البيانات هذه مشتعلة ...

اسمحوا لي أن أحكي قصة فنية.

منذ عدة سنوات مضت، كنت أقوم بتطوير تطبيق يشتمل على ميزات التعاون المضمنة فيه. لقد كانت حزمة تجريبية سهلة الاستخدام استفادت من الإمكانات الكاملة لـ React وCouchDB المبكرة. يقوم بمزامنة البيانات في الوقت الفعلي عبر JSON OT. وقد تم استخدامه داخليًا داخل الشركة، ولكن إمكانية تطبيقه على نطاق واسع وإمكاناته في مجالات أخرى كانت واضحة.

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


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

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

تصميم المزامنات اليومية

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

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

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

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

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

الأول يسمى قاعدة بيانات Firebase في الوقت الحقيقي، والثانية - Firebase Cloud Firestore. وكلاهما منتجات من مجموعة Firebase جوجل. يتم استدعاء واجهات برمجة التطبيقات الخاصة بهم على التوالي firebase.database(…) и firebase.firestore(…).

حدث هذا بسبب قاعدة بيانات في الوقت الحقيقي - انها مجرد الأصلي Firebase قبل أن تشتريها جوجل في عام 2014. ثم قررت Google إنشاء منتج موازٍ نسخة تعتمد Firebase على شركة البيانات الضخمة، ويُطلق عليها اسم Firestore with a cloud. أتمنى أن لا تكون مرتبكًا بعد. إذا كنت لا تزال في حيرة من أمرك، فلا تقلق، فأنا بنفسي أعدت كتابة هذا الجزء من المقال عشر مرات.

لأنك تحتاج إلى الإشارة Firebase في سؤال Firebase، و فايرستور في سؤال حول Firebase، على الأقل لتجعلك تفهم Stack Overflow قبل بضع سنوات.

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

انتصار باهظ

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

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

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

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

وخرج من غرفته وقال:

"وثيقة JSON كبيرة واحدة؟ لا. ستقوم بتقسيم البيانات إلى مستندات منفصلة، ​​لن يزيد حجم كل منها عن 1 ميغابايت.

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

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

"مصفوفات المصفوفات التي يمكن أن تحتوي بشكل متكرر على عناصر أخرى؟ لا. ستحتوي المصفوفات على كائنات أو أرقام ذات طول ثابت فقط، كما أراد الله."

لذا، إذا كنت تأمل في وضع GeoJSON في متجر Firestore الخاص بك، فستجد أن هذا غير ممكن. لا يوجد شيء غير أحادي البعد مقبول. أتمنى أن يعجبك Base64 و/أو JSON داخل JSON.

"استيراد وتصدير JSON عبر HTTP أو أدوات سطر الأوامر أو لوحة الإدارة؟ لا. لن تتمكن إلا من تصدير البيانات واستيرادها إلى Google Cloud Storage. هذا ما يسمى الآن، على ما أعتقد. وعندما أقول "أنت"، فأنا أخاطب فقط أولئك الذين لديهم بيانات اعتماد مالك المشروع. يمكن لأي شخص آخر الذهاب وإنشاء التذاكر."

كما ترون، من السهل وصف نموذج بيانات FireBase. يحتوي على مستند JSON ضخم يربط مفاتيح JSON بمسارات URL. إذا كنت تكتب مع HTTP PUT в / FireBase هو ما يلي:

{
  "hello": "world"
}

ثم GET /hello سيعود "world". في الأساس يعمل تمامًا كما تتوقع. مجموعة من كائنات FireBase /my-collection/:id يعادل قاموس JSON {"my-collection": {...}} في الجذر، محتوياتها متوفرة في /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

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

بمعنى آخر، قاعدة البيانات متوافقة بنسبة 100% مع JSON(*) وتعمل بشكل رائع مع HTTP، مثل CouchDB. لكنك تستخدمه بشكل أساسي من خلال واجهة برمجة التطبيقات في الوقت الفعلي التي تلخص مجموعات الويب والتفويض والاشتراكات. تتمتع لوحة الإدارة بكلتا الإمكانيتين، مما يسمح بالتحرير في الوقت الفعلي واستيراد/تصدير JSON. إذا فعلت الشيء نفسه في التعليمات البرمجية الخاصة بك، فسوف تتفاجأ من مقدار التعليمات البرمجية المتخصصة التي سيتم إهدارها عندما تدرك أن patch and diff JSON يحل 90٪ من المهام الروتينية للتعامل مع الحالة المستمرة.

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

لقد أخذوا قاعدة بيانات NoSQL في الوقت الفعلي وقاموا بتحويلها إلى قاعدة بيانات بطيئة غير تابعة لـ SQL مع انضمام تلقائي وعمود منفصل غير JSON. شيء من هذا القبيل GraftQL.

جافا الساخنة

إذا كان من المفترض أن يكون Firestore أكثر موثوقية وقابلية للتطوير، فإن المفارقة هي أن المطور العادي سينتهي به الأمر بحل أقل موثوقية من اختيار FireBase خارج الصندوق. يتطلب نوع البرنامج الذي يحتاجه مسؤول قاعدة بيانات Grumpy مستوى من الجهد ومستوى من الموهبة وهو أمر غير واقعي ببساطة بالنسبة للمجال الذي من المفترض أن يكون المنتج جيدًا فيه. يشبه هذا كيف أن HTML5 Canvas لا يحل محل Flash على الإطلاق في حالة عدم وجود أدوات تطوير ومشغل. علاوة على ذلك، فإن Firestore غارق في الرغبة في نقاء البيانات والتحقق من صحتها، الأمر الذي لا يتوافق ببساطة مع الطريقة التي يتبعها المستخدم التجاري العادي. يحب العمل: بالنسبة له كل شيء اختياري، لأنه حتى النهاية كل شيء هو مسودة.

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

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

لا أعرف كل المنطق وراء إنشاء Firestore. إن التكهن بالدوافع التي تنشأ داخل الصندوق الأسود هو أيضًا جزء من المتعة. يعد هذا التجاور بين قاعدتي بيانات متشابهتين للغاية ولكن لا يمكن مقارنتهما أمرًا نادرًا جدًا. كما لو أن أحدهم فكر: "Firebase هي مجرد وظيفة يمكننا محاكاتها في Google Cloud"ولكنها لم تكتشف بعد مفهوم تحديد متطلبات العالم الحقيقي أو إنشاء حلول مفيدة تلبي جميع تلك المتطلبات. "دع المطورين يفكرون في الأمر. فقط اجعل واجهة المستخدم جميلة... هل يمكنك إضافة المزيد من الإثارة؟"

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

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

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

آخر شيء تريده مع قاعدة البيانات في الوقت الفعلي هو شيء يصنعه الأشخاص في جداول الرواتب الإدارية ومن أجلهم.

(*) دي مزحة، مفيش حاجة اسمها متوافق مع JSON بنسبة 100%.

كإعلان

البحث عن VDS لتصحيح المشاريع، خادم للتطوير والاستضافة؟ أنت بالتأكيد عميلنا 🙂 الأسعار اليومية للخوادم ذات التكوينات المختلفة وتراخيص مكافحة DDoS وWindows مدرجة بالفعل في السعر.

المصدر: www.habr.com