คู่มือ NoSQL สำหรับนักพัฒนา

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

ทำไมเราถึงต้องการฐานข้อมูลใหม่กะทันหัน?

คุณอาจจะงงเมื่อถามว่า เกิดอะไรขึ้นกับฐานข้อมูลเชิงสัมพันธ์? ประเด็นก็คือพวกเขาทำงานได้ดีมากมาหลายปีแล้ว แต่ตอนนี้มีปัญหาที่พวกเขาไม่สามารถจัดการได้อีกต่อไป ตามการคาดการณ์ ในปี 2561 มนุษยชาติจะสร้างข้อมูล 50,000 กิกะไบต์ต่อวินาที นี่เป็นข้อมูลจำนวนมหาศาล! การจัดเก็บและการจัดการถือเป็นความท้าทายทางวิศวกรรมที่ร้ายแรง ที่แย่ไปกว่านั้นคือปริมาณการซื้อขายนี้มีการเติบโตอย่างต่อเนื่อง ปรากฎว่าฐานข้อมูลเชิงสัมพันธ์ไม่เหมาะที่จะทำงานกับข้อมูลปริมาณมาก ได้รับการออกแบบมาให้ทำงานบนเครื่องเดียว และหากคุณต้องการจัดการกับคำขอเพิ่มเติม ทางเลือกเดียวคือซื้อคอมพิวเตอร์ที่มี RAM มากกว่าและโปรเซสเซอร์ที่ทรงพลังกว่า ขออภัย จำนวนการสืบค้นที่เครื่องหนึ่งสามารถรองรับนั้นมีจำกัด และสำหรับงานที่กระจายไปยังเครื่องหลายเครื่อง เราจำเป็นต้องมีเทคโนโลยีฐานข้อมูลที่แตกต่างกัน แน่นอนว่าผู้อ่านบางคนจะหัวเราะคิกคัก ณ จุดนี้และกล่าวว่ามีสองวิธีที่ใช้กันอย่างแพร่หลายในการใช้เครื่องหลายเครื่องในกรณีของฐานข้อมูลเชิงสัมพันธ์: การจำลองแบบและการแบ่งส่วน นั่นเป็นเรื่องจริง แต่วิธีการเหล่านี้ไม่เพียงพอที่จะรับมือกับงานของเรา การจำลองแบบอ่านเป็นเทคนิคที่การอัพเดตฐานข้อมูลแต่ละรายการถูกเผยแพร่ไปยังเครื่องอื่นที่สามารถจัดการได้เฉพาะคำขออ่านเท่านั้น ในกรณีนี้ การเปลี่ยนแปลงทั้งหมดจะดำเนินการโดยเซิร์ฟเวอร์เดียว เรียกว่าโหนดหลัก ในขณะที่เซิร์ฟเวอร์อื่นๆ เรียกว่าแบบจำลองการอ่าน จะรักษาเฉพาะสำเนาของข้อมูลเท่านั้น ผู้ใช้สามารถอ่านจากเครื่องใดก็ได้ แต่เปลี่ยนข้อมูลผ่านโหนดหลักเท่านั้น นี่เป็นวิธีที่สะดวกและเป็นที่นิยมมาก แต่อนุญาตให้คุณประมวลผลคำขออ่านเพิ่มเติมเท่านั้นและไม่สามารถแก้ปัญหาการประมวลผลปริมาณข้อมูลที่ต้องการได้ แต่อย่างใด Shardingเป็นอีกวิธีหนึ่งที่ได้รับความนิยมซึ่งใช้หลายอินสแตนซ์ของฐานข้อมูลเชิงสัมพันธ์ แต่ละรายการจะจัดการการเขียนและการอ่านสำหรับส่วนหนึ่งของข้อมูล หากฐานข้อมูลจัดเก็บข้อมูลเกี่ยวกับลูกค้า เช่น การใช้การแบ่งส่วน เครื่องหนึ่งสามารถจัดการคำขอทั้งหมดสำหรับลูกค้าที่ชื่อขึ้นต้นด้วย A อีกเครื่องหนึ่งสามารถจัดเก็บข้อมูลทั้งหมดสำหรับลูกค้าที่ชื่อขึ้นต้นด้วย B และอื่นๆ แม้ว่าการแบ่งส่วนจะช่วยให้คุณสามารถบันทึกข้อมูลได้มากขึ้น แต่การจัดการฐานข้อมูลดังกล่าวถือเป็นฝันร้ายอย่างแท้จริง คุณต้องจัดเรียงข้อมูลข้ามเครื่องและปรับขนาดคลัสเตอร์ทั้งสองทิศทางตามต้องการ แม้ว่าในทางทฤษฎีจะดูเรียบง่าย แต่การทำให้ถูกต้องนั้นค่อนข้างท้าทาย

