Teknik bir hikaye anlatayım.
Yıllar önce, işbirliği özelliklerinin yerleşik olduğu bir uygulama geliştiriyordum. Bu, erken dönem React ve CouchDB'nin tüm potansiyelinden yararlanan, kullanıcı dostu bir deneysel yığındı. Verileri JSON aracılığıyla gerçek zamanlı olarak senkronize etti . Şirket içinde kullanıldı ancak diğer alanlarda da geniş çapta uygulanabilirliği ve potansiyeli açıktı.
Bu teknolojiyi potansiyel müşterilere satmaya çalışırken beklenmedik bir engelle karşılaştık. Demo videoda teknolojimiz harika görünüyordu ve çalışıyordu, hiçbir sorun yoktu. Video tam olarak nasıl çalıştığını gösterdi ve hiçbir şeyi taklit etmedi. Programın kullanımına ilişkin gerçekçi bir senaryo oluşturduk ve kodladık.
Aslında bu sorun haline geldi. Demomuz tam olarak herkesin uygulamalarını simüle ettiği şekilde çalıştı. Spesifik olarak, büyük medya dosyaları olsa bile bilgiler A'dan B'ye anında aktarılıyordu. Giriş yaptıktan sonra her kullanıcı yeni girişler gördü. Uygulamayı kullanarak, köyün herhangi bir yerinde internet bağlantısı kesilse bile farklı kullanıcılar aynı projeler üzerinde net bir şekilde birlikte çalışabiliyordu. Bu, After Effects'te kesilen herhangi bir ürün videosunda örtülü olarak ima edilir.
Herkes Yenile düğmesinin ne işe yaradığını bilmesine rağmen, bizden oluşturmamızı istedikleri web uygulamalarının genellikle kendi sınırlamalarına tabi olduğunu kimse anlamadı. Ve eğer bunlara artık ihtiyaç duyulmazsa kullanıcı deneyimi tamamen farklı olacaktır. Çoğunlukla konuştukları kişilere not bırakarak "sohbet" edebildiklerini fark ettiler ve bunun örneğin Slack'ten ne kadar farklı olduğunu merak ettiler. Vay be!
Günlük senkronizasyonların tasarımı
Yazılım geliştirme konusunda deneyiminiz varsa, çoğu insanın bir arayüzün resmine bakıp onunla etkileşime girdiğinde ne yapacağını anlayamadığını hatırlamak sinir bozucu olmalı. Programın içinde olup bitenlerden bahsetmiyorum bile. Bilgi kutu gerçekleşmesi büyük ölçüde neyin olamayacağını ve neyin olmaması gerektiğini bilmenin sonucudur. Bu gerektirir Yalnızca yazılımın ne yaptığı değil, aynı zamanda bireysel parçalarının nasıl koordine edildiği ve birbirleriyle nasıl iletişim kurduğu da önemlidir.
Bunun klasik bir örneği, bir kullanıcıya bakan bir kullanıcıdır. spinner.gifişin ne zaman tamamlanacağını merak ediyor. Geliştirici, sürecin muhtemelen sıkışıp kaldığını ve gif'in ekrandan asla kaybolmayacağını fark ederdi. Bu animasyon bir işin yürütülmesini simüle eder ancak işin durumuyla ilgili değildir. Bu gibi durumlarda, bazı teknoloji uzmanları, kullanıcıların kafa karışıklığının boyutu karşısında hayrete düşerek gözlerini devirmeyi severler. Ancak dikkat edin, kaç tanesi dönen saati işaret ediyor ve onun aslında sabit olduğunu söylüyor?
Gerçek zamanlı değerin özü budur. Günümüzde gerçek zamanlı veritabanları hâlâ çok az kullanılıyor ve birçok kişi bunlara şüpheyle yaklaşıyor. Bu veritabanlarının çoğu ağırlıklı olarak NoSQL stiline yöneliyor, bu yüzden genellikle unutulması gereken Mongo tabanlı çözümleri kullanıyorlar. Ancak benim için bu, CouchDB ile çalışma konusunda rahat olmanın yanı sıra bazı bürokratların verilerle dolduramayacağı yapıları tasarlamayı öğrenmek anlamına geliyor. Zamanımı daha iyi kullandığımı düşünüyorum.
Ancak bu yazının asıl konusu bugün kullandığım şey. Kendi tercihimiz değil, kayıtsız ve körü körüne uygulanan kurumsal politikalar yüzünden. Bu nedenle, birbiriyle yakından ilişkili iki Google gerçek zamanlı veritabanı ürününün Tamamen Adil ve Tarafsız bir karşılaştırmasını sunacağım.
Her ikisinin de adında Ateş kelimesi var. Sevgiyle hatırladığım bir şey var. Benim için ikinci şey farklı bir yangın türüdür. İsimlerini söylemek için acelem yok, çünkü söylediğimde ilk büyük sorunla karşılaşacağız: isimler.
İlki denir Firebase Gerçek Zamanlı Veritabanı, ve ikinci - Firebase Bulut Firestore. İkisi de Türkiye'nin ürünü Firebase paketi Google. API'leri sırasıyla çağrılır firebase.database(…) и firebase.firestore(…).
Bu oldu çünkü Gerçek Zamanlı Veritabanı - bu sadece orijinal Firebase 2014 yılında Google tarafından satın alınmadan önce. Daha sonra Google paralel bir ürün oluşturmaya karar verdi kopyalamak Firebase, büyük veri şirketini temel alıyor ve buna bulutlu Firestore adını veriyor. Umarım henüz kafanız karışmamıştır. Hala kafanız karıştıysa endişelenmeyin, makalenin bu bölümünü kendim on kez yeniden yazdım.
Çünkü belirtmeniz gerekiyor Firebase Firebase sorusunda ve itfaiye Firebase ile ilgili bir soruda, en azından birkaç yıl önce Stack Overflow'u anlamanızı sağlamak için.
En kötü yazılım adlandırma deneyimi ödülü olsaydı, bu kesinlikle adaylardan biri olurdu. Bu isimler arasındaki Hamming mesafesi o kadar küçük ki, parmakları bir ismi yazarken kafaları başka bir ismi düşünen deneyimli mühendislerin bile kafasını karıştırıyor. Bunlar, sefil bir şekilde başarısızlığa uğrayan iyi niyetli planlardır; veritabanının yanacağı kehanetini yerine getirdiler. Ve hiç şaka yapmıyorum. Bu isimlendirme düzenini ortaya atan kişi kan, ter ve gözyaşına neden oldu.
Pyrrhic zafer
Birisi Firestore'un olduğunu düşünebilir yedek Firebase, onun yeni nesil soyundan geliyor, ancak bu yanıltıcı olur. Firestore'un Firebase'in yerine uygun bir alternatif olacağı garanti edilmez. Görünüşe göre birisi ondan ilginç olan her şeyi kesmiş ve geri kalanların çoğunu çeşitli şekillerde karıştırmış.
Ancak iki ürüne kısa bir bakış kafanızı karıştırabilir: temelde aynı API'ler aracılığıyla ve hatta aynı veritabanı oturumunda aynı şeyi yapıyor gibi görünüyorlar. Farklılıklar çok incedir ve yalnızca kapsamlı belgelerin dikkatli karşılaştırmalı incelenmesiyle ortaya çıkar. Veya Firebase'de mükemmel şekilde çalışan kodu Firestore ile çalışacak şekilde taşımaya çalıştığınızda. O zaman bile, fareyle gerçek zamanlı olarak sürükleyip bırakmayı denediğinizde veritabanı arayüzünün aydınlandığını görürsünüz. Tekrar ediyorum şaka yapmıyorum.
Firebase istemcisi, değişiklikleri arabelleğe alması ve son yazma işlemine öncelik veren güncellemeleri otomatik olarak yeniden denemesi açısından kibardır. Ancak Firestore'un belge başına kullanıcı başına saniyede 1 yazma işlemi sınırı vardır ve bu sınır sunucu tarafından uygulanır. Bununla çalışırken, yalnızca uygulamanızı oluşturmaya çalışıyor olsanız bile, bunun üstesinden gelmenin bir yolunu bulmak ve bir güncelleme hızı sınırlayıcı uygulamak size kalmıştır. Yani Firestore, gerçek zamanlı istemcisi olmayan, API kullanıyormuş gibi görünen, gerçek zamanlı bir veritabanıdır.
Burada Firestore'un varlık nedeninin ilk işaretlerini görmeye başlıyoruz. Yanılıyor olabilirim ama Google'ın yönetiminde üst düzey birisinin satın alma işleminden sonra Firebase'e baktığını ve basitçe şöyle dediğini sanıyorum: “Hayır, aman Tanrım, hayır. Bu kabul edilemez. Sadece benim liderliğimde değil."
Odasından çıktı ve şunları söyledi:
“Büyük bir JSON belgesi mi? HAYIR. Verileri, her biri 1 megabaytı geçmeyecek şekilde ayrı belgelere böleceksiniz.”
Öyle görünüyor ki, böyle bir sınırlama, yeterince motive olmuş bir kullanıcı tabanıyla ilk karşılaşmada hayatta kalamayacak. Öyle olduğunu biliyorsun. Mesela iş yerinde bir buçuk binden fazla sunumumuz var ve bu Tamamen Normal.
Bu sınırlamayla birlikte, veritabanındaki bir "belgenin", kullanıcının belge diyebileceği hiçbir nesneye benzemeyeceği gerçeğini kabul etmek zorunda kalacaksınız.
"Başka öğeleri yinelemeli olarak içerebilen dizi dizileri mi? HAYIR. Diziler, Tanrı'nın amaçladığı gibi yalnızca sabit uzunlukta nesneler veya sayılar içerecektir."
Yani GeoJSON'u Firestore'unuza yerleştirmeyi umuyorsanız bunun mümkün olmadığını göreceksiniz. Tek boyutlu olmayan hiçbir şey kabul edilemez. Umarım JSON içindeki Base64 ve/veya JSON'u beğenirsiniz.
“JSON'u HTTP, komut satırı araçları veya yönetici paneli aracılığıyla içe ve dışa aktarmak mı istiyorsunuz? HAYIR. Verileri yalnızca Google Cloud Storage'a aktarıp aktarabileceksiniz. Artık buna böyle deniyor sanırım. Ve “siz” dediğimde yalnızca Proje Sahibi kimlik bilgilerine sahip olanlara hitap ediyorum. Herkes gidip bilet oluşturabilir."
Gördüğünüz gibi FireBase veri modelini açıklamak kolaydır. JSON anahtarlarını URL yollarıyla ilişkilendiren büyük bir JSON belgesi içerir. Eğer ile yazarsan HTTP PUT в / FireBase şudur:
{
"hello": "world"
}
O GET /hello dönecek "world". Temel olarak tam olarak beklediğiniz gibi çalışır. FireBase nesnelerinin toplanması /my-collection/:id JSON sözlüğüne eşdeğer {"my-collection": {...}} içeriği mevcut olan kökte /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Her bir kesici parçanın, sistemin standart bir çözümü olan çarpışmasız bir kimliği varsa, bu iyi çalışır.
Başka bir deyişle, veritabanı %100 JSON(*) uyumludur ve CouchDB gibi HTTP ile harika çalışır. Ancak temel olarak bunu web soketlerini, yetkilendirmeyi ve abonelikleri soyutlayan gerçek zamanlı bir API aracılığıyla kullanırsınız. Yönetici paneli, hem gerçek zamanlı düzenlemeye hem de JSON içe/dışa aktarımına olanak tanıyan her iki özelliğe de sahiptir. Kodunuzda da aynısını yaparsanız, yama ve diff JSON'un kalıcı durumu işlemeye ilişkin rutin görevlerin %90'ını çözdüğünü fark ettiğinizde ne kadar özel kodun boşa harcanacağına şaşıracaksınız.
Firestore veri modeli JSON'a benzer ancak bazı önemli noktalarda farklılık gösterir. Dizilerin içindeki dizilerin eksikliğinden daha önce bahsetmiştim. Alt koleksiyonların modeli, onları içeren JSON belgesinden ayrı olarak birinci sınıf konseptler olmalarıdır. Bunun için hazır bir serileştirme olmadığından veri almak ve yazmak için özel bir kod yoluna ihtiyaç vardır. Kendi koleksiyonlarınızı işlemek için kendi komut dosyalarınızı ve araçlarınızı yazmanız gerekir. Yönetici paneli aynı anda yalnızca bir alanda küçük değişiklikler yapmanıza izin verir ve içe/dışa aktarma yeteneklerine sahip değildir.
Gerçek zamanlı bir NoSQL veritabanını aldılar ve onu otomatik birleştirme ve JSON olmayan ayrı bir sütun ile yavaş, SQL olmayan bir veritabanına dönüştürdüler. GraftQL'e benzer bir şey.
Sıcak Java
Firestore'un daha güvenilir ve ölçeklenebilir olması gerekiyorsa ironik olan şu ki, ortalama bir geliştirici, FireBase'i kutudan çıkar çıkmaz seçmekten daha az güvenilir bir çözümle sonuçlanacaktır. Huysuz Veritabanı Yöneticisinin ihtiyaç duyduğu yazılım türü, ürünün iyi olması gereken niş için kesinlikle gerçekçi olmayan bir düzeyde çaba ve yetenek gerektirir. Bu, geliştirme araçları ve oynatıcı olmadığında HTML5 Canvas'ın Flash'ın yerini alamayacağına benzer. Üstelik Firestore, ortalama iş kullanıcısının çalışma biçimiyle hiç uyuşmayan veri saflığı ve steril doğrulama arzusuna saplanmış durumda. çalışmayı seviyor: Onun için her şey isteğe bağlıdır, çünkü sonuna kadar her şey bir taslaktır.
FireBase'in ana dezavantajı, istemcinin, çoğu web geliştiricisinin değişmezliği bilmeden birkaç yıl önce oluşturulmuş olmasıdır. Bu nedenle FireBase, verileri değiştireceğinizi varsayar ve bu nedenle kullanıcı tarafından sağlanan değişmezlik avantajından yararlanmaz. Ayrıca kullanıcıya ilettiği anlık görüntülerdeki verileri yeniden kullanmaz, bu da diff'i çok daha zorlaştırır. Büyük belgeler için değişken fark tabanlı işlem mekanizması kesinlikle yetersizdir. Arkadaşlar zaten var WeakMap JavaScript'te. O konforlu.
Verilere istediğiniz şekli verirseniz ve ağaçları çok hacimli yapmazsanız bu sorunun üstesinden gelinebilir. Ancak geliştiriciler, veritabanı tasarımıyla ilgili bazı ciddi pratik tavsiyelerle birlikte değişmezliği kullanan gerçekten iyi bir istemci API'si yayınlasa FireBase'in çok daha ilginç olup olmayacağını merak ediyorum. Bunun yerine, bozuk olmayan şeyi onarmaya çalışıyor gibiydiler ve bu da durumu daha da kötüleştirdi.
Firestore'un yaratılmasının ardındaki mantığın tamamını bilmiyorum. Kara kutunun içinde ortaya çıkan nedenler hakkında spekülasyon yapmak da eğlencenin bir parçası. Son derece benzer ancak kıyaslanamaz iki veri tabanının bu şekilde yan yana gelmesi oldukça nadirdir. Sanki birisi şunu düşünmüş gibi: "Firebase yalnızca Google Cloud'da taklit edebileceğimiz bir işlev", ancak gerçek dünyadaki gereksinimleri belirleme veya bu gereksinimlerin tümünü karşılayan kullanışlı çözümler oluşturma kavramını henüz keşfetmedi. “Geliştiricilerin bunu düşünmesine izin verin. Sadece kullanıcı arayüzünü güzelleştirin... Daha fazla ateş ekleyebilir misiniz?"
Veri yapılarıyla ilgili birkaç şeyi anlıyorum. Kesinlikle "her şey büyük bir JSON ağacında" konseptini, büyük ölçekli yapı hissini veri tabanından soyutlama girişimi olarak görüyorum. Yazılımın herhangi bir şüpheli veri yapısı fraktalıyla başa çıkmasını beklemek tamamen deliliktir. İşlerin ne kadar kötü olabileceğini hayal etmeme bile gerek yok, sıkı kod denetimleri yaptım ve Sizlerin asla hayal edemeyeceği şeyler gördüm. Ama aynı zamanda iyi yapıların neye benzediğini de biliyorum. и . Firestore'un mantıklı görüneceği ve onu yaratan insanların iyi bir iş çıkardıklarını düşünecekleri bir dünya hayal edebiliyorum. Ama biz bu dünyada yaşamıyoruz.
FireBase'in sorgu desteği tüm standartlara göre zayıftır ve neredeyse hiç yoktur. Kesinlikle iyileştirilmesi veya en azından revizyona ihtiyacı var. Ancak Firestore çok daha iyi değil çünkü düz SQL'de bulunan aynı tek boyutlu dizinlerle sınırlı. İnsanların kaotik veriler üzerinde çalıştırdığı sorgulara ihtiyacınız varsa, tam metin aramaya, çok aralıklı filtrelere ve özel kullanıcı tanımlı sıralamaya ihtiyacınız vardır. Daha yakından incelendiğinde, düz SQL'in fonksiyonlarının kendi başına çok sınırlı olduğu görülür. Ek olarak, insanların üretimde çalıştırabileceği tek SQL sorguları hızlı sorgulardır. İyi düşünülmüş veri yapılarına sahip özel bir indeksleme çözümüne ihtiyacınız olacak. Diğer her şey için, en azından artımlı harita azaltma veya benzeri bir şey olmalıdır.
Bununla ilgili bilgi için Google Dokümanlar'da arama yaparsanız BigTable ve BigQuery gibi bir şeye yönlendirileceğinizi umarız. Ancak tüm bu çözümlere o kadar yoğun kurumsal satış jargonu eşlik ediyor ki, hemen geri dönüp başka bir şey aramaya başlayacaksınız.
Gerçek zamanlı bir veritabanıyla isteyeceğiniz son şey, yönetim maaş skalasındaki kişiler tarafından ve onlar için yapılmış bir şeydir.
(*) Bu bir şakadır, diye bir şey yoktur. .
Reklam gibi
Arıyor projelerde hata ayıklamak için, geliştirme ve barındırma için bir sunucu? Kesinlikle bizim müşterimizsiniz 🙂 Çeşitli konfigürasyonlardaki sunucular, anti-DDoS ve Windows lisansları için günlük fiyatlandırma halihazırda fiyata dahildir.
Kaynak: habr.com