การใช้ฐานข้อมูล NoSQL ทำไม่ได้กับชุดข้อมูลขนาดใหญ่ที่คุณต้องการค้นหาตามเนื้อหาหรือไม่?

ฉันได้เรียนรู้เกี่ยวกับฐานข้อมูล NoSQL เป็นเวลาหนึ่งสัปดาห์แล้ว

ฉันเข้าใจถึงข้อดีของฐานข้อมูล NoSQL และกรณีการใช้งานจำนวนมากที่ยอดเยี่ยม

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

ฐานข้อมูล NoSQL เป็นที่เก็บคีย์ - ค่า (มัก)

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

ดังนั้นฐานข้อมูล NoSQL จึงไม่ใช่ทางเลือกสำหรับการเก็บข้อมูลที่ต้องการค้นหาเนื้อหาของพวกเขา หรือฉันเข้าใจผิดบางอย่าง?

ตัวอย่าง:

คุณต้องจัดเก็บข้อมูลผู้ใช้สำหรับ webshop

ในฐานข้อมูลเชิงสัมพันธ์คุณเก็บผู้ใช้ทุกคนเป็นแถวในusersตารางโดยมี ID, ชื่อ, ประเทศของเขา ฯลฯ

ในฐานข้อมูล NoSQL คุณจะเก็บ ID ของผู้ใช้แต่ละคนเป็นกุญแจและข้อมูลทั้งหมดของเขา (เข้ารหัสใน JSON ฯลฯ ) เป็นค่า

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

ฉันไม่ได้บอกว่ามันเป็นไปไม่ได้แต่มันก็ยากกว่ามากและฉันคิดว่ามันไม่ได้ผลถ้าคุณต้องการค้นหาในข้อมูลของ NoSQL

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

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

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

ในฐานข้อมูล NoSQL คุณมีเกณฑ์เดียวเท่านั้นที่คุณสามารถค้นหาได้อย่างมีประสิทธิภาพ - กุญแจ

เห็นได้ชัดว่าไม่เป็นความจริง

ตัวอย่างเช่น MongoDB รองรับดัชนี (จากhttps://docs.mongodb.org/v3.0/core/indexes-introduction/ )

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

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

เช่นเดียวกับ couchbase (จากhttp://docs.couchbase.com/admin/admin/Views/views-intro.html )

มุมมอง Couchbase เปิดใช้งานการจัดทำดัชนีและการสืบค้นข้อมูล

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

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

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

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

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

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

ในการใช้ตัวอย่างในการสืบค้น SQL ตามประเทศนั้นช้าเท่ากับการสแกน NoSQL ของผู้ใช้ทั้งหมดเว้นแต่คุณจะบอกให้ SQL ทำดัชนีusersตารางตามประเทศ NoSQL สามารถทำเช่นเดียวกันกับที่คุณสร้างคอลเลกชันคีย์ - ค่าที่สั่งซื้อซึ่งเป็นดัชนี (เช่นเดียวกับ SQL ที่ทำภายใต้ประทุน) และบำรุงรักษา

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

NoSQL เป็นคำที่ค่อนข้างคลุมเครือเนื่องจากครอบคลุมระบบฐานข้อมูลทั้งหมดที่ไม่สัมพันธ์

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

ไม่มีใครในใจที่ถูกต้องของพวกเขาจะอ้างว่าร้านค้าคีย์ - ค่าสามารถแทนที่ฐานข้อมูลเชิงสัมพันธ์โดยทั่วไป อย่างไรก็ตามอาจมีกรณีการใช้งานเฉพาะที่เก็บคีย์ - ค่าเหมาะสม ร้านค้าคีย์ - ค่ามักจะใช้สำหรับการแคชเนื่องจากโดยทั่วไปแล้วคุณจะแคชไอเท็มตาม id แต่คุณไม่จำเป็นต้องทำการเคียวรีเฉพาะกิจบนแคช ตัวอย่างเช่นไซต์ Stackoverflow เองใช้ Redis (คีย์ - ค่า db) อย่างกว้างขวางแต่สำหรับการแคชเอาต์พุตเท่านั้น ข้อมูล canonical พื้นฐานยังคงอยู่ในฐานข้อมูลเชิงสัมพันธ์

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

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

เป้าหมายเหล่านี้มักขัดแย้งกัน ผู้ใช้ทวิตเตอร์จำนวนมากติดตามผู้คนจากทั่วทุกมุมโลก ฐานข้อมูลของ twitter ควรได้รับการปรับให้เหมาะสมทางภูมิศาสตร์สำหรับการอ่านทวีตหรือการเขียนทวีตหรือไม่

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

ฐานข้อมูล NoSQL นั้นมีส่วนเกี่ยวข้องกับ“ No SQL” เพียงเล็กน้อยเท่านั้น

พวกเขากำลังยอมรับว่าคุณไม่สามารถมีฐานข้อมูลในระดับที่สอดคล้องกันเสมอและรองรับธุรกรรมที่ซับซ้อนและมีความทนทาน

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

ในฐานข้อมูล NoSQL โปรแกรมเมอร์มีหน้าที่รับผิดชอบในการดูแลรักษาดัชนีจำนวนมากและสันนิษฐานว่าดัชนีนั้นจะล้าสมัยอยู่เสมอ

ตัวอย่างเช่น:

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

ตามตัวอย่างจริง Amazon ต้องการแสดงคำอธิบายที่ล้าสมัยของหนังสือมากกว่าการหน่วงเวลาการแสดงหน้าเว็บโดยรอคอมพิวเตอร์ 106 เครื่องเพื่อยืนยันว่าการล็อคที่ถูกต้องได้ถูกนำออกไป

ดังนั้น.....

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

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

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

ฐานข้อมูลเชิงสัมพันธ์ได้รับการปรับให้เหมาะสมเพื่อค้นหาค่าใด ๆ ใน datarow ได้อย่างมีประสิทธิภาพ

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

มีคำตอบมากมายอยู่แล้ว แต่ฉันต้องการเพิ่มบทสรุปของฉัน

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

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

ฉันใช้ couchdb มาสองปีแล้ว ส่วนใหญ่จะใช้สำหรับการจัดการเนื้อหาและการกำหนดค่า

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

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

โปรแกรมเมอร์ส่วนใหญ่เข้าใจ Javascript และโปรแกรมเมอร์ส่วนใหญ่มักประสบกับ SQL เป็นครั้งคราว

ใน Couchdb มุมมองสามารถถือเป็นนามธรรมของเอกสาร JSON โครงสร้างข้อมูลมุมมองขึ้นอยู่กับคุณอย่างไร (คุณไม่ได้ถูก จำกัด โดยลำดับชั้นดั้งเดิม)

ฉันจะไม่ใช้ Couchdb สำหรับข้อมูลการทำธุรกรรมสูง แต่สำหรับข้อมูลกึ่งคงที่ที่มีโครงสร้างชนิดการระเบิดส่วนมันจะทำงานได้ง่ายกว่า SQL

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