Itu semua tergantung pada bagaimana Anda akan menggunakannya. Jika setiap byte diperhitungkan, misalnya ketika Anda harus membayar untuk setiap kB yang ditransfer ke layanan cloud, Anda dapat menghitung biayanya. Matematikanya sederhana; byte adalah byte 'on the wire'. Di dalam redis, untuk nilai yang lebih besar sama sederhananya. Untuk nilai yang lebih kecil, Redis melakukan beberapa pengoptimalan memori.
Di HSET . Anda misalnya, Anda membagi anggota, yang hanya masuk akal jika Anda membutuhkan mereka untuk dipisahkan satu sama lain hampir sepanjang waktu. Pendekatan yang lebih baik -mungkin- menjadi:HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . Pisahkan kunci/anggota 'berbiaya' lebih banyak daripada string yang lebih panjang, dari segi kinerja. Anda bahkan dapat meletakkan seluruh tabel atau kumpulan data dalam satu anggota jika itu hanya akan digunakan sebagai satu entitas semi-statis lengkap.
Kecepatan dan Ukuran:Ada perbedaan mencolok antara tombol dan nilai .
Kunci: Lebih pendek umumnya lebih hemat memori serta efisien kecepatan. Jika Anda menggunakan Redis Sorted Set, Anda bahkan dapat menggunakan 'angka' sebagai kunci (set terurut 'anggota' plus 'skor'). Saya mengatakan 'angka' karena skor secara teknis adalah float64, tetapi untuk digunakan sebagai ID itu harus antara -999999999999999 dan 999999999999999 termasuk (itu 15 digit), tanpa bagian pecahan. Ini bisa sangat membantu, karena Redis melakukan penyortiran O(log(n)) yang cepat dan skalabel dari Kumpulan Terurut (menggunakan skiplist, disederhanakan).
Nilai: Format MsgPack (tidak terkompresi) menggunakan paling sedikit ruang, terutama jika Anda menyimpan definisi sekali dan nilainya banyak. JSON sedikit kurang hemat memori, tetapi tentu saja merupakan format IPC yang umum sehingga tidak boleh ditinggalkan. String mentah, karakter dipisahkan, panjang tetap (ugh), apa pun keinginan Anda, itu mungkin untuk digunakan. Anda selalu dapat mengompres data Anda sebelum menyimpannya di Redis. Sejauh ini efisiensi memori . Dalam hal kecepatan , itu kurang sederhana. Jika Anda ingin menggunakan skrip sisi server Lua (yang seharusnya Anda lakukan), Anda tidak dapat melakukan apa pun dengan data terkompresi. JSON dan MsgPack dapat di-deserialized, tetapi hanya 'secara keseluruhan'. Yang baik-baik saja dalam kebanyakan skenario. Yang paling fleksibel adalah menyimpan nilai terpisah (misalnya sebagai anggota HSET), tetapi ini juga memiliki harga (sebagian besar waktu:harga terlalu tinggi). Anda juga dapat menggabungkan semua ini. Yang paling sering kami gunakan:awalan dua atau tiga nilai yang dipisahkan oleh pembatas, diikuti dengan muatan MsgPack.
Saran umum saya adalah:mulai dengan hanya menggunakan HSET dan ZSET, jangan pisahkan data yang dimiliki bersama, gunakan nama PascalCased deskriptif untuk kunci Anda antara 10-25 karakter, gunakan ':' jika Anda memerlukan pembatas di kunci Anda (ruang nama) , buat serial sebagai JSON (untuk penyederhanaan, tetapi kode agar mudah beralih ke MsgPack), gunakan skrip Lua (bahkan jika Anda tidak tahu Lua, subset yang Anda gunakan di Redis kecil).
Saya tidak akan terlalu mengkhawatirkannya dalam fase startup proyek Anda, Anda selalu dapat mengubahnya nanti dan melakukan beberapa perbandingan A/B segera setelah Anda memiliki beberapa data yang dapat diinterpolasi.
Semoga membantu, TW
