Seberapa cepat Redis daripada mongoDB?


204

Disebutkan secara luas bahwa Redis adalah "Blazing Fast" dan mongoDB juga cepat. Tapi, saya kesulitan menemukan angka aktual membandingkan hasil keduanya. Dengan konfigurasi, fitur, dan operasi yang serupa (dan mungkin menunjukkan bagaimana faktor berubah dengan konfigurasi dan operasi yang berbeda), dll, apakah Redis 10x lebih cepat ?, 2x lebih cepat?, 5x lebih cepat?

Saya HANYA berbicara tentang kinerja. Saya mengerti bahwa mongoDB adalah alat yang berbeda dan memiliki set fitur yang lebih kaya. Ini bukan debat "Apakah mongoDB lebih baik dari Redis". Saya bertanya, dengan margin apa Redis mengungguli mongoDB?

Pada titik ini, bahkan tolok ukur murah lebih baik daripada tanpa tolok ukur.


10
Tolok ukur murah selalu lebih baik daripada tidak ada tolok ukur. Terima kasih untuk pertanyaannya.
Maziyar

2
Secara umum, peduli tentang perbedaan antara 5.000 ops / dtk dan 10.000 ops / dtk sering merupakan kasus optimasi prematur. Yang mengatakan, itu masih merupakan jawaban yang menarik :)
Kevin

Jawaban:


238

Hasil kasar dari patokan berikut: 2x menulis, 3x dibaca .

Berikut ini adalah patokan sederhana dalam python yang dapat Anda sesuaikan dengan tujuan Anda, saya melihat seberapa baik masing-masing akan melakukan pengaturan / pengambilan nilai:

#!/usr/bin/env python2.7
import sys, time
from pymongo import Connection
import redis

# connect to redis & mongodb
redis = redis.Redis()
mongo = Connection().test
collection = mongo['test']
collection.ensure_index('key', unique=True)

def mongo_set(data):
    for k, v in data.iteritems():
        collection.insert({'key': k, 'value': v})

def mongo_get(data):
    for k in data.iterkeys():
        val = collection.find_one({'key': k}, fields=('value',)).get('value')

def redis_set(data):
    for k, v in data.iteritems():
        redis.set(k, v)

def redis_get(data):
    for k in data.iterkeys():
        val = redis.get(k)

def do_tests(num, tests):
    # setup dict with key/values to retrieve
    data = {'key' + str(i): 'val' + str(i)*100 for i in range(num)}
    # run tests
    for test in tests:
        start = time.time()
        test(data)
        elapsed = time.time() - start
        print "Completed %s: %d ops in %.2f seconds : %.1f ops/sec" % (test.__name__, num, elapsed, num / elapsed)

if __name__ == '__main__':
    num = 1000 if len(sys.argv) == 1 else int(sys.argv[1])
    tests = [mongo_set, mongo_get, redis_set, redis_get] # order of tests is significant here!
    do_tests(num, tests)

Hasil untuk dengan mongodb 1.8.1 dan redis 2.2.5 dan pymongo / redis-py terbaru:

$ ./cache_benchmark.py 10000
Completed mongo_set: 10000 ops in 1.40 seconds : 7167.6 ops/sec
Completed mongo_get: 10000 ops in 2.38 seconds : 4206.2 ops/sec
Completed redis_set: 10000 ops in 0.78 seconds : 12752.6 ops/sec
Completed redis_get: 10000 ops in 0.89 seconds : 11277.0 ops/sec

Ambil hasilnya dengan sebutir garam tentunya! Jika Anda memprogram dalam bahasa lain, menggunakan klien lain / implementasi berbeda, dll. Hasil Anda akan sangat bervariasi. Belum lagi penggunaan Anda akan sangat berbeda! Taruhan terbaik Anda adalah dengan membandingkannya sendiri, tepatnya dengan cara yang ingin Anda gunakan. Sebagai akibat wajar Anda mungkin akan menemukan cara terbaik untuk memanfaatkan masing-masing. Selalu patok untuk diri sendiri!