สามารถปรับปรุงฐานข้อมูลเชิงสัมพันธ์ได้หรือไม่?

ฉันคิดว่าคุณเชื่อแล้วว่าฐานข้อมูลเชิงสัมพันธ์ไม่เหมาะที่สุดสำหรับปริมาณข้อมูลที่สร้างขึ้นในโลกสมัยใหม่ แม้ว่าคุณอาจยังคงสงสัยว่าทำไมยังไม่มีใครสร้างฐานข้อมูลเชิงสัมพันธ์ที่ "ดีกว่า" ซึ่งสามารถทำงานได้อย่างมีประสิทธิภาพบนเครื่องหลายเครื่อง อาจดูเหมือนว่าเทคโนโลยีนี้ยังไม่ได้รับการพัฒนาและฐานข้อมูลเชิงสัมพันธ์แบบกระจายจะปรากฏขึ้นในไม่ช้า อนิจจาสิ่งนี้จะไม่เกิดขึ้น นี่เป็นไปไม่ได้ในทางคณิตศาสตร์ และไม่สามารถทำอะไรกับมันได้ เพื่อทำความเข้าใจว่าเหตุใดจึงเป็นเช่นนั้น คุณต้องดูสิ่งที่เรียกว่าทฤษฎีบท CAP (หรือที่รู้จักในชื่อทฤษฎีบทของบรูเออร์) ได้รับการพิสูจน์ในปี 1999 และระบุว่าฐานข้อมูลแบบกระจายที่ทำงานบนเครื่องหลายเครื่องสามารถมีคุณสมบัติสามประการต่อไปนี้: ความสอดคล้อง - การดำเนินการอ่าน ใด ๆจะส่งกลับผลลัพธ์ของการดำเนินการเขียนที่สอดคล้องกันครั้งล่าสุด หากระบบมีความสม่ำเสมอ หลังจากเขียนข้อมูลใหม่แล้ว จะไม่สามารถอ่านข้อมูลเก่าที่ถูกเขียนทับไปแล้วได้ ความพร้อมใช้งาน ( ความพร้อมใช้งาน) - ระบบแบบกระจายสามารถให้บริการคำขอที่เข้ามาได้ตลอดเวลาและส่งคืนการตอบกลับที่ปราศจากข้อผิดพลาด ความทนทานต่อการแบ่งพาร์ติชัน - ฐานข้อมูลยังคงตอบสนองต่อคำขออ่านและเขียนแม้ว่าเซิร์ฟเวอร์บางแห่งจะไม่สามารถสื่อสารระหว่างกันได้ชั่วคราว ความล้มเหลวชั่วคราวนี้เรียกว่าความล้มเหลวในการเชื่อมต่อเครือข่าย และอาจเกิดจากปัจจัยหลายประการ ตั้งแต่ปัญหาเครือข่ายทางกายภาพเนื่องจากเซิร์ฟเวอร์ช้าไปจนถึงความเสียหายทางกายภาพต่ออุปกรณ์เครือข่าย คุณสมบัติทั้งหมดนี้มีประโยชน์อย่างแน่นอน และเราต้องการฐานข้อมูลเพื่อรวมคุณสมบัติทั้งหมดเข้าด้วยกัน ไม่มีนักพัฒนาที่มีสติคนใดอยากจะละทิ้งการเข้าถึงโดยไม่ได้รับผลตอบแทนใดๆ น่าเสียดายที่ทฤษฎีบท CAP ยังระบุด้วยว่าเป็นไปไม่ได้ที่คุณสมบัติทั้งสามจะคงไว้พร้อมกัน การตระหนักรู้เรื่องนี้อาจไม่ใช่เรื่องง่าย แต่ก็เป็นไปได้ อันดับแรก หากเราต้องการฐานข้อมูลแบบกระจาย ฐานข้อมูลนั้นจะต้อง “ทนทานต่อการตัดการเชื่อมต่อ” สิ่งนี้ไม่ได้กล่าวถึงด้วยซ้ำ การตัดการเชื่อมต่อเกิดขึ้นตลอดเวลาและฐานข้อมูลของเราจะต้องทำงานได้แม้ว่าจะเป็นเช่นนั้นก็ตาม ตอนนี้เรามาทำความเข้าใจว่าทำไมเราไม่สามารถบรรลุทั้งความสอดคล้องและความพร้อมใช้งานได้ ลองนึกภาพเรามีฐานข้อมูลง่ายๆ ที่ทำงานอยู่บนเครื่องสองเครื่อง: A และ B ผู้ใช้ทุกคนสามารถเขียนไปยังเครื่องใดเครื่องหนึ่งได้ หลังจากนั้นข้อมูลจะถูกคัดลอกไปยังอีกเครื่องหนึ่ง ลองจินตนาการว่าเครื่องเหล่านี้ไม่สามารถสื่อสารระหว่างกันได้ชั่วคราว และเครื่อง B ไม่สามารถส่งข้อมูลไปหรือรับข้อมูลจากเครื่อง A ได้ หากในช่วงเวลานี้ของไทม์แมชชีน B ได้รับคำขออ่านจากไคลเอนต์ จะมีสองตัวเลือก:

1. รับข้อมูลในเครื่องของคุณกลับคืนมา แม้ว่าจะไม่ใช่ข้อมูลล่าสุดก็ตาม ในกรณีนี้ จะมีการกำหนดให้มีความพร้อมใช้งาน (เพื่อส่งคืนข้อมูลบางส่วนเป็นอย่างน้อย แม้กระทั่งข้อมูลที่ล้าสมัย)
2. ข้อผิดพลาดในการส่งคืน ในกรณีนี้ ต้องการความสอดคล้องมากกว่า: ไคลเอนต์จะไม่ได้รับข้อมูลที่ล้าสมัย แต่จะไม่ได้รับข้อมูลใด ๆ เลย

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

ฐานข้อมูล NoSQL มีความสมดุลและความพร้อมใช้งานอย่างไร

อาจดูเหมือนว่าหากคุณเลือกฐานข้อมูล NoSQL คุณจะได้รับข้อมูลที่ล้าสมัยหรือมีข้อผิดพลาดเสมอในกรณีที่เกิดความล้มเหลว ในทางปฏิบัติ ความพร้อมใช้งานและความสม่ำเสมอไม่ได้เป็นเพียงตัวเลือกเดียวเท่านั้น มีตัวเลือกมากมายให้คุณเลือก ฐานข้อมูลเชิงสัมพันธ์ไม่มีตัวเลือกเหล่านี้ แต่ NoSQL ช่วยให้คุณควบคุมการดำเนินการสืบค้นในลักษณะเดียวกัน ไม่ทางใดก็ทางหนึ่งอนุญาตให้คุณตั้งค่าพารามิเตอร์สองตัวเมื่อดำเนินการเขียนหรืออ่านในฐานข้อมูล NoSQL: W - จำนวนเครื่องในคลัสเตอร์ที่ต้องยืนยันการบันทึกข้อมูลเมื่อดำเนินการเขียน . ยิ่งเครื่องที่คุณเขียนข้อมูลมีจำนวนมากขึ้นเท่าใด การอ่านข้อมูลล่าสุดในการดำเนินการอ่านครั้งถัดไปก็จะยิ่งง่ายขึ้นเท่านั้น แต่ยังจะใช้เวลานานขึ้นอีกด้วย R – จำนวนเครื่องที่คุณต้องการอ่านข้อมูล จาก . ในระบบแบบกระจาย การกระจายข้อมูลไปยังเครื่องทั้งหมดในคลัสเตอร์อาจใช้เวลาสักระยะ ดังนั้นบางเซิร์ฟเวอร์จะมีข้อมูลล่าสุดในขณะที่เซิร์ฟเวอร์อื่นๆ จะล่าช้า ยิ่งจำนวนเครื่องที่ใช้อ่านข้อมูลมากเท่าใด โอกาสในการอ่านข้อมูลปัจจุบันก็จะยิ่งสูงขึ้นเท่านั้น ลองดูตัวอย่างการปฏิบัติ หากคุณมีคอมพิวเตอร์ห้าเครื่องในคลัสเตอร์ของคุณ และคุณตัดสินใจที่จะเขียนข้อมูลลงเพียงเครื่องเดียว จากนั้นอ่านข้อมูลจากคอมพิวเตอร์ที่เลือกแบบสุ่มเครื่องหนึ่ง มีโอกาส 80% ที่คุณจะอ่านข้อมูลเก่า ในทางกลับกัน จะใช้ทรัพยากรน้อยที่สุด ดังนั้นหากคุณใช้ข้อมูลเดิมได้ ก็ไม่ใช่ตัวเลือกที่แย่นัก ในกรณีนี้ พารามิเตอร์ W และ R เท่ากับ 1 ในทางกลับกัน หากคุณเขียนข้อมูลลงในทั้งห้าเครื่องในฐานข้อมูล NoSQL คุณสามารถอ่านข้อมูลจากเครื่องใดก็ได้และรับประกันว่าจะได้รับข้อมูลที่เป็นปัจจุบันทุกครั้ง การดำเนินการเดียวกันบนเครื่องจำนวนมากจะใช้เวลานานกว่า แต่หากข้อมูลล่าสุดเป็นสิ่งสำคัญสำหรับคุณ คุณสามารถเลือกตัวเลือกนี้ได้ ในกรณีนี้ W = R = 5 จำนวนการอ่านและเขียนขั้นต่ำที่จำเป็นสำหรับความสอดคล้องของฐานข้อมูลคือเท่าใด นี่คือสูตรง่ายๆ: R + W ≥ N + 1โดยที่ N คือจำนวนเครื่องในคลัสเตอร์ ซึ่งหมายความว่า ด้วยห้าเซิร์ฟเวอร์ คุณสามารถเลือก R = 2 และ W = 4 หรือ R = 3 และ W = 3 หรือ R = 4 และ W = 2 ในกรณีนี้ มันไม่สำคัญว่าข้อมูลจะเป็นเครื่องใด ถูกเขียนไว้ การอ่านจะดำเนินการจากเครื่องอย่างน้อยหนึ่งเครื่องที่มีข้อมูลที่ทันสมัยอยู่เสมอ ฐานข้อมูลอื่นๆ เช่น DynamoDB มีข้อจำกัดที่แตกต่างกัน และอนุญาตเฉพาะการเขียนที่สอดคล้องกันเท่านั้น ข้อมูลแต่ละชิ้นจะถูกจัดเก็บไว้ในเซิร์ฟเวอร์สามเครื่อง และเมื่อมีการเขียนข้อมูลใดๆ ข้อมูลนั้นก็จะถูกเขียนลงในเครื่องสองในสามเครื่อง แต่เมื่ออ่านข้อมูล คุณสามารถเลือกหนึ่งในสองตัวเลือก:

1. การอ่านที่สอดคล้องกันอย่างเคร่งครัด โดยข้อมูลจะถูกอ่านจากสองเครื่องจากสามเครื่อง และส่งคืนข้อมูลล่าสุดที่เขียนเสมอ
2. การอ่านที่สอดคล้องกันในที่สุด โดยสุ่มเลือกเครื่องหนึ่งเครื่องเพื่ออ่านข้อมูล อย่างไรก็ตาม สิ่งนี้อาจส่งคืนข้อมูลที่ล้าสมัยชั่วคราว

เหตุใดจึงมีฐานข้อมูล NoSQL มากมาย

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

ฐานข้อมูลเชิงเอกสาร

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

ฐานข้อมูลคีย์/ค่า

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

ฐานข้อมูลกราฟ

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

ฐานข้อมูลเรียงเป็นแนว

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

คุณควรเลือกฐานข้อมูลใด

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

คุณจะเรียนรู้ทั้งหมดนี้ได้อย่างไร?

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

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


2. ไดนาโมดีบี หากคุณใช้ Amazon Web Services (AWS) คุณควรเรียนรู้เพิ่มเติมเกี่ยวกับ DynamoDB เป็นฐานข้อมูลที่เชื่อถือได้อย่างยิ่ง สามารถปรับขนาดได้ และมีความหน่วงต่ำ พร้อมด้วยชุดคุณลักษณะที่หลากหลายและการผสานรวมกับบริการของ AWS อื่นๆ มากมาย ส่วนที่ดีที่สุดคือคุณไม่จำเป็นต้องปรับใช้ด้วยตนเอง การตั้งค่าคลัสเตอร์ DynamoDB ที่ปรับขนาดได้ซึ่งสามารถรองรับการสืบค้นนับพันรายการได้ด้วยการคลิกเพียงไม่กี่ครั้ง หากคุณสนใจ คุณสามารถดูหลักสูตรนี้ได้


3. นีโอ4เจ . ฐานข้อมูลกราฟที่พบบ่อยที่สุด นี่เป็นโซลูชันที่ปรับขนาดได้และมีเสถียรภาพ เหมาะสำหรับผู้ที่ต้องการใช้โมเดลข้อมูลกราฟ หากต้องการเรียนรู้เพิ่มเติม ให้เริ่มด้วยหลักสูตรนี้


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

ในปี 2561 ด้วย NoSQL

ฐานข้อมูล NoSQL เป็นสาขาที่กว้างขวางและเติบโตอย่างรวดเร็ว ช่วยให้คุณสามารถจัดเก็บและประมวลผลข้อมูลจำนวนมหาศาลที่ไม่สามารถจินตนาการได้ก่อนหน้านี้ แต่ก็ต้องเสียค่าใช้จ่าย ฐานข้อมูลเหล่านี้ไม่มีคุณลักษณะมากมายที่คุณคุ้นเคยในฐานข้อมูลเชิงสัมพันธ์ และอาจเป็นเรื่องยากที่จะเตรียมตัวเองให้พร้อมสำหรับการใช้งาน แต่เมื่อคุณเข้าใจแล้ว คุณสามารถสร้างฐานข้อมูลแบบกระจายที่ปรับขนาดได้ ซึ่งสามารถรองรับคำขออ่านและเขียนจำนวนมหาศาล ซึ่งอาจมีความสำคัญอย่างยิ่งเมื่อมีการสร้างข้อมูลจำนวนมากขึ้นเรื่อยๆ ต้นฉบับ: https://simpleprogrammer.com/guide-nosql-software-developers/