สิ่งที่ฉันต้องการไม่ใช่การเปรียบเทียบระหว่าง Redis และ MongoDB ฉันรู้ว่ามันแตกต่างกัน ประสิทธิภาพและ API แตกต่างอย่างสิ้นเชิง

Redis นั้นเร็วมาก แต่ API นั้น 'atomic' มาก MongoDB จะกินทรัพยากรมากขึ้น แต่ API นั้นใช้งานง่ายมากและฉันมีความสุขมาก

พวกมันทั้งยอดเยี่ยมและฉันต้องการใช้ Redis ในการปรับใช้ให้มากที่สุด แต่มันยากที่จะเขียนโค้ด ฉันต้องการใช้ MongoDB ในการพัฒนามากที่สุดเท่าที่จะทำได้ แต่ต้องใช้เครื่องราคาแพง

แล้วคุณคิดอย่างไรเกี่ยวกับการใช้ทั้งสองอย่าง เมื่อใดที่จะเลือก Redis เมื่อใดที่จะเลือก MongoDB

ฉันจะบอกว่ามันขึ้นอยู่กับประเภทของทีม dev ที่คุณเป็นและความต้องการใบสมัครของคุณ

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

MongoDB นำเสนอความเรียบง่ายโค้งการเรียนรู้ที่สั้นลงมากสำหรับนักพัฒนาด้วย DB และ SQL แบบดั้งเดิม อย่างไรก็ตามวิธีการที่ไม่ใช่แบบดั้งเดิมของ Redis ต้องการความพยายามในการเรียนรู้มากกว่า แต่มีความยืดหยุ่นมากกว่า

เช่น. แคชชั้นอาจจะสามารถดำเนินการได้ดีขึ้นใน Redis สำหรับข้อมูลที่สามารถทำคีมาได้มากขึ้น MongoDB จะดีกว่า [หมายเหตุ: ทั้ง MongoDB และ Redis เป็นแบบแผนทางเทคนิค]

หากคุณถามฉันทางเลือกส่วนบุคคลของฉันคือ Redis สำหรับความต้องการส่วนใหญ่

สุดท้ายนี้ฉันหวังว่าคุณจะได้เห็นhttp://antirez.com/post/MongoDB-and-Redis.htmlตอนนี้

ฉันเพิ่งสังเกตเห็นว่าคำถามนี้ค่อนข้างเก่า อย่างไรก็ตามฉันคิดว่าประเด็นต่อไปนี้น่าจะเพิ่มมูลค่า:

• ใช้ MongoDB หากคุณยังไม่รู้ว่าจะสืบค้นข้อมูลอย่างไร

  MongoDB เหมาะสำหรับ Hackathons, startups หรือทุกครั้งที่คุณไม่ทราบว่าคุณจะสืบค้นข้อมูลที่คุณแทรกไว้อย่างไร MongoDB ไม่ได้ตั้งสมมติฐานใด ๆ กับสคีมาพื้นฐานของคุณ แม้ว่า MongoDB จะเป็นแบบแผนและไม่สัมพันธ์กัน แต่ก็ไม่ได้หมายความว่าจะไม่มี schema เลย หมายความว่าสคีมาของคุณจะต้องกำหนดไว้ในแอปของคุณ (เช่นใช้ Mongoose) นอกจากนั้น MongoDB ยังเหมาะสำหรับการสร้างต้นแบบหรือทดลองใช้ ประสิทธิภาพของมันนั้นยอดเยี่ยมและไม่สามารถเทียบได้กับ Redis