3
Layak dikomentari bahwa MongoDB dan Redis memiliki struktur ketekunan yang berbeda, dan bahwa Redis hanya mendukung skema data yang mampu masuk dalam memori. Meskipun ram murah, jika Anda perlu menggunakan / menyimpan lebih dari 12-16GB data, saya akan melihat seperti apa pilihan server Anda.
Pelacak1

53
@sivann posting ini beralih dari tidak ada tolok ukur ke tolok ukur "kasar" yang dinyatakan dengan jelas. Jangan menjadi troll dengan omong kosong "tolok ukur yang menyesatkan". Tentu saja kondisi yang berbeda dapat mengubah hasilnya. Berkontribusi kembali dan kirimkan tolok ukur Anda sendiri yang menguji kasus Anda dan tautan dari pos ini sebagai gantinya, maka kita semua akan mendapat manfaat dari pendapat "teruji" Anda.
Homer6

2
@sivann Konfigurasi default (yang dikirimkan) adalah yang diuji oleh patokan ini. IMHO, konfigurasi default menentukan di sisi mana fsync memagari sebuah paket. Untuk Redis, itu diiklankan sebagai server memori yang mendesak orang untuk menggunakan alternatif lain ketika database lebih besar dari total memori sistem. Untuk MongoDB, itu diiklankan sebagai basis data. Postgres tidak akan pernah mematikan fsync karena mereka jelas berada di kamp kegigihan. Kebanyakan orang tidak mengubah konfigurasi, jadi tolok ukur ini agak akurat untuk kasus-kasus itu.
Homer6

4
Saya setuju dengan @sivann, patokan yang Anda posting cacat fatal . MongoDB adalah multi-threaded dan Redis tidak. Jika benchmark Anda multi-threaded, Anda akan melihat bahwa MongoDb sebenarnya memiliki throughput yang lebih tinggi pada mesin multi-core.
ColinM

2
@ Homer6 bahkan untuk DB yang berorientasi pada memori, Anda harus menguji dengan WriteConcern diaktifkan (dinonaktifkan secara default). Pengujian tanpa benar-benar omong kosong untuk segala jenis tolok ukur. Mirip dengan reddis. DB yang tidak melakukan sinkronisasi pada disk semua transaksi, menjaga keamanan dengan mereplikasi data ke setidaknya 2 server. Itu berarti tulisan Anda tidak menunggu sinkronisasi disk, tetapi untuk replikasi jaringan sebelum kembali. Tidak menunggu kesalahan adalah sesuatu yang tidak pernah dilakukan pada prod. suka tidak mendeteksi jika kabel jaringan terhubung saat menulis ke jaringan.
sivann

18

Silakan periksa posting ini tentang analisis kinerja penyisipan Redis dan MongoDB:

Hingga 5000 entri mongodb $ push lebih cepat bahkan jika dibandingkan dengan Redis RPUSH, maka itu menjadi sangat lambat, mungkin tipe array mongodb memiliki waktu penyisipan linier dan sehingga menjadi lebih lambat dan lebih lambat. mongodb mungkin mendapatkan sedikit kinerja dengan mengekspos tipe daftar penyisipan waktu yang konstan, tetapi bahkan dengan tipe array waktu linier (yang dapat menjamin pencarian waktu yang konstan) ia memiliki aplikasi untuk set kecil data.


15

Tolok ukur yang bagus dan sederhana

Saya mencoba untuk menghitung ulang hasilnya lagi menggunakan versi redis saat ini (2.6.16) dan mongo (2.4.8) dan inilah hasilnya

Completed mongo_set: 100000 ops in 5.23 seconds : 19134.6 ops/sec
Completed mongo_get: 100000 ops in 36.98 seconds : 2703.9 ops/sec
Completed redis_set: 100000 ops in 6.50 seconds : 15389.4 ops/sec
Completed redis_get: 100000 ops in 5.59 seconds : 17896.3 ops/sec

Juga posting blog ini membandingkan keduanya tetapi menggunakan node.js. Ini menunjukkan efek peningkatan jumlah entri dalam database seiring dengan waktu.


