เรากำลังใช้ Ruby web-app กับเซิร์ฟเวอร์Redisเพื่อทำการแคช มีจุดทดสอบMemcachedแทนหรือไม่

อะไรจะทำให้เรามีประสิทธิภาพที่ดีขึ้น ข้อดีหรือข้อเสียระหว่าง Redis และ Memcached?

คะแนนที่ต้องพิจารณา:

• ความเร็วในการอ่าน / เขียน
• การใช้ความจำ.
• การถ่ายโอนข้อมูลดิสก์ I / O
• ขูดหินปูน

สรุป (TL; DR)

อัปเดต 3 มิถุนายน 2560

Redis มีประสิทธิภาพมากขึ้นเป็นที่นิยมมากขึ้นและรองรับได้ดีกว่า memcached Memcached สามารถทำสิ่งเล็กน้อยที่ Redis ทำได้ Redis จะดีกว่าแม้จะมีฟีเจอร์ที่ทับซ้อนกัน

สำหรับสิ่งใหม่ใช้ Redis

Memcached vs Redis: การเปรียบเทียบโดยตรง

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

จุดที่ต้องพิจารณา

เมื่อใช้เพื่อสิ่งเดียวกันนี่คือการเปรียบเทียบโดยใช้ "คะแนนที่ควรพิจารณา" ของคำถามเดิม

• ความเร็วในการอ่าน / เขียน : ทั้งสองอย่างรวดเร็วมาก การวัดประสิทธิภาพแตกต่างกันไปตามปริมาณงานรุ่นและปัจจัยอื่น ๆ แต่โดยทั่วไปแล้วการแสดงสีแดงให้เร็วหรือเกือบเร็วเท่ากับ memcached ฉันแนะนำ Redis แต่ไม่ใช่เพราะ memcached ช้า มันไม่ใช่.
• การใช้หน่วยความจำ : Redis จะดีกว่า
  • memcached: คุณระบุขนาดแคชและเมื่อคุณแทรกไอเท็ม daemon จะโตขึ้นอย่างรวดเร็วมากกว่าขนาดนี้เล็กน้อย ไม่มีทางที่จะเรียกคืนพื้นที่ใด ๆ ได้จริง ๆ ไม่ต้องรีสตาร์ท memcached คีย์ทั้งหมดของคุณอาจหมดอายุคุณสามารถล้างข้อมูลในฐานข้อมูลและจะยังคงใช้ RAM เต็มรูปแบบที่คุณกำหนดค่าด้วย
  • redis: การตั้งค่าขนาดสูงสุดนั้นขึ้นอยู่กับคุณ Redis จะไม่ใช้มากกว่าที่เคยมีและจะให้หน่วยความจำกลับมาที่คุณไม่ได้ใช้อีกต่อไป
  • ฉันเก็บประโยคแบบสุ่ม 100,000 ~ 2KB (~ 200MB) ไว้ในประโยคทั้งสอง การใช้แรม Memcached เพิ่มขึ้นเป็น ~ 225MB การใช้ RAM Redis เพิ่มขึ้นเป็น ~ 228MB หลังจากล้างทั้งสองแล้ว Redis ก็ลดลงเหลือ ~ 29MB และ memcached จะอยู่ที่ ~ 225MB มีประสิทธิภาพคล้ายกันกับวิธีจัดเก็บข้อมูล แต่มีเพียงคนเดียวที่สามารถเรียกคืนได้
• การดัมพ์ I / O ของดิสก์ : การชนะที่ชัดเจนสำหรับ Redis เนื่องจากการทำเช่นนี้เป็นค่าเริ่มต้นและมีความคงทนที่กำหนดค่าได้มาก Memcached ไม่มีกลไกสำหรับการถ่ายโอนข้อมูลไปยังดิสก์โดยไม่ใช้เครื่องมือของบุคคลที่สาม
• การปรับสเกล : ทั้งคู่ให้พื้นที่ว่างมากสำหรับคุณก่อนที่คุณจะต้องการแคชมากกว่าหนึ่งอินสแตนซ์ Redis มีเครื่องมือที่จะช่วยให้คุณก้าวข้ามสิ่งนั้นไปได้ขณะที่ memcached ไม่มี

memcached

Memcached เป็นเซิร์ฟเวอร์แคชแบบง่าย อนุญาตให้คุณจัดเก็บคู่ของคีย์ / ค่าที่ค่าถูก จำกัด ให้เป็นสตริงสูงสุด 1MB

มันดีที่นี่ แต่ก็แค่นั้นแหละ คุณสามารถเข้าถึงค่าเหล่านั้นด้วยกุญแจของพวกเขาด้วยความเร็วสูงมากมักจะทำให้เครือข่ายที่มีอยู่อิ่มตัวหรือแบนด์วิดธ์หน่วยความจำ

เมื่อคุณรีสตาร์ท memcached ข้อมูลของคุณจะหายไป นี่เป็นสิ่งที่ดีสำหรับแคช คุณไม่ควรเก็บอะไรที่สำคัญไว้ที่นั่น

หากคุณต้องการประสิทธิภาพสูงหรือความพร้อมใช้งานสูงมีเครื่องมือผลิตภัณฑ์และบริการของบุคคลที่สาม

Redis

Redis สามารถทำงานเช่นเดียวกับ memcached สามารถและสามารถทำได้ดีกว่า

Redis สามารถทำหน้าที่เป็นแคชได้เช่นกัน มันสามารถเก็บคู่ของคีย์ / ค่าได้เช่นกัน ในสีแดงพวกเขายังสามารถได้ถึง 512MB

