این بانک اطلاعاتی در آتش است...

بگذارید یک داستان فنی بگویم.

سال‌ها پیش، من در حال توسعه برنامه‌ای بودم که ویژگی‌های همکاری در آن تعبیه شده بود. این یک پشته آزمایشی کاربرپسند بود که از پتانسیل کامل React و CouchDB اولیه استفاده کرد. این داده ها را در زمان واقعی از طریق JSON همگام می کند OT. در داخل شرکت مورد استفاده قرار گرفت، اما کاربرد گسترده و پتانسیل آن در سایر زمینه ها مشخص بود.

هنگام تلاش برای فروش این فناوری به مشتریان بالقوه، با یک مانع غیرمنتظره مواجه شدیم. در ویدیوی آزمایشی، فناوری ما عالی به نظر می‌رسد و کار می‌کند، هیچ مشکلی در آنجا وجود ندارد. این ویدیو دقیقاً نحوه عملکرد آن را نشان می دهد و چیزی را تقلید نمی کند. ما یک سناریوی واقع بینانه برای استفاده از برنامه ایجاد کردیم و کدگذاری کردیم.


در واقع این مشکل شد. نسخه ی نمایشی ما دقیقاً به روشی کار می کرد که بقیه برنامه های خود را شبیه سازی کردند. به طور خاص، اطلاعات فوراً از A به B منتقل می‌شد، حتی اگر فایل‌های رسانه‌ای بزرگ باشند. پس از ورود به سیستم، هر کاربر ورودی های جدیدی را مشاهده کرد. با استفاده از برنامه، کاربران مختلف می‌توانند به وضوح روی پروژه‌های مشابه با هم کار کنند، حتی اگر اتصال اینترنت در جایی در روستا قطع شده باشد. این به طور ضمنی در هر ویدیوی محصولی که در After Effects برش داده شده است، وجود دارد.

حتی اگر همه می دانستند که دکمه Refresh برای چیست، هیچ کس واقعاً متوجه نشد که برنامه های وب که از ما می خواهند بسازیم معمولاً تابع محدودیت های خودشان هستند. و اینکه اگر دیگر مورد نیاز نباشند، تجربه کاربری کاملا متفاوت خواهد بود. آن‌ها بیشتر متوجه شدند که می‌توانند با گذاشتن یادداشت برای افرادی که با آنها صحبت می‌کنند «چت» کنند، بنابراین تعجب کردند که چگونه این با مثلاً Slack متفاوت است. اوه!

طراحی همگام سازی های روزمره

اگر تجربه ای در زمینه توسعه نرم افزار دارید، باید اعصاب خردکن باشد که به یاد داشته باشید که بیشتر مردم نمی توانند فقط به تصویر یک رابط نگاه کنند و بفهمند که هنگام تعامل با آن چه کاری انجام می دهد. ناگفته نماند که در داخل خود برنامه چه اتفاقی می افتد. بدان که می تواند اتفاق می افتد تا حد زیادی نتیجه دانستن این است که چه چیزی نمی تواند اتفاق بیفتد و چه چیزی نباید اتفاق بیفتد. این نیاز دارد مدل ذهنی نه تنها کاری که نرم افزار انجام می دهد، بلکه همچنین نحوه هماهنگی و ارتباط بخش های جداگانه آن با یکدیگر.

یک مثال کلاسیک از این کار، خیره شدن کاربر به a است spinner.gif، به این فکر می کنم که بالاخره چه زمانی کار به پایان می رسد. توسعه‌دهنده متوجه می‌شد که احتمالاً این فرآیند متوقف شده است و گیف هرگز از صفحه نمایش محو نمی‌شود. این انیمیشن اجرای یک کار را شبیه سازی می کند، اما به وضعیت آن مربوط نمی شود. در چنین مواردی، برخی از فناوران دوست دارند چشمان خود را بچرخانند و از میزان سردرگمی کاربران شگفت زده شوند. با این حال، توجه کنید که چند نفر از آنها به ساعت چرخان اشاره می کنند و می گویند که در واقع ثابت است؟

این ماهیت ارزش زمان واقعی است. این روزها، پایگاه داده های بلادرنگ هنوز بسیار کم استفاده می شوند و بسیاری از مردم با شک به آنها نگاه می کنند. اکثر این پایگاه‌های داده به شدت به سبک NoSQL متمایل هستند، به همین دلیل است که معمولاً از راه‌حل‌های مبتنی بر Mongo استفاده می‌کنند که بهتر است فراموش شوند. با این حال، برای من این به معنای راحت بودن کار با CouchDB و همچنین یادگیری طراحی ساختارهایی است که بیش از یک بوروکرات فقط می تواند با داده ها پر کند. فکر می کنم از زمانم بهتر استفاده می کنم.

