Redis เร็วกว่า mongoDB เร็วเท่าใด


204

มีการกล่าวถึงอย่างกว้างขวางว่า Redis คือ "Blazing Fast" และ mongoDB นั้นก็รวดเร็วเช่นกัน แต่ฉันมีปัญหาในการหาตัวเลขจริงเปรียบเทียบผลลัพธ์ของทั้งสอง ด้วยการกำหนดค่าคุณสมบัติและการทำงานที่คล้ายกัน (และอาจแสดงให้เห็นว่าปัจจัยที่เปลี่ยนแปลงไปด้วยการกำหนดค่าและการทำงานที่แตกต่างกัน) ฯลฯ Redis เร็วขึ้น 10 เท่าหรือไม่ 2x เร็วกว่าหรือเร็วขึ้น 5 เท่า?

ฉันพูดถึงการแสดงเท่านั้น ฉันเข้าใจว่า mongoDB เป็นเครื่องมือที่แตกต่างและมีชุดคุณลักษณะที่สมบูรณ์ยิ่งขึ้น นี่ไม่ใช่ "is mongoDB ที่ดีกว่าอภิปรายกว่า Redis" ฉันถามว่า Redis มีประสิทธิภาพเหนือกว่า mongoDB อย่างไร

ณ จุดนี้แม้การวัดประสิทธิภาพราคาถูกจะดีกว่าการไม่มีการวัดประสิทธิภาพ


10
การเปรียบเทียบราคาถูกนั้นดีกว่าการเปรียบเทียบ ขอบคุณสำหรับคำถาม
Maziyar

2
โดยทั่วไปการดูแลเกี่ยวกับความแตกต่างระหว่าง 5,000 ops / วินาทีและ 10,000 ops / วินาทีมักจะเป็นกรณีของการเพิ่มประสิทธิภาพก่อนวัยอันควร ที่กล่าวว่ามันยังคงเป็นคำตอบที่น่าสนใจ :)
เควิน

คำตอบ:


238

ผลลัพท์คร่าวๆจากมาตรฐานต่อไปนี้: การเขียน 2x, 3x อ่าน

นี่เป็นเกณฑ์มาตรฐานอย่างง่ายใน python ที่คุณสามารถปรับให้เข้ากับวัตถุประสงค์ของคุณได้ฉันดูว่าแต่ละคนจะทำงานได้ดีเพียงใดการตั้งค่า / รับค่า:

#!/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)

ผลลัพธ์สำหรับ mongodb 1.8.1 และ redis 2.2.5 และ pymongo ล่าสุด / redis-py ล่าสุด:

$ ./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

นำผลการทดสอบมาพร้อมเม็ดเกลือแน่นอน! หากคุณกำลังเขียนโปรแกรมในภาษาอื่นใช้ไคลเอนต์อื่น ๆ / การใช้งานที่แตกต่างกัน ฯลฯ ผลลัพธ์ของคุณจะแตกต่างกันไป ไม่พูดถึงการใช้งานของคุณจะแตกต่างอย่างสิ้นเชิง! ทางออกที่ดีที่สุดของคุณคือการกำหนดมาตรฐานด้วยตนเองในลักษณะที่คุณต้องการใช้อย่างแม่นยำ คุณอาจหาวิธีที่ดีที่สุดในการใช้ประโยชน์จากแต่ละวิธี มาตรฐานเสมอสำหรับตัวคุณเอง!


3
เป็นความคิดเห็นที่คุ้มค่าที่ MongoDB และ Redis มีโครงสร้างการคงอยู่ที่แตกต่างกันและ Redis สนับสนุนเฉพาะสกีมาข้อมูลที่สามารถใส่ในหน่วยความจำได้ แม้ว่า ram จะราคาถูกถ้าคุณต้องการใช้ / เก็บข้อมูลมากกว่า 12-16GB ฉันจะเห็นว่าตัวเลือกเซิร์ฟเวอร์ของคุณเป็นอย่างไร
Tracker1

53
@Sivann โพสต์นี้เริ่มจากการไม่มีการวัดประสิทธิภาพไปยังการวัดมาตรฐาน "หยาบ" ที่ระบุไว้อย่างชัดเจน อย่าหมุนรอบด้วยเรื่องไร้สาระ แน่นอนเงื่อนไขที่แตกต่างสามารถเปลี่ยนแปลงผลลัพธ์ ส่งกลับและส่งการวัดประสิทธิภาพของคุณเองที่ทดสอบเคสและลิงก์ของคุณจากโพสต์นี้แทนจากนั้นเราทุกคนจะได้รับประโยชน์จากความคิดเห็นที่ "ทดสอบ" ของคุณ
Homer6

