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

วิวัฒนาการของ NoSQL

ปัญหาความสามารถในการปรับขนาด SQL ได้รับการยอมรับจาก บริษัท Web 2.0 ที่มีความต้องการข้อมูลและโครงสร้างพื้นฐานจำนวนมากที่เติบโตขึ้นเช่น Google, Amazon และ Facebook พวกเขาคิดวิธีแก้ปัญหาด้วยตนเอง - เทคโนโลยีเช่น BigTable , DynamoDB และ คาสซานดรา .

ความสนใจที่เพิ่มขึ้นนี้ส่งผลให้ระบบการจัดการฐานข้อมูล 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 นั้นไม่สมบูรณ์แบบและไม่ใช่ตัวเลือกที่ถูกต้องเสมอไป

หากความยืดหยุ่นของราคาข้ามของอุปสงค์คือ 1.9 รายการคือ:

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

เพื่อรองรับความน่าเชื่อถือและคุณสมบัติที่สอดคล้องกัน นักพัฒนา ต้องติดตั้งรหัสกรรมสิทธิ์ของตนเองซึ่งจะเพิ่มความซับซ้อนให้กับระบบมากขึ้น

ซึ่งอาจ จำกัด จำนวนแอปพลิเคชันที่สามารถพึ่งพาฐานข้อมูล NoSQL เพื่อการทำธุรกรรมที่ปลอดภัยและเชื่อถือได้เช่นระบบธนาคาร

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

NoSQL กับฐานข้อมูลเชิงสัมพันธ์

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

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

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

ประเภทที่เก็บข้อมูล NoSQL

ที่เก็บค่าคีย์

ในประเภทที่เก็บค่าคีย์ตารางแฮชจะใช้ซึ่งคีย์เฉพาะจะชี้ไปที่รายการ

.h ไฟล์ c++

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

สำคัญ	มูลค่า
'เบลฟัสต์'	{“ University of Ulster วิทยาเขต Belfast, York Street, Belfast, BT15 1ED”}
“ โคลเรน”	{“ University of Ulster, วิทยาเขต Coleraine, Cromore Road, Co. Londonderry, BT52 1SA”}

การใช้งานที่เก็บค่าคีย์บางอย่างมีกลไกการแคชซึ่งช่วยเพิ่มประสิทธิภาพได้อย่างมาก

สิ่งที่จำเป็นในการจัดการกับรายการที่จัดเก็บในฐานข้อมูลคือกุญแจสำคัญ ข้อมูลจะถูกจัดเก็บในรูปแบบของสตริง JSON หรือ BLOB (Binary Large OBject)

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

ฐานข้อมูล NoSQL ที่มีชื่อเสียงที่สุดที่สร้างขึ้นจากที่เก็บค่าคีย์คือ Amazon’s DynamoDB

ที่เก็บเอกสาร

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

อย่างไรก็ตามมีความแตกต่างที่สำคัญระหว่างทั้งสอง

ในที่เก็บเอกสารค่า (เอกสาร) จะจัดเตรียมการเข้ารหัสสำหรับข้อมูลที่จัดเก็บ การเข้ารหัสเหล่านั้นสามารถเป็น XML, JSON หรือ BSON (ไบนารีเข้ารหัส JSON) .

นอกจากนี้การสืบค้นตามข้อมูลสามารถทำได้

แอปพลิเคชันฐานข้อมูลที่ได้รับความนิยมมากที่สุดซึ่งอาศัยที่เก็บเอกสารคือ MongoDB

ร้านคอลัมน์

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

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

Column Stores สามารถอ่าน / เขียนข้อมูลที่จัดเก็บได้อย่างรวดเร็ว ในที่เก็บคอลัมน์แถวที่สอดคล้องกับคอลัมน์เดียวจะถูกจัดเก็บเป็นรายการดิสก์เดียว ทำให้เข้าถึงได้เร็วขึ้นระหว่างการอ่าน / เขียน

ฐานข้อมูลยอดนิยมที่ใช้ที่เก็บคอลัมน์ ได้แก่ BigTable, HBase และ Cassandra ของ Google

ฐานกราฟ

ในฐานข้อมูล Graph Base NoSQL โครงสร้างกราฟกำกับถูกใช้เพื่อแสดงข้อมูล กราฟประกอบด้วยขอบและโหนด

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

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

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

ปัจจุบัน InfoGrid และ InfiniteGraph เป็นฐานข้อมูลกราฟที่ได้รับความนิยมสูงสุด

ระบบจัดการฐานข้อมูล NoSQL

สำหรับการเปรียบเทียบโดยย่อของฐานข้อมูลตารางต่อไปนี้แสดงการเปรียบเทียบสั้น ๆ ระหว่างระบบการจัดการฐานข้อมูล NoSQL ต่างๆ

	ประเภทการจัดเก็บ	วิธีการสืบค้น	อินเตอร์เฟซ	ภาษาโปรแกรม	โอเพ่นซอร์ส	การจำลองแบบ
คาสซานดรา	ร้านคอลัมน์	Thrift API	ประหยัด	Java	ใช่	Async
MongoDB	ที่เก็บเอกสาร	Mongo Query	TCP / IP	C ++	ใช่	Async
HyperTable	ร้านคอลัมน์	HQL	ประหยัด	Java	ใช่	Async
CouchDB	ที่เก็บเอกสาร	MapReduce	ส่วนที่เหลือ	Erlang	ใช่	Async
BigTable	ร้านคอลัมน์	MapReduce	TCP / IP	C ++	ไม่	Async
HBase	ร้านคอลัมน์	MapReduce	ส่วนที่เหลือ	Java	ใช่	Async

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 ซึ่งเป็นฐานข้อมูลคีย์ - ค่า

สิ่งนี้ทำได้โดยการจัดเตรียมระบบคีย์ - ค่า แต่คีย์ใน Cassandra ชี้ไปที่ชุดของตระกูลคอลัมน์โดยอาศัยระบบไฟล์แบบกระจาย BigTable ของ Google และคุณลักษณะความพร้อมใช้งานของ Dynamo (ตารางแฮชแบบกระจาย)

Cassandra ออกแบบมาเพื่อจัดเก็บข้อมูลจำนวนมากที่กระจายไปตามโหนดต่างๆ Cassandra เป็น DBMS ที่ออกแบบมาเพื่อจัดการกับข้อมูลจำนวนมหาศาลโดยกระจายไปทั่วเซิร์ฟเวอร์จำนวนมากในขณะที่ให้บริการที่พร้อมใช้งานสูงโดยไม่มีจุดล้มเหลวแม้แต่จุดเดียวซึ่งจำเป็นสำหรับบริการขนาดใหญ่เช่น Facebook

คุณสมบัติหลักของ Cassandra ได้แก่ :

