NoSQL (MongoDB) vs Lucene (หรือ Solr) เป็นฐานข้อมูลของคุณ

ด้วยความเคลื่อนไหว NoSQL ที่เพิ่มขึ้นตามฐานข้อมูลที่ใช้เอกสารฉันได้ดู MongoDB เมื่อเร็ว ๆ นี้ ฉันได้สังเกตเห็นความคล้ายคลึงกันที่น่าทึ่งกับวิธีการปฏิบัติต่อรายการเป็น "เอกสาร" เช่นเดียวกับ Lucene (และผู้ใช้ของ Solr)

ดังนั้นคำถาม: ทำไมคุณต้องการใช้ NoSQL (MongoDB, Cassandra, CouchDB ฯลฯ ) เหนือ Lucene (หรือ Solr) เป็น "ฐานข้อมูล" ของคุณ?

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

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

คุณสามารถเปรียบเทียบผู้ให้บริการแคชนอกเช่น Velocity หรือ MemCached เมื่อพูดถึงการจัดเก็บข้อมูลที่คล้ายกันและความยืดหยุ่นของ MongoDB

ข้อ จำกัด ของ MongoDB ทำให้ฉันนึกถึงการใช้ MemCached แต่ฉันสามารถใช้ Velocity ของ Microsoft และมีการจัดกลุ่มและการรวบรวมรายชื่อมากกว่า MongoDB (ฉันคิดว่า) ไม่สามารถรับได้เร็วขึ้นหรือปรับขนาดได้กว่าการแคชข้อมูลในหน่วยความจำ แม้แต่ Lucene ก็มีผู้ให้บริการหน่วยความจำ

MongoDB (และอื่น ๆ ) มีข้อดีเช่นความสะดวกในการใช้ API สร้างเอกสารใหม่สร้าง ID และเก็บไว้ เสร็จสิ้น ดีและง่าย

นี่เป็นคำถามที่ยอดเยี่ยมสิ่งที่ฉันได้ไตร่ตรองมาบ้าง ฉันจะสรุปบทเรียนที่ได้เรียนรู้:

1. คุณสามารถใช้ Lucene / Solr แทน MongoDB ได้อย่างง่ายดายสำหรับทุกสถานการณ์ แต่ไม่ใช่ในทางกลับกัน โพสต์ของ Grant Ingersoll สรุปได้ที่นี่

2. MongoDB เป็นต้นดูเหมือนจะให้บริการตามวัตถุประสงค์ที่ไม่ต้องการการค้นหาและ / หรือการเผชิญ มันดูเหมือนจะเป็นการเปลี่ยนที่ง่ายขึ้นและง่ายขึ้นสำหรับโปรแกรมเมอร์ในการล้างสารพิษจากโลก RDBMS Lucene & Solr นอกจากจะคุ้นเคยกับมันแล้ว

3. มีไม่มากตัวอย่างของการใช้ Lucene / Solr เป็น Datastore แต่การ์เดียนได้ทำให้ความคืบหน้าบางและสรุปนี้ในการที่ดีเยี่ยมสไลด์ดาดฟ้าแต่พวกเขาก็มีความไม่ผูกมัดบนทั้งหมดกระโดดบน bandwagon Solr และ "การตรวจสอบ" การรวม Solr ด้วย CouchDB

4. ในที่สุดฉันจะนำเสนอประสบการณ์ของเรา แต่น่าเสียดายที่ไม่สามารถเปิดเผยได้มากเกี่ยวกับกรณีธุรกิจ เราทำงานบนมาตราส่วนของข้อมูลจำนวนหลาย TB ซึ่งเป็นแอปพลิเคชันใกล้เวลาจริง หลังจากตรวจสอบชุดค่าผสมต่าง ๆ ตัดสินใจติดกับ Solr ไม่มีความเสียใจในตอนนี้ (6 เดือน & การนับ) และไม่เห็นเหตุผลที่จะเปลี่ยนไปใช้สิ่งอื่น

สรุป: หากคุณไม่มีข้อกำหนดการค้นหา Mongo เสนอวิธีการที่ง่ายและมีประสิทธิภาพ อย่างไรก็ตามหากการค้นหาเป็นกุญแจสำคัญในข้อเสนอของคุณคุณน่าจะติดเทคโนโลยีเดียว (Solr / Lucene) และปรับการใช้ประโยชน์จากมัน - ชิ้นส่วนที่เคลื่อนไหวน้อยลง

2 เซนต์ของฉันหวังว่าจะช่วย

คุณไม่สามารถปรับปรุงเอกสารบางส่วนใน solr คุณต้องโพสต์ฟิลด์ทั้งหมดอีกครั้งเพื่ออัปเดตเอกสาร

และเรื่องประสิทธิภาพ หากคุณไม่ยอมรับการเปลี่ยนแปลง solr ของคุณจะไม่มีผลถ้าคุณส่งมอบทุกครั้งประสิทธิภาพจะลดลง

ไม่มีธุรกรรมใน solr

เนื่องจาก solr มีข้อเสียเหล่านี้บางครั้ง nosql จึงเป็นทางเลือกที่ดีกว่า

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

