Apa itu database toko Kunci / Nilai?

Saya telah mencari di halaman wikipedia untuk NoSQL dan mencantumkan beberapa variasi pada basis data Key / Value store, tetapi saya tidak dapat menemukan detail tentang apa artinya oleh toko Key / Value dalam konteks ini. Bisakah seseorang menjelaskan atau menautkan penjelasan kepada saya? Juga, kapan saya akan menggunakan database seperti itu?

Apakah Anda terbiasa dengan konsep Pasangan Kunci / Nilai? Anggap Anda terbiasa dengan Java atau C # ini dalam bahasa sebagai peta / hash / datatable / KeyValuePair (yang terakhir adalah dalam kasus C #)

Cara kerjanya ditunjukkan dalam bagan sampel kecil ini:

Color        Red
Age          18
Size         Large
Name         Smith
Title        The Brown Dog

Di mana Anda memiliki kunci (kiri) dan nilai (kanan) ... perhatikan itu bisa berupa string, int, atau sejenisnya. Sebagian besar objek KVP memungkinkan Anda untuk menyimpan objek di sebelah kanan, karena itu hanya sebuah nilai.

Karena Anda akan selalu memiliki kunci unik untuk objek tertentu yang ingin Anda kembalikan, Anda bisa saja meminta basis data untuk kunci unik itu dan mendapatkan hasilnya kembali dari simpul mana pun yang memiliki objek (inilah mengapa bagus untuk sistem terdistribusi, karena ada hal-hal lain yang terlibat seperti polling untuk n node pertama untuk mengembalikan nilai yang cocok dengan node lain kembali).

Sekarang contoh saya di atas sangat sederhana, jadi inilah versi KVP yang sedikit lebih baik

user1923_color    Red
user1923_age      18
user3371_color    Blue
user4344_color    Brackish
user1923_height   6' 0"
user3371_age      34

Jadi seperti yang Anda lihat, pembuatan kunci sederhana adalah dengan menempatkan "pengguna" nomor pengguna unik, garis bawah dan objek. Sekali lagi, ini adalah variasi sederhana, tetapi saya pikir kita mulai memahami bahwa selama kita dapat mendefinisikan bagian di sebelah kiri dan memformatnya secara konsisten, kita dapat menarik nilainya.

Perhatikan bahwa tidak ada batasan pada nilai kunci (ok, bisa ada beberapa batasan, seperti hanya teks) atau pada properti nilai (mungkin ada batasan ukuran) tetapi sejauh ini saya belum memiliki sistem yang benar-benar kompleks. Mari kita coba dan melangkah lebih jauh:

app_setting_width      450
user1923_color         Red
user1923_age           18
user3371_color         Blue
user4344_color         Brackish
user1923_height        6' 0"
user3371_age           34
error_msg_457          There is no file %1 here
error_message_1        There is no user with %1 name
1923_name              Jim
user1923_name          Jim Smith
user1923_lname         Smith
Application_Installed  true
log_errors             1
install_path           C:\Windows\System32\Restricted
ServerName             localhost
test                   test
test1                  test
test123                Brackish
devonly
wonderwoman
value                  key

Anda mendapatkan idenya ... semua itu akan disimpan dalam satu "tabel" besar pada node terdistribusi (ada matematika di balik itu semua) dan Anda hanya akan meminta sistem terdistribusi untuk nilai yang Anda butuhkan dengan nama.

Paling tidak, itulah pemahaman saya tentang cara kerjanya. Saya mungkin memiliki beberapa hal yang salah, tetapi itulah dasar-dasarnya.

tautan wikipedia wajib http://en.wikipedia.org/wiki/Associative_array

Dalam istilah SQL, database NoSQL adalah tabel tunggal dengan dua kolom: satu menjadi Kunci (Primer), dan yang lainnya adalah Nilai. Dan hanya itu, itu semua keajaiban NoSQL.

Anda akan menggunakan NoSQL karena satu alasan utama: skalabilitas.

Jika aplikasi Anda perlu menangani jutaan permintaan per detik, satu-satunya cara untuk mencapainya adalah menambahkan lebih banyak server. Itu sangat murah dan mudah dengan NoSQL. Sebaliknya, penskalaan basis data SQL tradisional jauh lebih rumit.

Hanya situs web terbesar di luar sana yang benar-benar memanfaatkan potensi NoSQL lengkap, yaitu Facebook, yang memiliki ribuan server yang menjalankan Cassandra .

Saya sangat merekomendasikan untuk membaca posting blog ini, membandingkan SQL, NoSQL dan ORM:

http://seldo.com/weblog/2010/07/12/in_defence_of_sql

Saya berasumsi Anda memiliki pemahaman dasar tentang gerakan NoSQL dan model database non-relasional.

Key Value store adalah salah satu model basis data non-relasi, seperti grafik, model basis data berorientasi dokumen.

Toko Nilai Utama dan gerakan NoSQL

Secara umum, SQL berhasil menangani data terstruktur khusus dan memungkinkan permintaan yang sangat dinamis sesuai dengan kebutuhan departemen yang bersangkutan.

Meskipun masih belum ada pesaing nyata untuk SQL dalam bidang khusus ini, kasus penggunaan dalam aplikasi web sehari-hari berbeda. Anda tidak akan menemukan rentang kueri yang sangat dinamis, penuh dengan gabungan luar dan dalam, serikat pekerja, dan perhitungan kompleks di atas tabel besar. Anda biasanya akan menemukan cara berpikir yang sangat berorientasi objek. Terutama dengan adopsi pola-pola seperti MVC, data di back-end biasanya tidak dimodelkan untuk database, tetapi untuk integritas logis yang juga membantu orang untuk dapat memahami infrastruktur perangkat lunak yang besar. Apa yang sedang dilakukan untuk menempatkan model-model berorientasi objek ini ke dalam basis data relasional adalah sejumlah besar normalisasi yang mengarah pada hierarki tabel yang kompleks dan sepenuhnya bertentangan dengan ide utama di balik pemrograman berorientasi objek.

Fakta bahwa SQL memungkinkan untuk query dinamis yang berubah-ubah untuk set data yang kompleks dianggap tidak berguna dengan menggunakan Database SQL hanya untuk penyimpanan data berorientasi objek yang persisten, yang pada dasarnya dilakukan sebagian besar aplikasi saat ini.

Di sinilah toko Value Key ikut bermain. Key value stores allow the application developer to store schema-less data. This data is usually consisting of a string which represents the key and the actual data which is considered to be the value in the "key - value" relationship. Data itu sendiri biasanya semacam primitif dari bahasa pemrograman (string, integer, array) atau objek yang sedang disusun oleh bahasa pemrograman yang mengikat ke penyimpanan nilai kunci. Ini menggantikan kebutuhan untuk model data tetap dan membuat persyaratan untuk data yang diformat dengan benar menjadi kurang ketat.

They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval. Perbedaan terbesar untuk toko "sederhana" adalah cara Anda dapat (atau tidak bisa) mengautentikasi atau mengakses toko yang berbeda (jika mungkin). Sementara keuntungan kecepatan dalam menyimpan dan mengambil data mungkin menjadi alasan untuk mempertimbangkannya daripada SQL Database umum, keuntungan besar lain yang muncul ketika menggunakan toko nilai-kunci adalah bahwa kode yang dihasilkan cenderung terlihat bersih dan sederhana jika dibandingkan dengan string SQL tertanam di bahasa pemrograman Anda. Ini adalah sesuatu yang cenderung dilawan orang dengan kerangka pemetaan objek-relasional seperti Hibernate atau Rekaman Aktif. Memiliki objek pemetaan relasional pada dasarnya tampaknya meniru nilai toko kunci dengan menambahkan banyak kode yang sangat kompleks antara database SQL dan bahasa pemrograman berorientasi objek.

Seluruh komunitas orang berkumpul bersama di bawah tag " NoSQL " dan mendiskusikan keuntungan ini dan juga kerugian menggunakan alternatif untuk sistem manajemen basis data nasional. Baca lebih lanjut
Ini adalah artikel yang agak lama, tetapi saya temukan sangat berguna.

when would I use such a database? Could someone explain or link an explanation to me?
Ini lebih dari keputusan arsitektur, dan yang dapat diperdebatkan ... Anda harus mempertimbangkan banyak faktor seperti skalabilitas, kinerja dll ...

Lihat di bawah ini slide / artikel dan Anda akan mendapatkan ide, kapan, mengapa dan mengapa tidak menggunakan toko nilai utama :)

• Basis Data Non-Relasional & Toko Kunci / Nilai
• Kunci-Nilai-Toko - Kunci Menskalai?
• http://highscalability.com/blog/category/key-value-store [harus dibaca]
• http://ayende.com/Blog/archive/2010/03/29/that-no-sql-thing-keyvalue-stores.aspx

Orang lain telah menjelaskan hal ini, tetapi saya tetap akan mencoba.

Database kunci / nilai menyimpan data dengan kunci utama. Ini memungkinkan kami mengidentifikasi secara unik catatan dalam ember. Karena semua nilai unik, pencarian sangat cepat: selalu merupakan pencarian disk yang sederhana.

Nilainya adalah segala jenis nilai. Cara data disimpan adalah buram ke database itu sendiri. Saat Anda menyimpan data di penyimpanan kunci / nilai, basis data tidak tahu atau tidak peduli apakah itu XML, JSON, teks, atau gambar. Akibatnya, apa yang kami lakukan di toko kunci / nilai adalah memindahkan tanggung jawab untuk memahami bagaimana data disimpan dari database ke dalam aplikasi yang mengambil data kami. Karena Anda hanya memiliki satu rentang kunci yang perlu dikhawatirkan per ember, sangat mudah untuk menyebarkan kunci di banyak server dan menggunakan teknik pemrograman terdistribusi untuk memungkinkan data ini diakses dengan cepat (setiap server menyimpan berbagai data) .

Kelemahan dari pendekatan terhadap data ini adalah bahwa pencarian adalah tugas yang sangat sulit. Anda harus membaca setiap catatan dalam data Anda atau Anda perlu membuat indeks sekunder sendiri.

Ada beberapa alasan Anda mungkin ingin menggunakan basis data kunci / nilai:

• Ketika menulis kinerja adalah prioritas tertinggi Anda. Mozilla Test Pilot menggunakan database kunci / nilai untuk merekam data dengan cepat.
• Ketika membaca dijamin hanya akan terjadi oleh PK.
• Saat Anda bekerja dengan model data datar.
• Saat Anda bekerja dengan model data yang kaya dan kompleks yang tidak dapat dimodelkan dalam RDBMS.

Ada banyak alasan untuk menggunakan basis data kunci / nilai seperti halnya menggunakan RDBMS dan ada banyak argumen untuk membenarkan satu di atas yang lain. Penting untuk melihat bagaimana Anda menanyakan data Anda dan memahami bagaimana pola akses data tersebut memandu bagaimana Anda akan memasukkan dan menyimpan data.

Ingatlah bahwa basis data kunci / nilai hanyalah salah satu jenis basis data NoSQL.

Jika Anda memiliki basis data relasional, maka Anda dapat dengan mudah bereksperimen dengan ini:

create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);

Ini adalah bagaimana semua database dulu, dengan Berkeley DBM menjadi contoh yang baik, dari tahun 1979. Sejak itu, banyak hal telah maju (Anda dapat memiliki banyak nilai per kunci dalam RDBMS apa pun). Untuk banyak aplikasi, penyimpanan nilai kunci sudah cukup (mis. Ini adalah bagaimana sendmail menyimpan aliasnya). Tetapi jika Anda mendapati diri Anda melakukan pra-pemrosesan nilai dalam kode Anda sendiri (atau merangkai string untuk membuat "kunci" Anda), mungkin membagi nilai pada pembatas atau menguraikannya, sebelum Anda dapat menggunakannya, Anda mungkin akan lebih baik dengan RDBMS dan sebenarnya menyimpannya seperti itu.