ใครสามารถยกตัวอย่างกรณีการใช้งานที่คุณจะได้รับประโยชน์จากการใช้ Redis และ MongoDB ร่วมกันได้หรือไม่?
ใครสามารถยกตัวอย่างกรณีการใช้งานที่คุณจะได้รับประโยชน์จากการใช้ Redis และ MongoDB ร่วมกันได้หรือไม่?
คำตอบ:
Redis และ MongoDB สามารถใช้ร่วมกับผลลัพธ์ที่ดีได้ บริษัท ที่มีชื่อเสียงในการใช้งาน MongoDB และ Redis (พร้อมกับ MySQL และ Sphinx) คือ Craiglist ดูการนำเสนอนี้จาก Jeremy Zawodny
MongoDB เป็นสิ่งที่น่าสนใจสำหรับการจัดทำดัชนีข้อมูลในรูปแบบต่างๆ Redis น่าสนใจกว่าสำหรับข้อมูลที่มีความผันผวนหรือข้อมูลกึ่งถาวรที่มีความอ่อนไหวต่อเวลาแฝง
นี่คือตัวอย่างบางส่วนของการใช้งาน Redis ที่เป็นรูปธรรมบน MongoDB
Pre-2.2 MongoDB ยังไม่มีกลไกการหมดอายุ ไม่สามารถใช้คอลเลกชันที่ต่อยอดเพื่อใช้ TTL จริงได้ Redis มีกลไกการหมดอายุตาม TTL ทำให้สะดวกในการจัดเก็บข้อมูลที่ระเหยได้ ตัวอย่างเช่นโดยทั่วไปเซสชันของผู้ใช้จะถูกเก็บไว้ใน Redis ในขณะที่ข้อมูลผู้ใช้จะถูกจัดเก็บและจัดทำดัชนีใน MongoDB โปรดทราบว่า MongoDB 2.2 ได้นำเสนอกลไกการหมดอายุที่มีความแม่นยำต่ำในระดับการรวบรวม (เพื่อใช้ในการล้างข้อมูลเป็นต้น)
Redis จัดเตรียมประเภทข้อมูลชุดที่สะดวกและการดำเนินการที่เกี่ยวข้อง (สหภาพการตัดกันความแตกต่างในหลายชุด ฯลฯ ... ) มันค่อนข้างง่ายที่จะใช้เครื่องมือค้นหาหรือการติดแท็กพื้นฐานที่ด้านบนของคุณสมบัตินี้ซึ่งเป็นส่วนเสริมที่น่าสนใจสำหรับ MongoDB ความสามารถในการจัดทำดัชนีแบบเดิม ๆ
Redis รองรับการบล็อกป๊อปที่มีประสิทธิภาพในรายการ สามารถใช้เพื่อติดตั้งระบบการจัดคิวแบบกระจายเฉพาะกิจ มีความยืดหยุ่นมากกว่า IMO ของ MongoDB tailable cursors เนื่องจากแอปพลิเคชันแบ็กเอนด์สามารถรับฟังคิวต่างๆได้โดยมีการหมดเวลาถ่ายโอนรายการไปยังคิวอื่นแบบอะตอมเป็นต้นหากแอปพลิเคชันต้องการการจัดคิวบางอย่างควรจัดเก็บคิวใน Redis และเก็บข้อมูลการทำงานที่คงอยู่ไว้ใน MongoDB
Redis ยังมีกลไก pub / sub ในแอปพลิเคชันแบบกระจายระบบการเผยแพร่เหตุการณ์อาจมีประโยชน์ นี่เป็นอีกกรณีการใช้งานที่ยอดเยี่ยมสำหรับ Redis ในขณะที่ข้อมูลถาวรจะถูกเก็บไว้ใน MongoDB
เนื่องจากการออกแบบโมเดลข้อมูลด้วย MongoDB นั้นง่ายกว่า Redis มาก (Redis เป็นระดับต่ำกว่า) จึงน่าสนใจที่จะได้รับประโยชน์จากความยืดหยุ่นของ MongoDB สำหรับข้อมูลถาวรหลักและจากคุณสมบัติพิเศษที่ Redis จัดหาให้ (เวลาแฝงต่ำ , การหมดอายุของรายการ, คิว, ผับ / ย่อย, บล็อคอะตอม ฯลฯ ... ) มันเป็นการผสมผสานที่ดี
โปรดทราบว่าคุณไม่ควรเรียกใช้เซิร์ฟเวอร์ Redis และ MongoDB บนเครื่องเดียวกัน หน่วยความจำ MongoDB ได้รับการออกแบบมาให้สามารถสลับออก Redis ไม่ได้ หาก MongoDB ทริกเกอร์กิจกรรมการแลกเปลี่ยนประสิทธิภาพของ Redis จะหายนะ ควรแยกออกจากกันบนโหนดต่างๆ
เห็นได้ชัดว่ามีไกลความแตกต่างมากกว่านี้ แต่สำหรับภาพรวมสูงมาก:
สำหรับกรณีการใช้งาน:
ในทางเทคนิค:
มีการทับซ้อนกัน แต่เป็นเรื่องปกติมากที่จะใช้ทั้งสองอย่าง นี่คือเหตุผล:
Redis สามารถใช้แทนพื้นที่เก็บข้อมูลแบบเดิมได้ แต่ส่วนใหญ่มักใช้กับที่เก็บข้อมูล "แบบยาว" อื่น ๆ เช่น Mongo, Postgresql, MySQL เป็นต้น
Redis ทำงานได้อย่างยอดเยี่ยมกับ MongoDB ในฐานะเซิร์ฟเวอร์แคช นี่คือสิ่งที่เกิดขึ้น
ทุกครั้งที่พังพอนออกแบบสอบถามแคชมันจะไปที่เซิร์ฟเวอร์แคชก่อน
เซิร์ฟเวอร์แคชจะตรวจสอบว่าเคยมีการออกแบบสอบถามที่แน่นอนมาก่อนหรือไม่
หากยังไม่เป็นเช่นนั้นเซิร์ฟเวอร์แคชจะรับคำถามส่งไปที่ mongodb และ Mongo จะดำเนินการค้นหา
จากนั้นเราจะนำผลลัพธ์ของแบบสอบถามนั้นกลับไปที่เซิร์ฟเวอร์แคชเซิร์ฟเวอร์แคชจะเก็บผลลัพธ์ของแบบสอบถามไว้ในตัวเอง
มันจะบอกว่าเมื่อใดก็ตามที่ฉันดำเนินการค้นหานั้นฉันได้รับการตอบกลับนี้ดังนั้นมันจะรักษาบันทึกระหว่างคำถามที่ออกและการตอบกลับที่กลับมาจากการค้นหา
เซิร์ฟเวอร์แคชจะตอบสนองและส่งกลับไปยังพังพอนพังพอนจะให้มันแสดงและในที่สุดมันก็จบลงในแอปพลิเคชัน
เมื่อใดก็ตามที่มีการออกแบบสอบถามเดียวกันอีกครั้งพังพอนจะส่งแบบสอบถามเดียวกันไปยังเซิร์ฟเวอร์แคช แต่ถ้าเซิร์ฟเวอร์แคชเห็นว่าแบบสอบถามนี้ออกก่อนที่จะไม่ส่งแบบสอบถามไปยัง mongodb แทนที่จะตอบกลับไปที่ ข้อความค้นหามีครั้งสุดท้ายและส่งกลับไปที่พังพอนทันที ไม่มีดัชนีที่นี่ไม่มีการสแกนแบบเต็มตารางไม่มีอะไรเลย
เรากำลังทำการค้นหาแบบง่ายๆเพื่อบอกว่ามีการเรียกใช้แบบสอบถามนี้หรือไม่? ใช่? โอเครับคำขอและส่งกลับทันทีและอย่าส่งอะไรไปที่ mongo
เรามีเซิร์ฟเวอร์พังพอนเซิร์ฟเวอร์แคช (Redis) และ Mongodb
บนเซิร์ฟเวอร์แคชอาจมีที่เก็บข้อมูลที่มีประเภทค่าคีย์ของที่เก็บข้อมูลซึ่งคีย์ทั้งหมดเป็นแบบสอบถามบางประเภทที่ออกก่อนหน้านี้และค่าผลลัพธ์ของคิวรีนั้น
บางทีเรากำลังค้นหาบล็อกโพสต์จำนวนมากโดย _id
ดังนั้นบางทีคีย์ในนี้คือ _id ของเร็กคอร์ดที่เราค้นหามาก่อน
ลองจินตนาการว่าพังพอนออกแบบสอบถามใหม่โดยพยายามค้นหาบล็อกโพสต์ที่มี _id ของ 123 ข้อความค้นหาจะไหลเข้าสู่เซิร์ฟเวอร์แคชเซิร์ฟเวอร์แคชจะตรวจสอบเพื่อดูว่ามีผลลัพธ์สำหรับข้อความค้นหาใด ๆ ที่กำลังมองหา _id หรือไม่ จาก 123
หากไม่มีอยู่ในแคชเซิร์ฟเวอร์แบบสอบถามนี้จะถูกนำและส่งไปยังอินสแตนซ์ mongodb Mongodb จะดำเนินการค้นหารับคำตอบและส่งกลับ
ผลลัพธ์นี้จะถูกส่งกลับไปยังเซิร์ฟเวอร์แคชซึ่งรับผลลัพธ์นั้นและส่งกลับไปยังพังพอนทันทีเพื่อให้เราได้รับคำตอบอย่างรวดเร็ว
หลังจากนั้นเซิร์ฟเวอร์แคชจะนำแบบสอบถามที่ออกและเพิ่มเข้าไปในคอลเลกชันของคิวรีที่ออกและรับผลลัพธ์ของคิวรีและจัดเก็บให้ตรงกับคิวรี
ดังนั้นเราจึงสามารถจินตนาการได้ว่าในอนาคตเราจะออกแบบสอบถามเดียวกันอีกครั้งมันไปที่เซิร์ฟเวอร์แคชมันดูคีย์ทั้งหมดที่มีและบอกว่าโอ้ฉันพบบล็อกโพสต์นั้นแล้วมันไม่สามารถเข้าถึง mongo ได้เพียงแค่ใช้เวลา ผลลัพธ์ของแบบสอบถามและส่งโดยตรงไปยังพังพอน
เราไม่ได้ใช้ตรรกะการสืบค้นที่ซับซ้อนไม่มีดัชนีไม่มีอะไรเช่นนั้น เร็วที่สุด การค้นหาค่าคีย์ที่เรียบง่าย
นั่นคือภาพรวมของการทำงานของแคชเซิร์ฟเวอร์ (Redis) กับ MongoDB
ตอนนี้มีความกังวลอื่น ๆ เรากำลังแคชข้อมูลตลอดไปหรือไม่? เราจะอัปเดตบันทึกได้อย่างไร
เราไม่ต้องการจัดเก็บข้อมูลในแคชเสมอไปและอ่านจากแคช
เซิร์ฟเวอร์แคชไม่ได้ใช้สำหรับการดำเนินการเขียนใด ๆ ชั้นแคชใช้สำหรับการอ่านข้อมูลเท่านั้น หากเราเคยเขียนข้อมูลการเขียนจะไปที่อินสแตนซ์ mongodb เสมอและเราจำเป็นต้องตรวจสอบให้แน่ใจว่าเมื่อใดก็ตามที่เราเขียนข้อมูลเราจะล้างข้อมูลใด ๆ ที่เก็บไว้ในเซิร์ฟเวอร์แคชที่เกี่ยวข้องกับบันทึกที่เราเพิ่งอัปเดตใน Mongo