ขนาดของข้อมูลที่เป็นประโยชน์ในการย้ายจาก SQL เป็น NoSQL คืออะไร?

ในฐานะโปรแกรมเมอร์ฐานข้อมูลเชิงสัมพันธ์ (ส่วนใหญ่) ฉันอ่านบทความเกี่ยวกับวิธีที่ฐานข้อมูลเชิงสัมพันธ์ไม่ได้ปรับขนาดและโซลูชั่น NoSQL เช่น MongoDB ทำ เนื่องจากฐานข้อมูลส่วนใหญ่ที่ฉันพัฒนามามีขนาดเล็กจนถึงขนาดกลางฉันไม่เคยมีปัญหาที่ไม่ได้รับการแก้ไขด้วยการจัดทำดัชนีการเพิ่มประสิทธิภาพการสืบค้นหรือการออกแบบสคีมา

ขนาดที่ฉันคาดหวังว่าจะเห็น MySQL ดิ้นรนกับขนาด มีกี่แถว

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

ข้อมูลมีขนาดใหญ่เพียงใด

มีขีด จำกัด ที่สำคัญสองประการ:

1. ข้อมูลทั้งหมดจะพอดีกับ RAM
2. ข้อมูลดัชนีทั้งหมดพอดีใน RAM

ด้วย SSD ที่รวดเร็วเกณฑ์แรกก็กลายเป็นปัญหาน้อยลงเว้นแต่คุณจะมีปริมาณการใช้งานสูงมาก

ความเป็นกรด

ปัญหาอย่างหนึ่งของการปรับขนาด RDBMS คือโดยการออกแบบเป็น ACID ซึ่งหมายถึงธุรกรรมและการล็อกระดับแถว (หรือแม้แต่ระดับตารางใน RDBMS ที่เก่ากว่า / ง่ายกว่า) อาจเป็นปัจจัย จำกัด หากคุณมีการค้นหาจำนวนมากที่แก้ไขข้อมูลจำนวนมากที่ทำงานในเวลาเดียวกัน โซลูชัน NoSQL มักจะเป็นโมเดลที่สอดคล้องกันในที่สุด

RDBMS ปรับขนาดข้อมูลอย่างไร

มันไม่ได้เป็นความจริงอย่างสิ้นเชิงว่า RDBMS ไม่สามารถปรับขนาดกับขนาดของข้อมูลที่มีสองทางเลือก: การแบ่งแนวตั้งและแนวนอนแบ่งพาร์ทิชัน (aka sharding)

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

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

ในกรณีที่มีการแบ่งพาร์ติชั่นทั้งสองแบบถ้าคุณไปสุดขั้วคุณจะพบกับสถานการณ์เดียวกับฐานข้อมูล NoSQL

ฉันไม่คิดว่าขนาดของข้อมูลเป็นเพียงปัจจัยเดียว "ตัวแบบข้อมูล" ก็เป็นส่วนที่สำคัญเช่นกัน

หน้าแคตตาล็อกอีคอมเมิร์ซ (Solr, ElasticSearch) ข้อมูลการวิเคราะห์เว็บ (Riak, Cassandra) ราคาหุ้น (Redis) การเชื่อมต่อความสัมพันธ์ในเครือข่ายสังคมออนไลน์ (Neo4J, FleetDB) เป็นเพียงตัวอย่างเมื่อโซลูชัน NoSQL ส่องแสงจริงๆ

IMHO แบบจำลองข้อมูลมีบทบาทสำคัญมากกว่าขนาดของข้อมูลเมื่อพิจารณาโซลูชัน NoSQL หรือ RDBMS

หากฐานข้อมูลเชิงสัมพันธ์ไม่ได้ขยายขนาด ไม่ต้องกังวลเกี่ยวกับปัญหาการปรับสเกล

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