คุณสามารถปิดการคงอยู่และมันจะสูญเสียข้อมูลของคุณอย่างมีความสุขเมื่อรีสตาร์ทเช่นกัน หากคุณต้องการให้แคชของคุณอยู่รอดรีสตาร์ทจะช่วยให้คุณทำเช่นนั้นได้ ที่จริงแล้วนั่นคือค่าเริ่มต้น

มันเร็วมากเช่นกันมักถูก จำกัด ด้วยแบนด์วิดท์เครือข่ายหรือหน่วยความจำ

หากอินสแตนซ์หนึ่งของ redis / memcached มีประสิทธิภาพไม่เพียงพอสำหรับเวิร์กโหลดของคุณ redis เป็นตัวเลือกที่ชัดเจน Redis รวมถึงการสนับสนุนคลัสเตอร์และมาพร้อมกับเครื่องมือความพร้อมใช้งานสูง ( redis-sentinel ) ขวา "ในกล่อง" ในช่วงไม่กี่ปีที่ผ่านมา Redis ก็กลายเป็นผู้นำที่ชัดเจนในการใช้เครื่องมือของบุคคลที่สาม บริษัท เช่น Redis Labs, Amazon และอื่น ๆ เสนอเครื่องมือและบริการ redis ที่มีประโยชน์มากมาย ระบบนิเวศรอบ Redis มีขนาดใหญ่กว่ามาก จำนวนการปรับใช้ขนาดใหญ่ในขณะนี้น่าจะมากกว่า memcached

The Redis Superset

Redis เป็นมากกว่าแคช มันเป็นเซิร์ฟเวอร์โครงสร้างข้อมูลในหน่วยความจำ ด้านล่างคุณจะพบภาพรวมอย่างรวดเร็วของสิ่งต่าง ๆ ที่ Redis ทำได้นอกเหนือจากการเป็นแคช / คีย์ / ค่าอย่างง่ายเช่น memcached คุณสมบัติส่วนใหญ่ของ redis เป็นสิ่งที่ memcached ไม่สามารถทำได้

เอกสาร

Redis เป็นเอกสารที่ดีกว่า memcached แม้ว่าสิ่งนี้อาจเป็นเรื่องส่วนตัว แต่ดูเหมือนว่าจะเป็นจริงมากขึ้นเรื่อย ๆ ตลอดเวลา

redis.ioเป็นแหล่งข้อมูลการนำทางที่ง่ายดาย มันช่วยให้คุณลอง redis ในเบราว์เซอร์และให้ตัวอย่างแบบอินเทอร์แอคทีฟกับแต่ละคำสั่งในเอกสาร

ขณะนี้มีสแต็กโอเวอร์โฟลว์มากถึง 2 เท่าสำหรับ redis เป็น memcached ผลการค้นหาของ Google มากถึง 2 เท่า ตัวอย่างที่เข้าถึงได้ง่ายขึ้นในภาษาอื่น ๆ พัฒนาอย่างต่อเนื่อง การพัฒนาลูกค้าที่ใช้งานมากขึ้น การวัดเหล่านี้อาจไม่ได้มีความหมายแยกกันมากนัก แต่เมื่อใช้ร่วมกันพวกเขาจะวาดภาพที่ชัดเจนว่าการสนับสนุนและเอกสารประกอบสำหรับ Redis นั้นใหญ่กว่าและทันสมัยกว่ามาก

วิริยะ

โดยค่าเริ่มต้น redis ยืนยันข้อมูลของคุณไปยังดิสก์โดยใช้กลไกที่เรียกว่าสแนปชอต หากคุณมี RAM เพียงพอก็สามารถเขียนข้อมูลทั้งหมดลงดิสก์ได้เกือบจะไม่มีประสิทธิภาพลดลง เกือบฟรีแล้ว!

ในโหมดสแนปชอตมีโอกาสที่ความผิดพลาดฉับพลันอาจส่งผลให้ข้อมูลสูญหายเล็กน้อย หากคุณต้องการตรวจสอบให้แน่ใจว่าไม่มีข้อมูลสูญหายไม่ต้องกังวล redis มีข้อมูลของคุณอยู่ที่นั่นด้วยโหมด AOF (Append Only File) ในข้อมูลโหมดการคงอยู่นี้สามารถซิงค์กับดิสก์ได้ตามที่เขียน วิธีนี้สามารถลดปริมาณงานการเขียนสูงสุดได้อย่างรวดเร็ว แต่ดิสก์ของคุณสามารถเขียนได้เร็ว แต่ก็ควรจะค่อนข้างเร็ว

มีตัวเลือกการกำหนดค่ามากมายเพื่อปรับแต่งการคงอยู่หากคุณต้องการ แต่ค่าเริ่มต้นนั้นสมเหตุสมผลมาก ตัวเลือกเหล่านี้ทำให้การติดตั้ง redis นั้นเป็นเรื่องง่ายและปลอดภัยในการจัดเก็บข้อมูล มันเป็นฐานข้อมูลจริง

ประเภทข้อมูลจำนวนมาก

Memcached ถูก จำกัด ไว้ที่สตริง แต่ Redis เป็นเซิร์ฟเวอร์โครงสร้างข้อมูลที่สามารถรองรับชนิดข้อมูลที่หลากหลาย นอกจากนี้ยังมีคำสั่งที่คุณต้องการใช้ประโยชน์จากประเภทข้อมูลเหล่านั้นให้มากที่สุด

สตริง ( คำสั่ง )

ข้อความธรรมดาหรือค่าไบนารีที่มีขนาดสูงสุด 512MB นี่เป็นเพียงชนิดข้อมูล redis และการแชร์ memcached แม้ว่าสตริง memcached จะถูก จำกัด ที่ 1MB