• ใช้ Redis เพื่อเร่งความเร็วแอปพลิเคชันที่มีอยู่ของคุณ

  Redis สามารถบูรณาการได้อย่างง่ายดายเป็นแคช LRU เป็นเรื่องแปลกที่จะใช้ Redis เป็นระบบฐานข้อมูลแบบสแตนด์อโลน (บางคนชอบที่จะอ้างถึงมันเป็น เว็บไซต์เช่น Craigslist ใช้Redis ต่อไปยังฐานข้อมูลหลักของพวกเขา Antirez (ผู้พัฒนา Redis) สาธิตการใช้ Lamernews ว่าเป็นไปได้ที่จะใช้ Redis เป็นระบบฐานข้อมูลแบบสแตนด์อะโลน

• Redis ไม่ได้ตั้งสมมติฐานใด ๆ ขึ้นอยู่กับข้อมูลของคุณ

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

ควรใช้ Redis เมื่อใด

• เก็บเอาไว้

  การแคชโดยใช้ MongoDB นั้นไม่สมเหตุสมผลนัก มันจะช้าเกินไป

• หากคุณมีเวลาพอที่จะคิดถึงการออกแบบฐานข้อมูลของคุณ

  คุณไม่สามารถส่งเอกสารของคุณไปที่ Redis คุณต้องคิดถึงวิธีการที่คุณต้องการจัดเก็บและจัดระเบียบข้อมูลของคุณ ตัวอย่างหนึ่งคือแฮชใน Redis พวกเขาค่อนข้างแตกต่างจากวัตถุที่ซ้อน "ดั้งเดิม" ซึ่งหมายความว่าคุณจะต้องคิดใหม่เกี่ยวกับวิธีการจัดเก็บเอกสารที่ซ้อนกัน วิธีแก้ปัญหาหนึ่งคือการเก็บข้อมูลอ้างอิงไว้ในแฮชไปยังแฮชอื่น (เช่นรหัส: [id ของแฮชที่สอง] ) อีกแนวคิดหนึ่งก็คือการจัดเก็บเป็น JSON ซึ่งดูเหมือนว่าจะต่อต้านคนส่วนใหญ่ที่มี * SQL-background

• หากคุณต้องการประสิทธิภาพสูงจริงๆ

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

• หากคุณไม่สนใจว่ามากเกี่ยวกับการปรับ

  Scaling Redis นั้นไม่ยากอย่างที่เคยเป็นมา ตัวอย่างเช่นคุณสามารถใช้พร็อกซีเซิร์ฟเวอร์ชนิดหนึ่งเพื่อแจกจ่ายข้อมูลระหว่าง Redis หลาย ๆ อินสแตนซ์ การจำลองแบบ master ทาสไม่ได้ที่ซับซ้อน แต่กระจายคุณแป้นหมู่หลาย Redis-กรณีจะต้องทำบนเว็บไซต์ของแอพลิเคชัน (เช่นการใช้กัญชาฟังก์ชั่ Modulo ฯลฯ ) การปรับ MongoDB โดยการเปรียบเทียบนั้นง่ายกว่ามาก

เมื่อใดควรใช้ MongoDB

• การสร้างต้นแบบ, Startups, Hackathons

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

• เมื่อคุณต้องการเปลี่ยนสคีมาของคุณอย่างรวดเร็ว

  เพราะไม่มีสคีมา! การเปลี่ยนแปลงตารางใน DBMS เชิงสัมพันธ์แบบดั้งเดิมนั้นมีราคาแพงและช้าอย่างเจ็บปวด MongoDB แก้ปัญหานี้ได้โดยไม่ทำให้ข้อสันนิษฐานมากมายกับข้อมูลที่คุณมีอยู่ อย่างไรก็ตามจะพยายามปรับให้เหมาะสมที่สุดโดยไม่ต้องให้คุณกำหนดสคีมา

TL; DR - ใช้ Redis หากประสิทธิภาพเป็นสิ่งสำคัญและคุณยินดีที่จะใช้เวลาปรับให้เหมาะสมและจัดการข้อมูลของคุณ - ใช้ MongoDB ถ้าคุณต้องการสร้างต้นแบบโดยไม่ต้องกังวลเกี่ยวกับฐานข้อมูลของคุณมากเกินไป

อ่านเพิ่มเติม:

• ประเด็นที่น่าสนใจที่ควรพิจารณาเมื่อใช้Redis เป็นแหล่งข้อมูลหลัก

Redis สมมติว่าคุณเขียนไซต์เป็น php ไม่ว่าด้วยเหตุผลใดก็ตามมันจะกลายเป็นที่นิยมและถึงเวลาแล้วหรือมีโป๊อยู่ คุณรู้ว่า php นี้ช้ามาก "ฉันจะทำกับแฟน ๆ ของฉันเพราะพวกเขาเพียงแค่จะไม่รอ 10 วินาทีสำหรับหน้า" คุณมีการรับรู้อย่างฉับพลันว่าหน้าเว็บมี URL คงที่ (ไม่เคยเปลี่ยนเลย) เป็นคีย์หลักถ้าคุณต้องการแล้วคุณจะจำได้ว่าหน่วยความจำนั้นเร็วในขณะที่ดิสก์ทำงานช้าและ php ก็ช้าลง :( จากนั้นคุณสร้างกลไกการจัดเก็บโดยใช้หน่วยความจำและ URL นี้ที่คุณเรียกว่า "คีย์" ในขณะที่เนื้อหาเว็บเพจที่คุณตัดสินใจเรียกว่า "ค่า" นั่นคือทั้งหมดที่คุณมี - คีย์และเนื้อหาคุณเรียกมันว่า "meme cache" คุณชอบ Richard Dawkins เพราะเขายอดเยี่ยมคุณแคช html ของคุณเหมือนกระรอกแคชถั่วของพวกเขาคุณไม่จำเป็นต้องเขียนรหัส php ของคุณอีกครั้ง คุณมีความสุข. จากนั้นคุณจะเห็นว่าคนอื่นทำไปแล้ว - แต่คุณเลือก Redis เพราะอีกคนหนึ่งสับสนภาพแมวบางตัวมีเขี้ยว

Mongo คุณได้เขียนเว็บไซต์ Heck คุณเขียนหลายอย่างและในภาษาใด ๆ คุณรู้ว่าเวลาส่วนใหญ่ของคุณใช้เวลาในการเขียนคำสั่ง SQL ที่เหม็น คุณไม่ได้เป็น dba แต่ก็มีคุณกำลังเขียนคำสั่ง sql ที่โง่เขลาไม่ใช่แค่เพียงคนเดียว "เลือกตัวเลือกนี้" แต่โดยเฉพาะอย่างยิ่งคุณจำประโยคที่น่ารำคาญ ที่นามสกุลเท่ากับ "ธ อร์นตัน" และภาพยนตร์เท่ากับ "bad santa" Urgh คุณคิดว่า "ทำไม dbas เหล่านั้นไม่ทำงานและให้ขั้นตอนการจัดเก็บไว้กับฉัน" จากนั้นคุณลืมเขตข้อมูลย่อยเช่น middlename แล้วคุณต้องวางตารางส่งออก 10G ของข้อมูลขนาดใหญ่และสร้างใหม่ด้วยเขตข้อมูลใหม่นี้และนำเข้าข้อมูล - และจะดำเนินการ 10 ครั้งในช่วง 14 วันถัดไปในขณะที่คุณ จำอึไว้เหมือนคำทักทาย, ชื่อ, รวมถึงการเพิ่มกุญแจต่างประเทศพร้อมที่อยู่ จากนั้นคุณคิดว่านามสกุลควรเป็นนามสกุล เกือบหนึ่งวันเปลี่ยน จากนั้นคุณพูดว่า darnit ฉันต้องขึ้นและเขียนเว็บไซต์ / ระบบไม่ต้องสนใจรุ่นข้อมูล bs ดังนั้นคุณ google, "ฉันเกลียดการเขียน SQL, โปรดอย่า SQL, หยุดมัน" แต่เพิ่ม pops 'nosql' แล้วคุณอ่านบางสิ่งและมันบอกว่ามันทิ้งข้อมูลโดยไม่ต้องคีมาใด ๆ คุณจำได้ว่าเมื่อสัปดาห์ที่แล้วความล้มเหลวในการวางโต๊ะและยิ้มมากขึ้น ถ้าอย่างนั้นคุณเลือก mongo เพราะบางคนชอบ 'airbud' ที่เว็บไซต์ apt ให้เช่าใช้มัน หวาน. ไม่มีการเปลี่ยนแปลงรูปแบบข้อมูลอีกต่อไปเพราะคุณมีรูปแบบที่คุณต้องทำการเปลี่ยนแปลงต่อไป

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

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

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

คุณต้องทดสอบพวกเขาทั้งสองเพื่อดูว่าพวกเขาตรงไหนที่คุณต้องการ

จากที่กล่าวมา MongoDB ไม่ต้องการฮาร์ดแวร์ราคาแพง เช่นเดียวกับโซลูชันฐานข้อมูลอื่น ๆ มันจะทำงานได้ดีขึ้นกับ CPU และหน่วยความจำที่มากขึ้น แต่ก็ไม่ได้เป็นข้อกำหนด - โดยเฉพาะอย่างยิ่งสำหรับการพัฒนาในช่วงต้น

Redis เป็นที่เก็บข้อมูลในหน่วยความจำที่สามารถคงสถานะเป็นดิสก์ (เพื่อเปิดใช้งานการกู้คืนหลังจากรีสตาร์ท) อย่างไรก็ตามการเป็นแหล่งเก็บข้อมูลในหน่วยความจำหมายความว่าขนาดของแหล่งข้อมูล (บนโหนดเดียว) ไม่สามารถเกินพื้นที่หน่วยความจำทั้งหมดบนระบบ (ฟิสิคัล RAM + พื้นที่สว็อป) ในความเป็นจริงมันจะน้อยกว่านี้เมื่อ Redis แชร์พื้นที่นั้นกับกระบวนการอื่น ๆ ในระบบและหากพื้นที่หน่วยความจำของระบบหมดลงระบบปฏิบัติการก็จะถูกกำจัด

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

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

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

MongoDB: ข้อมูลที่ซับซ้อน

MongoDB เป็นที่เก็บเอกสาร เพื่อเปรียบเทียบกับฐานข้อมูลเชิงสัมพันธ์ที่ขับเคลื่อนด้วย SQL: ฐานข้อมูลเชิงสัมพันธ์ทำให้ไฟล์ CSV ที่จัดทำดัชนีง่ายขึ้นแต่ละไฟล์เป็นตาราง ที่เก็บเอกสารทำให้การจัดทำดัชนีไฟล์ JSON ง่ายขึ้นแต่ละไฟล์เป็นเอกสารโดยมีหลายไฟล์รวมกัน

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

{
  _id:  0x194f38dc491a,
  Name:  "John Smith",
  PhoneNumber:
    Home: "555 999-1234",
    Work: "555 999-9876",
    Mobile: "555 634-5789"
  Accounts:
    - "379-1111"
    - "379-2574"
    - "414-6731"
}

เอกสารดังกล่าวข้างต้นมีคีย์ซึ่งมีค่าPhoneNumber.Mobile 555 634-5789คุณสามารถค้นหาเอกสารที่สำคัญPhoneNumber.Mobileมีค่าบางอย่าง; พวกเขากำลังจัดทำดัชนี

นอกจากนี้ยังมีอาร์เรย์Accountsที่เก็บดัชนีหลายรายการ มันเป็นไปได้ที่จะสอบถามสำหรับเอกสารที่Accountsมีตรงส่วนย่อยบางส่วนของค่าทั้งหมดของส่วนย่อยบางส่วนของค่าหรือใด ๆของส่วนย่อยบางส่วนของค่า หมายความว่าคุณสามารถค้นหาAccounts = ["379-1111", "379-2574"]และไม่พบสิ่งที่กล่าวมา คุณสามารถค้นหาAccounts includes ["379-1111"]และค้นหาเอกสารด้านบน และคุณสามารถค้นหาAccounts includes any of ["974-3785","414-6731"]และค้นหาเอกสารข้างต้นและสิ่งใดก็ตามที่มีบัญชี "974-3785" หากมี

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

หากข้อมูลของคุณส่วนใหญ่แบนสัมพันธ์และโครงสร้างอย่างเหนียวแน่นคุณจะดีกว่าด้วยฐานข้อมูลเชิงสัมพันธ์ สัญญาณขนาดใหญ่คือว่าข้อมูลของคุณเป็นแบบจำลองที่ดีที่สุดในการรวบรวมไฟล์ CSV ที่เกี่ยวข้องหรือชุดของไฟล์ XML / JSON / YAML

สำหรับโครงการส่วนใหญ่คุณจะต้องประนีประนอมโดยยอมรับการแก้ไขปัญหาเล็กน้อยในพื้นที่เล็ก ๆ ที่ SQL หรือ Document Store ไม่พอดี สำหรับโครงการขนาดใหญ่และซับซ้อนที่เก็บการกระจายข้อมูลในวงกว้าง (หลายคอลัมน์; แถวไม่เกี่ยวข้อง) มันจะสมเหตุสมผลที่จะเก็บข้อมูลในรูปแบบหนึ่งและข้อมูลอื่นในรูปแบบอื่น Facebook ใช้ทั้ง SQL และฐานข้อมูลกราฟ (โดยที่ข้อมูลถูกใส่ลงในโหนดและโหนดเชื่อมต่อกับโหนดอื่น) Craigslist เคยใช้ MySQL และ MongoDB แต่ได้รับการมองการย้ายทั้งหมดไปยัง MongoDB เหล่านี้คือสถานที่ที่ช่วงและความสัมพันธ์ของข้อมูลเผชิญกับแต้มต่อสำคัญหากวางไว้ภายใต้รูปแบบเดียว

Redis: คีย์ - ค่า

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

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

กรณีที่ชัดเจนที่สุดของการทำให้การปรับปรุงในการเขียน: ถ้าคุณอ่านuser:Simon:lingots = NOTFOUNDคุณอาจSELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simonและเก็บผลที่ได้เป็น100 SET user:Simon:lingots = 100จากนั้นเมื่อคุณได้รับรางวัล Simon 5 lingots คุณอ่านuser:Simon:lingots = 100, และSET user:Simon:lingots = 105 UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simonตอนนี้คุณมี 105 ในฐานข้อมูลของคุณและใน Redis และสามารถรับได้user:Simon:lingotsโดยไม่ต้องสอบถามฐานข้อมูล

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

$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
  $t = BuildTemplate("StatsBox.tmpl",
                     GetStatsFromDatabase($playerName));
  SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;

เนื่องจากคุณเพิ่งอัปเดตผลลัพธ์ของGetStatsFromDatabase("Simon")คุณจึงต้องtemplates:*:Simonออกจากแคชคีย์ - ค่าของคุณ เมื่อคุณพยายามแสดงผลเทมเพลตเหล่านี้แอปพลิเคชันของคุณจะทำการดึงข้อมูลจากฐานข้อมูลของคุณ (PostgreSQL, MongoDB) และแทรกลงในเทมเพลตของคุณ จากนั้นจะเก็บผลลัพธ์ใน Redis และหวังว่าจะไม่ทำให้แบบสอบถามฐานข้อมูลและเทมเพลตการแสดงผลในครั้งถัดไปที่แสดงบล็อกของเอาต์พุตนั้น

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

ข้อสรุป

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

และคุณไม่ควรใช้ถ้าคุณมี RAM มากมาย Redis และ MongoDB มาถึงราคาของเครื่องมือเอนกประสงค์ นี่เป็นการแนะนำค่าใช้จ่ายจำนวนมาก

มีคำกล่าวว่า Redis เร็วกว่า Mongo 10 เท่า นั่นอาจไม่เป็นความจริงอีกต่อไป MongoDB (ถ้าฉันจำได้ถูกต้อง) อ้างว่าเอาชนะ memcache สำหรับจัดเก็บและแคชเอกสารตราบเท่าที่การกำหนดค่าหน่วยความจำเหมือนกัน

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

Redis และ MongoDB เป็นทั้งฐานข้อมูลที่ไม่เกี่ยวข้อง แต่มีประเภทต่างกัน

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

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

หากโครงการของคุณถูกจัดสรรให้คุณมีหน่วยความจำ RAM เพียงพอในสภาพแวดล้อมของคุณ - คำตอบคือ Redis โดยเฉพาะการพิจารณา Redis 3.2 ใหม่ด้วยฟังก์ชั่นคลัสเตอร์