Texniki bir hekayə danışım.
Uzun illər əvvəl mən onun daxilində əməkdaşlıq xüsusiyyətləri olan bir proqram inkişaf etdirirdim. Bu, erkən React və CouchDB-nin bütün potensialından istifadə edən istifadəçi dostu eksperimental yığın idi. JSON vasitəsilə real vaxt rejimində məlumatları sinxronlaşdırdı . O, şirkət daxilində istifadə olunurdu, lakin onun geniş tətbiqi və digər sahələrdə potensialı aydın idi.
Bu texnologiyanı potensial müştərilərə satmağa çalışarkən gözlənilməz bir maneə ilə qarşılaşdıq. Demo videoda texnologiyamız əla görünürdü və işləyirdi, heç bir problem yoxdur. Video onun necə işlədiyini dəqiq göstərdi və heç bir şeyi təqlid etmədi. Proqramdan istifadə üçün real ssenari hazırladıq və kodladıq.
Əslində bu problemə çevrildi. Bizim demo hər kəsin öz tətbiqlərini simulyasiya etdiyi kimi işləyirdi. Konkret olaraq, informasiya böyük media faylları olsa belə, dərhal A-dan B-yə ötürülürdü. Daxil olduqdan sonra hər bir istifadəçi yeni qeydlər gördü. Tətbiqdən istifadə edərək, kəndin bir yerində İnternet bağlantısı kəsilsə belə, müxtəlif istifadəçilər eyni layihələrdə aydın şəkildə birlikdə işləyə bilər. Bu, After Effects-də kəsilmiş hər hansı məhsul videosunda gizli şəkildə nəzərdə tutulur.
Hər kəs Yenilə düyməsinin nə üçün olduğunu bilsə də, heç kim bizdən qurmamızı istədikləri veb proqramların adətən öz məhdudiyyətlərinə tabe olduğunu başa düşmürdü. Və onlar artıq lazım deyilsə, istifadəçi təcrübəsi tamamilə fərqli olacaq. Onlar daha çox danışdıqları insanlar üçün qeydlər buraxaraq "söhbət" edə bildiklərini gördülər, buna görə də bunun, məsələn, Slack-dən nə ilə fərqləndiyini merak etdilər. vay!
Gündəlik sinxronizasiyanın dizaynı
Əgər proqram təminatının hazırlanmasında təcrübəniz varsa, insanların çoxunun sadəcə interfeysin şəklinə baxmaq və onunla qarşılıqlı əlaqədə olarkən onun nə edəcəyini anlamaqla kifayətlənmədiyini xatırlamaq əsəbləri dağıdıcı olmalıdır. Proqramın özündə nə baş verdiyini demirəm. Bil ki can baş verməsi əsasən nəyin baş verə bilməyəcəyini və nəyin baş verməməli olduğunu bilmənin nəticəsidir. Bu tələb edir yalnız proqram təminatının nə etdiyini deyil, həm də onun ayrı-ayrı hissələrinin bir-biri ilə necə əlaqələndirildiyini və əlaqə saxladığını.
Bunun klassik nümunəsi a-a baxan bir istifadəçidir spinner.gif, işin nəhayət nə vaxt tamamlanacağı ilə maraqlanır. Tərtibatçı prosesin yəqin ki, ilişib qaldığını və gif-in heç vaxt ekrandan itməyəcəyini başa düşəcəkdi. Bu animasiya işin icrasını simulyasiya edir, lakin onun vəziyyəti ilə əlaqəli deyil. Belə hallarda, bəzi texnoloqlar istifadəçi çaşqınlığının ölçüsünə heyran qalaraq gözlərini gəzdirməyi xoşlayırlar. Lakin, diqqət yetirin, onlardan neçəsi fırlanan saata işarə edir və əslində stasionar olduğunu söyləyir?
Bu, real vaxt dəyərinin mahiyyətidir. Bu günlərdə real vaxt verilənlər bazaları hələ də çox az istifadə olunur və bir çox insanlar onlara şübhə ilə yanaşır. Bu verilənlər bazalarının əksəriyyəti NoSQL üslubuna çox meyllidir, buna görə də onlar adətən ən yaxşı unudulan Mongo əsaslı həllərdən istifadə edirlər. Bununla belə, mənim üçün bu, CouchDB ilə rahat işləmək, həmçinin bəzi bürokratların məlumatlarla doldura biləcəyi strukturların dizaynını öyrənmək deməkdir. Düşünürəm ki, vaxtımı daha yaxşı istifadə edirəm.
Amma bu yazının əsl mövzusu bu gün istifadə etdiyim mövzudur. Seçimlə deyil, laqeyd və kor-koranə tətbiq edilən korporativ siyasətlər üzündən. Beləliklə, mən iki yaxından əlaqəli Google real vaxt verilənlər bazası məhsulunun Tamamilə Ədalətli və Qərəzsiz müqayisəsini təqdim edəcəyəm.
Hər ikisinin adında Od sözü var. Bir şeyi sevə-sevə xatırlayıram. Mənim üçün ikinci şey fərqli bir yanğın növüdür. Mən onların adlarını deməyə tələsmirəm, çünki desəm, ilk böyük problemlə qarşılaşacağıq: adlar.
Birincisi adlanır Firebase Real-Time Databasevə ikinci - Firebase Cloud Firestore. Onların hər ikisi firmanın məhsullarıdır Firebase dəsti Google. Onların API-ləri müvafiq olaraq adlanır firebase.database(…) и firebase.firestore(…).
Bu ona görə baş verdi Real vaxt verilənlər bazası - bu sadəcə orijinaldır Firebase 2014-cü ildə Google tərəfindən satın alınmazdan əvvəl. Sonra Google paralel məhsul kimi yaratmağa qərar verdi bir surəti Firebase böyük məlumat şirkətinə əsaslanır və onu buludlu Firestore adlandırır. Ümid edirəm ki, hələ çaşqın deyilsiniz. Hələ də çaşqınsınızsa, narahat olmayın, mən özüm məqalənin bu hissəsini on dəfə yenidən yazdım.
Çünki göstərmək lazımdır Firebase Firebase sualında və Firestore Firebase ilə bağlı bir sualda, ən azı bir neçə il əvvəl Stack Overflow-da başa düşməyiniz üçün.
Ən pis proqram adlandırma təcrübəsi üçün bir mükafat olsaydı, bu, mütləq namizədlərdən biri olardı. Bu adlar arasındakı Hamming məsafəsi o qədər kiçikdir ki, başları başqa bir ad haqqında düşünərkən barmaqları bir ad yazan təcrübəli mühəndisləri belə çaşdırır. Bunlar uğursuz bir şəkildə uğursuz olan yaxşı niyyətli planlardır; verilənlər bazası alovlanacağına dair peyğəmbərliyi yerinə yetirdilər. Mən isə heç zarafat etmirəm. Bu adlandırma sxemi ilə gündəmə gələn şəxs qan, tər və göz yaşı tökdü.
Pirik qələbə
Biri Firestore olduğunu düşünə bilər dəyişdirmə Firebase, onun növbəti nəsli, lakin bu, yanıltıcı olardı. Firestore-un Firebase üçün uyğun bir əvəz olacağına zəmanət verilmir. Deyəsən, kimsə ondan maraqlı olan hər şeyi kəsib, qalanlarının çoxunu müxtəlif yollarla qarışdırıb.
Bununla belə, iki məhsula sürətli nəzər salmaq sizi çaşdıra bilər: onlar eyni şeyi, əsasən eyni API-lər vasitəsilə və hətta eyni verilənlər bazası sessiyasında edirlər. Fərqlər incədir və yalnız geniş sənədlərin diqqətlə müqayisəli öyrənilməsi ilə aşkar edilir. Və ya Firestore ilə işləməsi üçün Firebase-də mükəmməl işləyən kodu portlamağa çalışdığınız zaman. Hətta onda siz real vaxt rejimində siçan ilə sürükləyib buraxmağa cəhd edən kimi verilənlər bazası interfeysinin yanıb-söndüyünü öyrənirsiniz. Yenə deyirəm, zarafat etmirəm.
Firebase müştərisi o mənada nəzakətlidir ki, o, dəyişiklikləri bufer edir və sonuncu yazma əməliyyatına üstünlük verən yeniləmələri avtomatik olaraq yenidən sınayır. Bununla belə, Firestore-da istifadəçi başına saniyədə sənəd başına 1 yazma əməliyyatı limiti var və bu limit server tərəfindən tətbiq edilir. Onunla işləyərkən, hətta sadəcə tətbiqinizi yaratmağa çalışdığınız zaman belə onun ətrafında bir yol tapmaq və yeniləmə dərəcəsi məhdudlaşdırıcısını tətbiq etmək sizə bağlıdır. Yəni, Firestore real vaxt müştərisi olmayan, API istifadə edən bir verilənlər bazasıdır.
Burada biz Firestore-un yaranma səbəbinin ilk əlamətlərini görməyə başlayırıq. Səhv edə bilərəm, amma mən şübhələnirəm ki, Google-un rəhbərliyində yüksək səviyyəli kimsə satın alındıqdan sonra Firebase-ə baxıb və sadəcə “Yox, aman Allahım, yox. Bu qəbuledilməzdir. Sadəcə mənim rəhbərliyim altında deyil”.
O, otağından çıxdı və dedi:
“Bir böyük JSON sənədi? Yox. Siz məlumatları hər birinin ölçüsü 1 meqabaytdan çox olmayan ayrıca sənədlərə böləcəksiniz.”
Görünür, belə bir məhdudiyyət kifayət qədər motivasiya edilmiş istifadəçi bazası ilə ilk qarşılaşmadan sağ çıxmayacaq. olduğunu bilirsən. Məsələn, işdə bir yarım mindən çox təqdimatımız var və bu, Tamamilə Normaldır.
Bu məhdudiyyətlə siz verilənlər bazasındakı bir "sənədin" istifadəçinin sənəd adlandıra biləcəyi heç bir obyektə bənzəməyəcəyi faktını qəbul etməyə məcbur olacaqsınız.
"Rekursiv olaraq digər elementləri ehtiva edə bilən massivlər massivləri? Yox. Massivlər Allahın nəzərdə tutduğu kimi yalnız sabit uzunluqlu obyektləri və ya rəqəmləri ehtiva edəcək."
Beləliklə, GeoJSON-u Firestore-a yerləşdirməyə ümid edirsinizsə, bunun mümkün olmadığını görəcəksiniz. Qeyri-ölçülü heç bir şey qəbul edilə bilməz. Ümid edirəm ki, JSON daxilində Base64 və/yaxud JSON xoşunuza gəlir.
“HTTP, komanda xətti alətləri və ya idarəetmə paneli vasitəsilə JSON idxalı və ixracı? Yox. Siz yalnız Google Bulud Yaddaşına data ixrac və idxal edə biləcəksiniz. Məncə, indi belə adlanır. Mən “sən” deyəndə yalnız Layihə Sahibi etimadnaməsi olanlara müraciət edirəm. Qalan hər kəs gedib bilet yarada bilər”.
Gördüyünüz kimi, FireBase məlumat modelini təsvir etmək asandır. O, JSON açarlarını URL yolları ilə əlaqələndirən böyük bir JSON sənədini ehtiva edir. ilə yazsanız HTTP PUT в / FireBase aşağıdakılardır:
{
"hello": "world"
}
Məqalələr GET /hello geri dönəcək "world". Əsasən gözlədiyiniz kimi işləyir. FireBase obyektlərinin kolleksiyası /my-collection/:id JSON lüğətinə bərabərdir {"my-collection": {...}} məzmunu mövcud olan kökdə /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Bu, hər bir əlavənin sistemin standart həllinə malik olduğu toqquşmadan identifikatoru varsa, yaxşı işləyir.
Başqa sözlə, verilənlər bazası 100% JSON(*) uyğun gəlir və CouchDB kimi HTTP ilə əla işləyir. Ancaq əsasən siz onu veb-sockets, avtorizasiya və abunəlikləri mücərrəd edən real vaxt API vasitəsilə istifadə edirsiniz. İdarəetmə paneli həm real vaxt rejimində redaktə etməyə, həm də JSON idxal/ixrac etməyə imkan verən hər iki imkana malikdir. Əgər kodunuzda eyni şeyi etsəniz, yamaq və fərq JSON-un davamlı vəziyyətin idarə olunması ilə bağlı rutin tapşırıqların 90%-ni həll etdiyini dərk etdikdə nə qədər xüsusi kodun boşa çıxacağına təəccüblənəcəksiniz.
Firestore məlumat modeli JSON-a bənzəyir, lakin bəzi kritik yollarla fərqlənir. Mən artıq massivlərdə massivlərin olmamasını qeyd etdim. Alt kolleksiyalar üçün model, onları ehtiva edən JSON sənədindən ayrı, birinci dərəcəli konsepsiyalar olmalıdır. Bunun üçün hazır seriallaşdırma olmadığı üçün məlumatların alınması və yazılması üçün xüsusi kod yolu tələb olunur. Öz kolleksiyalarınızı emal etmək üçün öz skriptlərinizi və alətlərinizi yazmalısınız. İdarəetmə paneli yalnız bir anda bir sahədə kiçik dəyişikliklər etməyə imkan verir və idxal/ixrac imkanlarına malik deyil.
Onlar real vaxt rejimində NoSQL verilənlər bazasını götürdülər və onu avtomatik qoşulma və ayrıca qeyri-JSON sütunu ilə yavaş qeyri-SQL-ə çevirdilər. GraftQL kimi bir şey.
İsti Java
Əgər Firestore daha etibarlı və miqyaslı olmalı idisə, istehza ondadır ki, adi tərtibatçı qutudan kənarda FireBase seçməkdən daha az etibarlı həll yolu tapacaq. Grumpy Database Administratorunun ehtiyac duyduğu proqram növü məhsulun yaxşı olacağı güman edilən yer üçün sadəcə qeyri-real olan səy və istedad səviyyəsini tələb edir. Bu, heç bir inkişaf alətləri və oyunçu olmadıqda HTML5 Canvas-ın ümumiyyətlə Flash-ı əvəz etməməsinə bənzəyir. Üstəlik, Firestore verilənlərin təmizliyi və steril təsdiqləmə arzusundadır ki, bu da sadəcə orta biznes istifadəçisi ilə uyğun gəlmir. işləməyi sevir: onun üçün hər şey isteğe bağlıdır, çünki sona qədər hər şey qaralamadır.
FireBase-in əsas çatışmazlığı odur ki, müştəri öz vaxtından bir neçə il əvvəl yaradılıb, əksər veb tərtibatçılar dəyişməzlik haqqında bilmirdilər. Buna görə FireBase məlumatı dəyişdirəcəyinizi güman edir və buna görə də istifadəçi tərəfindən təmin edilən dəyişməzlikdən istifadə etmir. Bundan əlavə, istifadəçiyə ötürdüyü snapshotlardakı məlumatları təkrar istifadə etmir, bu da fərqi daha da çətinləşdirir. Böyük sənədlər üçün onun dəyişkən fərqə əsaslanan əməliyyat mexanizmi sadəcə qeyri-adekvatdır. Uşaqlar, bizdə artıq var WeakMap JavaScript-də. Rahatdır.
Məlumatlara istədiyiniz formanı verirsinizsə və ağacları çox həcmli etmirsinizsə, bu problemdən qaçınmaq olar. Ancaq mənə maraqlıdır ki, tərtibatçılar verilənlər bazası dizaynı ilə bağlı bəzi ciddi praktik məsləhətlərlə birlikdə dəyişməzlikdən istifadə edən həqiqətən yaxşı müştəri API-ni buraxsalar, FireBase daha maraqlı olardı. Əvəzində, sanki pozulmamış şeyi düzəltməyə çalışırdılar və bu, onu daha da pisləşdirirdi.
Firestore-un yaradılmasının bütün məntiqini bilmirəm. Qara qutunun içərisində yaranan motivlər haqqında spekulyasiya etmək də əyləncənin bir hissəsidir. Son dərəcə oxşar, lakin müqayisə olunmayan iki verilənlər bazasının bu cür üst-üstə düşməsi olduqca nadirdir. Sanki kimsə fikirləşdi: "Firebase sadəcə Google Cloud-da təqlid edə biləcəyimiz bir funksiyadır", lakin real dünya tələblərini müəyyən etmək və ya bütün bu tələblərə cavab verən faydalı həllər yaratmaq konsepsiyasını hələ kəşf etməyib. “Qoy tərtibatçılar bu barədə düşünsünlər. Sadəcə UI-ni gözəlləşdirin... Daha çox atəş əlavə edə bilərsinizmi?
Məlumat strukturları ilə bağlı bir neçə şeyi başa düşürəm. Mən mütləq "hər şey bir böyük JSON ağacında" konsepsiyasını verilənlər bazasından genişmiqyaslı strukturun hər hansı hissini mücərrədləşdirmə cəhdi kimi görürəm. Proqram təminatının sadəcə olaraq hər hansı bir şübhəli məlumat strukturu fraktalının öhdəsindən gəlməsini gözləmək sadəcə ağılsızlıqdır. İşlərin nə qədər pis ola biləcəyini təsəvvür etmək belə məcburiyyətində deyiləm, mən ciddi kod yoxlamaları etmişəm və Mən sizin heç vaxt arzulamadığınız şeyləri gördüm. Amma yaxşı strukturların necə göründüyünü də bilirəm, и . Mən Firestore-un məntiqli göründüyü və onu yaradan insanların yaxşı iş gördüklərini düşündüyü bir dünya təsəvvür edə bilərəm. Amma biz bu dünyada yaşamırıq.
FireBase-in sorğu dəstəyi istənilən standarta görə zəifdir və praktiki olaraq mövcud deyil. Mütləq təkmilləşdirməyə və ya ən azı yenidən nəzərdən keçirməyə ehtiyac duyur. Lakin Firestore o qədər də yaxşı deyil, çünki o, sadə SQL-də tapılan eyni birölçülü indekslərlə məhdudlaşır. Əgər insanların xaotik məlumatlar üzərində işlədiyi sorğulara ehtiyacınız varsa, sizə tam mətnli axtarış, çox diapazonlu filtrlər və istifadəçi tərəfindən müəyyən edilmiş sifariş lazımdır. Daha yaxından təftiş edildikdə, sadə SQL-in funksiyaları öz-özünə çox məhduddur. Bundan əlavə, insanların istehsalda işlədə biləcəyi yeganə SQL sorğuları sürətli sorğulardır. Düşünülmüş məlumat strukturları ilə fərdi indeksləşdirmə həllinə ehtiyacınız olacaq. Qalan hər şey üçün, ən azı artımlı xəritə azaldılması və ya buna bənzər bir şey olmalıdır.
Bu barədə məlumat üçün Google Sənədlərdə axtarış etsəniz, ümid edirik ki, BigTable və BigQuery kimi bir şeyin istiqamətini göstərəcəksiniz. Bununla belə, bütün bu həllər o qədər sıx korporativ satış jarqonu ilə müşayiət olunur ki, siz tez geri dönüb başqa bir şey axtarmağa başlayacaqsınız.
Real vaxt verilənlər bazası ilə istədiyiniz ən son şey, idarəetmə ödənişləri üzrə insanlar tərəfindən və onlar üçün hazırlanmış bir şeydir.
(*) Bu zarafatdır, belə bir şey yoxdur .
Reklam Hüquqları haqqında
Axtarmaq sazlama layihələri, inkişaf və hostinq üçün server? Siz mütləq bizim müştərimizsiniz 🙂 Müxtəlif konfiqurasiyalı serverlər üçün gündəlik qiymətlər, anti-DDoS və Windows lisenziyaları artıq qiymətə daxildir.
Mənbə: www.habr.com