พิจารณาตารางที่ตั้งสำนักงานในระดับประเทศจังหวัด / รัฐ, เขต, เมืองและหมู่บ้านโดยแต่ละสำนักงานจะอ้างอิงสำนักงานที่รายงาน นอกจากนี้ไม่มีการรับประกันว่าสำนักงานการรายงานของสำนักงานแต่ละแห่งเป็นเพียงขึ้นหนึ่งระดับ สำหรับชุดสำนักงานที่เลือกไม่ใช่สำนักงานทั้งหมดในระดับเดียวคุณต้องการแสดงรายการสำนักงานแห่งชาติที่เกี่ยวข้อง สิ่งนี้ต้องการลูปของ statments SQL และจะใช้เวลานานแม้กระทั่งทุกวันนี้ (ฉันเคยใช้เวลา 30 วินาทีในการเลือกสำนักงาน 30 แห่ง แต่เมื่อนานมาแล้ว - และการเปลี่ยนไปใช้ขั้นตอนการจัดเก็บช่วยหน่อย)

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

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

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

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

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

RDBMS สามารถทำได้ แต่คลื่นลูกใหม่ของฐานข้อมูล NoSQL ถูกสร้างขึ้นเพื่อทำสิ่งนี้ Oracle, MSSQL, MySQL ใช้โมเดลส่วนกลางและปรับแต่งมันเพื่อให้ทำงานในสภาพแวดล้อมแบบกระจาย อย่างไรก็ตามพวกเขายังคงปฏิบัติตามกฎ ACID ที่เข้มงวดในขณะที่ฐานข้อมูลใหม่บางส่วนไม่ปฏิบัติตามกฎที่เข้มงวดเช่นโดยใช้ความสอดคล้องในที่สุด

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

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

เช่นเดียวกับคนอื่น ๆ ที่บอกว่าคุณควรคำนึงถึงสิ่งที่เกิดขึ้นในใบสมัครของคุณด้วย ถ้าคุณต้องการ ACID ข้ามหลายตารางคุณจำเป็นต้องใช้ RDBMS จริง ๆ แต่ถ้าคุณมีบางอย่างที่คุณสามารถมีข้อมูลเก่า ๆ ได้บ้างและคุณต้องการความยืดหยุ่นของ NoSQL schema (เรียกว่า schemaless ถ้าคุณชอบ แต่มันเป็น ยังคงมีรูปแบบของ implicit schema) จากนั้นคุณอาจพิจารณาคว้า NoSQL store ( http://www.10gen.com/customers/craigslistที่นี่เป็นตัวอย่างของเหตุผลที่ craigslist เปลี่ยนไป ... แต่ยอมรับว่าพวกเขากำลังเก็บถาวร ~ 10TB จาก ข้อมูลที่ฉันรู้ว่าไม่พอดีกับฐานข้อมูลขนาดเล็กถึงขนาดกลางของคุณ แต่กรณีการใช้งานอาจมีประโยชน์)

โปรดจำไว้ว่าระบบ NoSQL นั้นไม่จำเป็นต้องแทนที่ RDMS แต่ในหลาย ๆ กรณีคุณสามารถเสริม RDBMS ของคุณผ่านแนวคิดของ Polyglot Persistence และคุณสามารถเก็บข้อมูลส่วนใหญ่ของคุณใน RDBMS แต่ในกรณีเฉพาะคุณสามารถถ่ายบางส่วนของคุณได้ ข้อมูลไปยังรูปแบบบางส่วนของการจัดเก็บ NoSQL

Mongoสามารถติดตั้งได้กับคอมพิวเตอร์ / โหนดจำนวนหนึ่ง PostgreSQLไม่ได้ให้เครื่องมือในตัวสำหรับการแยกชิ้นส่วนแต่citusอยู่ใกล้ ๆ

MongoDBรองรับฐานข้อมูลสูงสุด 64 เทราไบต์และขนาดเอกสาร 16 เมกะไบต์

MySQLมีขีด จำกัด ฐานข้อมูล 256 เทราไบต์, 64 เทราไบต์ขนาดสูงสุดสำหรับตารางและ จำกัด การบันทึก 4 กิกะไบต์

PostgreSQLไม่มีข้อ จำกัด ในฐานข้อมูล (4 เทราไบต์มีอยู่ที่ใดที่หนึ่งสำหรับการทดสอบ) และมีขีด จำกัด 1 กิกะไบต์สำหรับขนาดของฟิลด์ใดฟิลด์หนึ่งในตารางและอีก 64 เทราไบต์สำหรับขนาดสูงสุดของตาราง