2
@sivann การกำหนดค่าเริ่มต้น (จัดส่ง) คือสิ่งที่เกณฑ์มาตรฐานนี้กำลังทำการทดสอบ IMHO การกำหนดค่าเริ่มต้นกำหนดด้านของรั้ว fsync ที่แพ็คเกจตั้งอยู่ สำหรับ Redis จะมีการโฆษณาเป็นเซิร์ฟเวอร์หน่วยความจำที่กระตุ้นให้ผู้คนใช้ทางเลือกอื่นเมื่อฐานข้อมูลมีขนาดใหญ่กว่าหน่วยความจำระบบทั้งหมด สำหรับ MongoDB จะมีการโฆษณาเป็นฐานข้อมูล Postgres จะไม่ปิด fsync เพราะเห็นได้ชัดว่าอยู่ในค่ายที่มีอยู่ คนส่วนใหญ่ไม่ได้แก้ไขการกำหนดค่าดังนั้นมาตรฐานนี้ค่อนข้างแม่นยำสำหรับกรณีเหล่านั้น
Homer6

4
ฉันเห็นด้วยกับ @sivann มาตรฐานที่คุณโพสต์นั้นมีข้อบกพร่องร้ายแรง MongoDB เป็นแบบมัลติเธรดและ Redis ไม่ใช่ หากมาตรฐานของคุณเป็นแบบมัลติเธรดคุณจะเห็นว่า MongoDb มีปริมาณงานสูงกว่าในเครื่องมัลติคอร์
ColinM

2
@ Homer6 แม้สำหรับหน่วยความจำแบบ DB คุณควรทดสอบด้วยการเปิดใช้งานWriteConcern (ปิดใช้งานโดยค่าเริ่มต้น) การทดสอบที่ปราศจากนั้นเป็นเรื่องไร้สาระสำหรับการวัดผลทุกประเภท คล้ายกับเรดดิส ฐานข้อมูลที่ไม่ซิงค์บนดิสก์ธุรกรรมทั้งหมดรักษาความปลอดภัยโดยการจำลองข้อมูลไปยังเซิร์ฟเวอร์อย่างน้อย 2 แห่ง นั่นหมายความว่าการเขียนของคุณจะไม่รอการซิงค์ดิสก์ แต่เป็นการจำลองเครือข่ายก่อนส่งคืน การไม่รอข้อผิดพลาดเป็นสิ่งที่ไม่เคยทำ ไม่ตรวจจับว่าสายเคเบิลเครือข่ายเชื่อมต่ออยู่เมื่อเขียนไปยังเครือข่าย
sivann

18

โปรดตรวจสอบโพสต์นี้เกี่ยวกับการวิเคราะห์ประสิทธิภาพการแทรก Redis และ MongoDB:

มากถึง 5,000 รายการ mongodb $ push นั้นเร็วกว่าเมื่อเทียบกับ Redis RPUSH จากนั้นมันจะช้าอย่างไม่น่าเชื่อประเภทของอาร์เรย์ mongodb อาจมีเวลาการแทรกแบบเชิงเส้นดังนั้นมันจึงช้าลงและช้าลง mongodb อาจได้รับการแสดงเล็กน้อยโดยการเปิดเผยประเภทรายการการแทรกเวลาคงที่ แต่แม้จะมีประเภทอาเรย์เชิงเส้นเวลา (ซึ่งสามารถรับประกันการค้นหาเวลาคงที่) แต่ก็มีแอปพลิเคชันสำหรับชุดข้อมูลขนาดเล็ก


15

มาตรฐานที่ดีและเรียบง่าย

ฉันพยายามคำนวณผลลัพธ์อีกครั้งโดยใช้ Redis เวอร์ชันปัจจุบัน (2.6.16) และ Mongo (2.4.8) และนี่คือผลลัพธ์

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

โพสต์บล็อกนี้เปรียบเทียบทั้งคู่ แต่ใช้ node.js มันแสดงผลของการเพิ่มจำนวนรายการในฐานข้อมูลพร้อมกับเวลา


8

ตัวเลขจะหายากเนื่องจากทั้งสองไม่อยู่ในพื้นที่เดียวกัน คำตอบทั่วไปคือ Redis เร็วขึ้น 10 - 30% เมื่อชุดข้อมูลพอดีกับหน่วยความจำในการทำงานของเครื่องเดียว เมื่อเกินจำนวนข้อมูลนั้นแล้ว Redis จะล้มเหลว Mongo จะช้าลงตามจำนวนซึ่งขึ้นอยู่กับประเภทของโหลด สำหรับการแทรกแบบโหลดเท่านั้นผู้ใช้รายหนึ่งรายงานการชะลอตัวของขนาด 6 ถึง 7 คำสั่ง (10,000 ถึง 100,000 เท่า) แต่รายงานดังกล่าวยอมรับว่ามีปัญหาการกำหนดค่าและนี่เป็นภาระการทำงานที่ผิดปกติมาก โหลดหนักในการอ่านปกติโดยปกติจะช้าลงประมาณ 10 เท่าเมื่อข้อมูลบางอย่างต้องอ่านจากดิสก์