[... ] อย่างไรก็ตามเราสังเกตว่าประสิทธิภาพการค้นหาของ Solr ลดลงเมื่อขนาดดัชนีเพิ่มขึ้น เราตระหนักว่าทางออกที่ดีที่สุดคือการใช้ทั้ง Solr และ Mongo DB ด้วยกัน จากนั้นเรารวม Solr กับ MongoDB โดยจัดเก็บเนื้อหาลงใน MongoDB และสร้างดัชนีโดยใช้ Solr สำหรับการค้นหาข้อความแบบเต็ม เราเก็บ id เฉพาะสำหรับแต่ละเอกสารในดัชนี Solr และดึงเนื้อหาจริงจาก MongoDB หลังจากค้นหา Solr การรับเอกสารจาก MongoDB นั้นเร็วกว่า Solr เพราะไม่มีการวิเคราะห์การให้คะแนน ฯลฯ [... ]

นอกจากนี้โปรดทราบว่าบางคนได้รวม Solr / Lucene เข้ากับ Mongo โดยการจัดทำดัชนีทั้งหมดจะถูกเก็บไว้ใน Solr และตรวจสอบการทำงานของ oplog และลดการปรับปรุงที่เกี่ยวข้องลงใน Solr

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

มันค่อนข้างเทคนิคในการเซ็ตอัพ แต่มี oplog tailers มากมายที่สามารถรวมเข้ากับ solr ได้ ตรวจสอบสิ่งที่ rangespan ทำในบทความนี้

http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html

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

และที่นี่ที่ Lucene / Solr ได้รับชัยชนะครั้งใหญ่โดยเฉพาะอย่างยิ่งกับการแคช FilterQuery ประสิทธิภาพนั้นยอดเยี่ยม

เนื่องจากไม่มีใครพูดถึงมันขอให้ฉันเพิ่ม MongoDB ที่เป็น schema-less ในขณะที่ Solr บังคับให้ schema ดังนั้นหากฟิลด์เอกสารของคุณมีแนวโน้มที่จะเปลี่ยนแปลงนั่นเป็นเหตุผลหนึ่งที่เลือก MongoDB ผ่าน Solr

@ mauricio-scheffer พูดถึง Solr 4 - สำหรับผู้ที่สนใจ LucidWorks อธิบาย Solr 4 เป็น "เซิร์ฟเวอร์ค้นหา NoSQL" และมีวิดีโอที่http://www.lucidworks.com/webinar-solr-4-the-nosql - การค้นหาเซิร์ฟเวอร์ /ที่พวกเขาเข้าไปดูรายละเอียดเกี่ยวกับคุณสมบัติ NoSQL (ish) (-ish นั้นมีไว้สำหรับสกีมาเวอร์ชันจริงของพวกเขาเป็นสกีมาแบบไดนามิก)

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

โซลูชันของ บริษัท อื่นเช่นหาง mongo op-log น่าสนใจ ความคิดหรือคำถามบางส่วนยังคงเกี่ยวกับการแก้ปัญหาที่สามารถบูรณาการอย่างแน่นหนาสมมติว่ามุมมองการพัฒนา / สถาปัตยกรรม ฉันไม่ได้คาดหวังว่าจะเห็นโซลูชันที่ผสานรวมอย่างแน่นหนาสำหรับคุณสมบัติเหล่านี้ด้วยเหตุผลบางประการ (ค่อนข้างเป็นการเก็งกำไรและอาจมีการชี้แจงและไม่ได้รับการปรับปรุงด้วยความพยายาม):

• Mongo คือ c ++, lucene / solr คือ java
  • บางที Lucene อาจใช้ libs mongo ได้บ้าง
  • บางทีชาวongoอาจจะเขียนอัลกอริธึมลูซีนใหม่ให้ดู:
    • http://clucene.sourceforge.net/
    • http://lucy.apache.org/
• lucene รองรับรูปแบบเอกสารต่างๆ
  • mongo มุ่งเน้นไปที่ JSON (BSON)
• lucene ใช้เอกสารที่ไม่เปลี่ยนรูป
  • การอัปเดตฟิลด์เดียวเป็นปัญหาถ้ามี
• ดัชนี Lucene ไม่เปลี่ยนรูปด้วย ops ผสานที่ซับซ้อน
• คำสั่ง mongo คือ javascript
• mongo ไม่มีข้อความวิเคราะห์ / tokenizers (AFAIK)
• Mongo doc มีขนาด จำกัด ซึ่งอาจเทียบกับเกรนสำหรับลูซีน
• การรวมตัวกันของ mongo อาจไม่มีตำแหน่งใน lucene
  • lucene มีตัวเลือกในการจัดเก็บเขตข้อมูลข้ามเอกสาร แต่นั่นไม่ใช่สิ่งเดียวกัน
  • อย่างใด solr ให้การรวม / สถิติและแบบสอบถาม SQL / กราฟ

MongoDB Atlas จะมีเสิร์ชเอ็นจิ้นที่ใช้สารลูซีนในไม่ช้า การประกาศครั้งใหญ่ได้เกิดขึ้นในการประชุม MongoDB World 2019 ในสัปดาห์นี้ นี่เป็นวิธีที่ยอดเยี่ยมในการสนับสนุนการใช้งานผลิตภัณฑ์ MongoDB Atlas ที่มีรายได้สูง

ฉันหวังว่าจะเห็นมันม้วนเข้าสู่ MongoDB Enterprise เวอร์ชัน 4.2 แต่ไม่มีข่าวว่าจะนำไปสู่สายผลิตภัณฑ์ของพวกเขาในช่วงต้น

ข้อมูลเพิ่มเติมที่นี่: https://www.mongodb.com/atlas/full-text-search