• ไม่มีจุดล้มเหลวแม้แต่จุดเดียว เพื่อให้บรรลุเป้าหมายนี้ Cassandra ต้องรันบนคลัสเตอร์ของโหนดแทนที่จะเป็นเครื่องเดียว นั่นไม่ได้หมายความว่าข้อมูลในแต่ละคลัสเตอร์จะเหมือนกัน แต่เป็นซอฟต์แวร์การจัดการ เมื่อเกิดความล้มเหลวในโหนดใดโหนดหนึ่งข้อมูลบนโหนดนั้นจะไม่สามารถเข้าถึงได้ อย่างไรก็ตามโหนดอื่น ๆ (และข้อมูล) จะยังคงสามารถเข้าถึงได้
• แฮชชิ่งแบบกระจาย เป็นรูปแบบที่จัดเตรียมฟังก์ชันตารางแฮชในลักษณะที่การเพิ่มหรือการลบหนึ่งสล็อตไม่ได้เปลี่ยนการแมปคีย์เป็นสล็อตอย่างมีนัยสำคัญ สิ่งนี้ให้ความสามารถในการกระจายโหลดไปยังเซิร์ฟเวอร์หรือโหนดตามความจุและในทางกลับกันลดเวลาหยุดทำงาน
• ใช้งาน Client Interface ได้ค่อนข้างง่าย . Cassandra ใช้ Apache Thrift สำหรับอินเทอร์เฟซไคลเอ็นต์ Apache Thrift ให้บริการไคลเอนต์ RPC ข้ามภาษา แต่นักพัฒนาส่วนใหญ่ชอบทางเลือกโอเพ่นซอร์สที่สร้างขึ้นจาก Apple Thrift เช่น Hector
• คุณสมบัติความพร้อมใช้งานอื่น ๆ คุณลักษณะอย่างหนึ่งของ Cassandra คือการจำลองข้อมูล โดยทั่วไปจะมิเรอร์ข้อมูลไปยังโหนดอื่นในคลัสเตอร์ การจำลองแบบอาจเป็นแบบสุ่มหรือเฉพาะเจาะจงเพื่อเพิ่มการปกป้องข้อมูลโดยวางในโหนดในศูนย์ข้อมูลอื่นเป็นต้น คุณลักษณะอื่นที่พบใน Cassandra คือนโยบายการแบ่งพาร์ติชัน นโยบายการแบ่งพาร์ติชันเป็นตัวกำหนดว่าโหนดใดที่จะวางคีย์ นอกจากนี้ยังสามารถสุ่มหรือตามลำดับ เมื่อใช้นโยบายการแบ่งพาร์ติชันทั้งสองประเภท Cassandra สามารถสร้างสมดุลระหว่างการจัดสรรภาระงานและการเพิ่มประสิทธิภาพการสืบค้น
• ความสม่ำเสมอ คุณสมบัติเช่นการจำลองแบบทำให้ความสอดคล้องเป็นสิ่งที่ท้าทาย นี่เป็นเพราะความจริงที่ว่าโหนดทั้งหมดต้องเป็นข้อมูลล่าสุด ณ เวลาใดก็ได้ด้วยค่าล่าสุดหรือในขณะที่มีการทริกเกอร์การดำเนินการอ่าน ในที่สุด Cassandra พยายามรักษาสมดุลระหว่างการจำลองแบบและการดำเนินการอ่าน / เขียนโดยให้ความสามารถในการปรับแต่งนี้แก่ผู้พัฒนา
• อ่าน / เขียนการดำเนินการ ไคลเอนต์ส่งคำขอไปยังโหนด Cassandra เดียว โหนดตามนโยบายการจำลองแบบเก็บข้อมูลไว้ในคลัสเตอร์ แต่ละโหนดจะดำเนินการเปลี่ยนแปลงข้อมูลในบันทึกการคอมมิตก่อนจากนั้นอัปเดตโครงสร้างตารางด้วยการเปลี่ยนแปลงทั้งสองอย่างพร้อมกัน การดำเนินการอ่านยังคล้ายกันมากคำขออ่านจะถูกส่งไปยังโหนดเดียวและโหนดเดียวคือโหนดที่กำหนดว่าโหนดใดเก็บข้อมูลตามนโยบายการแบ่งพาร์ติชัน / ตำแหน่ง

MongoDB

MongoDB เป็นฐานข้อมูลเชิงเอกสารที่ไม่มีสคีมาเขียนด้วยภาษา C ++ ฐานข้อมูลเป็นที่เก็บเอกสารซึ่งหมายความว่าจะเก็บค่า (เรียกว่าเอกสาร) ในรูปแบบของข้อมูลที่เข้ารหัส

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

ส่วนย่อยที่ตามมาอธิบายคุณสมบัติหลักบางประการที่มีใน MongoDB

เศษ