Redis ให้เครื่องมือเพิ่มเติมสำหรับการใช้ประโยชน์จากประเภทข้อมูลนี้โดยเสนอคำสั่งสำหรับการดำเนินการระดับบิตการจัดการระดับบิตสนับสนุนการเพิ่ม / ลดจำนวนจุดลอยตัวแบบสอบถามแบบพิสัยและการดำเนินการแบบหลายคีย์ Memcached ไม่รองรับสิ่งเหล่านี้

สตริงมีประโยชน์สำหรับกรณีการใช้งานทุกประเภทซึ่งเป็นเหตุผลที่ memcached มีประโยชน์กับประเภทข้อมูลนี้เพียงอย่างเดียว

แฮช ( คำสั่ง )

Hashes นั้นเหมือนกับที่เก็บค่าคีย์ภายในที่จัดเก็บค่าคีย์ พวกเขาแมประหว่างเขตข้อมูลสตริงและค่าสตริง การแมปฟิลด์ -> ค่าโดยใช้แฮชจะมีพื้นที่ว่างที่มีประสิทธิภาพมากกว่าการแม็พคีย์ -> โดยใช้สตริงปกติ

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

ตัวอย่างหนึ่งที่ใช้แฮชคือการจัดเก็บโปรไฟล์ผู้ใช้ระหว่างแอปพลิเคชัน แฮช Redis ที่จัดเก็บด้วย ID ผู้ใช้เป็นคีย์จะช่วยให้คุณสามารถจัดเก็บข้อมูลจำนวนมากเกี่ยวกับผู้ใช้ได้ตามต้องการในขณะที่ยังคงเก็บไว้ภายใต้คีย์เดียว ข้อดีของการใช้แฮชแทนการทำให้ซีเรียลโปรไฟล์เป็นสตริงคือคุณสามารถมีแอพพลิเคชั่นต่าง ๆ อ่าน / เขียนฟิลด์ต่าง ๆ ภายในโปรไฟล์ผู้ใช้โดยไม่ต้องกังวลเกี่ยวกับแอพหนึ่งที่เอาชนะการเปลี่ยนแปลงที่เกิดขึ้นโดยคนอื่น ๆ ข้อมูล).

รายการ ( คำสั่ง )

รายการ Redis เป็นชุดคำสั่งของสตริง มีการปรับให้เหมาะสมสำหรับการแทรกการอ่านหรือการลบค่าจากด้านบนหรือด้านล่าง (aka: ซ้ายหรือขวา) ของรายการ

Redis มีคำสั่งมากมายสำหรับการใช้ประโยชน์จากลิสต์รวมถึงคำสั่งในการพุช / ป๊อปไอเท็มพุช / ป๊อประหว่างรายการ

รายการทำให้ทนทานยิ่งยวดอะตอมคิว ใช้งานได้ดีกับคิวงาน, บันทึก, บัฟเฟอร์, และกรณีการใช้งานอื่น ๆ

ชุด ( คำสั่ง )

ชุดคือชุดที่ไม่ซ้ำกันของค่าที่ไม่ซ้ำกัน มีการปรับให้เหมาะสมเพื่อให้คุณตรวจสอบได้อย่างรวดเร็วว่ามีค่าอยู่ในชุดเพิ่ม / ลบค่าอย่างรวดเร็วและเพื่อวัดความซ้ำซ้อนกับชุดอื่นหรือไม่

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

Redis ให้หลาย ๆ คำสั่งเพื่อจัดการชุด มีคนที่เห็นได้ชัดเช่นการเพิ่มการลบและการตรวจสอบชุดที่มีอยู่ ดังนั้นคำสั่งที่ชัดเจนน้อยกว่าเช่นการ popping / อ่านรายการสุ่มและคำสั่งสำหรับการดำเนินการสหภาพและทางแยกกับชุดอื่น ๆ

ชุดเรียง ( คำสั่ง )

ชุดที่เรียงเป็นชุดของค่าที่ไม่ซ้ำกัน คำสั่งเหล่านี้ตามชื่อหมายถึงถูกสั่ง พวกเขาได้รับคำสั่งจากคะแนนแล้วพจนานุกรม

ชนิดข้อมูลนี้เหมาะสำหรับการค้นหาอย่างรวดเร็วด้วยคะแนน การรับค่าสูงสุดต่ำสุดหรือช่วงใด ๆ ในระหว่างนั้นจะเร็วมาก

หากคุณเพิ่มผู้ใช้ไปยังกลุ่มที่เรียงลำดับพร้อมกับคะแนนสูงสุดของพวกเขาคุณจะมีกระดานผู้นำที่สมบูรณ์แบบ เมื่อคะแนนสูงสุดใหม่เข้ามาเพียงแค่เพิ่มพวกเขาไปยังชุดอีกครั้งด้วยคะแนนสูงของพวกเขาและมันจะสั่งคณะผู้นำของคุณอีกครั้ง ยังยอดเยี่ยมสำหรับการติดตามครั้งล่าสุดที่ผู้ใช้เข้าชมและผู้ที่ทำงานในแอปพลิเคชันของคุณ

การจัดเก็บค่าที่มีคะแนนเท่ากันจะทำให้เรียงลำดับพจนานุกรม (คิดตามตัวอักษร) สิ่งนี้มีประโยชน์สำหรับสิ่งต่าง ๆ เช่นคุณลักษณะการทำให้สมบูรณ์อัตโนมัติ

