NoSQL คืออะไร? ฐานข้อมูลสำหรับอนาคตระดับคลาวด์

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

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

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

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

NoSQL กับ SQL

ความแตกต่างพื้นฐานระหว่าง SQL และ NoSQL นั้นไม่ซับซ้อนทั้งหมด แต่ละคนมีปรัชญาที่แตกต่างกันในการจัดเก็บและเรียกใช้ข้อมูล

ด้วยฐานข้อมูล SQL ข้อมูลทั้งหมดมีโครงสร้างโดยธรรมชาติ ฐานข้อมูลทั่วไปเช่น Microsoft SQL Server, MySQL หรือ Oracle Database ใช้สคีมาซึ่งเป็นคำจำกัดความอย่างเป็นทางการว่าข้อมูลที่แทรกลงในฐานข้อมูลจะประกอบขึ้นอย่างไร ตัวอย่างเช่นคอลัมน์ที่ระบุในตารางอาจ จำกัด เฉพาะจำนวนเต็มเท่านั้น ด้วยเหตุนี้ข้อมูลที่บันทึกในคอลัมน์จะมีระดับการทำให้เป็นมาตรฐานสูง สคีมาที่เข้มงวดของฐานข้อมูล SQL ยังทำให้การรวมข้อมูลเป็นเรื่องง่ายตัวอย่างเช่นการเข้าร่วม

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

  1. ฐานข้อมูลเอกสาร (เช่น CouchDB, MongoDB) ข้อมูลที่แทรกจะถูกจัดเก็บในรูปแบบของโครงสร้าง JSON รูปแบบอิสระหรือ "เอกสาร" ซึ่งข้อมูลอาจเป็นอะไรก็ได้ตั้งแต่จำนวนเต็มไปจนถึงสตริงไปจนถึงข้อความอิสระ ไม่จำเป็นต้องระบุว่าจะมีฟิลด์ใดในเอกสารใดบ้างหากมี
  2. ที่เก็บคีย์ - ค่า (เช่น Redis, Riak) ค่ารูปแบบอิสระตั้งแต่จำนวนเต็มหรือสตริงธรรมดาไปจนถึงเอกสาร JSON ที่ซับซ้อนจะถูกเข้าถึงในฐานข้อมูลโดยใช้คีย์
  3. ร้านค้าเสากว้าง (เช่น HBase, Cassandra) ข้อมูลจะถูกเก็บไว้ในคอลัมน์แทนที่จะเป็นแถวเช่นเดียวกับระบบ SQL ทั่วไป สามารถจัดกลุ่มหรือรวมคอลัมน์จำนวนเท่าใดก็ได้ (และข้อมูลประเภทต่างๆ) ได้ตามต้องการสำหรับคิวรีหรือมุมมองข้อมูล
  4. ฐานข้อมูลกราฟ (เช่น Neo4j) ข้อมูลจะแสดงเป็นเครือข่ายหรือกราฟของเอนทิตีและความสัมพันธ์โดยแต่ละโหนดในกราฟเป็นกลุ่มข้อมูลรูปแบบอิสระ

การจัดเก็บข้อมูลแบบไม่ใช้สคีมามีประโยชน์ในสถานการณ์ต่อไปนี้:

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

การสืบค้นฐานข้อมูล NoSQL

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

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

ผลิตภัณฑ์ NoSQL บางอย่างสามารถใช้ไวยากรณ์ที่คล้าย SQL เพื่อทำงานกับข้อมูลได้ แต่ในขอบเขตที่ จำกัด เท่านั้น ตัวอย่างเช่น Apache Cassandra ซึ่งเป็นฐานข้อมูลที่เก็บคอลัมน์มีภาษาคล้าย SQL ของตัวเองคือ Cassandra Query Language หรือ CQL ไวยากรณ์ CQL บางส่วนตรงมาจากสมุดเล่น SQL เช่นคำหลัก SELECT หรือ INSERT แต่ไม่มีวิธีการเข้าร่วมหรือแบบสอบถามย่อยใน Cassandra ดังนั้นคำหลักที่เกี่ยวข้องจึงไม่มีอยู่ใน CQL

สถาปัตยกรรมที่ไม่ใช้ร่วมกัน

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

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

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

ข้อ จำกัด NoSQL

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

ไม่มีสคีมา

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

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

ความสอดคล้องในที่สุด

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

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

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

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

ล็อคอิน NoSQL

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

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

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

ทักษะ NoSQL

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

สำหรับการอ้างอิง Indeed.com รายงานว่า ณ สิ้นปี 2017 ปริมาณงานสำหรับฐานข้อมูล SQL แบบเดิมเช่น MySQL, Microsoft SQL Server, Oracle Database และอื่น ๆ ยังคงสูงกว่าปริมาณงานในช่วงสามปีที่ผ่านมา สำหรับ MongoDB, Couchbase และ Cassandra ความต้องการความเชี่ยวชาญ NoSQL กำลังเพิ่มขึ้น แต่ก็ยังคงเป็นเพียงส่วนหนึ่งของตลาดสำหรับ SQL ทั่วไป

การรวม SQL และ NoSQL

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

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

ที่นี่และมีสัญญาณว่าฐานข้อมูลรุ่นต่อ ๆ ไปจะคร่อมกระบวนทัศน์และมีทั้งฟังก์ชัน NoSQL และ SQL ตัวอย่างเช่น Azure Cosmos DB ของ Microsoft ใช้ชุดของไพรมารีภายใต้ประทุนเพื่อทำซ้ำพฤติกรรมของระบบทั้งสองชนิด Google Cloud Spanner เป็นฐานข้อมูล SQL ที่รวมความสอดคล้องอย่างมากกับความสามารถในการปรับขนาดแนวนอนของระบบ NoSQL

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