اما موضوع واقعی این پست چیزی است که من امروز از آن استفاده می کنم. نه از روی انتخاب، بلکه به دلیل بی تفاوتی و کورکورانه اعمال سیاست های شرکتی. بنابراین من یک مقایسه کاملاً منصفانه و بی‌طرفانه از دو محصول پایگاه داده بی‌درنگ Google ارائه خواهم کرد.

هر دو در نام خود کلمه آتش را دارند. یک چیز را با علاقه به یاد دارم. دومین مورد برای من نوع دیگری از آتش است. من عجله ای برای گفتن نام آنها ندارم، زیرا وقتی این کار را انجام دهم، با اولین مشکل بزرگ روبرو خواهیم شد: نام ها.

اولی نام دارد پایگاه داده زمان واقعی Firebase، و دوم - Firebase Cloud Firestore. هر دوی آنها محصولی از مجموعه Firebase گوگل. APIهای آنها به ترتیب نامیده می شود firebase.database(…) и firebase.firestore(…).

این اتفاق افتاد زیرا پایگاه داده بلادرنگ - این فقط اصلی است آتش نشانی قبل از خرید آن توسط گوگل در سال 2014. سپس گوگل تصمیم گرفت به عنوان یک محصول موازی ایجاد کند کپی 🀄 Firebase بر اساس شرکت داده های بزرگ است و آن را Firestore با یک ابر نامید. امیدوارم هنوز گیج نشده باشید. اگر هنوز گیج هستید، نگران نباشید، من خودم این قسمت از مقاله را ده بار بازنویسی کردم.

زیرا باید نشان دهید آتش نشانی در سوال Firebase، و آتش فروشی در یک سوال در مورد Firebase، حداقل برای اینکه چند سال پیش در مورد Stack Overflow متوجه شوید.

اگر جایزه ای برای بدترین تجربه نام گذاری نرم افزار وجود داشت، قطعا این یکی از مدعیان بود. فاصله هامینگ بین این نام ها به قدری کم است که حتی مهندسان با تجربه را که انگشتانشان یک نام را تایپ می کنند در حالی که سرشان به نام دیگری فکر می کند، گیج می کند. اینها نقشه هایی با نیت خوب هستند که به طرز بدی با شکست مواجه می شوند. آنها این پیشگویی را برآورده کردند که پایگاه داده در آتش خواهد افتاد. و من اصلا شوخی ندارم. فردی که این طرح نامگذاری را مطرح کرد باعث خون، عرق و اشک شد.

پیروزی پیره

یکی فکر می کند که Firestor است جایگزینی Firebase، نسل بعدی آن است، اما این گمراه کننده خواهد بود. Firestore تضمین نمی شود که جایگزین مناسبی برای Firebase باشد. به نظر می رسد کسی همه چیز جالب را از آن حذف کرده است و بیشتر بقیه را به روش های مختلف گیج کرده است.

با این حال، نگاهی گذرا به این دو محصول ممکن است شما را گیج کند: به نظر می رسد که آنها همان کار را انجام می دهند، اساساً از طریق API های یکسان و حتی در یک جلسه پایگاه داده. تفاوت ها ظریف هستند و تنها با مطالعه تطبیقی ​​دقیق اسناد گسترده آشکار می شوند. یا زمانی که می‌خواهید کدی را پورت کنید که کاملاً روی Firebase کار کند تا با Firestore کار کند. حتی پس از آن متوجه می شوید که رابط پایگاه داده به محض اینکه بخواهید با ماوس در زمان واقعی بکشید و رها کنید روشن می شود. بازم میگم شوخی نمیکنم

مشتری Firebase مودبانه است به این معنا که تغییرات را بافر می کند و به طور خودکار به روز رسانی هایی را که اولویت را به آخرین عملیات نوشتن می دهد دوباره امتحان می کند. با این حال، Firestore دارای محدودیت 1 عملیات نوشتن در هر سند به ازای هر کاربر در ثانیه است و این محدودیت توسط سرور اعمال می شود. هنگام کار با آن، این شما هستید که باید راهی برای دور زدن آن پیدا کنید و یک محدود کننده نرخ به روز رسانی را پیاده سازی کنید، حتی زمانی که فقط می خواهید برنامه خود را بسازید. یعنی Firestore یک پایگاه داده بلادرنگ بدون کلاینت بلادرنگ است که با استفاده از یک API به عنوان یک پایگاه داده ظاهر می شود.

در اینجا ما شروع به دیدن اولین نشانه های دلیل وجودی Firestor می کنیم. ممکن است اشتباه کنم، اما گمان می‌کنم که یکی از مدیران ارشد گوگل پس از خرید به 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 عالی کار می کند. اما اساساً شما از آن از طریق یک API بلادرنگ استفاده می‌کنید که سوکت‌های وب، مجوزها و اشتراک‌ها را خلاصه می‌کند. پنل مدیریت هر دو قابلیت را دارد و امکان ویرایش بی‌درنگ و واردات/صادرات JSON را می‌دهد. اگر همین کار را در کد خود انجام دهید، از اینکه چه مقدار کد تخصصی هدر می‌رود تعجب خواهید کرد وقتی متوجه شوید که وصله و تفاوت JSON 90٪ ​​از وظایف معمول مدیریت وضعیت پایدار را حل می‌کند.

مدل داده Firestore شبیه به JSON است، اما از برخی جهات مهم متفاوت است. قبلاً به کمبود آرایه ها در آرایه ها اشاره کردم. مدل زیر مجموعه ها این است که آنها مفاهیم درجه یک باشند، جدا از سند JSON که حاوی آنهاست. از آنجایی که سریال سازی آماده ای برای این کار وجود ندارد، یک مسیر کد تخصصی برای بازیابی و نوشتن داده ها مورد نیاز است. برای پردازش مجموعه های خود، باید اسکریپت ها و ابزارهای خود را بنویسید. پنل مدیریت تنها به شما امکان می دهد تغییرات کوچک را در یک قسمت در یک زمان انجام دهید و قابلیت واردات/صادرات ندارد.

آنها یک پایگاه داده بی‌درنگ NoSQL را گرفتند و آن را به یک غیر SQL کند با پیوستن خودکار و یک ستون جداگانه غیر JSON تبدیل کردند. چیزی شبیه GraftQL.

جاوا داغ

اگر قرار بود Firestore قابل اعتمادتر و مقیاس پذیرتر باشد، طنز ماجرا این است که توسعه دهندگان معمولی در نهایت با راه حلی کمتر قابل اعتمادتر از انتخاب FireBase خارج از جعبه مواجه خواهند شد. نوع نرم افزاری که مدیر پایگاه داده Grumpy به آن نیاز دارد به سطحی از تلاش و استعداد نیاز دارد که برای جایگاهی که محصول قرار است در آن خوب باشد، به سادگی غیر واقعی است. این شبیه به این است که اگر ابزار توسعه و پخش کننده وجود نداشته باشد، Canvas HTML5 اصلاً جایگزینی برای فلش نیست. علاوه بر این، Firestore در میل به خلوص داده ها و اعتبار سنجی استریل غرق شده است که به سادگی با نحوه استفاده از کاربران تجاری معمولی همخوانی ندارد. عاشق کار کردن است: برای او همه چیز اختیاری است، زیرا تا آخر همه چیز یک پیش نویس است.

نقطه ضعف اصلی FireBase این است که مشتری چندین سال زودتر از زمان خود ایجاد شده است، قبل از اینکه اکثر توسعه دهندگان وب از تغییرناپذیری بدانند. به همین دلیل، FireBase فرض می کند که شما داده ها را تغییر خواهید داد و بنابراین از تغییر ناپذیری ارائه شده توسط کاربر استفاده نمی کند. علاوه بر این، از داده‌های موجود در عکس‌های فوری که به کاربر ارسال می‌کند، استفاده مجدد نمی‌کند، که تفاوت را بسیار دشوارتر می‌کند. برای اسناد بزرگ، مکانیسم تراکنش مبتنی بر تفاوت قابل تغییر آن به سادگی ناکافی است. بچه ها، ما قبلا داریم WeakMap در جاوا اسکریپت راحت است.

