NoSQL ใช้กรณีและสถานการณ์เมื่อใช้ NoSQL [ปิด]

ดูเหมือนจะยากที่จะหาข้อมูลที่เชื่อถือได้ว่าจะใช้เมื่อใด ดังนั้นฉันจึงถามคำถามต่อไปนี้และฉันขอโทษถ้าคำถามเหล่านี้เป็นคำถามโง่ ๆ ล่วงหน้า:

1. ฉันควรใช้ NoSQL สำหรับข้อมูลผู้ใช้หรือไม่ โปรไฟล์เช่นชื่อผู้ใช้ + รหัสผ่าน ฯลฯ
2. ฉันควรใช้ NoSQL สำหรับเนื้อหาสำคัญหรือไม่ เช่นบทความบล็อกโพสต์สินค้าคงคลัง ฯลฯ

ฉันคิดว่าไม่ และฉันรู้สึกว่า NoSQL เป็นเพียงสิ่งที่เข้าถึงได้อย่างรวดเร็วซึ่งมันก็โอเคที่จะสูญเสียข้อมูล แต่ฉันยังอ่านด้วยว่าแอป NoSQL มีความซ้ำซ้อนในตัวดังนั้นฉันจะไม่สูญเสียข้อมูลหรือไม่

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

ขอบคุณ!

มันเป็นคำถามแบบ "ขึ้นอยู่กับ" จริงๆ บางจุดทั่วไป :

• โดยทั่วไป NoSQL นั้นดีสำหรับข้อมูลที่ไม่มีโครงสร้าง / "schemaless" - โดยทั่วไปคุณไม่จำเป็นต้องกำหนด schema ของคุณอย่างชัดเจนและสามารถรวมเขตข้อมูลใหม่โดยไม่ต้องทำพิธีใด ๆ
• โดยทั่วไป NoSQL จะชอบ schema ที่เป็นปกติเนื่องจากไม่รองรับ JOIN ต่อโลก RDBMS ดังนั้นคุณมักจะมีการแสดงข้อมูลของคุณแบน
• การใช้ NoSQL ไม่ได้หมายความว่าคุณอาจสูญเสียข้อมูล ฐานข้อมูลที่แตกต่างกันมีกลยุทธ์ที่แตกต่างกัน เช่น MongoDB - คุณสามารถเลือกระดับการแลกเปลี่ยนประสิทธิภาพเทียบกับศักยภาพในการสูญเสียข้อมูล - ประสิทธิภาพที่ดีที่สุด = ขอบเขตที่ดีกว่าสำหรับการสูญเสียข้อมูล
• บ่อยครั้งที่ง่ายมากในการขยายโซลูชัน NoSQL การเพิ่มโหนดเพื่อทำซ้ำข้อมูลเป็นวิธีหนึ่งในการ a) ให้ความยืดหยุ่นที่มากขึ้นและ b) ให้การป้องกันที่มากขึ้นต่อการสูญเสียข้อมูลหากมีโหนดใดโหนดหนึ่งล่ม แต่อีกครั้งขึ้นอยู่กับ NoSQL DB / การกำหนดค่า NoSQL ไม่ได้แปลว่า "การสูญเสียข้อมูล" อย่างที่คุณเห็น
• IMHO แบบสอบถาม / การรายงานที่ซับซ้อน / แบบไดนามิกให้บริการที่ดีที่สุดจาก RDBMS บ่อยครั้งที่ฟังก์ชันการสืบค้นสำหรับ NoSQL DB นั้นถูก จำกัด
• ไม่จำเป็นต้องเป็น 1 หรือตัวเลือกอื่น ประสบการณ์ของฉันใช้ RDBMS ร่วมกับ NoSQL สำหรับกรณีการใช้งานบางอย่าง
• NoSQL DBs มักจะขาดความสามารถในการดำเนินการปรมาณูข้ามหลาย "ตาราง"

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

สำหรับ MongoDb เป็นตัวอย่างให้ตรวจสอบUse Casesของพวกเขาเพื่อดูว่าพวกเขาแนะนำให้ใช้ MongoDb แบบ "เหมาะสมดี" หรือ "ไม่เหมาะสม" หรือไม่

ฉันคิดว่า Nosql นั้น "เหมาะสมกว่า" ในสถานการณ์เหล่านี้เป็นอย่างน้อย

1. ง่ายต่อการปรับขนาดแนวนอนเพียงแค่เพิ่มโหนดเพิ่ม

2. ค้นหาชุดข้อมูลขนาดใหญ่

   ลองนึกภาพทวีตทวีตที่โพสต์บน Twitter ทุกวัน ใน RDMS อาจมีตารางที่มีหลายล้านแถว (หรือหลายพันล้านแถว) และคุณไม่ต้องการทำแบบสอบถามบนตารางเหล่านั้นโดยตรงไม่ต้องพูดถึงเวลาส่วนใหญ่การรวมตารางนั้นจำเป็นสำหรับการสืบค้นที่ซับซ้อนด้วย

3. คอขวด I / O

   หากเว็บไซต์ต้องการส่งผลลัพธ์ไปยังผู้ใช้ที่แตกต่างกันตามข้อมูลเรียลไทม์ของผู้ใช้เราอาจกำลังพูดถึงการร้องขออ่าน / เขียน SQL เป็นหมื่นหรือแสนครั้งต่อวินาที จากนั้นดิสก์ i / o จะเป็นคอขวดที่ร้ายแรง