2.1 การเกิดขึ้นของคำว่า NoSQL
เมื่อเร็ว ๆ นี้ คำว่า "NoSQL" ได้กลายเป็นที่นิยมและเป็นที่นิยมอย่างมาก โซลูชันซอฟต์แวร์ทุกประเภทกำลังได้รับการพัฒนาและส่งเสริมอย่างแข็งขันภายใต้สัญลักษณ์นี้ NoSQL มีความหมายเหมือนกันกับข้อมูลจำนวนมหาศาล ความสามารถในการปรับขนาดเชิงเส้น คลัสเตอร์ ความทนทานต่อความผิดพลาด ความไม่สัมพันธ์กัน อย่างไรก็ตาม มีเพียงไม่กี่คนที่เข้าใจอย่างชัดเจนว่าที่เก็บข้อมูล NoSQL คืออะไร คำนี้ปรากฏขึ้นมาอย่างไร และมีลักษณะทั่วไปอย่างไร ลองเติมช่องว่างนี้
สิ่งที่น่าสนใจที่สุดเกี่ยวกับคำนี้คือแม้จะมีการใช้ครั้งแรกในช่วงปลายยุค 90 แต่ก็ได้รับความหมายที่แท้จริงในรูปแบบที่ใช้ในกลางปี 2552 เท่านั้น ในขั้นต้นนี่คือชื่อของ open - ฐานข้อมูลต้นฉบับที่สร้างโดย Carlo Strozzi ซึ่งเก็บข้อมูลทั้งหมดเป็นไฟล์ ASCII และใช้เชลล์สคริปต์แทน SQL เพื่อเข้าถึงข้อมูล ไม่มีส่วนเกี่ยวข้องกับ "NoSQL" ในรูปแบบปัจจุบัน
ในเดือนมิถุนายน พ.ศ. 2552 Johan Oskarsson จัดการประชุมในซานฟรานซิสโกเพื่อหารือเกี่ยวกับแนวโน้มใหม่ในตลาดการจัดเก็บข้อมูลและการประมวลผลด้านไอที แรงผลักดันหลักสำหรับการประชุมคือผลิตภัณฑ์โอเพ่นซอร์สใหม่ๆ เช่น BigTable และ Dynamo สำหรับสัญญาณที่ชัดเจนสำหรับการประชุม จำเป็นต้องค้นหาคำที่กว้างขวางและรัดกุมที่จะเข้ากับแฮชแท็ก Twitter ได้อย่างสมบูรณ์แบบ หนึ่งในเงื่อนไขเหล่านี้ถูกเสนอโดย Eric Evans จาก RackSpace - "NoSQL" คำนี้ถูกวางแผนไว้สำหรับการประชุมเพียงครั้งเดียวและไม่มีความหมายเชิงลึก แต่มันเกิดขึ้นจนแพร่กระจายไปทั่วเครือข่ายทั่วโลกเหมือนโฆษณาแบบไวรัล และกลายเป็นชื่อโดยพฤตินัยของเทรนด์ทั้งหมดในอุตสาหกรรมไอที อย่างไรก็ตาม Voldemort (Amazon Dynamo clone), Cassandra, Hbase (แอนะล็อกของ Google BigTable), Hypertable, CouchDB, MongoDB พูดในที่ประชุม
ควรเน้นอีกครั้งว่าคำว่า "NoSQL" นั้นเกิดขึ้นเองโดยสมบูรณ์และไม่มีคำจำกัดความหรือสถาบันทางวิทยาศาสตร์ที่เป็นที่ยอมรับโดยทั่วไป ชื่อนี้ค่อนข้างแสดงลักษณะเวกเตอร์ของการพัฒนาไอทีที่ห่างไกลจากฐานข้อมูลเชิงสัมพันธ์ ย่อมาจาก Not Only SQL แม้ว่าจะมีผู้สนับสนุนคำนิยามโดยตรงของ No SQL Pramod Sadalaj และ Martin Fowler พยายามจัดกลุ่มและจัดระบบความรู้เกี่ยวกับโลกของ NoSQL ในหนังสือเล่มล่าสุดของพวกเขา "NoSQL Distilled"
2.2 ลักษณะพื้นฐานของฐานข้อมูล NoSQL
มีลักษณะทั่วไปบางประการสำหรับ NoSQL ทั้งหมด เนื่องจากขณะนี้ระบบที่แตกต่างกันจำนวนมากถูกซ่อนไว้ภายใต้ป้ายกำกับ NoSQL (อาจพบรายการที่สมบูรณ์ที่สุดได้ที่ http://nosql-database.org/) คุณลักษณะหลายอย่างมีลักษณะเฉพาะสำหรับฐานข้อมูล NoSQL บางฐานข้อมูลเท่านั้น ฉันจะพูดถึงสิ่งนี้อย่างแน่นอนเมื่อทำรายการ
1. ไม่ใช้ SQL
ฉันหมายถึง ANSI SQL DML เนื่องจากฐานข้อมูลจำนวนมากพยายามใช้ภาษาแบบสอบถามที่คล้ายกับไวยากรณ์ที่ชื่นชอบที่รู้จักกันดี แต่ไม่มีใครจัดการเพื่อใช้งานอย่างเต็มที่และไม่น่าจะประสบความสำเร็จ แม้ว่าจะมีข่าวลือว่าสตาร์ทอัพพยายามใช้ SQL เช่นใน hadup ( http://www.drawntoscalehq.com/และhttp://www.hadapt.com/ )
2. ไม่มีโครงสร้าง (schemaless)
ความหมายคือในฐานข้อมูล NoSQL ซึ่งแตกต่างจากฐานข้อมูลเชิงสัมพันธ์ โครงสร้างข้อมูลไม่ได้รับการควบคุม (หรือพิมพ์อย่างอ่อนแอ หากเราวาดความคล้ายคลึงกับภาษาโปรแกรม) - คุณสามารถเพิ่มฟิลด์โดยพลการในบรรทัดหรือเอกสารแยกต่างหากโดยไม่ต้องเปลี่ยนโครงสร้างอย่างเปิดเผยก่อน ของตารางทั้งหมด ดังนั้น หากจำเป็นต้องเปลี่ยนโมเดลข้อมูล การดำเนินการที่เพียงพอเพียงอย่างเดียวคือการแสดงการเปลี่ยนแปลงในรหัสแอปพลิเคชัน
ตัวอย่างเช่น เมื่อเปลี่ยนชื่อฟิลด์ใน MongoDB:
BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"หากเราเปลี่ยนตรรกะของแอปพลิเคชัน เราคาดว่าจะมีฟิลด์ใหม่เมื่ออ่านด้วย แต่เนื่องจากขาดสคีมาข้อมูล ฟิลด์ totalSum จึงหายไปจากออบเจกต์คำสั่งซื้ออื่นๆ ที่มีอยู่แล้ว ในสถานการณ์นี้ มีสองทางเลือกในการดำเนินการต่อไป
อย่างแรกคือการรวบรวมข้อมูลเอกสารทั้งหมดและอัปเดตฟิลด์นี้ในเอกสารที่มีอยู่ทั้งหมด เนื่องจากข้อมูลมีปริมาณมาก กระบวนการนี้จึงเกิดขึ้นโดยไม่มีการล็อกใดๆ (เปรียบได้กับคำสั่งคอลัมน์แก้ไขชื่อตาราง) ดังนั้นในระหว่างการอัปเดต ข้อมูลที่มีอยู่แล้วสามารถอ่านได้โดยกระบวนการอื่นๆ ดังนั้นตัวเลือกที่สอง - การตรวจสอบรหัสแอปพลิเคชัน - จึงหลีกเลี่ยงไม่ได้:
BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum == null)
totalSum = order.getDouble("totalSum"); // This is the updated modelและเมื่อเราบันทึกใหม่เราจะเขียนฟิลด์นี้ลงในฐานข้อมูลในรูปแบบใหม่
ผลที่น่ายินดีของการไม่มีสคีมาคือประสิทธิภาพของการทำงานกับข้อมูลที่เบาบาง หากเอกสารหนึ่งมีฟิลด์ date_published และเอกสารที่สองไม่มี จะไม่มีการสร้างฟิลด์ date_published ที่ว่างเปล่าสำหรับเอกสารที่สอง โดยหลักการแล้วสิ่งนี้เป็นตรรกะ แต่ตัวอย่างที่ชัดเจนน้อยกว่าคือฐานข้อมูล NoSQL ตระกูลคอลัมน์ซึ่งใช้แนวคิดตาราง / คอลัมน์ที่คุ้นเคย อย่างไรก็ตาม เนื่องจากไม่มีสคีมา คอลัมน์จึงไม่ได้รับการประกาศอย่างชัดเจนและสามารถเปลี่ยนแปลง/เพิ่มได้ในระหว่างเซสชันฐานข้อมูลของผู้ใช้ ซึ่งช่วยให้สามารถใช้คอลัมน์ไดนามิกสำหรับการใช้งานรายการได้
สคีมาที่ไม่มีโครงสร้างมีข้อเสีย - นอกเหนือจากโอเวอร์เฮดที่กล่าวถึงข้างต้นในรหัสแอปพลิเคชันเมื่อเปลี่ยนโมเดลข้อมูล - ไม่มีข้อ จำกัด ทุกประเภทจากฐาน (ไม่เป็นโมฆะ, ไม่ซ้ำกัน, ตรวจสอบข้อ จำกัด ฯลฯ ) รวมถึงที่นั่น เป็นปัญหาเพิ่มเติมในการทำความเข้าใจและควบคุมข้อมูลโครงสร้างเมื่อทำงานกับฐานข้อมูลของโครงการต่างๆ พร้อมกัน (ไม่มีพจนานุกรมที่ด้านข้างของฐานข้อมูล) อย่างไรก็ตาม ในโลกสมัยใหม่ที่เปลี่ยนแปลงอย่างรวดเร็ว ความยืดหยุ่นดังกล่าวยังคงเป็นข้อได้เปรียบ ตัวอย่างคือ Twitter ซึ่งเมื่อห้าปีที่แล้วพร้อมกับทวีตเก็บข้อมูลเพิ่มเติมเพียงเล็กน้อย (เวลา, แฮนเดิล Twitter และข้อมูลเมตาอีกสองสามไบต์) แต่ตอนนี้นอกเหนือจากข้อความแล้ว อีกสองสามตัว ข้อมูลเมตาหลายกิโลไบต์ถูกจัดเก็บไว้ในฐานข้อมูล
(ต่อไปนี้เราจะพูดถึงฐานข้อมูลคีย์-ค่า เอกสาร และคอลัมน์ตระกูลเป็นหลัก ฐานข้อมูลกราฟอาจไม่มีคุณสมบัติเหล่านี้)
2.3. การแสดงข้อมูลในรูปแบบของการรวม (aggregates)
ซึ่งแตกต่างจากโมเดลเชิงสัมพันธ์ซึ่งเก็บเอนทิตีธุรกิจเชิงตรรกะของแอปพลิเคชันไว้ในตารางทางกายภาพต่างๆ เพื่อวัตถุประสงค์ในการทำให้เป็นมาตรฐาน ร้านค้า NoSQL ทำงานในเอนทิตีเหล่านี้เป็นวัตถุแบบองค์รวม:
ตัวอย่างนี้สาธิตการรวมสำหรับแบบจำลองเชิงสัมพันธ์เชิงแนวคิดของอีคอมเมิร์ซมาตรฐาน "คำสั่งซื้อ - รายการสั่งซื้อ - การชำระเงิน - สินค้า" ในทั้งสองกรณี ลำดับจะรวมกับตำแหน่งเป็นออบเจกต์แบบลอจิคัลเดียว ในขณะที่แต่ละตำแหน่งจะเก็บลิงก์ไปยังผลิตภัณฑ์และแอตทริบิวต์บางอย่าง เช่น ชื่อ (จำเป็นต้องมีการทำให้ดีเป็นปกติเพื่อไม่ให้ร้องขอออบเจกต์ผลิตภัณฑ์เมื่อดึงข้อมูล คำสั่ง - กฎหลักของระบบกระจายคือการ "รวม" ระหว่างวัตถุ) ในการรวมรายการหนึ่ง การชำระเงินจะรวมกับคำสั่งซื้อและเป็นส่วนสำคัญของวัตถุ ส่วนอีกรายการหนึ่งจะอยู่ในวัตถุแยกต่างหาก สิ่งนี้แสดงให้เห็นถึงกฎหลักในการออกแบบโครงสร้างข้อมูลในฐานข้อมูล NoSQL นั่นคือต้องเป็นไปตามข้อกำหนดของแอปพลิเคชันและปรับให้เหมาะสมที่สุดสำหรับคำขอที่พบบ่อยที่สุด
หลายคนจะคัดค้าน โดยสังเกตว่าการทำงานกับออบเจ็กต์ขนาดใหญ่ซึ่งมักจะทำให้ไม่ปกตินั้นเต็มไปด้วยปัญหามากมายเมื่อพยายามค้นหาข้อมูลตามอำเภอใจเมื่อการสืบค้นไม่พอดีกับโครงสร้างของการรวม จะเกิดอะไรขึ้นหากเราใช้คำสั่งซื้อพร้อมกับรายการสั่งซื้อและการชำระเงิน (นี่คือวิธีการทำงานของแอป) แต่ธุรกิจขอให้เรานับจำนวนหน่วยของผลิตภัณฑ์เฉพาะที่ขายในเดือนที่แล้ว ในกรณีนี้ แทนที่จะสแกนตาราง OrderItem (ในกรณีของแบบจำลองเชิงสัมพันธ์) เราจะต้องดึงข้อมูลคำสั่งซื้อทั้งหมดในพื้นที่จัดเก็บ NoSQL แม้ว่าเราจะไม่ต้องการข้อมูลนี้มากนัก น่าเสียดาย นี่เป็นการประนีประนอมที่ต้องทำในระบบแบบกระจาย: เราไม่สามารถปรับข้อมูลให้เป็นมาตรฐานได้เหมือนในระบบเซิร์ฟเวอร์เดียวทั่วไป
ฉันพยายามจัดกลุ่มข้อดีและข้อเสียของทั้งสองวิธีในตาราง:
