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

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



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



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





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



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

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

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



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





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



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





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



الأول يسمى Firebase Real-Time Database والثاني هو Firebase Cloud Firestore . كلاهما منتجان من مجموعة Firebase من Google. يتم تسمية واجهات برمجة التطبيقات الخاصة بهم ، على التوالي ، firebase.database(…)و firebase.firestore(…).



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



نظرًا لأنه يجب ذكر Firebase في سؤال Firebase ، و Firestore في سؤال Firebase ، على الأقل ليتم فهمه قبل بضع سنوات على Stack Overflow.



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

نصر مكلف

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



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



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



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





خرج من غرفته وأعلن ،



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



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



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



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



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



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



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

{
  "hello": "world"
}

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

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

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



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



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



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

جافا الساخنة

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



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



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



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



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



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



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



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



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

---

إعلان

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