Di luar NoSQL: Kes untuk SQL yang diedarkan

Pada mulanya, terdapat fail. Kemudian terdapat pangkalan data navigasi berdasarkan fail berstruktur. Kemudian ada IMS dan CODASYL, dan sekitar 40 tahun yang lalu kami mempunyai beberapa pangkalan data hubungan pertama. Sepanjang tahun 1980-an dan 1990-an "pangkalan data" bermaksud "pangkalan data hubungan". SQL memerintah. 

Kemudian dengan semakin popularnya bahasa pengaturcaraan berorientasi objek, ada yang berpendapat solusi untuk "ketidakcocokan impedansi" bahasa berorientasi objek dan pangkalan data relasional adalah memetakan objek dalam pangkalan data. Oleh itu, kami berakhir dengan "pangkalan data berorientasikan objek." Perkara yang lucu mengenai pangkalan data objek adalah bahawa dalam banyak kes mereka pada dasarnya adalah pangkalan data biasa dengan built-in pemeta objek. Ini semakin popular dan percubaan pasar massal seterusnya adalah "NoSQL" pada tahun 2010.

Serangan ke atas SQL

NoSQL menyerang kedua-dua pangkalan data hubungan dan SQL dalam keadaan yang sama. Masalah utama kali ini ialah Internet telah menghancurkan premis asas seni bina sistem pengurusan pangkalan data relasi (RDBMS) berusia 40 tahun. Pangkalan data ini dirancang untuk menjimatkan ruang cakera berharga dan skala secara menegak. Kini terdapat terlalu banyak pengguna dan terlalu banyak untuk dikendalikan oleh satu pelayan gemuk. Pangkalan data NoSQL mengatakan bahawa jika anda mempunyai pangkalan data tanpa bergabung, tidak ada bahasa pertanyaan standard (kerana menerapkan SQL memerlukan waktu), dan tidak ada integriti data maka anda dapat membuat skala secara mendatar dan menangani volume tersebut. Ini menyelesaikan masalah skala menegak tetapi memperkenalkan masalah baru.

Dibangunkan selari dengan sistem pemprosesan transaksi dalam talian (OLTP) ini adalah jenis pangkalan data perhubungan yang disebut sistem pemprosesan analitik dalam talian (OLAP). Pangkalan data ini menyokong struktur hubungan tetapi melaksanakan pertanyaan dengan pemahaman bahawa mereka akan mengembalikan sejumlah besar data. Perniagaan pada tahun 1980-an dan 1990-an masih banyak didorong oleh pemprosesan kumpulan. Di samping itu, sistem OLAP mengembangkan kemampuan untuk pembangun dan penganalisis untuk membayangkan dan menyimpan data sebagai kubus n-dimensi. Sekiranya anda membayangkan susunan dan dimensi dua dimensi berdasarkan dua indeks sehingga pada dasarnya anda cekap seperti masa yang tetap tetapi kemudian ambil dan tambahkan dimensi lain atau yang lain sehingga anda dapat melakukan apa yang pada dasarnya adalah pencarian tiga faktor atau lebih (katakanlah penawaran, permintaan,dan bilangan pesaing) - anda dapat menganalisis dan meramalkan sesuatu dengan lebih berkesan. Membangun ini, bagaimanapun, adalah usaha yang sukar dan sangat berorientasikan kumpulan.

Pada masa yang sama seperti skala NoSQL, pangkalan data grafik muncul. Banyak perkara tidak "relasional" per se, atau tidak berdasarkan teori set dan aljabar hubungan, tetapi sebaliknya pada hubungan ibu bapa-anak atau teman-teman. Contoh klasik ialah barisan produk ke jenama produk hingga model ke komponen dalam model. Sekiranya anda ingin mengetahui "motherboard apa yang ada di komputer riba saya," anda akan mengetahui bahawa pengeluar mempunyai sumber yang rumit dan nombor jenama atau model mungkin tidak mencukupi. Sekiranya anda ingin mengetahui apa-semua motherboard digunakan dalam barisan produk, dalam SQL klasik (bukan CTE atau Common Table Expression) anda harus berjalan jadual dan mengeluarkan pertanyaan dalam pelbagai langkah. Pada mulanya, kebanyakan pangkalan data grafik sama sekali tidak merosot. Sebenarnya, banyak jenis analisis grafik dapat dilakukan tanpa benar-benar menyimpan data sebagai grafik.

