Pertanyaan Apakah ada sesuatu seperti Redis DB, tetapi tidak terbatas dengan ukuran RAM? [Tutup]


Saya mencari database yang cocok dengan kriteria ini:

  • Mungkin tidak terus-menerus;
  • Hampir semua kunci DB perlu diperbarui satu kali dalam 3-6 jam (kunci 100M + dengan total ukuran 100Gb)
  • Kemampuan untuk cepat memilih data berdasarkan kunci (atau Kunci Utama)
  • Ini perlu menjadi DBMS (jadi LevelDB tidak cocok)
  • Ketika data ditulis, DB cluster harus dapat melayani permintaan (node ​​tunggal dapat diblokir sekalipun)
  • Tidak di memori - dataset kami akan melebihi batas RAM
  • Penskalaan dan replikasi horizontal
  • Mendukung penulisan ulang penuh dari semua data (MongoDB tidak menghapus ruang setelah menghapus data)
  • C # dan dukungan Java

Berikut adalah proses saya bekerja dengan basis data semacam itu: Kami memiliki kluster analisis yang menghasilkan data 100M (50GB) data setiap 4-6 jam. Data adalah "key-array [20]". Data ini perlu didistribusikan kepada pengguna melalui sistem front-end dengan tingkat permintaan 1-10k per detik. Rata-rata, hanya ~ 15% dari data yang diminta, sisanya akan ditulis ulang dalam 4-6 jam ketika set data berikutnya dihasilkan.

Apa yang saya coba:

  1. MongoDB. Overhead datastorage, biaya defragmentasi tinggi.
  2. Redis. Terlihat sempurna, tetapi terbatas dengan RAM dan data kami melebihi itu.

Jadi pertanyaannya adalah: apakah ada sesuatu seperti Redis, tetapi tidak terbatas dengan ukuran RAM?


37
2017-08-26 15:12


asal


Jawaban:


Ya, ada dua alternatif untuk Redis yang tidak dibatasi oleh ukuran RAM sementara sisanya kompatibel dengan protokol Redis:

Ardb (C ++), replikasi (Master-Slave / Master-Master): https://github.com/yinqiwen/ardb

Sebuah server penyimpanan persisten kompatibel redis-protokol, dukungan   LevelDB / KyotoCabinet / LMDB sebagai mesin penyimpanan.

Edis (Erlang): http://inaka.github.io/edis/

Edis adalah pengganti Server yang kompatibel dengan protokol untuk Redis, ditulis dalam   Erlang. Tujuan Edis adalah menjadi pengganti pengganti Redis saat   ketekunan lebih penting daripada menyimpan set data dalam memori. Edis   (saat ini) menggunakan leveldb Google sebagai backend.

Dan untuk kelengkapan di sini adalah database data-struktur lain:

Hyperdex (Strings, Integers, Floats, Lists, Sets, Maps): http://hyperdex.org/doc/latest/DataTypes/#chap:data-types

HyperDex adalah:

  • Cepat: HyperDex memiliki latensi yang lebih rendah, throughput yang lebih tinggi, dan lebih rendah   varians dari toko-toko nilai kunci lainnya.
  • Scalable: HyperDex sebagai skala   lebih banyak mesin ditambahkan ke sistem.
  • Konsisten: Jaminan HyperDex   linearizability untuk operasi berbasis kunci. Jadi, bacaan selalu kembali   nilai terbaru yang dimasukkan ke dalam sistem. Bukan hanya "akhirnya," tapi   segera dan selalu.
  • Kesalahan Toleransi: HyperDex secara otomatis   mereplikasi data pada beberapa mesin sehingga kegagalan bersamaan, naik   hingga batas yang ditentukan oleh aplikasi, tidak akan menyebabkan kehilangan data.   Dapat ditelusuri:
  • HyperDex memungkinkan pencarian data sekunder yang efisien   atribut.
  • Mudah Digunakan: HyperDex menyediakan API untuk berbagai   scripting dan bahasa asli.
  • Self-Maintaining: HyperDex adalah   mempertahankan diri dan membutuhkan sedikit perawatan pengguna.

23
2017-08-27 08:28



Ya, SSDB (https://github.com/ideawu/ssdb), ia memiliki API yang sangat mirip dengan Redis: http://www.ideawu.com/ssdb/docs/php/

SSDB mendukung hash, zset. Ini menggunakan leveldb sebagai mesin penyimpanan, sebagian besar data disimpan pada disk, RAM digunakan untuk cache. Pada contoh SSDB kami dengan data 300GB, hanya menggunakan RAM 800MB.


21
2017-08-28 13:19



Hari-hari ini Anda dapat dengan mudah menemukan server dengan lebih dari 100 GB RAM untuk menjadi tuan rumah satu contoh, atau Anda dapat beling data Anda dan menggunakan beberapa server dengan lebih sedikit RAM. Menyimpan 100 GB dengan Redis (dalam RAM) sebenarnya bukan masalah.

Sekarang jika Anda benar-benar ingin mencoba klon berdarah Redis tidak dibatasi oleh ukuran RAM, ada NDS (oleh Matt Palmer):

Perhatikan bahwa backend penyimpanan NDS telah pindah dari Kabinet Kyoto ke LMDB (paket yang sangat bagus, yang juga mendukung OpenLDAP), justru karena masalah reklamasi ruang mengikuti kunci yang dihapus.

Solusi lain - tidak kompatibel dengan Redis - mungkin juga sesuai dengan kebutuhan Anda: Couchbase, dan Aerospike, misalnya dapat dengan mudah mendukung throughput Anda. Cassandra dan Riak mungkin akan bekerja dengan baik asalkan Anda memiliki cukup node.


5
2017-08-26 16:42