NoSQL: Apa itu data tidak terstruktur?

kami saat ini berjalan di tepi sumber daya dengan solusi berbasis server mssql kami.

Kami sekarang memiliki banyak pilihan tradisional mengenai langkah selanjutnya untuk mengatasi beban:

• beli CPU dan IO yang lebih cepat
• membagi beberapa pelanggan ke server terpisah
• pindahkan db ke cluster

Semuanya mahal dalam hal lisensi dan perangkat keras atau waktu. Jadi, saya ingin menambahkan opsi lain dengan memindahkan seluruh sistem ke solusi scalable yang dijanjikan mesin nosql cassandra.

Namun, saya tidak yakin dan tidak berpengalaman dengan database noSQL, jadi saya perlu memahami struktur data "tidak terstruktur".

Dalam aplikasi kami, kami pada dasarnya menyimpan data yang dimasukkan oleh pengguna dalam berbagai cara sebagai daftar "nilai kunci". Ada tabel induk, yang berisi elemen kepala (seperti Pesanan) dan ada tabel anak dengan pasangan nilai kunci yang terdiri dari isi pesanan (seperti Order_Lines).

Dari segi bisnis, Order dan OrderLines adalah satu unit. Tetapi karena RDBMS, mereka disimpan dalam tabel dan harus bergabung setiap saat.

Selama operasi, kami kadang-kadang memilih untuk memuat hanya bagian atas, tetapi sebagian besar waktu, kami memuat baris utama + beberapa KVP untuk menampilkan beberapa informasi yang berguna.

Misalnya, dalam daftar ikhtisar, kami menunjukkan pengidentifikasi kepala + beberapa nilai dalam kolom untuk setiap baris.

PEMBARUAN: Kami menyimpan segala bentuk. Jadi, pada dasarnya kami menyimpan "dokumen". Namun demikian, kami harus menyiapkan dan mencari melalui formulir-formulir ini dengan nilai apa pun, mengurutkan, dll. Kontrol akses data menambah lapisan kompeksitas pada basis data.

Seperti yang Anda duga, jumlah dan ketersediaan KVP tertentu bervariasi dari satu objek ke objek lainnya. Tidak ada kemungkinan yang valid untuk membuat tabel tunggal untuk setiap jenis objek karena kita harus membuat ribuan tabel untuk kombinasi data yang berbeda.

Apakah "Kamus" seperti kumpulan data ini lebih baik disimpan dalam basis data noSQL? Dan akankah kita mendapat manfaat kinerja dari ini? Apakah Cassandra akan memodelkan head + KVP ini sebagai satu dataset? Melihat halaman web cassandra dan beberapa tutorial, saya mendapat kesan, bahwa tidak ada banyak perbedaan antara RDBMS dan cassandra kami dalam hal organisasi data - meninggalkan kami dengan jumlah bergabung yang sangat besar jika Anda ingin memilih 5 KVPs untuk daftar untuk setiap baris.

Pencerahan diterima, juga petunjuk ke makalah yang menjelaskan masalah tidak masalah.

Ada beberapa konsep yang perlu dibedakan. Satu tentang struktur dan yang lainnya tentang skema.

Data terstruktur adalah data di mana aplikasi mengetahui terlebih dahulu arti dari setiap byte yang diterimanya. Contoh yang baik adalah pengukuran dari sensor. Sebaliknya aliran Twitter tidak terstruktur. Skema adalah tentang seberapa banyak struktur dikomunikasikan kepada DBMS sebagaimana diminta untuk menegakkan ini. Ini mengontrol berapa banyak DBMS mem-parsing data yang disimpannya. DBMS yang diperlukan skema seperti SQL Server dapat menyimpan data yang tidak diuraikan (varbinary) atau data yang diurai secara opsional (xml) dan data yang diurai sepenuhnya (kolom).