คำสั่งชุดที่เรียงลำดับจำนวนมากคล้ายกับคำสั่งสำหรับชุดบางครั้งก็มีพารามิเตอร์คะแนนเพิ่มเติม รวมทั้งยังเป็นคำสั่งสำหรับการจัดการคะแนนและแบบสอบถามโดยคะแนน

ภูมิศาสตร์

Redis มีหลายคำสั่งสำหรับการจัดเก็บการดึงและการวัดข้อมูลทางภูมิศาสตร์ ซึ่งรวมถึงการสอบถามรัศมีและการวัดระยะทางระหว่างจุดต่างๆ

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

บิตแมปและ HyperLogLog

เช่นเดียวกับที่ตั้งทางภูมิศาสตร์ประเภทข้อมูลเหล่านี้ไม่ได้แยกจากกัน เหล่านี้คือคำสั่งที่ให้คุณปฏิบัติต่อข้อมูลสตริงราวกับว่ามันเป็นบิตแมปหรือไฮเปอร์บล็อก

บิตแมปเป็นสิ่งที่ตัวดำเนินการระดับบิตที่ฉันอ้างถึงStringsใช้สำหรับ ชนิดของข้อมูลนี้เป็นกลุ่มอาคารพื้นฐานสำหรับ Reddit ล่าสุดของโครงการศิลปะการทำงานร่วมกัน: R / สถานที่

HyperLogLog ช่วยให้คุณใช้พื้นที่น้อยมากในการนับค่าที่ไม่ซ้ำกันเกือบไม่ จำกัด ด้วยความแม่นยำที่น่าตกใจ ด้วยการใช้เพียง ~ 16KB คุณสามารถนับจำนวนผู้เยี่ยมชมเว็บไซต์ของคุณได้อย่างมีประสิทธิภาพแม้ว่าจำนวนนั้นจะเป็นล้านก็ตาม

ธุรกรรมและปรมาณู

คำสั่งเป็นสีแดงคืออะตอมมิกหมายความว่าคุณสามารถมั่นใจได้ว่าทันทีที่คุณเขียนค่าให้กับ Redis ค่านั้นจะปรากฏให้ลูกค้าทุกคนที่เชื่อมต่อกับ Redis เห็น ไม่ต้องรอให้ค่านั้นเผยแพร่ เทคนิค memcached เป็นอะตอมเช่นกัน แต่ด้วย redis การเพิ่มฟังก์ชั่นทั้งหมดนี้นอกเหนือจาก memcached นั้นมีมูลค่า noting และค่อนข้างน่าประทับใจว่าชนิดข้อมูลและคุณสมบัติเพิ่มเติมทั้งหมดเหล่านี้ยังเป็นอะตอม

แม้ว่าจะไม่เหมือนกับธุรกรรมในฐานข้อมูลเชิงสัมพันธ์ แต่ Redis ก็มีธุรกรรมที่ใช้ "การล็อคในแง่ดี" ( WATCH / MULTI / EXEC )

pipelining

Redis ให้คุณสมบัติที่เรียกว่า ' pipelining ' หากคุณมีคำสั่ง redis จำนวนมากคุณต้องการเรียกใช้งานคุณสามารถใช้ pipelining เพื่อส่งคำสั่งไปยัง redis all-at-one แทนการจ่ายครั้งละครั้ง

โดยปกติเมื่อคุณรันคำสั่งเพื่อ redis หรือ memcached แต่ละคำสั่งจะเป็นรอบการร้องขอ / ตอบกลับที่แยกต่างหาก ด้วย pipelining, redis สามารถบัฟเฟอร์หลายคำสั่งและดำเนินการทั้งหมดในครั้งเดียวตอบสนองกับการตอบสนองทั้งหมดของคำสั่งทั้งหมดของคุณในการตอบกลับเดียว

สิ่งนี้ช่วยให้คุณสามารถรับปริมาณงานที่มากขึ้นในการนำเข้าจำนวนมากหรือการดำเนินการอื่น ๆ ที่เกี่ยวข้องกับคำสั่งจำนวนมาก

ผับ / ตำบล

Redis มีคำสั่งเฉพาะสำหรับฟังก์ชั่น pub / subช่วยให้Redis ทำหน้าที่เป็นผู้เผยแพร่ข้อความความเร็วสูง สิ่งนี้ช่วยให้ไคลเอนต์เดียวสามารถเผยแพร่ข้อความไปยังไคลเอนต์อื่น ๆ ที่เชื่อมต่อกับช่อง

Redis ทำ pub / sub รวมถึงเครื่องมือเกือบทุกชนิด โบรกเกอร์ข้อความเฉพาะเช่นRabbitMQอาจมีข้อได้เปรียบในบางพื้นที่ แต่ความจริงที่ว่าเซิร์ฟเวอร์เดียวกันยังสามารถให้คิวที่คงทนถาวรและโครงสร้างข้อมูลอื่น ๆ ที่ผับ / งานย่อยของคุณต้องการได้ Redis มักจะพิสูจน์ว่าเป็นเครื่องมือที่ดีที่สุดและง่ายที่สุด สำหรับงาน

ลัวะสคริปติ้ง

คุณสามารถคิดถึงสคริปต์ luaเช่น SQL ของ Redis เองหรือกระบวนงานที่เก็บไว้ มันมีทั้งมากกว่าและน้อยกว่านั้น แต่การเปรียบเทียบส่วนใหญ่ใช้งานได้

บางทีคุณอาจมีการคำนวณที่ซับซ้อนที่คุณต้องการให้ Redis ทำ บางทีคุณอาจไม่สามารถทำธุรกรรมของคุณย้อนกลับและต้องการรับประกันทุกขั้นตอนของกระบวนการที่ซับซ้อนจะเกิดขึ้นแบบอะตอม ปัญหาเหล่านี้และอีกมากมายสามารถแก้ไขได้ด้วยการเขียนสคริปต์ lua

สคริปต์ทั้งหมดจะถูกดำเนินการแบบอะตอมดังนั้นถ้าคุณสามารถปรับตรรกะของคุณเป็นสคริปต์ lua คุณมักจะสามารถหลีกเลี่ยงการยุ่งกับธุรกรรมล็อคในแง่ดี

ขูดหินปูน

ดังกล่าวข้างต้น Redis redis-sentinelรวมถึงการสร้างในการสนับสนุนการจัดกลุ่มและมาพร้อมกับเครื่องมือที่มีประสิทธิภาพที่สูงของตัวเองที่เรียกว่า

ข้อสรุป

โดยไม่ลังเลฉันจะแนะนำ redis มากกว่า memcached สำหรับโครงการใหม่ใด ๆ หรือโครงการที่มีอยู่ซึ่งยังไม่ได้ใช้ memcached

ด้านบนอาจฟังดูเหมือนฉันไม่ชอบ memcached ในทางตรงกันข้ามมันเป็นเครื่องมือที่ทรงพลังเรียบง่ายมั่นคงเป็นผู้ใหญ่และแข็งตัว มีบางกรณีที่ใช้งานได้เร็วกว่า redis เล็กน้อย ฉันรัก memcached ฉันไม่คิดว่ามันสมเหตุสมผลสำหรับการพัฒนาในอนาคต

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

มีเพียงสถานการณ์เดียวที่ memcached มีเหตุผลมากกว่านี้: โดยที่ memcached มีการใช้งานเป็นแคชอยู่แล้ว หากคุณแคชด้วย memcached แล้วให้ใช้ต่อไปหากตรงกับความต้องการของคุณ มันอาจไม่คุ้มค่ากับความพยายามที่จะเปลี่ยนเป็นสีแดงและถ้าคุณกำลังจะใช้ Redis เพียงเพื่อแคชมันอาจไม่ได้รับประโยชน์เพียงพอที่จะคุ้มค่ากับเวลาของคุณ หาก memcached ไม่ตอบสนองความต้องการของคุณคุณควรย้ายไปที่ Redis สิ่งนี้เป็นจริงไม่ว่าคุณจะต้องขยายขนาดเกิน memcached หรือคุณต้องการฟังก์ชั่นเพิ่มเติม

ใช้ Redis ถ้า

1. คุณต้องเลือกลบ / หมดอายุไอเท็มในแคช (คุณต้องการสิ่งนี้)

2. คุณต้องการความสามารถในการสืบค้นคีย์ชนิดเฉพาะ อีคิว 'blog1: โพสต์: *', 'blog2: หมวดหมู่: xyz: โพสต์: *' โอ้ใช่! สิ่งนี้สำคัญมาก ใช้สิ่งนี้เพื่อทำให้รายการแคชบางประเภทเลือกไม่ถูกต้อง นอกจากนี้คุณยังสามารถใช้สิ่งนี้เพื่อทำให้แคชแฟรกเมนต์เป็นโมฆะแคชของเพจเฉพาะวัตถุ AR ประเภทที่กำหนดเป็นต้น

3. การคงอยู่ (คุณจะต้องใช้สิ่งนี้ด้วยเช่นกันเว้นแต่คุณจะไม่เป็นไรเพราะแคชของคุณต้องอุ่นเครื่องทุกครั้งที่รีสตาร์ทจำเป็นอย่างยิ่งสำหรับวัตถุที่ไม่ค่อยมีการเปลี่ยนแปลง)

ใช้ memcached ถ้า

1. Memcached ให้คุณปวดหัว!
2. อืมม ... กำลังรวมกลุ่ม Meh ถ้าคุณจะไปไกลขนาดนั้นใช้ Varnish และ Redis สำหรับการแคชแฟรกเมนต์และ AR Objects

จากประสบการณ์ของฉันฉันมีเสถียรภาพที่ดีขึ้นกับ Redis มากกว่า Memcached

Memcached มีหลายเธรดและรวดเร็ว

Redis มีคุณสมบัติมากมายและรวดเร็วมาก แต่ถูก จำกัด ให้เป็นหนึ่งคอร์อย่างสมบูรณ์เนื่องจากเป็นไปตามเหตุการณ์ลูป

เราใช้ทั้งสองอย่าง Memcached ใช้สำหรับแคชวัตถุโดยหลัก ๆ แล้วจะช่วยลดภาระการอ่านลงบนฐานข้อมูล Redis ใช้สำหรับสิ่งต่าง ๆ เช่นชุดที่เรียงลำดับซึ่งมีประโยชน์สำหรับการรีดข้อมูลอนุกรมเวลา

นี่นานเกินไปที่จะโพสต์เป็นความคิดเห็นต่อคำตอบที่ยอมรับแล้วดังนั้นฉันจึงใส่ไว้เป็นคำตอบแยกต่างหาก

สิ่งหนึ่งที่ควรพิจารณาคือคุณคาดหวังว่าจะมีขีด จำกัด หน่วยความจำสูงสุดบนแคชของคุณหรือไม่