اگر به داده ها شکل دلخواه بدهید و درختان را بیش از حد حجیم نکنید، می توان این مشکل را دور زد. اما من کنجکاو هستم که اگر توسعه دهندگان یک API کلاینت واقعا خوب را منتشر کنند که از تغییر ناپذیری همراه با برخی توصیه های عملی جدی در مورد طراحی پایگاه داده استفاده می کند، FireBase بسیار جالب تر خواهد بود. در عوض، به نظر می‌رسید که سعی می‌کردند چیزی را که شکسته نشده بود، تعمیر کنند، و این وضعیت را بدتر کرد.

من تمام منطق پشت ایجاد Firestor را نمی دانم. گمانه زنی در مورد انگیزه هایی که در داخل جعبه سیاه ایجاد می شود نیز بخشی از سرگرمی است. این کنار هم قرار گرفتن دو پایگاه داده بسیار مشابه اما غیرقابل مقایسه بسیار نادر است. مثل این است که کسی فکر می کند: "Firebase فقط یک تابع است که می توانیم در Google Cloud شبیه سازی کنیم."، اما هنوز مفهوم شناسایی نیازمندی های دنیای واقعی یا ایجاد راه حل های مفیدی را که تمام آن الزامات را برآورده می کند، کشف نکرده است. اجازه دهید توسعه دهندگان در مورد آن فکر کنند. فقط رابط کاربری را زیبا کنید... آیا می‌توانید آتش بیشتری اضافه کنید؟»

من چند چیز را در مورد ساختار داده درک می کنم. من قطعا مفهوم "همه چیز در یک درخت JSON بزرگ" را به عنوان تلاشی برای انتزاع هرگونه ساختار مقیاس بزرگ از پایگاه داده می بینم. انتظار اینکه نرم افزار به سادگی با هر فراکتال ساختار داده مشکوک کنار بیاید، به سادگی دیوانه کننده است. من حتی لازم نیست تصور کنم که چقدر چیزها می تواند بد باشد، من ممیزی های دقیق کد انجام داده ام و من چیزهایی دیدم که شما مردم هرگز در خواب هم نمی دیدید. اما من همچنین می دانم که ساختارهای خوب چه شکلی هستند، نحوه استفاده از آنها и چرا باید این کار انجام شود. من می توانم دنیایی را تصور کنم که در آن Firestore منطقی به نظر برسد و افرادی که آن را ایجاد کرده اند فکر کنند کار خوبی انجام داده اند. اما ما در این دنیا زندگی نمی کنیم.

پشتیبانی Query FireBase با هر استانداردی ضعیف است و عملاً وجود ندارد. قطعا نیاز به بهبود یا حداقل تجدید نظر دارد. اما Firestore خیلی بهتر نیست زیرا به همان شاخص های تک بعدی موجود در SQL ساده محدود می شود. اگر به پرس و جوهایی نیاز دارید که افراد روی داده‌های آشفته اجرا می‌کنند، به جستجوی متن کامل، فیلترهای چند دامنه‌ای و سفارش‌گذاری سفارشی تعریف‌شده توسط کاربر نیاز دارید. با بررسی دقیق تر، عملکردهای SQL ساده به خودی خود بسیار محدود می شوند. علاوه بر این، تنها پرس و جوهای SQL که افراد می توانند در تولید اجرا کنند، پرس و جوهای سریع هستند. شما به یک راه حل نمایه سازی سفارشی با ساختارهای داده هوشمند نیاز دارید. برای هر چیز دیگری، حداقل باید کاهش تدریجی نقشه یا چیزی مشابه وجود داشته باشد.

اگر در Google Docs اطلاعاتی در این مورد جستجو کنید، امیدواریم به سمت چیزی مانند BigTable و BigQuery هدایت شوید. با این حال، همه این راه حل ها با اصطلاحات فروش شرکتی بسیار متراکم همراه هستند که شما به سرعت به عقب برمی گردید و به دنبال چیز دیگری خواهید بود.

آخرین چیزی که با یک پایگاه داده بلادرنگ می خواهید، چیزی است که توسط و برای افرادی که در مقیاس های پرداخت مدیریتی هستند ساخته شده است.

(*) این یک شوخی است، چیزی به نام وجود ندارد 100٪ با JSON سازگار است.

در حقوق تبلیغات

به دنبال VDS برای اشکال زدایی پروژه ها، سروری برای توسعه و میزبانی؟ شما قطعا مشتری ما هستید 🙂 قیمت روزانه سرورهای پیکربندی های مختلف، مجوزهای ضد DDoS و ویندوز از قبل در قیمت گنجانده شده است.

منبع: www.habr.com