คู่มือฉบับสมบูรณ์สำหรับฐานข้อมูล NoSQL
เผยแพร่แล้ว: 2022-03-11ไม่ต้องสงสัยเลยว่าวิธีที่เว็บแอปพลิเคชันจัดการกับข้อมูลได้เปลี่ยนแปลงไปอย่างมากในช่วงทศวรรษที่ผ่านมา มีการรวบรวมข้อมูลมากขึ้นและผู้ใช้เข้าถึงข้อมูลนี้พร้อมกันมากขึ้นกว่าเดิม ซึ่งหมายความว่าความสามารถในการปรับขนาดและประสิทธิภาพเป็นสิ่งที่ท้าทายมากกว่าที่เคยสำหรับฐานข้อมูลเชิงสัมพันธ์ที่ใช้สคีมา ดังนั้นจึงสามารถปรับขนาดได้ยากขึ้น
วิวัฒนาการของ NoSQL
ปัญหาการปรับขนาดของ SQL ได้รับการยอมรับจากบริษัท Web 2.0 ที่มีความต้องการข้อมูลและโครงสร้างพื้นฐานขนาดใหญ่ที่เพิ่มขึ้น เช่น Google, Amazon และ Facebook พวกเขาคิดหาวิธีแก้ไขปัญหาด้วยตนเอง – เทคโนโลยีเช่น BigTable, DynamoDB และ Cassandra
ความสนใจที่เพิ่มขึ้นนี้ส่งผลให้ระบบจัดการฐานข้อมูล NoSQL (DBMS) จำนวนหนึ่งมุ่งเน้นไปที่ประสิทธิภาพ ความน่าเชื่อถือ และความสม่ำเสมอ โครงสร้างการจัดทำดัชนีที่มีอยู่จำนวนหนึ่งถูกนำมาใช้ซ้ำและปรับปรุงโดยมีวัตถุประสงค์เพื่อเพิ่มประสิทธิภาพการค้นหาและการอ่าน
ประการแรก มีฐานข้อมูล NoSQL ประเภทที่เป็นกรรมสิทธิ์ (ปิดแหล่งที่มา) ที่พัฒนาโดยบริษัทขนาดใหญ่เพื่อตอบสนองความต้องการเฉพาะของตน เช่น BigTable ของ Google ซึ่งเชื่อกันว่าเป็นระบบ NoSQL แรก และ DynamoDB ของ Amazon
ความสำเร็จของระบบที่เป็นกรรมสิทธิ์เหล่านี้ได้เริ่มต้นการพัฒนาระบบฐานข้อมูลที่เป็นกรรมสิทธิ์และโอเพนซอร์สที่คล้ายกันจำนวนหนึ่ง ซึ่งระบบที่ได้รับความนิยมมากที่สุดคือ Hypertable, Cassandra, MongoDB, DynamoDB, HBase และ Redis
อะไรทำให้ NoSQL แตกต่าง
ข้อแตกต่างที่สำคัญอย่างหนึ่งระหว่างฐานข้อมูล NoSQL และฐานข้อมูลเชิงสัมพันธ์แบบดั้งเดิมคือข้อเท็จจริงที่ว่า NoSQL เป็นรูปแบบหนึ่งของการ จัดเก็บที่ไม่มีโครงสร้าง
ซึ่งหมายความว่าฐานข้อมูล NoSQL ไม่มี โครงสร้างตารางคงที่เหมือนที่พบในฐานข้อมูลเชิงสัมพันธ์
ข้อดีและข้อเสียของฐานข้อมูล NoSQL
ข้อดี
ฐานข้อมูล NoSQL มีข้อดีหลายประการเมื่อเทียบกับฐานข้อมูลเชิงสัมพันธ์แบบดั้งเดิม
ข้อแตกต่างที่สำคัญประการหนึ่งคือฐานข้อมูล NoSQL มีโครงสร้างที่เรียบง่ายและยืดหยุ่น พวกเขาไม่มีสคีมา
ฐานข้อมูล NoSQL ต่างจากฐานข้อมูลเชิงสัมพันธ์ โดยยึดตามคู่คีย์-ค่า
ฐานข้อมูล NoSQL บางประเภทรวมถึงที่เก็บคอลัมน์ ที่เก็บเอกสาร ที่เก็บคีย์ ที่เก็บกราฟ ที่เก็บอ็อบเจ็กต์ ที่เก็บ XML และโหมดการจัดเก็บข้อมูลอื่นๆ
โดยปกติ แต่ละค่าในฐานข้อมูลจะมีคีย์ ที่เก็บฐานข้อมูล NoSQL บางแห่งยังอนุญาตให้นักพัฒนาจัดเก็บอ็อบเจ็กต์ที่เป็นอนุกรมลงในฐานข้อมูล ไม่ใช่แค่ค่าสตริงอย่างง่าย
ฐานข้อมูล NoSQL แบบโอเพ่นซอร์สไม่ต้องการค่าธรรมเนียมใบอนุญาตที่แพง และสามารถทำงานบนฮาร์ดแวร์ราคาไม่แพง ทำให้การปรับใช้นั้นคุ้มค่า
นอกจากนี้ เมื่อทำงานกับฐานข้อมูล NoSQL ไม่ว่าจะเป็นโอเพ่นซอร์สหรือกรรมสิทธิ์ การขยายจะง่ายกว่าและถูกกว่าเมื่อทำงานกับฐานข้อมูลเชิงสัมพันธ์ เนื่องจากทำได้โดยการปรับขนาดในแนวนอนและกระจายโหลดบนโหนดทั้งหมด แทนที่จะเป็นประเภทการปรับขนาดแนวตั้งที่มักจะทำกับระบบฐานข้อมูลเชิงสัมพันธ์ ซึ่งจะแทนที่โฮสต์หลักด้วยระบบที่มีประสิทธิภาพมากกว่า
ข้อเสีย
แน่นอนว่าฐานข้อมูล NoSQL นั้นไม่ได้สมบูรณ์แบบ และไม่ใช่ตัวเลือกที่ถูกต้องเสมอไป
ประการหนึ่ง ฐานข้อมูล NoSQL ส่วนใหญ่ไม่สนับสนุน คุณลักษณะความน่าเชื่อถือ ที่ได้รับการสนับสนุนโดยกำเนิดโดยระบบฐานข้อมูลเชิงสัมพันธ์ คุณลักษณะความน่าเชื่อถือเหล่านี้สามารถสรุปได้เป็นอะตอมมิก ความสม่ำเสมอ การแยกตัว และความทนทาน นอกจากนี้ยังหมายถึงฐานข้อมูล NoSQL ซึ่งไม่รองรับคุณสมบัติเหล่านั้น ความสอดคล้องทางการค้าสำหรับประสิทธิภาพและความสามารถในการปรับขนาด
เพื่อรองรับคุณสมบัติความน่าเชื่อถือและความสอดคล้องกัน นักพัฒนาต้องใช้โค้ดที่เป็นกรรมสิทธิ์ของตนเอง ซึ่งเพิ่มความซับซ้อนให้กับระบบมากขึ้น
ซึ่งอาจจำกัดจำนวนแอปพลิเคชันที่สามารถพึ่งพาฐานข้อมูล NoSQL สำหรับธุรกรรมที่ปลอดภัยและเชื่อถือได้ เช่น ระบบธนาคาร
ความซับซ้อนรูปแบบอื่นๆ ที่พบในฐานข้อมูล NoSQL ส่วนใหญ่นั้นมีความไม่เข้ากันกับการสืบค้น SQL ซึ่งหมายความว่าจำเป็นต้องใช้ภาษาการสืบค้นด้วยตนเองหรือที่เป็นกรรมสิทธิ์ ซึ่งเพิ่มเวลาและความซับซ้อนมากยิ่งขึ้น
NoSQL กับฐานข้อมูลเชิงสัมพันธ์
ตารางนี้แสดงการเปรียบเทียบคุณลักษณะโดยย่อระหว่าง NoSQL และฐานข้อมูลเชิงสัมพันธ์:
คุณสมบัติ | ฐานข้อมูล NoSQL | ฐานข้อมูลเชิงสัมพันธ์ |
---|---|---|
ผลงาน | สูง | ต่ำ |
ความน่าเชื่อถือ | ยากจน | ดี |
มีจำหน่าย | ดี | ดี |
ความสม่ำเสมอ | ยากจน | ดี |
การจัดเก็บข้อมูล | ปรับให้เหมาะสมสำหรับข้อมูลขนาดใหญ่ | ขนาดกลางถึงใหญ่ |
ความสามารถในการปรับขนาด | สูง | สูง (แต่แพงกว่า) |
ควรสังเกตว่าตารางแสดงการเปรียบเทียบใน ระดับฐานข้อมูล ไม่ใช่ ระบบจัดการฐานข้อมูล ต่างๆ ที่ใช้ทั้งสองรุ่น ระบบเหล่านี้มี เทคนิคที่เป็นกรรมสิทธิ์ของตนเอง เพื่อเอาชนะปัญหาและข้อบกพร่องบางประการในทั้งสองระบบ และในบางกรณีจะปรับปรุงประสิทธิภาพและความน่าเชื่อถือได้อย่างมาก
NoSQL Data Store ประเภท
คีย์ แวลู สโตร์
ในประเภทที่เก็บค่าคีย์ ตารางแฮชถูกใช้โดยคีย์เฉพาะจะชี้ไปที่รายการ
คีย์สามารถจัดเป็นกลุ่มของคีย์แบบลอจิคัลได้ โดยกำหนดให้คีย์ไม่ซ้ำกันภายในกลุ่มของคีย์เท่านั้น ซึ่งช่วยให้สามารถใช้คีย์ที่เหมือนกันในกลุ่มลอจิคัลต่างๆ ตารางต่อไปนี้แสดงตัวอย่างที่เก็บคีย์-ค่า ซึ่งคีย์คือชื่อของเมือง และค่าคือที่อยู่ของ Ulster University ในเมืองนั้น
สำคัญ | ค่า |
---|---|
"เบลฟาสต์" | {“มหาวิทยาลัยอัลสเตอร์ วิทยาเขตเบลฟาสต์ ถนนยอร์ก เบลฟาสต์ BT15 1ED"} |
“โคเลน” | {“มหาวิทยาลัย Ulster วิทยาเขต Coleraine ถนน Cromore Co. Londonderry BT52 1SA”} |
การใช้งานที่เก็บค่าคีย์บางส่วนมีกลไกการแคช ซึ่งช่วยเพิ่มประสิทธิภาพการทำงานอย่างมาก
สิ่งที่จำเป็นในการจัดการกับรายการที่จัดเก็บไว้ในฐานข้อมูลคือกุญแจสำคัญ ข้อมูลถูกจัดเก็บในรูปแบบของสตริง JSON หรือ BLOB (Binary Large OBject)
ข้อบกพร่องที่ใหญ่ที่สุดประการหนึ่งของฐานข้อมูลรูปแบบนี้คือการขาดความสอดคล้องในระดับฐานข้อมูล นักพัฒนาสามารถเพิ่มสิ่งนี้ได้ด้วยรหัสของตนเอง แต่ดังที่ได้กล่าวไว้ก่อนหน้านี้ สิ่งนี้จะเพิ่มความพยายาม ความซับซ้อน และเวลามากขึ้น
ฐานข้อมูล NoSQL ที่มีชื่อเสียงที่สุดซึ่งสร้างขึ้นจากที่เก็บค่าคีย์คือ DynamoDB ของ Amazon
ร้านเอกสาร
ที่เก็บเอกสารคล้ายกับที่เก็บค่าคีย์ซึ่งไม่มีสคีมาและอิงตามโมเดลคีย์-ค่า ทั้งสองจึงมีข้อดีและข้อเสียเหมือนกันหลายอย่าง ทั้งสองไม่มีความสอดคล้องกันในระดับฐานข้อมูล ซึ่งทำให้แอปพลิเคชันมีคุณลักษณะความน่าเชื่อถือและความสอดคล้องกันมากขึ้น
อย่างไรก็ตาม มีความแตกต่างที่สำคัญระหว่างทั้งสอง
ใน Document Stores ค่า (เอกสาร) จะให้การเข้ารหัสสำหรับข้อมูลที่เก็บไว้ การเข้ารหัสเหล่านั้นอาจเป็น XML, JSON หรือ BSON (ไบนารีที่เข้ารหัส JSON)
นอกจากนี้ยังสามารถสืบค้นตามข้อมูลได้อีกด้วย
แอปพลิเคชั่นฐานข้อมูลยอดนิยมที่ใช้ Document Store คือ MongoDB
ร้านค้าคอลัมน์
ในฐานข้อมูล Column Store ข้อมูลจะถูกเก็บไว้ในคอลัมน์ ซึ่งต่างจากการจัดเก็บในแถวเช่นเดียวกับที่ทำในระบบการจัดการฐานข้อมูลเชิงสัมพันธ์ส่วนใหญ่
ที่เก็บคอลัมน์ประกอบด้วยกลุ่มคอลัมน์อย่างน้อยหนึ่งกลุ่มที่จัดกลุ่มบางคอลัมน์ตามตรรกะในฐานข้อมูล คีย์ใช้เพื่อระบุและชี้ไปที่คอลัมน์จำนวนหนึ่งในฐานข้อมูล โดยมีแอตทริบิวต์คีย์สเปซที่กำหนดขอบเขตของคีย์นี้ แต่ละคอลัมน์ประกอบด้วย tuples ของชื่อและค่า เรียงลำดับและคั่นด้วยเครื่องหมายจุลภาค
ร้านค้าคอลัมน์มีสิทธิ์อ่าน/เขียนข้อมูลที่เก็บไว้อย่างรวดเร็ว ในที่เก็บคอลัมน์ แถวที่สอดคล้องกับคอลัมน์เดียวจะถูกจัดเก็บเป็นรายการดิสก์เดียว ทำให้เข้าถึงได้เร็วขึ้นในระหว่างการดำเนินการอ่าน/เขียน
ฐานข้อมูลยอดนิยมที่ใช้ที่เก็บคอลัมน์ ได้แก่ BigTable, HBase และ Cassandra ของ Google
ฐานกราฟ
ในฐานข้อมูล NoSQL ของ Graph Base โครงสร้างกราฟแบบกำหนดทิศทางจะใช้เพื่อแสดงข้อมูล กราฟประกอบด้วยขอบและโหนด
อย่างเป็นทางการ กราฟเป็นตัวแทนของชุดของวัตถุ ซึ่งบางคู่ของวัตถุเชื่อมต่อกันด้วยลิงก์ วัตถุที่เชื่อมต่อถึงกันจะแสดงด้วยนามธรรมทางคณิตศาสตร์ที่เรียกว่าจุดยอด และจุดเชื่อมโยงที่เชื่อมจุดยอดบางคู่เรียกว่าขอบ ชุดของจุดยอดและขอบที่เชื่อมต่อกันเรียกว่ากราฟ
ซึ่งแสดงให้เห็นโครงสร้างของฐานข้อมูลฐานกราฟที่ใช้ขอบและโหนดเพื่อแสดงและจัดเก็บข้อมูล โหนดเหล่านี้ถูกจัดระเบียบโดยความสัมพันธ์บางอย่างซึ่งแสดงโดยขอบระหว่างโหนด ทั้งโหนดและความสัมพันธ์มีคุณสมบัติที่กำหนดไว้บางอย่าง
ฐานข้อมูลกราฟมักใช้ในแอปพลิเคชันเครือข่ายสังคมออนไลน์ ฐานข้อมูลกราฟช่วยให้นักพัฒนาให้ความสำคัญกับความสัมพันธ์ระหว่างวัตถุมากกว่าวัตถุ ในบริบทนี้ พวกเขายอมให้มีสภาพแวดล้อมที่ปรับขนาดได้และใช้งานง่ายอย่างแท้จริง
ปัจจุบัน InfoGrid และ InfiniteGraph เป็นฐานข้อมูลกราฟที่ได้รับความนิยมมากที่สุด
ระบบการจัดการฐานข้อมูล NoSQL
สำหรับการเปรียบเทียบโดยย่อของฐานข้อมูล ตารางต่อไปนี้แสดงการเปรียบเทียบสั้นๆ ระหว่างระบบการจัดการฐานข้อมูล NoSQL ที่แตกต่างกัน
ประเภทการจัดเก็บ | วิธีการสืบค้น | อินเตอร์เฟซ | ภาษาโปรแกรม | โอเพ่นซอร์ส | การจำลองแบบ | |
---|---|---|---|---|---|---|
แคสแซนดรา | ร้านค้าคอลัมน์ | Thrift API | ประหยัด | Java | ใช่ | อะซิงโครนัส |
MongoDB | ร้านเอกสาร | แบบสอบถาม Mongo | TCP/IP | C++ | ใช่ | อะซิงโครนัส |
HyperTable | ร้านค้าคอลัมน์ | HQL | ประหยัด | Java | ใช่ | อะซิงโครนัส |
CouchDB | ร้านเอกสาร | แผนที่ลด | พักผ่อน | แอร์ลัง | ใช่ | อะซิงโครนัส |
BigTable | ร้านค้าคอลัมน์ | แผนที่ลด | TCP/IP | C++ | ไม่ | อะซิงโครนัส |
HBase | ร้านค้าคอลัมน์ | แผนที่ลด | พักผ่อน | Java | ใช่ | อะซิงโครนัส |
MongoDB มีที่เก็บข้อมูลสคีมาที่ยืดหยุ่น ซึ่งหมายความว่าอ็อบเจ็กต์ที่เก็บไว้ไม่จำเป็นต้องมีโครงสร้างหรือฟิลด์เดียวกัน MongoDB ยังมีคุณสมบัติการปรับให้เหมาะสม ซึ่งกระจายการรวบรวมข้อมูลไปทั่ว ส่งผลให้มีการปรับปรุงประสิทธิภาพโดยรวมและระบบที่สมดุลมากขึ้น
ระบบฐานข้อมูล NoSQL อื่นๆ เช่น Apache CouchDB ยังเป็นฐานข้อมูลประเภทที่เก็บเอกสาร และใช้คุณสมบัติร่วมกันมากมายกับ MongoDB ยกเว้นว่าฐานข้อมูลสามารถเข้าถึงได้โดยใช้ RESTful API
REST คือรูปแบบสถาปัตยกรรมที่ประกอบด้วยชุดข้อจำกัดทางสถาปัตยกรรมที่ประสานกันซึ่งนำไปใช้กับส่วนประกอบ ตัวเชื่อมต่อ และองค์ประกอบข้อมูล ภายในเวิลด์ไวด์เว็บ โดยอาศัยโปรโตคอลการสื่อสารแบบไคลเอ็นต์-เซิร์ฟเวอร์แบบไร้สถานะ (เช่น โปรโตคอล HTTP)
แอปพลิเคชัน RESTful ใช้คำขอ HTTP เพื่อโพสต์ อ่านข้อมูล และลบข้อมูล
สำหรับฐานข้อมูลฐานคอลัมน์ Hypertable เป็นฐานข้อมูล NoSQL ที่เขียนด้วย C++ และอิงตาม BigTable ของ Google
Hypertable รองรับการกระจายที่เก็บข้อมูลข้ามโหนดเพื่อเพิ่มความสามารถในการปรับขนาดสูงสุด เช่นเดียวกับ MongoDB และ CouchDB
หนึ่งในฐานข้อมูล NoSQL ที่ใช้กันอย่างแพร่หลายมากที่สุดคือ Cassandra ซึ่งพัฒนาโดย Facebook
Cassandra เป็นฐานข้อมูลที่เก็บคอลัมน์ที่มีคุณลักษณะมากมายที่มุ่งเป้าไปที่ความน่าเชื่อถือและความทนทานต่อข้อผิดพลาด
แทนที่จะให้รายละเอียดเชิงลึกเกี่ยวกับ NoSQL DBMS, Cassandra และ MongoDB ทั้งสองระบบการจัดการฐานข้อมูล NoSQL ที่ใช้กันอย่างแพร่หลายมากที่สุด จะถูกสำรวจในหัวข้อย่อยถัดไป

แคสแซนดรา
Cassandra เป็นระบบจัดการฐานข้อมูลที่พัฒนาโดย Facebook
เป้าหมายเบื้องหลัง Cassandra คือการสร้าง DBMS ที่ไม่มีจุดบกพร่องจุดเดียวและให้ความพร้อมใช้งานสูงสุด
Cassandra ส่วนใหญ่เป็นฐานข้อมูลที่เก็บคอลัมน์ การศึกษาบางชิ้นเรียก Cassandra ว่าเป็นระบบไฮบริด โดยได้รับแรงบันดาลใจจาก BigTable ของ Google ซึ่งเป็นฐานข้อมูลที่เก็บคอลัมน์ และ DynamoDB ของ Amazon ซึ่งเป็นฐานข้อมูลคีย์-ค่า
ซึ่งทำได้โดยการจัดหาระบบคีย์-ค่า แต่คีย์ในคาสซานดราชี้ไปที่กลุ่มคอลัมน์กลุ่ม โดยอาศัยระบบไฟล์แบบกระจาย BigTable ของ Google และคุณลักษณะความพร้อมใช้งานของไดนาโม (ตารางแฮชแบบกระจาย)
Cassandra ได้รับการออกแบบมาเพื่อจัดเก็บข้อมูลจำนวนมหาศาลที่กระจายไปตามโหนดต่างๆ Cassandra เป็น DBMS ที่ออกแบบมาเพื่อจัดการข้อมูลจำนวนมหาศาล กระจายไปทั่วเซิร์ฟเวอร์จำนวนมาก ในขณะที่ให้บริการที่มีความพร้อมใช้งานสูงโดยไม่มีจุดล้มเหลวเพียงจุดเดียว ซึ่งจำเป็นสำหรับบริการขนาดใหญ่เช่น Facebook
คุณสมบัติหลักของคาสซานดรา ได้แก่ :
- ไม่มีจุดบกพร่องแม้แต่จุดเดียว เพื่อให้บรรลุเป้าหมายนี้ Cassandra ต้องทำงานบนคลัสเตอร์ของโหนด แทนที่จะเป็นเครื่องเดียว ไม่ได้หมายความว่าข้อมูลในแต่ละคลัสเตอร์จะเหมือนกัน แต่ซอฟต์แวร์การจัดการนั้นเหมือนกัน เมื่อเกิดความล้มเหลวในโหนดใดโหนดหนึ่ง ข้อมูลบนโหนดนั้นจะไม่สามารถเข้าถึงได้ อย่างไรก็ตาม โหนดอื่นๆ (และข้อมูล) จะยังสามารถเข้าถึงได้
- Distributed Hashing เป็นโครงร่างที่ให้ฟังก์ชันการทำงานของตารางแฮชในลักษณะที่การเพิ่มหรือลบสล็อตหนึ่งช่องไม่ได้เปลี่ยนการแมปคีย์กับสล็อตอย่างมีนัยสำคัญ สิ่งนี้ทำให้สามารถกระจายโหลดไปยังเซิร์ฟเวอร์หรือโหนดตามความจุ และในทางกลับกัน ลดการหยุดทำงานให้น้อยที่สุด
- Client Interface ค่อนข้างใช้งานง่าย Cassandra ใช้ Apache Thrift สำหรับอินเทอร์เฟซไคลเอ็นต์ Apache Thrift มีไคลเอนต์ RPC ข้ามภาษา แต่นักพัฒนาส่วนใหญ่ชอบทางเลือกโอเพนซอร์ซที่สร้างบน Apple Thrift เช่น Hector
- คุณสมบัติความพร้อมใช้งานอื่น ๆ คุณลักษณะหนึ่งของ Cassandra คือการจำลองข้อมูล โดยพื้นฐานแล้ว มันสะท้อนข้อมูลไปยังโหนดอื่นในคลัสเตอร์ การจำลองแบบอาจเป็นแบบสุ่มหรือแบบเฉพาะเจาะจงเพื่อเพิ่มการปกป้องข้อมูลสูงสุดโดยการวางโหนดในศูนย์ข้อมูลอื่น เป็นต้น คุณลักษณะอื่นที่พบใน Cassandra คือนโยบายการแบ่งพาร์ติชัน นโยบายการแบ่งพาร์ติชันจะกำหนดว่าโหนดใดที่จะวางคีย์ นอกจากนี้ยังสามารถสุ่มหรือตามลำดับ เมื่อใช้นโยบายการแบ่งพาร์ติชั่นทั้งสองประเภท คาสซานดราสามารถสร้างสมดุลระหว่างการทำโหลดบาลานซ์และการปรับประสิทธิภาพการสืบค้นให้เหมาะสม
- ความสม่ำเสมอ คุณลักษณะเช่นการจำลองแบบทำให้ความสอดคล้องเป็นสิ่งที่ท้าทาย ทั้งนี้เนื่องมาจากข้อเท็จจริงที่ว่าโหนดทั้งหมดต้องได้รับการอัปเดต ณ เวลาใดเวลาหนึ่งด้วยค่าล่าสุด หรือเมื่อการดำเนินการอ่านเริ่มทำงาน แม้ว่าในท้ายที่สุด Cassandra จะพยายามรักษาสมดุลระหว่างการดำเนินการจำลองแบบและการดำเนินการอ่าน/เขียนโดยมอบความสามารถในการปรับแต่งเองนี้ให้กับนักพัฒนา
- การดำเนินการอ่าน/เขียน ลูกค้าส่งคำขอไปยังโหนด Cassandra เดียว โหนด ตามนโยบายการจำลองแบบ เก็บข้อมูลไปยังคลัสเตอร์ แต่ละโหนดจะทำการเปลี่ยนแปลงข้อมูลในบันทึกการคอมมิตก่อน จากนั้นจึงอัปเดตโครงสร้างตารางด้วยการเปลี่ยนแปลง ซึ่งทั้งสองทำพร้อมกัน การดำเนินการอ่านมีความคล้ายคลึงกันมาก คำขออ่านจะถูกส่งไปยังโหนดเดียว และโหนดเดียวนั้นเป็นโหนดที่กำหนดว่าโหนดใดเก็บข้อมูลไว้ ตามนโยบายการแบ่งพาร์ติชัน/การวาง
MongoDB
MongoDB เป็นฐานข้อมูลเชิงเอกสารที่ไม่มีสคีมาซึ่งเขียนด้วยภาษา C++ ฐานข้อมูลเป็นแบบเก็บเอกสาร ซึ่งหมายความว่าจะเก็บค่า (เรียกว่าเอกสาร) ในรูปแบบของข้อมูลที่เข้ารหัส
ทางเลือกของรูปแบบที่เข้ารหัสใน MongoDB คือ JSON สิ่งนี้มีประสิทธิภาพ เพราะแม้ว่าข้อมูลจะซ้อนอยู่ในเอกสาร JSON ก็ยังสามารถ สืบค้น และ จัดทำดัชนี ได้
ส่วนย่อยที่ตามมาจะอธิบายคุณลักษณะหลักบางอย่างที่มีอยู่ใน MongoDB
เศษ
การแบ่งส่วนคือการแบ่งพาร์ติชั่นและการกระจายข้อมูลไปยังเครื่องหลายเครื่อง (โหนด) ชาร์ดคือชุดของโหนด MongoDB ตรงกันข้ามกับ Cassandra ที่โหนดมีการกระจายแบบสมมาตร การใช้ชาร์ดยังหมายถึงความสามารถในการปรับขนาดในแนวนอนข้ามโหนดหลาย ๆ โหนด ในกรณีที่มีแอปพลิเคชันที่ใช้เซิร์ฟเวอร์ฐานข้อมูลเดียว ก็สามารถแปลงเป็นคลัสเตอร์ที่แบ่งส่วนได้ โดยมีการเปลี่ยนแปลงเพียงเล็กน้อยในโค้ดแอปพลิเคชันดั้งเดิม เนื่องจาก MongoDB ทำการชาร์ดดิ้ง oftware เกือบจะแยกออกจาก API สาธารณะที่เปิดเผยต่อฝั่งไคลเอ็นต์เกือบทั้งหมด
ภาษาแบบสอบถาม Mongo
ตามที่กล่าวไว้ก่อนหน้านี้ MongoDB ใช้ RESTful API ในการดึงเอกสารบางอย่างจากคอลเล็กชัน db เอกสารการสืบค้นจะถูกสร้างขึ้นโดยมีฟิลด์ที่เอกสารที่ต้องการควรตรงกัน
การกระทำ
ใน MongoDB มีกลุ่มของเซิร์ฟเวอร์ที่เรียกว่าเราเตอร์ แต่ละคนทำหน้าที่เป็นเซิร์ฟเวอร์สำหรับลูกค้าตั้งแต่หนึ่งรายขึ้นไป ในทำนองเดียวกัน คลัสเตอร์ประกอบด้วยกลุ่มของเซิร์ฟเวอร์ที่เรียกว่าเซิร์ฟเวอร์การกำหนดค่า แต่ละคนมีสำเนาของข้อมูลเมตาที่ระบุว่าชาร์ดใดมีข้อมูลใดบ้าง การดำเนินการอ่านหรือเขียนจะถูกส่งจากไคลเอนต์ไปยังหนึ่งในเซิร์ฟเวอร์เราเตอร์ในคลัสเตอร์ และถูกกำหนดเส้นทางโดยอัตโนมัติโดยเซิร์ฟเวอร์นั้นไปยังชาร์ดที่เหมาะสมซึ่งมีข้อมูลโดยใช้เซิร์ฟเวอร์การกำหนดค่า
เช่นเดียวกับ Cassandra ชาร์ดใน MongoDB มีรูปแบบการจำลองข้อมูล ซึ่งจะสร้างชุดเรพลิคาของแต่ละชาร์ดที่เก็บข้อมูลเหมือนกันทุกประการ MongoDB มีโครงร่างแบบจำลองสองประเภท: การจำลองแบบ Master-Slave และการจำลองแบบ Replica-Set Replica-Set ให้การทำงานอัตโนมัติมากขึ้นและการจัดการที่ดีขึ้นสำหรับความล้มเหลว ในขณะที่ Master-Slave จำเป็นต้องมีการแทรกแซงของผู้ดูแลระบบในบางครั้ง ไม่ว่ารูปแบบการจำลองแบบจะเป็นอย่างไร ในช่วงเวลาใดๆ ในชุดเรพพลิกา ชาร์ดเดียวเท่านั้นที่ทำหน้าที่เป็นชาร์ดหลัก ส่วนชาร์ดเรพลิคาอื่นๆ ทั้งหมดจะเป็นชาร์ดรอง การดำเนินการเขียนและอ่านทั้งหมดไปที่ชาร์ดหลัก จากนั้นจะกระจายอย่างเท่าเทียมกัน (หากจำเป็น) ไปยังชาร์ดรองอื่นๆ ในชุด
ในกราฟิกด้านล่าง เราจะเห็นสถาปัตยกรรม MongoDB ที่อธิบายข้างต้น โดยแสดงเซิร์ฟเวอร์เราเตอร์เป็นสีเขียว เซิร์ฟเวอร์กำหนดค่าเป็นสีน้ำเงิน และชาร์ดที่มีโหนด MongoDB
ควรสังเกตว่าการแบ่งส่วนข้อมูล (หรือการแบ่งปันข้อมูลระหว่างส่วนแบ่งข้อมูล) ใน MongoDB นั้นเป็นไปโดยอัตโนมัติอย่างสมบูรณ์ ซึ่งจะช่วยลดอัตราความล้มเหลวและทำให้ MongoDB เป็นระบบการจัดการฐานข้อมูลที่ปรับขนาดได้สูง
โครงสร้างการจัดทำดัชนีสำหรับฐานข้อมูล NoSQL
การทำดัชนีคือกระบวนการเชื่อมโยงคีย์กับตำแหน่งของบันทึกข้อมูลที่เกี่ยวข้องใน DBMS มีโครงสร้างข้อมูลการทำดัชนีจำนวนมากที่ใช้ในฐานข้อมูล NoSQL ส่วนต่อไปนี้จะกล่าวถึงวิธีการทั่วไปบางวิธีโดยสังเขป ได้แก่ การทำดัชนี B-Tree การทำดัชนี T-Tree และการทำดัชนี O2-Tree
การทำดัชนี B-Tree
B-Tree เป็นหนึ่งในโครงสร้างดัชนีที่พบบ่อยที่สุดใน DBMS
ใน B-trees โหนดภายในสามารถมีจำนวนตัวแปรของโหนดย่อยภายในช่วงที่กำหนดไว้ล่วงหน้าบางส่วน
ความแตกต่างหลักประการหนึ่งจากโครงสร้างต้นไม้อื่นๆ เช่น AVL คือ B-Tree อนุญาตให้โหนดมีจำนวนโหนดย่อยที่แปรผันได้ ซึ่งหมายถึงการปรับสมดุลของต้นไม้น้อยลง แต่สิ้นเปลืองพื้นที่มากขึ้น
B+-Tree เป็นหนึ่งในสายพันธุ์ที่ได้รับความนิยมมากที่สุดของ B-Trees B+-Tree เป็นการพัฒนาที่เหนือกว่า B-Tree ที่ต้องใช้กุญแจทั้งหมดเพื่ออยู่ในใบไม้
การทำดัชนี T-Tree
โครงสร้างข้อมูลของ T-Trees ได้รับการออกแบบโดยการรวมคุณลักษณะจาก AVL-Trees และ B-Trees
AVL-Trees เป็นแผนผังการค้นหาแบบไบนารีที่ปรับสมดุลตนเองประเภทหนึ่ง ในขณะที่ B-Trees นั้นไม่สมดุล และแต่ละโหนดสามารถมีจำนวนลูกที่แตกต่างกันได้
ใน T-Tree โครงสร้างคล้ายกับ AVL-Tree และ B-Tree
แต่ละโหนดเก็บ tuple {key-value, pointer} มากกว่าหนึ่งรายการ นอกจากนี้ การค้นหาแบบไบนารียังใช้ร่วมกับโหนดหลายทูเพิลเพื่อสร้างพื้นที่จัดเก็บและประสิทธิภาพที่ดีขึ้น
T-Tree มีโหนดสามประเภท: T-Node ที่มีลูกขวาและซ้าย โหนดปลายสุดที่ไม่มีลูก และโหนดครึ่งใบที่มีลูกเพียงคนเดียว
เชื่อกันว่า T-Trees มีประสิทธิภาพโดยรวมดีกว่า AVL-Trees
การทำดัชนี O2-Tree
โดยพื้นฐานแล้ว O2-Tree เป็นการปรับปรุงเหนือต้นไม้สีแดง-ดำ ซึ่งเป็นรูปแบบของต้นไม้ Binary-Search ซึ่งโหนดลีฟประกอบด้วยทูเพิล {key value, pointer}
มีการเสนอ O2-Tree เพื่อปรับปรุงประสิทธิภาพของวิธีการสร้างดัชนีในปัจจุบัน O2-Tree ของคำสั่ง m (m ≥ 2) โดยที่ m คือระดับต่ำสุดของต้นไม้ มีคุณสมบัติดังต่อไปนี้:
- ทุกโหนดเป็นสีแดงหรือสีดำ รากมีสีดำ
- โหนดปลายสุดทุกอันเป็นสีดำและประกอบด้วยบล็อกหรือเพจที่มีคู่ "ค่าคีย์ ตัวชี้เรคคอร์ด"
- หากโหนดเป็นสีแดง แสดงว่าโหนดย่อยทั้งคู่เป็นสีดำ
- สำหรับแต่ละโหนดภายใน เส้นทางอย่างง่ายทั้งหมดจากโหนดไปยังโหนดปลายสุดของโหนดมีจำนวนโหนดสีดำเท่ากัน แต่ละโหนดภายในมีค่าคีย์เดียว
- Leaf-nodes คือบล็อกที่มีคู่ “คีย์-ค่า, เรคคอร์ด-พอยเตอร์” ระหว่าง ⌈m/2⌉ และ m
- หากต้นไม้มีโหนดเดียว จะต้องเป็นใบไม้ ซึ่งเป็นรากของต้นไม้ และสามารถมีรายการข้อมูลคีย์ได้ระหว่าง 1 ถึง m รายการ
- โหนดลีฟมีการเชื่อมโยงสองครั้งในทิศทางไปข้างหน้าและข้างหลัง
ในที่นี้ เราจะเห็นการเปรียบเทียบประสิทธิภาพอย่างตรงไปตรงมาระหว่าง O2-Tree, T-Tree, B+-Tree, AVL-Tree และ Red-Black Tree:
ลำดับของ T-Tree, B+-Tree และ O2-Tree ที่ใช้คือ m = 512
เวลาจะถูกบันทึกสำหรับการดำเนินการค้นหา แทรก และลบด้วยอัตราส่วนการอัปเดตที่แตกต่างกันระหว่าง 0% -100% สำหรับดัชนี 50 ล้านระเบียน โดยการดำเนินการส่งผลให้เพิ่มระเบียนอีก 50 ล้านรายการลงในดัชนี
เป็นที่ชัดเจนว่าด้วยอัตราการอัพเดต 0-10% B-Tree และ T-Tree ทำงานได้ดีกว่า O2-Tree อย่างไรก็ตาม ด้วยอัตราส่วนการอัปเดตที่เพิ่มขึ้น ดัชนี O2-Tree ทำงานได้ดีกว่าโครงสร้างข้อมูลอื่นๆ ส่วนใหญ่อย่างเห็นได้ชัด โดยโครงสร้าง B-Tree และ Red-Black Tree จะได้รับผลกระทบมากที่สุด
กรณีสำหรับ NoSQL?
ข้อมูลเบื้องต้นเกี่ยวกับฐานข้อมูล NoSQL โดยเน้นที่ส่วนสำคัญที่ฐานข้อมูลเชิงสัมพันธ์แบบเดิมขาดหายไป นำไปสู่ประเด็นแรก:
แม้ว่าฐานข้อมูลเชิงสัมพันธ์จะมีความสอดคล้องกัน แต่ก็ไม่ได้รับการปรับให้เหมาะสมสำหรับประสิทธิภาพสูงในแอปพลิเคชันที่มีการจัดเก็บและประมวลผลข้อมูลขนาดใหญ่บ่อยครั้ง
ฐานข้อมูล NoSQL ได้รับความนิยมอย่างมากเนื่องจากมีประสิทธิภาพสูง ปรับขนาดได้สูงและเข้าถึงได้ง่าย อย่างไรก็ตาม ยัง ขาดคุณสมบัติที่ให้ความสม่ำเสมอและความน่าเชื่อถือ
โชคดีที่ NoSQL DBMS จำนวนหนึ่งจัดการกับความท้าทายเหล่านี้โดยนำเสนอคุณสมบัติใหม่เพื่อเพิ่มความสามารถในการปรับขนาดและความน่าเชื่อถือ
ระบบฐานข้อมูล NoSQL ไม่ใช่ทุกระบบจะทำงานได้ดีกว่าฐานข้อมูลเชิงสัมพันธ์
MongoDB และ Cassandra มีประสิทธิภาพที่คล้ายคลึงกัน และในกรณีส่วนใหญ่ ดีกว่าฐานข้อมูลเชิงสัมพันธ์ในการดำเนินการเขียนและลบ
ไม่มีความสัมพันธ์โดยตรงระหว่างประเภทร้านค้าและประสิทธิภาพของ NoSQL DBMS การใช้งาน NoSQL มีการเปลี่ยนแปลง ดังนั้นประสิทธิภาพอาจแตกต่างกันไป
ดังนั้น การวัดประสิทธิภาพระหว่างฐานข้อมูลประเภทต่างๆ ในการศึกษาต่างๆ ควรได้รับการอัปเดตด้วยซอฟต์แวร์ฐานข้อมูลเวอร์ชันล่าสุด เสมอ เพื่อให้ตัวเลขเหล่านั้นมีความถูกต้อง
แม้ว่าฉันจะไม่สามารถให้คำตัดสินที่ชัดเจนเกี่ยวกับประสิทธิภาพได้ แต่ต่อไปนี้คือประเด็นบางประการที่ควรคำนึงถึง:
- การทำดัชนี B-Tree และ T-Tree แบบดั้งเดิมมักใช้ในฐานข้อมูลแบบดั้งเดิม
- งานวิจัยชิ้นหนึ่งเสนอการปรับปรุงและการปรับปรุงโดยการรวมคุณลักษณะของโครงสร้างการจัดทำดัชนีหลายแบบเข้าด้วยกันเพื่อสร้าง O2-Tree
- O2-Tree มีประสิทธิภาพเหนือกว่าโครงสร้างอื่นๆ ในการทดสอบส่วนใหญ่ โดยเฉพาะอย่างยิ่งกับชุดข้อมูลขนาดใหญ่และอัตราส่วนการอัปเดตที่สูง
- โครงสร้าง B-Tree ให้ประสิทธิภาพที่แย่ที่สุดของโครงสร้างการจัดทำดัชนีทั้งหมดที่กล่าวถึงในบทความนี้
การทำงานเพิ่มเติมสามารถทำได้และควรทำเพื่อเพิ่มความสอดคล้องของ NoSQL DBMS การผสานรวมของทั้งสองระบบ NoSQL และฐานข้อมูลเชิงสัมพันธ์เป็นพื้นที่ที่ต้องสำรวจเพิ่มเติม
สุดท้ายนี้ สิ่งสำคัญที่ควรทราบคือ NoSQL เป็นส่วนเสริมที่ดีจากมาตรฐานฐานข้อมูลที่มีอยู่ แต่มีข้อแม้ที่สำคัญบางประการ NoSQL แลกเปลี่ยนคุณสมบัติความน่าเชื่อถือและความสม่ำเสมอเพื่อประสิทธิภาพและความสามารถในการปรับขนาดที่แท้จริง สิ่งนี้ทำให้เป็นโซลูชันพิเศษ เนื่องจากจำนวนแอปพลิเคชันที่สามารถพึ่งพาฐานข้อมูล NoSQL ยังคงมีจำกัด
กลับหัวกลับหาง? ความเชี่ยวชาญพิเศษอาจไม่ได้ให้ความยืดหยุ่นมากนัก แต่เมื่อคุณต้องการทำงานเฉพาะทางให้เสร็จอย่างรวดเร็วและมีประสิทธิภาพที่สุด คุณไม่จำเป็นต้องมี Swiss Army Knife คุณต้องการ NoSQL