Apa perbedaan NoSQL yang berorientasi kolom dari berorientasi dokumen?


90

Tiga jenis database NoSQL yang pernah saya baca adalah nilai kunci, berorientasi kolom, dan berorientasi dokumen.

Nilai kunci cukup mudah - kunci dengan nilai biasa.

Saya telah melihat database berorientasi dokumen yang dideskripsikan sebagai nilai kunci, tetapi nilainya dapat berupa struktur, seperti objek JSON. Setiap "dokumen" dapat memiliki semua, beberapa, atau tidak ada kunci yang sama seperti yang lain.

Berorientasi kolom tampaknya sangat mirip dengan berorientasi dokumen di mana Anda tidak menentukan struktur.

Jadi apa perbedaan antara keduanya, dan mengapa Anda menggunakan salah satunya?

Saya secara khusus melihat MongoDB dan Cassandra. Saya pada dasarnya membutuhkan struktur dinamis yang dapat berubah, tetapi tidak memengaruhi nilai-nilai lain. Pada saat yang sama saya harus dapat menelusuri / memfilter kunci tertentu dan menjalankan laporan. Dengan CAP, AP adalah yang paling penting bagi saya. Data "pada akhirnya" dapat disinkronkan lintas node, selama tidak ada konflik atau kehilangan data. Setiap pengguna akan mendapatkan "tabel" mereka sendiri.

Jawaban:


41

Di Cassandra, setiap baris (dialamatkan oleh sebuah kunci) berisi satu atau lebih "kolom". Kolom itu sendiri adalah pasangan nilai kunci. Nama kolom tidak perlu ditentukan sebelumnya, yaitu strukturnya tidak tetap. Kolom dalam satu baris disimpan dalam urutan yang diurutkan sesuai dengan kunci (nama) mereka.

Dalam beberapa kasus, Anda mungkin memiliki jumlah kolom yang sangat besar dalam satu baris (misalnya untuk bertindak sebagai indeks untuk mengaktifkan jenis kueri tertentu). Cassandra dapat menangani struktur sebesar itu secara efisien, dan Anda dapat mengambil rentang kolom tertentu.

Ada tingkat lebih lanjut dari struktur (tidak begitu umum digunakan) yang disebut super-kolom, di mana kolom berisi (sub) kolom.

Anda dapat menganggap keseluruhan struktur sebagai hashtable / kamus bertingkat, dengan 2 atau 3 level kunci.

Keluarga kolom normal:

row
    col  col  col ...
    val  val  val ...

Keluarga kolom super:

row
      supercol                      supercol                     ...
          (sub)col  (sub)col  ...       (sub)col  (sub)col  ...
           val       val      ...        val       val      ...

Ada juga struktur tingkat yang lebih tinggi - kelompok kolom dan ruang kunci - yang dapat digunakan untuk membagi atau mengelompokkan data Anda.

Lihat juga Pertanyaan ini: Cassandra: Apa itu subkolom

Atau tautan pemodelan data dari http://wiki.apache.org/cassandra/ArticlesAndPresentations

Re: perbandingan dengan database berorientasi dokumen - yang terakhir biasanya memasukkan seluruh dokumen (biasanya JSON), sedangkan di Cassandra Anda dapat menangani kolom atau superkolom individual, dan memperbaruinya secara individual, yaitu mereka bekerja pada tingkat perincian yang berbeda. Setiap kolom memiliki stempel waktu / versi terpisah (digunakan untuk merekonsiliasi pembaruan di seluruh cluster terdistribusi).

Nilai kolom Cassandra hanya byte, tetapi dapat diketik sebagai teks ASCII, UTF8, angka, tanggal, dll.

Tentu saja, Anda dapat menggunakan Cassandra sebagai penyimpanan dokumen primitif dengan memasukkan kolom yang berisi JSON - tetapi Anda tidak akan mendapatkan semua fitur dari penyimpanan berorientasi dokumen yang sebenarnya.


5
Keluarga kolom seperti meja. Baris adalah seperti baris tabel. Kolom adalah semacam kolom database, kecuali bahwa kolom dapat ditentukan dengan cepat, jadi Anda mungkin memiliki tabel yang sangat jarang diisi dalam beberapa kasus, atau Anda mungkin memiliki kolom berbeda yang diisi di setiap baris.
DNA

1
Itu tergantung pada database. Di MongoDB (berorientasi dokumen) Anda juga dapat memperbarui setiap kunci.
David Raab

1
Jika itu benar, bagaimana MongoDB mendefinisikan database berorientasi dokumen sedangkan Cassandra berorientasi pada kolom. Bagaimana mereka berbeda?
Lukas

3
@ Luke Berorientasi kolom terlihat seperti RDBMS tanpa skema, tetapi selain strukturnya yang longgar, perbedaan utamanya adalah daripada bukan relasional.
pengguna327961

