Ciri-ciri pangkalan data NoSQL

2.1 Kemunculan istilah NoSQL

Baru-baru ini, istilah "NoSQL" telah menjadi sangat bergaya dan popular, semua jenis penyelesaian perisian sedang giat dibangunkan dan dipromosikan di bawah tanda ini. NoSQL telah menjadi sinonim dengan sejumlah besar data, skalabiliti linear, kluster, toleransi kesalahan, bukan hubungan. Walau bagaimanapun, beberapa orang mempunyai pemahaman yang jelas tentang apa itu storan NoSQL, cara istilah itu muncul dan ciri umum yang mereka ada. Mari cuba mengisi jurang ini.

Perkara yang paling menarik tentang istilah ini ialah walaupun pada hakikatnya ia pertama kali digunakan pada akhir 90-an, ia hanya memperoleh makna sebenar dalam bentuk yang digunakan sekarang pada pertengahan 2009. Pada mulanya, ini adalah nama terbuka -sumber pangkalan data yang dicipta oleh Carlo Strozzi, yang menyimpan semua data sebagai fail ASCII dan menggunakan skrip shell dan bukannya SQL untuk mengakses data. Ia tiada kaitan dengan "NoSQL" dalam bentuk semasanya.

Pada Jun 2009 Johan Oskarsson menganjurkan mesyuarat di San Francisco untuk membincangkan trend baharu dalam pasaran penyimpanan dan pemprosesan IT. Dorongan utama untuk mesyuarat itu ialah produk sumber terbuka baharu seperti BigTable dan Dynamo. Untuk tanda terang untuk mesyuarat, adalah perlu untuk mencari istilah yang luas dan ringkas yang sesuai dengan sempurna ke dalam hashtag Twitter. Salah satu istilah ini telah dicadangkan oleh Eric Evans dari RackSpace - "NoSQL". Istilah ini dirancang untuk satu pertemuan sahaja dan tidak mempunyai beban semantik yang mendalam, tetapi kebetulan ia merebak ke seluruh rangkaian global seperti iklan viral dan menjadi nama de facto bagi keseluruhan trend dalam industri IT. By the way, Voldemort (klon Amazon Dynamo), Cassandra, Hbase (analog Google BigTable), Hypertable, CouchDB, MongoDB bercakap pada persidangan itu.

Perlu ditekankan sekali lagi bahawa istilah "NoSQL" adalah asalnya spontan sepenuhnya dan tidak mempunyai definisi yang diterima umum atau institusi saintifik di belakangnya. Nama ini lebih mencirikan vektor pembangunan IT dari pangkalan data hubungan. Ia bermaksud Bukan Sahaja SQL, walaupun terdapat penyokong definisi langsung No SQL. Pramod Sadalaj dan Martin Fowler cuba mengumpulkan dan mensistemkan pengetahuan tentang dunia NoSQL dalam buku terbaru mereka "NoSQL Distilled".

2.2 Ciri-ciri asas pangkalan data NoSQL

