Akses Kunci Berkecepatan Tinggi dengan NoSQL

Toko nilai kunci di NoSQL semuanya tentang kecepatan. Anda dapat menggunakan berbagai teknik untuk memaksimalkan kecepatan itu, dari data caching, memiliki banyak salinan data, atau menggunakan struktur penyimpanan yang paling sesuai.

Caching data di memori

Karena data mudah diakses saat disimpan dalam memori akses acak (random access memory / RAM), memilih toko nilai kunci yang menyimpan data dalam RAM secara signifikan dapat mempercepat akses Anda ke data, walaupun dengan harga biaya server yang lebih tinggi

Seringkali, tradeoff ini layak dibuat. Anda dapat dengan mudah menghitung berapa persentase data yang tersimpan yang sering diminta. Jika Anda tahu lima persen umumnya diminta setiap beberapa menit, ambil lima persen dari ukuran data Anda dan tambahkan nomor itu sebagai ruang RAM cadangan di server database Anda.

Ingatlah bahwa sistem operasi, aplikasi lain, dan server database memiliki persyaratan memori juga.

Menggandakan data ke budak

Di toko dengan nilai penting, kunci tertentu disimpan di salah satu server di cluster. Proses ini disebut partisi kunci . Ini berarti bahwa, jika kunci ini terus-menerus diminta, simpul ini akan menerima sebagian besar permintaan. Node ini, oleh karena itu, akan lebih lambat dari kecepatan permintaan rata-rata Anda, yang berpotensi mempengaruhi kualitas layanan kepada pengguna Anda.

Untuk menghindari situasi ini, beberapa toko dengan nilai penting mendukung penambahan replika read-only, yang juga disebut sebagai budak. Redis, Riak, dan Aerospike adalah contoh yang bagus. Replikasi memungkinkan kunci untuk disimpan beberapa kali di beberapa server, yang meningkatkan kecepatan respons namun dengan biaya lebih banyak perangkat keras.

Beberapa toko dengan nilai kunci menjamin bahwa replika kunci akan selalu memiliki nilai yang sama dengan master. Jaminan ini disebut sepenuhnya konsisten. Jika update terjadi pada master server yang memegang kunci, semua replika dijamin up to date.

Tidak semua toko dengan nilai kunci menjamin status ini (Riak, misalnya), jadi jika penting untuk selalu up to date sampai milidetik, pilihlah database yang replikanya sepenuhnya konsisten (seperti Aerospike).

Pemodelan data di toko-toko bernilai kunci

Banyak toko dengan nilai kunci hanya mendukung struktur dasar untuk jenis nilainya, sehingga programmer aplikasi dengan pekerjaan menafsirkan data. Dukungan tipe data sederhana biasanya mencakup string, bilangan bulat, JSON, dan nilai biner.

Untuk banyak kasus penggunaan, ini bekerja dengan baik, namun terkadang akses data yang sedikit lebih rinci ke data berguna.Redis, misalnya, mendukung jenis nilai data berikut:

• String

• Daftar

• Set

• Kumpulan yang Diurutkan

• Peta hash

• Bit array

• Log hyperlog

Kumpulan yang diurutkan dapat ditanyai untuk mencocokkan rentang nilai - seperti query indeks nilai yang diurutkan berdasarkan tanggal, yang sangat berguna untuk mencari subset dari data yang diketik.

Mengoperasikan data

Redis mencakup operasi terhadap kenaikan dan penurunan nilai kunci secara langsung, tanpa harus melakukan serangkaian langkah pembaruan baca-modifikasi-update (RMU). Anda dapat melakukannya dalam satu transaksi untuk memastikan tidak ada aplikasi lain yang mengubah nilainya selama pembaruan. Operasi spesifik tipe data ini mencakup penambahan dan penghapusan item ke daftar dan kumpulan juga.

Anda bahkan dapat menyediakan fungsionalitas pelengkapan otomatis pada antarmuka pengguna aplikasi dengan menggunakan perintah Redis ZRANGEBYLEX. Perintah ini mengambil sekumpulan kunci yang sebagian cocok dengan sebuah string. Jadi, jika Anda mengetik "NoSQL for" di bilah penelusuran aplikasi yang ada di Redis, Anda akan melihat saran "NoSQL For Dummies. "Redis Redis

Redis membanggakan diri sebagai toko dengan nilai sangat ringan tapi sangat cepat. Ini pada awalnya dirancang untuk menjadi toko key-value in-memory, namun sekarang menawarkan penyimpanan data berbasis disk.

Anda dapat menggunakan Redis untuk melindungi data dengan mengaktifkan mode AOF (append only file) dan menginstruksikan Redis untuk memaksa data ke disk pada setiap query (dikenal sebagai pemalsuan fsync paksa). AOF memang memperlambat penulisan, tentu saja, namun memberikan tingkat ketahanan data yang lebih tinggi. Namun, sadarilah bahwa masih mungkin untuk kehilangan satu detik perintah. Juga, Redis baru saja menambahkan dukungan untuk pengelompokan. Sebenarnya, pada saat penulisan ini, dukungan clustering Redis ada di tahap pengujian beta. Untungnya, Redis menggunakan model cluster tanpa berbagi, dengan master untuk kunci dan budak tertentu yang tidak pernah ditulis langsung oleh klien; hanya tuan yang melakukannya. Menyediakan pengelompokan bersama-tidak ada artinya memudahkan Redis untuk menerapkan clustering yang andal daripada database yang memungkinkan penulisan ke semua replika. Jika Anda menginginkan lapisan caching berkecepatan tinggi dalam memori di depan database lain - MongoDB atau Riak biasa digunakan dengan Redis - kemudian evaluasikan Redis sebagai opsi. Sebagai dukungan untuk pengelompokan dan ketahanan data berkembang, mungkin Redis dapat menyalip database back-end lainnya.