8

Angka akan sulit ditemukan karena keduanya tidak cukup dalam ruang yang sama. Jawaban umum adalah bahwa Redis 10 - 30% lebih cepat ketika kumpulan data sesuai dengan memori kerja satu mesin. Setelah jumlah data terlampaui, Redis gagal. Mongo akan melambat pada jumlah yang tergantung pada jenis beban. Untuk jenis penyisipan saja, satu pengguna baru-baru ini melaporkan perlambatan 6 hingga 7 kali lipat (10.000 hingga 100.000 kali) tetapi laporan itu juga mengakui bahwa ada masalah konfigurasi, dan bahwa ini adalah beban kerja yang sangat tidak lazim. Normal membaca banyak beban secara anekdot lambat sekitar 10X ketika beberapa data harus dibaca dari disk.

Kesimpulan: Redis akan lebih cepat tetapi tidak secara keseluruhan.


7

Berikut adalah artikel yang bagus tentang kinerja sesi dalam kerangka Tornado sekitar 1 tahun. Ini memiliki perbandingan antara beberapa implementasi yang berbeda, termasuk Redis dan MongoDB. Grafik dalam artikel menyatakan bahwa Redis berada di belakang MongoDB sekitar 10% dalam kasus penggunaan khusus ini.

Redis hadir dengan tolok ukur bawaan yang akan menganalisis kinerja alat berat yang Anda pakai. Ada satu ton data mentah darinya di wiki Benchmark untuk Redis. Tapi Anda mungkin harus sedikit melihat-lihat Mongo. Seperti di sini , di sini , dan beberapa nomor semir acak (tetapi memberi Anda titik awal untuk menjalankan beberapa tolok ukur MongoDB sendiri).

Saya percaya solusi terbaik untuk masalah ini adalah dengan melakukan tes sendiri dalam jenis situasi yang Anda harapkan.


Benchmark Tornado selaras dengan tes saya sendiri dalam menggunakan Redis dan MongoDb sebagai backend Zend_Cache. Fungsionalitas yang lebih kaya dari MongoDb memungkinkan Anda menggunakan lebih sedikit permintaan dan skala desain multi-threaded jauh lebih baik daripada proses Redis tunggal yang tidak multi-threaded. Kesimpulannya adalah bahwa skala MongoDb lebih tinggi. Redis juga tidak lagi mendukung memori virtual.
ColinM

3

Dalam kasus saya, apa yang menjadi faktor penentu dalam perbandingan kinerja, adalah MongoDb WriteConcern yang digunakan. Kebanyakan driver mongo saat ini akan menetapkan WriteConcern default ke ACKNOWLEDGED yang berarti 'ditulis ke RAM' ( Mongo2.6.3-WriteConcern ), dalam hal itu, sangat sebanding dengan redis untuk sebagian besar operasi penulisan.

Tetapi kenyataannya tergantung pada kebutuhan aplikasi Anda dan pengaturan lingkungan produksi, Anda mungkin ingin mengubah masalah ini ke WriteConcern.JOURNALED (ditulis ke oplog) atau WriteConcern.FSYNCED (ditulis ke disk) atau bahkan ditulis ke set replika (cadangan) jika dibutuhkan.

Maka Anda mungkin mulai melihat penurunan kinerja. Faktor penting lainnya juga termasuk, seberapa optimal pola akses data Anda, indeks kehilangan% (lihat mongostat ) dan indeks secara umum.


0

Saya berpikir bahwa 2-3X pada patokan yang ditampilkan menyesatkan, karena jika Anda juga bergantung pada perangkat keras yang Anda gunakan - dari pengalaman saya, semakin kuat 'mesinnya, semakin besar kesenjangan (mendukung Redis) akan, mungkin oleh fakta bahwa patokan hits batas memori cukup cepat.

Adapun kapasitas memori - ini sebagian benar, karena ada juga cara untuk mengatasinya, ada produk (komersial) yang menulis kembali data Redis ke disk, dan juga solusi cluster (multi-sharded) yang mengatasi ukuran memori keterbatasan.

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.