Terdapat beberapa ciri umum untuk semua NoSQL, kerana banyak sistem heterogen kini tersembunyi di bawah label NoSQL (mungkin senarai paling lengkap boleh didapati di http://nosql-database.org/). Banyak ciri khas hanya untuk pangkalan data NoSQL tertentu, saya pasti akan menyebutnya apabila menyenaraikan.

1. Tiada SQL digunakan

Maksud saya ANSI SQL DML, kerana banyak pangkalan data cuba menggunakan bahasa pertanyaan yang serupa dengan sintaks kegemaran yang terkenal, tetapi tiada siapa yang berjaya melaksanakannya sepenuhnya dan tidak mungkin berjaya. Walaupun terdapat khabar angin yang cuba melaksanakan SQL, contohnya dalam hadup ( http://www.drawntoscalehq.com/ dan http://www.hadapt.com/ ).

2. Tidak berstruktur (tanpa skema)

Maksudnya ialah dalam pangkalan data NoSQL, tidak seperti pangkalan data hubungan, struktur data tidak dikawal (atau ditaip lemah, jika kita melukis analogi dengan bahasa pengaturcaraan) - anda boleh menambah medan sewenang-wenangnya dalam baris atau dokumen yang berasingan tanpa mengubah struktur secara deklaratif terlebih dahulu daripada keseluruhan meja. Oleh itu, jika terdapat keperluan untuk menukar model data, maka satu-satunya tindakan yang mencukupi adalah untuk mencerminkan perubahan dalam kod aplikasi.

Sebagai contoh, apabila menamakan semula medan dalam MongoDB:

BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"

Jika kita menukar logik aplikasi, maka kita mengharapkan medan baru juga apabila membaca. Tetapi disebabkan kekurangan skema data, medan totalSum tiada daripada objek Pesanan lain yang sedia ada. Dalam situasi ini, terdapat dua pilihan untuk tindakan selanjutnya.

Yang pertama ialah merangkak semua dokumen dan mengemas kini medan ini dalam semua dokumen sedia ada. Disebabkan oleh jumlah data, proses ini berlaku tanpa sebarang kunci (setanding dengan perintah lajur tukar nama semula jadual), jadi semasa kemas kini, data sedia ada boleh dibaca oleh proses lain. Oleh itu, pilihan kedua - menyemak kod aplikasi - tidak dapat dielakkan:

BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum  == null)
totalSum = order.getDouble("totalSum"); // This is the updated model

Dan apabila kami merakam semula, kami akan menulis medan ini ke pangkalan data dalam format baharu.

Akibat yang menyenangkan daripada ketiadaan skema ialah kecekapan bekerja dengan data yang jarang. Jika satu dokumen mempunyai medan date_published, dan yang kedua tidak, maka tiada medan date_published kosong akan dibuat untuk yang kedua. Ini, pada dasarnya, adalah logik, tetapi contoh yang kurang jelas ialah pangkalan data NoSQL keluarga lajur, yang menggunakan konsep jadual / lajur yang biasa. Walau bagaimanapun, disebabkan kekurangan skema, lajur tidak diisytiharkan secara deklaratif dan boleh ditukar/ditambah semasa sesi pangkalan data pengguna. Ini membolehkan, khususnya, penggunaan lajur dinamik untuk pelaksanaan senarai.

Skema tidak berstruktur mempunyai kelemahannya - sebagai tambahan kepada overhed yang disebutkan di atas dalam kod aplikasi apabila menukar model data - ketiadaan semua jenis sekatan dari pangkalan (bukan batal, unik, semak kekangan, dll.), ditambah di sana adalah kesukaran tambahan dalam memahami dan mengawal data struktur apabila bekerja dengan pangkalan data projek yang berbeza secara selari (tiada kamus di sisi pangkalan data). Walau bagaimanapun, dalam dunia moden yang pesat berubah, fleksibiliti sedemikian masih menjadi kelebihan. Contohnya ialah Twitter, yang lima tahun lalu, bersama-sama dengan tweet itu, hanya menyimpan sedikit maklumat tambahan (masa, pemegang Twitter dan beberapa bait lagi meta-maklumat), tetapi kini, sebagai tambahan kepada mesej itu sendiri, beberapa lagi. kilobait metadata disimpan dalam pangkalan data.

(Selepas ini, kita bercakap terutamanya mengenai pangkalan data nilai kunci, dokumen dan lajur keluarga, pangkalan data graf mungkin tidak mempunyai sifat ini)

2.3. Perwakilan data dalam bentuk agregat (agregat)

Tidak seperti model hubungan, yang menyimpan entiti perniagaan logik aplikasi ke dalam pelbagai jadual fizikal untuk tujuan normalisasi, stor NoSQL beroperasi pada entiti ini sebagai objek holistik:

Contoh ini menunjukkan pengagregatan untuk model perhubungan konseptual e-dagang standard "Pesanan - Pesanan Item - Pembayaran - Produk". Dalam kedua-dua kes, pesanan digabungkan dengan kedudukan ke dalam satu objek logik, manakala setiap kedudukan menyimpan pautan ke produk dan beberapa atributnya, sebagai contoh, nama (penyahnormalan sedemikian diperlukan agar tidak meminta objek produk semasa mendapatkan semula perintah - peraturan utama sistem teragih ialah "bercantum" antara objek). Dalam satu agregat, pembayaran digabungkan dengan pesanan dan merupakan sebahagian daripada objek, dalam satu lagi ia diletakkan dalam objek yang berasingan. Ini menunjukkan peraturan utama untuk mereka bentuk struktur data dalam pangkalan data NoSQL - ia mesti mematuhi keperluan aplikasi dan dioptimumkan sebanyak mungkin untuk permintaan yang paling kerap.

Ramai yang akan membantah, dengan menyatakan bahawa bekerja dengan objek yang besar, sering dinyahnormalkan, penuh dengan banyak masalah apabila mencuba pertanyaan sewenang-wenang pada data apabila pertanyaan tidak sesuai dengan struktur agregat. Bagaimana jika kami menggunakan pesanan bersama-sama dengan item baris pesanan dan pembayaran (begini cara apl berfungsi), tetapi perniagaan meminta kami mengira bilangan unit produk tertentu yang dijual bulan lepas? Dalam kes ini, bukannya mengimbas jadual OrderItem (dalam kes model hubungan), kami perlu mendapatkan semula keseluruhan pesanan dalam storan NoSQL, walaupun kami tidak memerlukan banyak maklumat ini. Malangnya, ini adalah kompromi yang perlu dibuat dalam sistem teragih: kami tidak boleh menormalkan data seperti dalam sistem pelayan tunggal konvensional,

Saya cuba mengumpulkan kebaikan dan keburukan kedua-dua pendekatan dalam jadual: