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

دعني أخبرك بقصة تقنية.

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

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


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

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

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

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

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

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

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

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

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

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

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

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

انتصار باهظ

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

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

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

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

وخرج من حجرته وأعلن:

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

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

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

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

لذا، إذا كنت تأمل في وضع 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. إذا اتبعت نفس النمط في الكود الخاص بك، فسوف تتفاجأ بكمية الكود المتخصص الذي يختفي عندما تدرك أن 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. ومع ذلك، فإن كل هذه الحلول تأتي مع قدر كبير من المصطلحات التجارية الكثيفة للشركات، مما يجعلك تعود بسرعة وتبدأ في البحث عن شيء آخر.

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

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

كإعلان

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

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