1
@ user327961 Tapi MongoDB juga seperti RDBMS tanpa skema, dan juga tidak relasional.
huggie

55

Perbedaan utamanya adalah bahwa penyimpanan dokumen (mis. MongoDB dan CouchDB) memungkinkan dokumen yang rumit secara sewenang-wenang, yaitu sub dokumen di dalam sub dokumen, daftar dengan dokumen, dll. Sedangkan penyimpanan kolom (misalnya Cassandra dan HBase) hanya mengizinkan format tetap, misalnya satu tingkat ketat atau kamus dua tingkat.


Dalam hal ini, mongo (dokumen) bisa melakukan apa yang bisa dilakukan oleh cassendra (Kolom). Mengapa Kolom dibutuhkan?
sanjay patel

1
Ini adalah trade-off antara fitur yang berbeda, dengan desain berorientasi kolom, mesin penyimpanan bisa jauh lebih efisien daripada mesin penyimpanan berorientasi dokumen. MongoDB harus menulis ulang seluruh dokumen di disk jika ukurannya bertambah besar, tetapi Cassandra tidak perlu melakukannya (ini adalah penyederhanaan, tentu saja, ada banyak detail untuk ini). Ini membuat Cassandra lebih cepat dalam hal menulis.
Theo

29

Dalam "sisipkan", untuk menggunakan kata rdbms, Berbasis dokumen lebih konsisten dan lurus ke depan. Catatan dari cassandra memungkinkan Anda mencapai konsistensi dengan gagasan kuorum, tetapi itu tidak berlaku untuk semua sistem berbasis kolom dan itu mengurangi ketersediaan. Pada sistem yang berat sekali / baca-sering, gunakan MongoDB. Pertimbangkan juga jika Anda selalu berencana untuk membaca seluruh struktur objek. Sistem berbasis dokumen dirancang untuk mengembalikan seluruh dokumen saat Anda mendapatkannya, dan tidak terlalu kuat dalam mengembalikan sebagian dari keseluruhan baris.

Sistem berbasis kolom seperti Cassandra jauh lebih baik daripada berbasis dokumen dalam "pembaruan". Anda dapat mengubah nilai kolom tanpa membaca baris yang memuatnya. Penulisan sebenarnya tidak perlu dilakukan di server yang sama, satu baris mungkin terdapat pada beberapa file dari beberapa server. Pada sistem data besar yang berkembang pesat, pilih Cassandra. Pertimbangkan juga jika Anda berencana memiliki potongan data yang sangat besar per kunci, dan tidak perlu memuat semuanya di setiap kueri. Dalam "pilih", Cassandra membiarkan Anda memuat hanya kolom yang Anda butuhkan.

Juga pertimbangkan bahwa Mongo DB ditulis dalam C ++, dan pada rilis mayor kedua, sementara Cassandra perlu dijalankan pada JVM, dan rilis mayor pertamanya hanya dalam kandidat rilis sejak kemarin (tetapi rilis 0.X diserahkan dalam produksi perusahaan besar).

Di sisi lain, desain Cassandra sebagian didasarkan pada Amazon Dynamo, dan itu dibangun pada intinya untuk menjadi solusi Ketersediaan Tinggi, tetapi itu tidak ada hubungannya dengan format berbasis kolom. MongoDB juga berskala, tapi tidak seanggun Cassandra.


1
Apa yang salah dengan perangkat lunak yang ditulis dalam C ++ versus Java?
Nayuki

@Nayuki Sekarang, saya menyadari ada beban kerja pertengkaran tinggi di mana pengumpulan sampah malas model manajemen memori Java akan mengungguli model manajemen "manual" C ++ secara teori, tetapi secara umum, biasanya tidak sulit untuk mengungguli Java dengan menulis yang setara program di C ++, setidaknya selama Anda menonaktifkan Pengecualian dan RTTI. Dan jika Anda memanfaatkan coroutine tanpa tumpukan dan fungsi yang dapat dilanjutkan dengan baik, saya pribadi belum melihat Java mengalahkan C ++ saya.
patrickjp93

0

Saya akan mengatakan bahwa perbedaan utama adalah cara masing-masing tipe DB ini menyimpan data secara fisik.
Dengan tipe kolom, data disimpan oleh kolom yang dapat mengaktifkan operasi / kueri agregasi yang efisien pada kolom tertentu.
Dengan jenis dokumen, seluruh dokumen secara logis disimpan di satu tempat dan umumnya diambil secara keseluruhan (tidak ada agregasi yang efisien pada "kolom" / "kolom").

Sedikit membingungkan adalah bahwa "baris" kolom lebar dapat dengan mudah direpresentasikan sebagai dokumen, tetapi, seperti yang disebutkan, mereka disimpan secara berbeda dan dioptimalkan untuk tujuan yang berbeda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.