เนื่องจาก redis เป็นฐานข้อมูล nosql ที่มีคุณสมบัติมากมายและการแคชเป็นเพียงตัวเลือกเดียวที่สามารถใช้งานได้จึงจัดสรรหน่วยความจำตามที่ต้องการ - ยิ่งคุณใส่วัตถุมากเท่าใดก็จะยิ่งใช้หน่วยความจำมากเท่านั้น maxmemoryตัวเลือกที่ไม่เคร่งครัดบังคับใช้การใช้งาน จำกัด หน่วยความจำบน ในขณะที่คุณทำงานกับแคชคีย์จะถูกไล่ออกและหมดอายุ โอกาสที่กุญแจของคุณจะไม่ได้มีขนาดเท่ากันดังนั้นการกระจายตัวของหน่วยความจำภายในจึงเกิดขึ้น

โดยค่าเริ่มต้น redis ใช้ตัวจัดสรรหน่วยความจำjemallocซึ่งพยายามอย่างดีที่สุดที่จะเป็นทั้งหน่วยความจำขนาดกะทัดรัดและเร็ว แต่มันเป็นตัวจัดสรรหน่วยความจำวัตถุประสงค์ทั่วไปและไม่สามารถติดตามการจัดสรรจำนวนมากและการล้างวัตถุที่เกิดขึ้น ด้วยเหตุนี้ในบางรูปแบบโหลดกระบวนการ redis สามารถรั่วหน่วยความจำเนื่องจากการกระจายตัวภายใน ตัวอย่างเช่นหากคุณมีเซิร์ฟเวอร์ที่มี RAM 7 Gb และคุณต้องการใช้ Redis เป็นแคช LRU ที่ไม่คงอยู่คุณอาจพบว่า Redis ประมวลผลด้วยmaxmemoryตั้งค่าเป็น 5Gb ในช่วงเวลาหนึ่งจะใช้หน่วยความจำมากขึ้นเรื่อย ๆ จนถึงขีด จำกัด RAM ทั้งหมด นักฆ่าออกจากหน่วยความจำรบกวน

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

ด้วยที่กล่าวไว้ memcached ยังคงมีสถานะที่แข็งแกร่งในสภาพแวดล้อมที่การใช้งานหน่วยความจำจะต้องมีการบังคับใช้และ / หรือสามารถคาดการณ์ได้ เราได้พยายามใช้ redis ที่เสถียรล่าสุด (2.8.19) เป็นการแทนที่ memcached ที่ใช้ LRU แบบดร็อปอินแบบไม่ดร็อปดาวน์ในเวิร์กโหลดของ 10-15k op / s และหน่วยความจำรั่วมาก เวิร์กโหลดเดียวกันนั้นล้มเหลว ElastiCache ของ Amazon ขัดข้องในหนึ่งวันหรือมากกว่านั้นเนื่องจากเหตุผลเดียวกัน

Memcached ดีในการเป็นที่เก็บคีย์ / ค่าอย่างง่ายและดีในการทำ key => STRING สิ่งนี้ทำให้ดีสำหรับการจัดเก็บเซสชัน

Redis ทำได้ดีในการทำคีย์ => SOME_OBJECT

มันขึ้นอยู่กับว่าคุณจะใส่อะไรเข้าไป ความเข้าใจของฉันคือว่าในแง่ของประสิทธิภาพพวกเขายังสวย

ขอให้โชคดีในการหาเกณฑ์มาตรฐานวัตถุประสงค์หากคุณพบว่ามีบางคนกรุณาส่งพวกเขาไปตามทางของฉัน

หากคุณไม่สนใจสไตล์การเขียนที่ไม่ดีนักRedis vs Memcachedบนบล็อก Systoilet นั้นคุ้มค่าที่จะอ่านจากมุมมองการใช้งาน แต่อย่าลืมอ่านย้อนกลับในความคิดเห็นก่อนที่จะสรุปผลการปฏิบัติงาน มีปัญหาบางอย่างเกี่ยวกับระเบียบวิธี (การทดสอบการวนรอบไม่ว่างเธรดเดียว) และ Redis ได้ทำการปรับปรุงบางอย่างตั้งแต่บทความถูกเขียนเช่นกัน

และไม่มีการเชื่อมโยงมาตรฐานสมบูรณ์โดยไม่ต้องสับสนสิ่งเล็กน้อยเพื่อให้ตรวจสอบออกมาตรฐานที่ขัดแย้งกันบางที่Dormondo ของ LiveJournalและAntirez บล็อก

แก้ไข - เมื่อ Antirez ชี้ให้เห็นการวิเคราะห์ Systoilet ค่อนข้างเข้าใจผิด แม้จะเกินความขาดแคลนเพียงเธรดเดียวความแตกต่างของประสิทธิภาพส่วนใหญ่ในการวัดประสิทธิภาพเหล่านั้นสามารถนำมาประกอบกับไลบรารีของไคลเอ็นต์แทนการส่งผ่านเซิร์ฟเวอร์ มาตรฐานที่Antirez Weblogจะนำเสนอการเปรียบเทียบแอปเปิ้ลกับแอปเปิ้ลมากขึ้น (ด้วยปากเดียวกัน)

ฉันได้รับโอกาสให้ใช้ทั้ง memcached และ redis ร่วมกันในแคชพร็อกซีที่ฉันได้ทำงานให้ฉันแบ่งปันให้คุณในสิ่งที่ฉันได้ใช้สิ่งและเหตุผลที่อยู่เบื้องหลังเดียวกัน ....

Redis>

1) ใช้สำหรับการจัดทำดัชนีเนื้อหาแคชในคลัสเตอร์ ฉันมีคีย์มากกว่าพันล้านตัวกระจายอยู่ทั่วกลุ่ม Redis เวลาตอบสนองของ Redis นั้นค่อนข้างน้อยและเสถียร