DBMS NoSQL terletak pada spektrum dari tanpa parsing (key-value store) ke atas. Cassandra menawarkan fungsionalitas yang kaya reatif dalam hal ini. Di mana mereka sangat berbeda dengan toko relasional adalah keseragaman data. Setelah tabel didefinisikan hanya data yang cocok dengan definisi yang dapat disimpan di sana. Namun, dalam Cassandra, bahkan jika kolom dan keluarga didefinisikan, tidak ada persyaratan untuk setiap dua baris dalam tabel yang sama untuk terlihat mirip satu sama lain. Itu jatuh ke desainer aplikasi untuk memutuskan berapa banyak yang terjadi dalam satu baris (juga disebut sebagai dokumen) dan apa yang dipegang secara terpisah, dihubungkan oleh pointer. Akibatnya, berapa banyak denormalisasi yang Anda inginkan.

Keuntungannya adalah Anda dapat mengambil set data lengkap dengan membaca sekuensial tunggal. Ini cepat. Satu kelemahan adalah bahwa Anda, pemrogram aplikasi, sekarang bertanggung jawab penuh atas semua integritas data dan masalah kompatibilitas mundur, untuk selamanya, untuk setiap bit kode yang pernah menyentuh penyimpanan data ini. Itu bisa sulit untuk diperbaiki. Juga, Anda terkunci pada satu sudut pandang pada data. Jika Anda memasukkan baris berdasarkan nomor pesanan, bagaimana Anda melaporkan penjualan pada satu produk, atau wilayah, atau pelanggan tertentu?

Terlepas dari arus utama pangkalan data noSQL IMHO, keputusan tentang mengadopsi teknologi seperti itu harus dibuat sesuai dengan pencapaian yang diperlukan sesuai dengan informasi yang disimpan, tidak hanya memperhatikan kinerja yang Anda miliki saat ini. Ini berarti bahwa mungkin pilihan terbaik Anda adalah tetap berpegang pada database SQL dan meningkatkan HW Anda.

Tetapi selain itu saya membaca sesuatu dalam pertanyaan Anda yang membuat saya berpikir. Tidak banyak tentang status saat ini dari basis data Anda tetapi kalimat Anda "kami pada dasarnya menyimpan data yang dimasukkan oleh pengguna dalam berbagai cara sebagai" nilai kunci "daftar" membuat saya berpikir apakah masalahnya bukan model data yang buruk daripada kurangnya sumber daya fisik. Saya telah mengelola tabel yang sangat besar (+10 miliar baris) dengan kinerja luar biasa dalam database SQL "tradisional".

Saya tidak mengatakan itu salah, hanya, karena tentu saja saya tidak dapat menilai Anda dalam model data yang tepat dengan sedikit informasi tentang solusi Anda saat ini, tetapi hanya berpikir tentang meninjau kembali model data Anda sebagai opsi tambahan bersama dengan sisanya karena Anda mungkin menemukan beberapa petunjuk menggaruk di sana.

Biasanya daftar nilai kunci baik-baik saja sebagai trade-off ketika Anda tidak dapat mengimplementasikan model dalam keadaan akhir karena Anda tidak tahu kunci berbeda yang harus Anda hadapi, atau ketika Anda membutuhkan nilai dari salah satu yang mungkin. kunci untuk elemen tertentu. Tetapi ketika diimplementasikan, saya biasanya suka memikirkan kembali keputusan seperti itu setelah beberapa saat ketika Anda telah mengumpulkan cukup banyak informasi untuk mengidentifikasi kasus umum penggunaan dan memutuskan apakah keputusan model data adalah yang terbaik. Jika Anda tahu Anda akan memiliki jumlah kunci tertentu, cobalah melakukan benchmark dengan desain meja biasa dengan cara tradisional

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

... dan menambahkan indeks yang sesuai. Cobalah dan ukur rencana pelaksanaan dengan kedua pendekatan. Anda mungkin akan terkejut terutama jika Anda mengumpulkan lebih dari satu kunci sekaligus, karena, di antara kelebihan lainnya ukuran blok data harus dikurangi dan dengan demikian kinerjanya akan ditingkatkan.

Semoga ini bisa membantu, atau setidaknya memperluas kemungkinan dan membuka jalur baru untuk penyelidikan.