Janji NoSQL ditepati dan janji ditepati

Pangkalan data NoSQL melakukan skala jauh lebih baik daripada Pangkalan Data Oracle, DB2, atau SQL Server, yang semuanya didasarkan pada reka bentuk berusia 40 tahun. Namun, setiap jenis pangkalan data NoSQL mempunyai batasan baru:

  • Kedai nilai kunci: Tidak ada carian yang lebih sederhana daripada db.get (key). Namun, sebilangan besar kes data dan penggunaan dunia tidak dapat disusun dengan cara ini. Lebih-lebih lagi, kita benar-benar bercakap mengenai strategi caching. Pencarian kunci utama cepat dalam pangkalan data mana pun; hanya dalam ingatan yang penting. Dalam kes terbaik, skala ini seperti peta hash. Walau bagaimanapun, jika anda perlu melakukan 30 perjalanan pangkalan data untuk mengumpulkan data anda atau melakukan apa-apa pertanyaan rumit - ini tidak akan berjaya. Ini kini lebih kerap dilaksanakan sebagai cache di hadapan pangkalan data lain. (Contoh: Redis.)
  • Pangkalan data dokumen: Ini mencapai popularitinya kerana mereka menggunakan JSON dan objek mudah diselaraskan ke JSON. Versi pertama pangkalan data ini tidak bergabung, dan memasukkan keseluruhan "entiti" anda ke dalam satu dokumen raksasa mempunyai kekurangannya sendiri. Tanpa jaminan transaksi, anda juga menghadapi masalah integriti data. Hari ini, beberapa pangkalan data dokumen menyokong bentuk urus niaga yang kurang mantap, tetapi ia bukanlah tahap jaminan yang sama seperti yang biasa dilakukan oleh kebanyakan orang. Juga, walaupun untuk pertanyaan mudah, selalunya lambat dari segi kependaman - walaupun jika skala lebih baik dari segi keseluruhan. (Contoh: MongoDB, Amazon DocumentDB.)
  • Kedai tiang: Ini secepat kedai nilai kunci untuk mencari dan mereka dapat menyimpan struktur data yang lebih rumit. Walau bagaimanapun, melakukan sesuatu yang kelihatan seperti gabungan di tiga jadual (dalam bahasa RDBMS) atau tiga koleksi (dalam bahasa MongoDB) paling menyakitkan. Ini sangat bagus untuk data siri masa (berikan saya semua yang berlaku antara jam 1:00 petang dan 2:00 petang).

Dan ada pangkalan data NoSQL yang lebih esoterik. Namun, apa yang dimiliki kesemua pangkalan data ini adalah kurangnya dukungan untuk simpulan pangkalan data umum dan kecenderungan untuk fokus pada "tujuan khusus." Beberapa pangkalan data NoSQL yang popular (misalnya MongoDB) menulis alat depan pangkalan data yang hebat dan alat ekosistem yang menjadikannya sangat mudah untuk digunakan oleh pemaju, tetapi membuat batasan serius dalam mesin penyimpanan mereka - belum lagi batasan daya tahan dan skalabilitas.

Piawaian pangkalan data masih penting

Salah satu perkara yang menjadikan pangkalan data hubungan menjadi dominan ialah mereka mempunyai ekosistem alat yang sama. Pertama, terdapat SQL. Walaupun dialek mungkin berbeza - sebagai pemaju atau penganalisis jika anda pergi dari SQL Server 6.5 ke Oracle 7, anda mungkin perlu menyelesaikan pertanyaan anda dan menggunakan "(+)" untuk penyambungan luar - tetapi perkara mudah berfungsi dan barang yang sukar adalah mudah. untuk menterjemahkan.

Kedua, anda mempunyai ODBC dan, kemudian, JDBC, antara lain. Hampir mana-mana alat yang dapat menyambung ke satu RDBMS (kecuali ia dibuat khusus untuk menguruskan RDBMS itu) dapat menyambung ke RDBMS lain. Terdapat banyak orang yang menyambung ke RDBMS setiap hari, dan memasukkan data ke dalam Excel untuk menganalisisnya. Saya tidak merujuk kepada Tableau atau ratusan alat lain; Saya bercakap mengenai "keibuan" Excel.