2) โดยทั่วไปมันเป็นที่จัดเก็บคีย์ / ค่าดังนั้นเมื่อใดก็ตามที่แอปพลิเคชันของคุณมีสิ่งที่คล้ายกันคุณสามารถใช้ redis โดยที่ไม่ต้องสนใจอะไรมากมาย

3) Redis persistency, failover และ backup (AOF) จะทำให้งานของคุณง่ายขึ้น

Memcache>

1) ใช่หน่วยความจำที่ได้รับการปรับปรุงซึ่งสามารถใช้เป็นแคชได้ ฉันใช้เพื่อเก็บเนื้อหาแคชการเข้าถึงบ่อยมาก (50 ครั้ง / วินาที) ที่มีขนาดน้อยกว่า 1 MB

2) ฉันจัดสรรเพียง 2GB จาก 16 GB สำหรับ memcached เช่นกันเมื่อขนาดเนื้อหาเดียวของฉันคือ> 1MB

3) เมื่อเนื้อหาเติบโตใกล้ขีด จำกัด บางครั้งฉันสังเกตเห็นเวลาตอบสนองที่สูงขึ้นในสถิติ (ไม่ใช่กรณีที่มี Redis)

หากคุณขอประสบการณ์โดยรวม Redis เป็นสีเขียวมากเพราะง่ายต่อการกำหนดค่ามีความยืดหยุ่นสูงพร้อมคุณสมบัติที่มีความเสถียร

นอกจากนี้ยังมีผลการเปรียบเทียบอยู่ที่ลิงค์ด้านล่างนี้มีค่าแสงน้อยจากเดียวกัน

หวังว่านี่จะช่วยได้ !!

ทดสอบ. ใช้การวัดประสิทธิภาพแบบง่าย ๆ ในขณะที่ฉันคิดว่าตัวเองเป็นแรดโรงเรียนเก่าตั้งแต่ฉันใช้ memcached ส่วนใหญ่และถือว่า Redis เป็นเด็กใหม่

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

memcached แม้ว่าง่ายพัด Redis ออกจากน้ำโดยสิ้นเชิง มันปรับขนาดได้ดีกว่ามาก:

• สำหรับค่าที่มากขึ้น (จำเป็นต้องเปลี่ยนขนาดพื้น แต่ทำงานได้)
• สำหรับคำขอที่เกิดขึ้นพร้อมกันหลายรายการ

นอกจากนี้นโยบายการขับไล่ memcached อยู่ในมุมมองของฉันนำมาใช้ที่ดีขึ้นมากทำให้เวลาตอบสนองโดยเฉลี่ยมีเสถียรภาพมากขึ้นในขณะที่การจัดการข้อมูลมากกว่าแคชสามารถจัดการ

การเปรียบเทียบบางคนเปิดเผยว่า Redis ในกรณีของเรามีประสิทธิภาพต่ำมาก ฉันเชื่อว่าสิ่งนี้เกี่ยวข้องกับตัวแปรหลายอย่าง:

• ประเภทของฮาร์ดแวร์ที่คุณเปิดใช้งาน Redis
• ประเภทข้อมูลที่คุณจัดเก็บ
• จำนวนที่ได้รับและชุด
• แอปของคุณเป็นอย่างไรพร้อมกัน
• คุณต้องการที่เก็บโครงสร้างข้อมูลหรือไม่

โดยส่วนตัวแล้วฉันไม่แบ่งปันมุมมองที่ผู้เขียน Redis มีต่อการทำงานพร้อมกันและมัลติเธรด

โบนัสอีกอย่างคือมันชัดเจนมากว่า memcache จะทำงานอย่างไรในสถานการณ์การแคชขณะที่ Redis มักใช้เป็นที่เก็บข้อมูลถาวรแม้ว่าจะสามารถกำหนดค่าให้ทำงานเหมือนกับ memcached หรือรายการที่ใช้ล่าสุดน้อยที่สุดเมื่อถึงค่าสูงสุด ความจุ

แอพบางตัวที่ฉันใช้งานทั้งสองอย่างเพื่อให้ชัดเจนว่าเราตั้งใจให้ข้อมูลทำงานอย่างไร - ใน memcache เราเขียนโค้ดเพื่อจัดการกับกรณีที่ไม่มี - สิ่งที่เป็นสีแดงเราพึ่งพามันอยู่ที่นั่น .

นอกเหนือจากนั้น Redis โดยทั่วไปถือว่าเป็น superior สำหรับกรณีการใช้งานส่วนใหญ่จะมีคุณลักษณะที่หลากหลายและมีความยืดหยุ่น

มันจะไม่ผิดถ้าเราบอกว่า redis เป็นการรวมกันของ (แคช + โครงสร้างข้อมูล) ในขณะที่ memcached เป็นเพียงแคช

การทดสอบที่ง่ายมากในการตั้งค่าและรับคีย์และค่าที่ไม่ซ้ำกัน 100k เทียบกับ redis-2.2.2 และ memcached ทั้งสองทำงานบน linux VM (CentOS) และรหัสลูกค้าของฉัน (วางด้านล่าง) ทำงานบน windows desktop

Redis

• เวลาที่ใช้ในการจัดเก็บ 100,000 ค่าคือ = 18954ms

• เวลาที่ใช้ในการโหลดค่า 100000 = 18328ms

memcached

• เวลาที่ใช้ในการจัดเก็บ 100000 ค่าคือ = 797ms

• เวลาที่ใช้เพื่อดึงค่า 100000 คือ = 38984ms

Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");

startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");

