ข้อมูลใน DBMS เชิงสัมพันธ์ของเรามีจำนวนเพิ่มขึ้นเป็นเวลาที่จะย้ายไปที่ NoSQL หรือไม่?


17

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


3
สำหรับเครือข่ายสังคมออนไลน์ฉันขอแนะนำฐานข้อมูลกราฟอย่างNeo4jหรือOrientDB
Apollo

คำตอบ:


14

ไม่กี่กิกะไบต์ไม่ใหญ่มาก มันเป็นเหมือนขนาดปกติของฐานข้อมูลองค์กร ตราบใดที่คุณเข้าร่วม PK เมื่อเข้าร่วมตารางมันก็จะทำงานได้ดีแม้ในอนาคต (ตราบใดที่คุณไม่ได้รับข้อมูลวัณโรคต่อวัน)

ผู้เชี่ยวชาญส่วนใหญ่ที่ทำงานในสภาพแวดล้อมข้อมูลขนาดใหญ่พิจารณา> ~ 5TBเป็นจุดเริ่มต้นของคำว่าข้อมูลขนาดใหญ่ แต่ถึงอย่างนั้นมันก็ไม่ใช่วิธีที่ดีที่สุดในการติดตั้งฐานข้อมูล nosql ที่ดีที่สุดต่อไป คุณควรคิดถึงงานที่คุณต้องการเก็บถาวรด้วยข้อมูล (สรุปรวมอ่านค้นหาค้นหาเหมือง .. ) เพื่อค้นหาเครื่องมือที่ดีที่สุดสำหรับปัญหาของคุณ

เช่นถ้าคุณทำการค้นหาจำนวนมากในฐานข้อมูลของคุณมันน่าจะดีกว่าถ้าคุณเรียกใช้งานอินสแตนซ์ของกลุ่ม / solr และทำให้ข้อมูลของคุณจาก DBMS เช่น Postgres หรือ SQL Server ของคุณเป็นครั้งคราวและใส่ลงใน solr แทนที่จะย้ายข้อมูล จาก sql ถึง nosql ในแง่ของการคงอยู่และประสิทธิภาพ


10

ในการตอบคำถามนี้คุณต้องตอบว่าคุณสามารถจ่ายได้แบบไหน RDBMS ดำเนินกรด สิ่งนี้มีราคาแพงในแง่ของทรัพยากร ไม่มีโซลูชัน NoSQL ซึ่งเป็นกรด ดูทฤษฎีบทของ CAPเพื่อดำดิ่งลงไปในความคิดเหล่านี้

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


8

บิ๊กดาต้าไม่ได้เกี่ยวกับ "ความยิ่งใหญ่"

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

จากนั้นคุณต้องคิดว่าคุณใช้ข้อมูลของคุณอย่างไร

  • วิธีการของ SQL: ข้อมูลทุกอย่างมีค่ารวบรวมและเลือกมาอย่างดีและมุ่งเน้นที่การจัดเก็บข้อมูลที่มีค่าและมีโครงสร้างสูง สิ่งนี้อาจมีค่าใช้จ่ายสูงทุกอย่างเชื่อมโยงกันและเป็นสิ่งที่ดีสำหรับระบบที่ดีและข้อมูลของฟังก์ชัน
  • วิธีบิ๊กดาต้า: ในข้อมูลขนาดใหญ่คุณมักจะเก็บเกือบทุกอย่างโดยไม่คำนึงถึงคุณค่าที่มีอยู่จากนั้นทำการวิเคราะห์ที่ใช้งานอยู่ สิ่งที่ไม่ได้เชื่อมโยงพวกเขาจะถูกคัดลอก ตัวอย่างเช่นสมมติว่าฉันมีรายการบล็อก ใน Big Data จะไม่มีลิงก์ไปยังผู้แต่ง แต่ผู้เขียนจะถูกฝังอยู่ในรายการบล็อก ปรับขนาดได้มากกว่าวิธี แต่ต้องใช้วิธีที่แตกต่างและซับซ้อนมากขึ้น

หากการจัดเก็บข้อมูลของคุณ "functionnal" ใช้โดยแอปพลิเคชันของคุณฉันจะแนะนำให้คุณใช้ SQL หากการจัดเก็บข้อมูลของคุณเพื่อค้นหาในภายหลังหรือเพื่อรายงานและหากจำนวนข้อมูลนี้อาจเพิ่มขึ้นอย่างรวดเร็วฉันจะแนะนำข้อมูลขนาดใหญ่ ในความคิดของฉันข้อมูลขนาดใหญ่มีประโยชน์เมื่อคุณจัดการกับข้อมูลจริงที่ต้องรวบรวมและวิเคราะห์อย่างต่อเนื่อง


8

ฉันโพสต์คำตอบโดยละเอียดเกี่ยวกับ stackoverflow ว่าควรใช้ฐานข้อมูลเชิงสัมพันธ์กับเอกสาร (หรือ NoSQL) เมื่อใดที่นี่:

แรงจูงใจในการใช้ฐานข้อมูลเชิงสัมพันธ์ / ORM หรือฐานข้อมูลเอกสาร / ODM

สรุป:

  • สำหรับสิ่งเล็ก ๆ ไปกับเครื่องมืออะไรก็ได้ที่คุณคุ้นเคย

  • ไม่กี่กิกะไบต์มีขนาดเล็ก: มันไม่ใหญ่จนกระทั่งมันใหญ่เกินกว่าที่จะใส่ลงในMySQL Clusterเดียวที่มีจำนวนพอสมควร (16-32) ซึ่งหมายความว่าอาจมีข้อมูล 8-16TB และธุรกรรมไม่กี่ล้านรายการ ต่อวินาที (หรือฐานข้อมูลฮาร์ดไดรฟ์ทั่วไปที่มีข้อมูลวัณโรคมากถึง 100 รายการและธุรกรรมไม่กี่พันรายการต่อวินาที)

  • หากคุณติดอยู่กับฐานข้อมูลอื่น (ไม่ใช่ MySQL Cluster) ให้เพิ่มระยะทางมากขึ้นโดยการโยนในฮาร์ดแวร์ FusionIO

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

  • คาสซานดรา :)


6

มันเป็นเวลาที่จะย้ายไป NoSQL จะขึ้นอยู่กับ 2 สิ่ง:

  1. ลักษณะ / โครงสร้างของข้อมูลของคุณ
  2. ประสิทธิภาพปัจจุบันของคุณ

ฐานข้อมูล SQL excel เมื่อข้อมูลมีโครงสร้างที่ดี (เช่นเมื่อสามารถสร้างแบบจำลองเป็นตารางสเปรดชีต Excel หรือชุดของแถวที่มีจำนวนคอลัมน์คงที่) ยังดีเมื่อคุณต้องทำตารางจำนวนมากเข้าร่วม (ซึ่งฟังดูเหมือนคุณ)

ฐานข้อมูล NoSQL จะ excel เมื่อข้อมูลนั้นไม่มีโครงสร้างเกินกว่าคู่ของคีย์ - ค่า

คุณควรถามตัวเองด้วยคำถามเดียว: โซลูชัน SQL ปัจจุบันของคุณช้าหรือไม่?

ถ้าไม่ไปให้ใช้หลักการ " IIABDFI "

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.