NoSQL menghilangkan standard. MongoDB tidak menggunakan SQL sebagai bahasa utama. Ketika pesaing terdekat MongoDB Couchbase mencari bahasa pertanyaan untuk menggantikan kerangka peta peta berbasis Java mereka, mereka membuat dialek SQL mereka sendiri.

Piawaian penting sama ada untuk menyokong ekosistem alat, atau kerana banyak orang yang meminta pangkalan data bukan pembangun - dan mereka tahu SQL.

GraphQL dan kebangkitan pengurusan negara

Anda tahu siapa yang mempunyai dua jempol dan hanya mahu keadaan aplikasinya masuk ke pangkalan data dan tidak peduli bagaimana? Lelaki ini. Dan ternyata seluruh generasi pemaju. GraphQL - yang tidak ada kaitan dengan pangkalan data grafik - menyimpan grafik objek anda di datastore yang mendasari. Ini membebaskan pembangun daripada bimbang tentang masalah ini.

Percubaan sebelumnya untuk ini adalah alat pemetaan hubungan-objek, atau ORM, seperti Hibernate. Mereka mengambil objek dan pada dasarnya mengubahnya menjadi SQL berdasarkan penyetelan pemetaan objek-ke-meja. Sebilangan besar generasi pertama ini sukar dikonfigurasi. Lebih-lebih lagi, kami berada pada tahap pembelajaran.

Sebilangan besar pelaksanaan GraphQL berfungsi dengan alat pemetaan relasi objek seperti Sequelize atau TypeORM. Daripada membocorkan masalah pengurusan negara di seluruh kod anda, pelaksanaan dan API GraphQL yang tersusun dengan baik akan menulis dan mengembalikan data yang relevan ketika perubahan berlaku pada grafik objek anda. Siapa, di peringkat aplikasi, yang peduli bagaimana data disimpan, sebenarnya?

Salah satu asas pangkalan data berorientasikan objek dan NoSQL adalah bahawa pemaju aplikasi harus mengetahui seluk-beluk bagaimana data disimpan dalam pangkalan data. Sememangnya sukar bagi pengembang untuk menguasai teknologi yang lebih baru, tetapi tidak sukar lagi. Kerana GraphQL menghilangkan masalah ini sama sekali.

Masukkan NewSQL atau SQL diedarkan

Google mengalami masalah pangkalan data dan menulis makalah dan kemudian implementasi yang disebut "Spanner", yang menggambarkan bagaimana pangkalan data hubungan yang diedarkan secara global akan berfungsi. Spanner mencetuskan gelombang inovasi baru dalam teknologi pangkalan data hubungan. Anda sebenarnya boleh mempunyai pangkalan data hubungan dan memilikinya tidak hanya dengan pecahan tetapi di seluruh dunia jika diperlukan. Dan kita bercakap skala dalam pengertian moden, bukan cara RAC / Streams / GoldenGate yang sering mengecewakan dan selalu rumit.

Jadi premis "menyimpan objek" dalam sistem hubungan adalah salah. Bagaimana jika masalah utama pangkalan data hubungan adalah bahagian belakang dan bukan bahagian depan? Inilah idea di sebalik pangkalan data "NewSQL" atau lebih tepat "diedarkan SQL". Ideanya adalah untuk menggabungkan pembelajaran penyimpanan NoSQL dan idea Google Spanner dengan front end RDBMS yang matang dan terbuka seperti PostgreSQL atau MySQL / MariaDB.

Apa maksudnya? Ini bermaksud anda boleh mengambil kek anda dan memakannya juga. Ini bermaksud anda boleh mempunyai beberapa nod dan skala secara mendatar - termasuk di seluruh zon ketersediaan awan. Ini bermaksud anda boleh memiliki banyak pusat data atau wilayah geografi awan - dengan satu pangkalan data. Ini bermaksud anda boleh memiliki kebolehpercayaan sejati, kumpulan pangkalan data yang tidak pernah turun sejauh pengguna berkenaan.

Sementara itu, keseluruhan ekosistem SQL masih berfungsi! Anda boleh melakukan ini tanpa membina semula keseluruhan infrastruktur IT anda. Walaupun anda mungkin bukan permainan untuk "merobek dan mengganti" RDBMS tradisional anda, kebanyakan syarikat tidak berusaha menggunakan lebih banyak Oracle. Dan yang terbaik, anda masih boleh menggunakan SQL dan semua alat anda di awan dan di seluruh dunia.