Biar saya cerita teknikal.
Bertahun-tahun yang lalu, saya sedang membangunkan aplikasi dengan ciri kerjasama terbina di dalamnya. Ia adalah timbunan percubaan mesra pengguna yang memanfaatkan potensi penuh React awal dan CouchDB. Ia menyegerakkan data dalam masa nyata melalui JSON . Ia digunakan secara dalaman dalam syarikat, tetapi kebolehgunaan dan potensinya yang luas di kawasan lain adalah jelas.
Semasa cuba menjual teknologi ini kepada bakal pelanggan, kami menghadapi halangan yang tidak dijangka. Dalam video demo, teknologi kami kelihatan dan berfungsi dengan baik, tiada masalah di sana. Video itu menunjukkan dengan tepat cara ia berfungsi dan tidak meniru apa-apa. Kami menghasilkan dan mengodkan senario realistik untuk menggunakan program ini.
Malah, ini menjadi masalah. Demo kami berfungsi sama seperti orang lain mensimulasikan aplikasi mereka. Khususnya, maklumat telah dipindahkan serta-merta dari A ke B, walaupun ia adalah fail media yang besar. Selepas log masuk, setiap pengguna melihat entri baharu. Menggunakan aplikasi itu, pengguna yang berbeza boleh bekerjasama dengan jelas pada projek yang sama, walaupun sambungan Internet terputus di suatu tempat di kampung. Ini secara tersirat tersirat dalam mana-mana potongan video produk dalam After Effects.
Walaupun semua orang tahu untuk apa butang Muat Semula, tiada siapa yang benar-benar memahami bahawa aplikasi web yang mereka minta kami bina biasanya tertakluk kepada batasan mereka sendiri. Dan jika mereka tidak lagi diperlukan, pengalaman pengguna akan berbeza sama sekali. Mereka kebanyakannya menyedari bahawa mereka boleh "berbual" dengan meninggalkan nota untuk orang yang mereka bercakap, jadi mereka tertanya-tanya bagaimana ini berbeza daripada, sebagai contoh, Slack. Fuh!
Reka bentuk penyegerakan setiap hari
Jika anda mempunyai pengalaman dalam pembangunan perisian, ia pasti menyakitkan hati untuk mengingati bahawa kebanyakan orang tidak boleh hanya melihat gambar antara muka dan memahami apa yang akan dilakukan apabila berinteraksi dengannya. Apatah lagi apa yang berlaku di dalam program itu sendiri. Pengetahuan itu boleh berlaku sebahagian besarnya adalah hasil daripada mengetahui apa yang tidak boleh berlaku dan apa yang tidak sepatutnya berlaku. Ini memerlukan bukan sahaja perkara yang dilakukan oleh perisian, tetapi juga bagaimana bahagian individunya diselaraskan dan berkomunikasi antara satu sama lain.
Contoh klasik ini ialah pengguna merenung a spinner.gif, tertanya-tanya bila kerja akhirnya akan siap. Pembangun akan menyedari bahawa proses itu mungkin tersekat dan bahawa gif tidak akan hilang dari skrin. Animasi ini mensimulasikan pelaksanaan kerja, tetapi tidak berkaitan dengan keadaannya. Dalam kes sedemikian, sesetengah juruteknik suka melelapkan mata, kagum dengan tahap kekeliruan pengguna. Walau bagaimanapun, perhatikan berapa ramai daripada mereka menunjuk ke jam berputar dan mengatakan bahawa ia sebenarnya tidak bergerak?
Inilah intipati nilai masa nyata. Hari ini, pangkalan data masa nyata masih kurang digunakan dan ramai orang melihatnya dengan curiga. Kebanyakan pangkalan data ini banyak bersandar pada gaya NoSQL, itulah sebabnya mereka biasanya menggunakan penyelesaian berasaskan Mongo, yang paling baik dilupakan. Walau bagaimanapun, bagi saya ini bermakna menjadi selesa bekerja dengan CouchDB, serta belajar untuk mereka bentuk struktur yang lebih daripada sekadar beberapa birokrat boleh mengisi dengan data. Saya rasa saya menggunakan masa saya dengan lebih baik.
Tetapi topik sebenar siaran ini adalah apa yang saya gunakan hari ini. Bukan dengan pilihan, tetapi kerana dasar korporat yang diterapkan secara membuta tuli. Oleh itu, saya akan memberikan perbandingan yang Adil dan Tidak Berat sebelah sepenuhnya bagi dua produk pangkalan data masa nyata Google yang berkait rapat.
Kedua-duanya mempunyai perkataan Api dalam nama mereka. Satu perkara yang saya ingat. Perkara kedua bagi saya ialah jenis api yang berbeza. Saya tidak tergesa-gesa untuk menyebut nama mereka, kerana apabila saya melakukannya, kita akan menghadapi masalah besar pertama: nama.
Yang pertama dipanggil Pangkalan Data Masa Nyata Firebase, dan kedua - Firebase Cloud Firestore. Kedua-duanya adalah produk dari Suite Firebase Google. API mereka dipanggil masing-masing firebase.database(β¦) ΠΈ firebase.firestore(β¦).
Ini berlaku kerana Pangkalan Data Masa Nyata - ia hanya yang asal Firebase sebelum pembeliannya oleh Google pada tahun 2014. Kemudian Google memutuskan untuk mencipta sebagai produk selari salinan Firebase berdasarkan syarikat data besar, dan memanggilnya Firestore dengan awan. Saya harap anda tidak keliru lagi. Jika anda masih keliru, jangan risau, saya sendiri telah menulis semula bahagian artikel ini sebanyak sepuluh kali.
Kerana anda perlu menunjukkan Firebase dalam soalan Firebase, dan kedai api dalam soalan tentang Firebase, sekurang-kurangnya untuk membuat anda memahami beberapa tahun yang lalu tentang Stack Overflow.
Sekiranya terdapat anugerah untuk pengalaman penamaan perisian terburuk, ini pastinya akan menjadi salah satu pesaing. Jarak Hamming antara nama-nama ini sangat kecil sehingga mengelirukan walaupun jurutera berpengalaman yang jari mereka menaip satu nama sambil kepala mereka memikirkan nama lain. Ini adalah rancangan berniat baik yang gagal dengan teruk; mereka memenuhi ramalan bahawa pangkalan data akan terbakar. Dan saya tidak bergurau sama sekali. Orang yang mencipta skema penamaan ini menyebabkan darah, peluh dan air mata.
Kemenangan pyrrhic
Seseorang akan berfikir bahawa Firestore adalah penggantian Firebase, keturunan generasi seterusnya, tetapi itu akan mengelirukan. Firestore tidak dijamin sebagai pengganti yang sesuai untuk Firebase. Nampaknya seseorang memotong semua yang menarik daripadanya, dan mengelirukan kebanyakan yang lain dalam pelbagai cara.
Walau bagaimanapun, sepintas lalu pada kedua-dua produk mungkin mengelirukan anda: mereka nampaknya melakukan perkara yang sama, melalui API yang sama dan juga dalam sesi pangkalan data yang sama. Perbezaannya adalah halus dan didedahkan hanya melalui kajian perbandingan yang teliti terhadap dokumentasi yang luas. Atau apabila anda cuba mengalihkan kod yang berfungsi dengan sempurna pada Firebase supaya ia berfungsi dengan Firestore. Walaupun begitu anda mendapati bahawa antara muka pangkalan data menyala sebaik sahaja anda cuba menyeret dan melepaskan dengan tetikus dalam masa nyata. Saya ulang, saya tidak bergurau.
Klien Firebase bersikap sopan dalam erti kata ia menimbal perubahan dan mencuba semula kemas kini secara automatik yang memberi keutamaan kepada operasi tulis terakhir. Walau bagaimanapun, Firestore mempunyai had 1 operasi tulis bagi setiap dokumen bagi setiap pengguna sesaat, dan had ini dikuatkuasakan oleh pelayan. Apabila bekerja dengannya, terpulang kepada anda untuk mencari jalan mengatasinya dan melaksanakan pengehad kadar kemas kini, walaupun semasa anda baru cuba membina aplikasi anda. Iaitu, Firestore ialah pangkalan data masa nyata tanpa pelanggan masa nyata, yang menyamar sebagai satu menggunakan API.
Di sini kita mula melihat tanda-tanda pertama raison d'Γͺtre Firestore. Saya mungkin salah, tetapi saya mengesyaki bahawa seseorang yang tinggi dalam pengurusan Google melihat Firebase selepas pembelian dan hanya berkata, βTidak, ya Tuhanku, tidak. Ini tidak boleh diterima. Cuma bukan di bawah pimpinan saya."
Dia muncul dari biliknya dan menyatakan:
"Satu dokumen JSON yang besar? Tidak. Anda akan membahagikan data kepada dokumen berasingan, yang setiap satu daripadanya tidak lebih daripada 1 megabait dalam saiz."
Nampaknya had sedemikian tidak akan bertahan pada pertemuan pertama dengan mana-mana pangkalan pengguna yang cukup bermotivasi. Anda tahu ia adalah. Di tempat kerja, sebagai contoh, kami mempunyai lebih daripada satu setengah ribu pembentangan, dan ini adalah Normal Sepenuhnya.
Dengan pengehadan ini, anda akan dipaksa untuk menerima hakikat bahawa satu "dokumen" dalam pangkalan data tidak akan menyerupai mana-mana objek yang pengguna mungkin memanggil dokumen.
"Susun atur tatasusunan yang boleh mengandungi unsur-unsur lain secara rekursif? Tidak. Tatasusunan hanya akan mengandungi objek atau nombor dengan panjang tetap, seperti yang Tuhan maksudkan."
Jadi jika anda berharap untuk meletakkan GeoJSON ke dalam Firestore anda, anda akan mendapati bahawa ini tidak mungkin. Tiada apa-apa yang bukan satu dimensi boleh diterima. Saya harap anda suka Base64 dan/atau JSON dalam JSON.
"Import dan eksport JSON melalui HTTP, alat baris arahan atau panel pentadbir? Tidak. Anda hanya akan dapat mengeksport dan mengimport data ke Storan Awan Google. Itulah yang dipanggil sekarang, saya fikir. Dan apabila saya berkata "anda," saya hanya merujuk kepada mereka yang mempunyai kelayakan Pemilik Projek. Orang lain boleh pergi dan buat tiket."
Seperti yang anda lihat, model data FireBase mudah diterangkan. Ia mengandungi satu dokumen JSON besar yang mengaitkan kunci JSON dengan laluan URL. Jika anda menulis dengan HTTP PUT Π² / FireBase ialah yang berikut:
{
"hello": "world"
}
yang GET /hello akan kembali "world". Pada asasnya ia berfungsi seperti yang anda jangkakan. Koleksi objek FireBase /my-collection/:id bersamaan dengan kamus JSON {"my-collection": {...}} dalam akar, yang kandungannya tersedia dalam /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Ini berfungsi dengan baik jika setiap sisipan mempunyai ID bebas perlanggaran, yang mana sistem mempunyai penyelesaian standard.
Dalam erti kata lain, pangkalan data adalah 100% JSON(*) serasi dan berfungsi hebat dengan HTTP, seperti CouchDB. Tetapi pada asasnya anda menggunakannya melalui API masa nyata yang mengabstraksi soket web, kebenaran dan langganan. Panel pentadbir mempunyai kedua-dua keupayaan, membenarkan pengeditan masa nyata dan import/eksport JSON. Jika anda melakukan perkara yang sama dalam kod anda, anda akan terkejut melihat betapa banyak kod khusus akan dibazirkan apabila anda menyedari bahawa tampalan dan perbezaan JSON menyelesaikan 90% tugas rutin mengendalikan keadaan berterusan.
Model data Firestore adalah serupa dengan JSON, tetapi berbeza dalam beberapa cara kritikal. Saya telah menyebut kekurangan tatasusunan dalam tatasusunan. Model untuk subkoleksi ialah konsep kelas pertama, berasingan daripada dokumen JSON yang mengandunginya. Memandangkan tiada siri siap sedia untuk ini, laluan kod khusus diperlukan untuk mendapatkan dan menulis data. Untuk memproses koleksi anda sendiri, anda perlu menulis skrip dan alatan anda sendiri. Panel pentadbir hanya membenarkan anda membuat perubahan kecil satu medan pada satu masa, dan tidak mempunyai keupayaan import/eksport.
Mereka mengambil pangkalan data NoSQL masa nyata dan mengubahnya menjadi bukan SQL yang perlahan dengan auto-cantum dan lajur bukan JSON yang berasingan. Sesuatu seperti GraftQL.
Jawa panas
Jika Firestore sepatutnya lebih dipercayai dan berskala, maka ironinya ialah rata-rata pembangun akan mendapat penyelesaian yang kurang boleh dipercayai daripada memilih FireBase di luar kotak. Jenis perisian yang diperlukan oleh Pentadbir Pangkalan Data Grumpy memerlukan tahap usaha dan bakat berkaliber yang tidak realistik untuk niche produk yang sepatutnya mahir. Ini serupa dengan cara HTML5 Canvas bukan pengganti Flash sama sekali jika tiada alat pembangunan dan pemain. Lebih-lebih lagi, Firestore terperangkap dalam keinginan untuk ketulenan data dan pengesahan steril yang tidak sejajar dengan cara pengguna perniagaan biasa. suka bekerja: baginya segala-galanya adalah pilihan, kerana sehingga akhir semuanya adalah draf.
Kelemahan utama FireBase ialah pelanggan telah dicipta beberapa tahun lebih awal daripada masanya, sebelum kebanyakan pembangun web mengetahui tentang ketidakbolehubah. Oleh sebab itu, FireBase menganggap bahawa anda akan menukar data dan oleh itu tidak mengambil kesempatan daripada kebolehubahan yang disediakan pengguna. Selain itu, ia tidak menggunakan semula data dalam syot kilat yang dihantar kepada pengguna, yang menjadikan perbezaan lebih sukar. Untuk dokumen yang besar, mekanisme transaksi berasaskan perbezaan boleh ubahnya adalah tidak mencukupi. Kawan-kawan, kita sudah ada WeakMap dalam JavaScript. Ia selesa.
Jika anda memberikan data bentuk yang diingini dan tidak membuat pokok terlalu besar, maka masalah ini boleh dielakkan. Tetapi saya ingin tahu jika FireBase akan menjadi lebih menarik jika pembangun mengeluarkan API pelanggan yang benar-benar baik yang menggunakan kebolehubahan digabungkan dengan beberapa nasihat praktikal yang serius mengenai reka bentuk pangkalan data. Sebaliknya, mereka nampaknya cuba membaiki apa yang tidak rosak, dan itu memburukkan lagi keadaan.
Saya tidak tahu semua logik di sebalik penciptaan Firestore. Berspekulasi tentang motif yang timbul di dalam kotak hitam juga merupakan sebahagian daripada keseronokan. Penjajaran dua pangkalan data yang sangat serupa tetapi tidak dapat dibandingkan ini agak jarang berlaku. Ia seperti seseorang berfikir: "Firebase hanyalah fungsi yang boleh kita contohi dalam Google Cloud", tetapi masih belum menemui konsep mengenal pasti keperluan dunia sebenar atau mencipta penyelesaian berguna yang memenuhi semua keperluan tersebut. βBiar pemaju memikirkannya. Cantikkan UI saja... Boleh tambah api lagi?β
Saya memahami beberapa perkara tentang struktur data. Saya pasti melihat konsep "segala-galanya dalam satu pokok JSON yang besar" sebagai percubaan untuk mengabstrakkan sebarang bentuk struktur berskala besar daripada pangkalan data. Mengharapkan perisian untuk mengatasi mana-mana fraktal struktur data yang meragukan adalah tidak masuk akal. Saya tidak perlu membayangkan betapa buruknya perkara yang boleh berlaku, saya telah melakukan audit kod yang ketat dan Saya melihat perkara yang tidak pernah anda impikan. Tetapi saya juga tahu bagaimana rupa struktur yang baik, ΠΈ . Saya boleh bayangkan dunia di mana Firestore kelihatan logik dan orang yang menciptanya akan fikir mereka melakukan kerja yang baik. Tetapi kita tidak hidup di dunia ini.
Sokongan pertanyaan FireBase adalah lemah mengikut mana-mana standard dan boleh dikatakan tidak wujud. Ia pasti memerlukan penambahbaikan atau sekurang-kurangnya semakan. Tetapi Firestore tidak jauh lebih baik kerana ia terhad kepada indeks satu dimensi yang sama yang terdapat dalam SQL biasa. Jika anda memerlukan pertanyaan yang dijalankan oleh orang pada data huru-hara, anda memerlukan carian teks penuh, penapis berbilang julat dan susunan tersuai yang ditentukan pengguna. Setelah diperiksa lebih dekat, fungsi SQL biasa adalah terlalu terhad dengan sendirinya. Selain itu, satu-satunya pertanyaan SQL yang orang boleh jalankan dalam pengeluaran ialah pertanyaan pantas. Anda memerlukan penyelesaian pengindeksan tersuai dengan struktur data pintar. Untuk semua yang lain, sekurang-kurangnya perlu ada pengurangan peta tambahan atau sesuatu yang serupa.
Jika anda mencari Google Docs untuk mendapatkan maklumat tentang perkara ini, anda diharapkan akan dihalakan ke arah sesuatu seperti BigTable dan BigQuery. Walau bagaimanapun, semua penyelesaian ini disertakan dengan jargon jualan korporat yang begitu padat sehingga anda akan segera berpatah balik dan mula mencari sesuatu yang lain.
Perkara terakhir yang anda mahukan dengan pangkalan data masa nyata ialah sesuatu yang dibuat oleh dan untuk orang dalam skala gaji pengurusan.
(*) Ini adalah gurauan, tidak ada perkara seperti itu .
Sebagai iklan
Mencari untuk projek penyahpepijatan, pelayan untuk pembangunan dan pengehosan? Anda pasti pelanggan kami π Harga harian untuk pelayan pelbagai konfigurasi, lesen anti-DDoS dan Windows sudah termasuk dalam harga.
Sumber: www.habr.com