Sharding คือการแบ่งพาร์ติชันและการกระจายข้อมูลไปยังหลาย ๆ เครื่อง (โหนด) ชาร์ดคือชุดของโหนด MongoDB ซึ่งตรงกันข้ามกับ Cassandra ที่โหนดมีการกระจายแบบสมมาตร การใช้เศษยังหมายถึงความสามารถในการปรับขนาดตามแนวนอนในหลายโหนด ในกรณีที่มีแอปพลิเคชันที่ใช้เซิร์ฟเวอร์ฐานข้อมูลเดียวก็สามารถแปลงเป็นคลัสเตอร์ที่มีการชาร์ดได้โดยมีการเปลี่ยนแปลงโค้ดแอปพลิเคชันเดิมน้อยมากเนื่องจาก MongoDB ทำวิธีการชาร์ด oftware เกือบทั้งหมดถูกแยกออกจาก API สาธารณะที่เปิดเผยกับฝั่งไคลเอ็นต์

ภาษา Mongo Query

ตามที่กล่าวไว้ก่อนหน้านี้ MongoDB ใช้ RESTful API ในการดึงเอกสารบางอย่างจากคอลเลกชัน db เอกสารแบบสอบถามจะถูกสร้างขึ้นโดยมีฟิลด์ที่เอกสารที่ต้องการควรตรงกัน

การดำเนินการ

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

เช่นเดียวกับ Cassandra ชาร์ดใน MongoDB มีรูปแบบการจำลองข้อมูลซึ่งสร้างชุดจำลองของแต่ละชาร์ดที่เก็บข้อมูลเดียวกันทุกประการ รูปแบบการจำลองใน MongoDB มีสองประเภท: การจำลองแบบ Master-Slave และการจำลองแบบ Replica-Set Replica-Set ให้ระบบอัตโนมัติมากขึ้นและจัดการกับความล้มเหลวได้ดีขึ้นในขณะที่ Master-Slave ต้องการการแทรกแซงของผู้ดูแลระบบในบางครั้ง ไม่ว่ารูปแบบการจำลองจะเป็นอย่างไรในช่วงเวลาใดก็ตามในชุดการจำลองจะมีเพียงชิ้นเดียวเท่านั้นที่ทำหน้าที่เป็นชาร์ดหลักส่วนชิ้นส่วนจำลองอื่น ๆ ทั้งหมดจะเป็นเศษรอง การดำเนินการเขียนและอ่านทั้งหมดจะไปที่ชาร์ดหลักจากนั้นจะกระจายอย่างเท่าเทียมกัน (ถ้าจำเป็น) ไปยังส่วนอื่น ๆ ในชุด

cfo ไปรายงานตัวกับใคร

ในภาพด้านล่างเราจะเห็นสถาปัตยกรรม MongoDB ที่อธิบายไว้ข้างต้นโดยแสดงเซิร์ฟเวอร์เราเตอร์เป็นสีเขียวเซิร์ฟเวอร์การกำหนดค่าเป็นสีน้ำเงินและเศษที่มีโหนด MongoDB

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

โครงสร้างการจัดทำดัชนีสำหรับฐานข้อมูล NoSQL

การสร้างดัชนีเป็นกระบวนการเชื่อมโยงคีย์กับตำแหน่งของบันทึกข้อมูลที่เกี่ยวข้องใน DBMS มีโครงสร้างข้อมูลการทำดัชนีมากมายที่ใช้ในฐานข้อมูล NoSQL ส่วนต่อไปนี้จะกล่าวถึงวิธีการทั่วไปบางส่วนโดยสังเขป ได้แก่ การจัดทำดัชนี B-Tree การจัดทำดัชนี T-Tree และการจัดทำดัชนี O2-Tree

การจัดทำดัชนี B-Tree

B-Tree เป็นโครงสร้างดัชนีที่พบบ่อยที่สุดใน DBMS

ใน B-tree โหนดภายในสามารถมีจำนวนโหนดย่อยที่ผันแปรได้ภายในช่วงที่กำหนดไว้ล่วงหน้าบางช่วง

ความแตกต่างที่สำคัญอย่างหนึ่งจากโครงสร้างต้นไม้อื่น ๆ เช่น 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 มาก

แต่ละโหนดเก็บทูเปิล {key-value, pointer} มากกว่าหนึ่งรายการ นอกจากนี้การค้นหาไบนารียังใช้ร่วมกับโหนดหลายทูเพิลเพื่อสร้างพื้นที่จัดเก็บและประสิทธิภาพที่ดีขึ้น

T-Tree มีโหนดสามประเภท: T-Node ที่มีชายด์ด้านขวาและซ้ายโหนดลีฟที่ไม่มีลูกและโหนดครึ่งใบที่มีลูกเพียงคนเดียว

เชื่อกันว่า T-Trees มีประสิทธิภาพโดยรวมที่ดีกว่า AVL-Trees

การจัดทำดัชนี O2-Tree

โดยพื้นฐานแล้ว O2-Tree เป็นการปรับปรุงบนต้นไม้สีแดง - ดำซึ่งเป็นรูปแบบของต้นไม้ค้นหาแบบไบนารีซึ่งโหนดของใบไม้มีสิ่งที่เป็น {ค่าคีย์ตัวชี้}

วิธีการเริ่มโครงการ angularjs

O2-Tree ถูกเสนอเพื่อเพิ่มประสิทธิภาพของวิธีการจัดทำดัชนีในปัจจุบัน O2-Tree of order m (m ≥ 2) โดยที่ m คือระดับต่ำสุดของต้นไม้ตรงตามคุณสมบัติต่อไปนี้:

• ทุกโหนดมีสีแดงหรือดำ รากเป็นสีดำ
• โหนดลีฟทุกโหนดเป็นสีดำและประกอบด้วยบล็อกหรือหน้าที่มีคู่ 'ค่าคีย์ตัวชี้เรกคอร์ด'
• หากโหนดเป็นสีแดงแสดงว่าลูกทั้งสองเป็นสีดำ
• สำหรับแต่ละโหนดภายในเส้นทางอย่างง่ายทั้งหมดจากโหนดไปยังโหนดลีฟที่สืบทอดมาจะมีโหนดสีดำจำนวนเท่ากัน แต่ละโหนดภายในมีค่าคีย์เดียว
• Leaf-nodes คือบล็อกที่มีคู่ระหว่าง⌈m / 2⌉และ m“ คีย์ - ค่าตัวชี้เรกคอร์ด”
• ถ้าต้นไม้มีโหนดเดียวก็ต้องเป็นใบไม้ซึ่งเป็นรากของต้นไม้และสามารถมีรายการข้อมูลคีย์ได้ระหว่าง 1 ถึง m
• โหนด Leaf เชื่อมโยงสองครั้งในทิศทางไปข้างหน้าและย้อนกลับ

ที่นี่เราเห็นการเปรียบเทียบประสิทธิภาพอย่างตรงไปตรงมาระหว่าง O2-Tree, T-Tree, B + -Tree, AVL-Tree และ Red-Black Tree:

ลำดับของ T-Tree, B +-Tree และ O2-Tree ที่ใช้คือ m = 512

เวลาจะถูกบันทึกไว้สำหรับการดำเนินการค้นหาแทรกและลบโดยมีอัตราส่วนการอัปเดตที่แตกต่างกันระหว่าง 0% -100% สำหรับดัชนี 50M เรกคอร์ดโดยการดำเนินการส่งผลให้มีการเพิ่มระเบียน 50M อีกรายการในดัชนี

เป็นที่ชัดเจนว่าด้วยอัตราส่วนการอัปเดต 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

ที่เกี่ยวข้อง: แพลตฟอร์ม Business Intelligence: บทช่วยสอนการใช้ MongoDB Aggregation Pipeline