บทสรุป: Redis จะเร็วขึ้น แต่ไม่มากทั้ง


7

นี่คือบทความที่ยอดเยี่ยมเกี่ยวกับประสิทธิภาพของเซสชันในกรอบทอร์นาโดอายุประมาณ 1 ปี มันมีการเปรียบเทียบระหว่างการใช้งานที่แตกต่างกันไม่กี่แห่งซึ่งรวมถึง Redis และ MongoDB กราฟในบทความระบุว่า Redis อยู่ด้านหลัง MongoDB ประมาณ 10% ในกรณีการใช้งานเฉพาะนี้

Redis มาพร้อมกับเกณฑ์มาตรฐานในตัวที่จะวิเคราะห์ประสิทธิภาพของเครื่องที่คุณอยู่ มีข้อมูลดิบมากมายที่Benchmark wikiสำหรับ Redis แต่คุณอาจต้องมอง Mongo สักหน่อย เช่นเดียวกับที่นี่ , ที่นี่และบางสุ่มหมายเลขขัด ( แต่มันจะช่วยให้คุณเป็นจุดเริ่มต้นสำหรับการทำงานบาง MongoDB มาตรฐานตัวเอง)

ฉันเชื่อว่าทางออกที่ดีที่สุดสำหรับปัญหานี้คือการทดสอบด้วยตัวเองในประเภทของสถานการณ์ที่คุณคาดหวัง


มาตรฐานของ Tornado นั้นสอดคล้องกับการทดสอบของฉันในการใช้ Redis และ MongoDb เป็นแบ็กเอนด์ Zend_Cache ฟังก์ชันการทำงานที่สมบูรณ์ยิ่งขึ้นของ MongoDb ช่วยให้คุณใช้คำขอน้อยลงและการออกแบบแบบมัลติเธรดมีขนาดที่ดีกว่ากระบวนการ Redis เดียวซึ่งไม่ได้เป็นแบบมัลติเธรด สรุปก็คือ MongoDb มีขนาดสูงขึ้น Redis ไม่รองรับหน่วยความจำเสมือนอีกต่อไป
ColinM

3

ในกรณีของฉันสิ่งที่เป็นตัวกำหนดปัจจัยในการเปรียบเทียบประสิทธิภาพคือ MongoDb WriteConcern ที่ใช้ ไดรเวอร์ mongo ส่วนใหญ่ในปัจจุบันจะตั้งค่าเริ่มต้น WriteConcern เป็น ACKNOWLEDGED ซึ่งหมายถึง 'เขียนไปยัง RAM' ( Mongo2.6.3-WriteConcern ) ในเรื่องนั้นมันเปรียบได้กับ redis สำหรับการเขียนส่วนใหญ่

แต่ความเป็นจริงนั้นขึ้นอยู่กับความต้องการของแอปพลิเคชันและการตั้งค่าสภาพแวดล้อมการผลิตคุณอาจต้องการเปลี่ยนข้อกังวลนี้เป็น ถ้าจำเป็น

จากนั้นคุณอาจเริ่มเห็นประสิทธิภาพลดลง ปัจจัยสำคัญอื่น ๆ ได้แก่ การปรับรูปแบบการเข้าถึงข้อมูลของคุณให้ดีขึ้นอย่างไรดัชนีพลาด% (ดูmongostat ) และดัชนีโดยทั่วไป


0

ฉันคิดว่า 2-3X ของเบนช์มาร์กที่แสดงนั้นทำให้เข้าใจผิดเพราะถ้าคุณยังขึ้นอยู่กับฮาร์ดแวร์ที่คุณใช้บน - จากประสบการณ์ของฉันเครื่องที่ 'แข็งแกร่ง' ก็คือช่องว่างที่ใหญ่กว่า (เพื่อ Redis) อาจเป็นเพราะความจริงที่ว่าเบนช์มาร์กจะ จำกัด ขอบเขตหน่วยความจำอย่างรวดเร็ว

สำหรับความจุของหน่วยความจำ - นี่เป็นความจริงบางส่วนเนื่องจากยังมีวิธีที่จะไปรอบ ๆ มีผลิตภัณฑ์ (เชิงพาณิชย์) ที่เขียนกลับ Redis ข้อมูลไปยังดิสก์และโซลูชั่นคลัสเตอร์ (multi-sharded) ที่เอาชนะขนาดหน่วยความจำ การ จำกัด

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.