ความแตกต่างที่สำคัญอย่างหนึ่งที่ยังไม่ได้กล่าวถึงคือ Memcache มีขีด จำกัด หน่วยความจำสูงสุดตลอดเวลาในขณะที่ Redis ไม่ได้เป็นค่าเริ่มต้น (แต่สามารถกำหนดค่าได้) หากคุณต้องการจัดเก็บคีย์ / ค่าสำหรับระยะเวลาหนึ่ง (และไม่เคยขับไล่เพราะหน่วยความจำเหลือน้อย) คุณต้องการใช้ Redis แน่นอนคุณยังเสี่ยงต่อปัญหาความจำไม่เพียงพอ ...

เหตุผลที่เหลือที่ใหญ่ที่สุดคือความเชี่ยวชาญ

Redis สามารถทำสิ่งต่าง ๆ มากมายและผลข้างเคียงอย่างหนึ่งของมันคือนักพัฒนาอาจเริ่มใช้ชุดคุณลักษณะที่แตกต่างกันจำนวนมากในอินสแตนซ์เดียวกัน หากคุณกำลังใช้คุณสมบัติ LRU ของ Redis สำหรับแคชที่เก็บข้อมูลด้านข้างที่ไม่ใช่ LRU คุณอาจมีหน่วยความจำหมด

หากคุณกำลังจะตั้งค่าอินสแตนซ์ Redis โดยเฉพาะที่จะใช้เป็นอินสแตนซ์ LRU เพื่อหลีกเลี่ยงสถานการณ์เฉพาะนั้นไม่มีเหตุผลที่น่าสนใจจริงๆที่จะใช้ Redis ผ่าน Memcached

หากคุณต้องการความน่าเชื่อถือ "ไม่ลง" แคช LRU ... Memcached จะพอดีกับใบเสร็จเนื่องจากเป็นไปไม่ได้ที่หน่วยความจำจะหมดโดยการออกแบบ แยกความกังวลได้ง่าย

Memcached จะเร็วขึ้นหากคุณสนใจในประสิทธิภาพแม้ว่า Redis จะเกี่ยวข้องกับเครือข่าย (การโทร TCP) Memcache ภายในยังเร็วกว่า

Redis มีคุณสมบัติเพิ่มเติมตามที่ถูกกล่าวถึงโดยคำตอบอื่น ๆ

เราคิดว่า Redis เป็นรถยกสำหรับโครงการของเราในที่ทำงาน เราคิดว่าการใช้โมดูลที่nginxเรียกว่าHttpRedis2Moduleหรือสิ่งที่คล้ายกันเราจะมีความเร็วที่ยอดเยี่ยม แต่เมื่อทดสอบกับ AB-test เราได้พิสูจน์แล้วว่าผิด

บางทีโมดูลอาจไม่ดีหรือเลย์เอาต์ของเรา แต่มันเป็นงานที่ง่ายมากและมันก็ยิ่งเร็วกว่าที่จะรับข้อมูลด้วย php จากนั้นก็บรรจุลงใน MongoDB เราใช้ APC เป็นระบบแคชและด้วย php และ MongoDB นั้น มันเร็วกว่ามากแล้วnginxโมดูล Redis

เคล็ดลับของฉันคือการทดสอบด้วยตัวเองการทำเช่นนั้นจะแสดงผลลัพธ์ให้กับสภาพแวดล้อมของคุณ เราตัดสินใจว่าการใช้ Redis นั้นไม่จำเป็นในโครงการของเราเพราะมันไม่สมเหตุสมผล

Redis ดีกว่า

ข้อดีของการRedisเป็น

1. มันมีตัวเลือกการจัดเก็บข้อมูลจำนวนมากเช่นสตริง, ชุด, ชุดเรียง, hash, บิตแมป
2. ความคงทนของดิสก์ในการบันทึก
3. การสนับสนุน Stored Procedure ( LUAscripting)
4. สามารถทำหน้าที่เป็นนายหน้าซื้อขายข้อความโดยใช้ PUB / SUB

ในขณะที่Memcacheเป็นระบบประเภทแคชค่าคีย์ในหน่วยความจำ

1. ไม่รองรับการจัดเก็บข้อมูลประเภทต่างๆเช่นรายการตั้งค่าเป็น redis
2. ข้อโต้แย้งหลักคือ Memcache ไม่มีการคงอยู่ของดิสก์

ฉันส่วนใหญ่ใช้ทั้งกับแอพของฉัน Memcache สำหรับแคชเซสชันและ redis สำหรับวัตถุหลักคำสอน / orm ในแง่ของประสิทธิภาพทั้งสองเกือบจะเหมือนกัน

นี่คือบทความ / ความแตกต่างที่ยอดเยี่ยมจริงๆของ Amazon

Redis เป็นผู้ชนะที่ชัดเจนเมื่อเปรียบเทียบกับ memcached

จุดบวกเดียวสำหรับ Memcached มันเป็นแบบมัลติเธรดและรวดเร็ว Redis มีคุณสมบัติที่ยอดเยี่ยมมากมายและรวดเร็วมาก แต่ จำกัด เพียงแกนเดียว

จุดที่ยอดเยี่ยมเกี่ยวกับ Redis ซึ่งไม่ได้รับการสนับสนุนใน Memcached

• สแนปชอต - ผู้ใช้สามารถถ่ายภาพแคช Redis และเก็บข้อมูลสำรองไว้ได้ทุกเวลา
• การสนับสนุน Inbuilt สำหรับโครงสร้างข้อมูลจำนวนมากเช่น Set, Map, SortedSet, List, BitMaps เป็นต้น
• รองรับการเขียนสคริปต์ Lua ด้วยสีแดง