เบสกับกรด

6.1 การต่อสู้ของตัวย่อ: BASE vs. กรด

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

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

ไม่เชิง. ท้ายที่สุดแล้ว พวกเขาก็ต้องขายตัวเองในแพ็คเกจที่สวยงามเช่นเดียวกับฐานข้อมูลเชิงสัมพันธ์ และพวกเขาก็สร้างตัวย่อ "เคมี" ขึ้นมาเอง - BASE

6.2 BASE เป็นคู่อริ

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

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

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

NoSQL ถูกมองว่าเป็นฐานข้อมูลสำหรับการวิเคราะห์ตามเวลาจริง และเพื่อให้ได้ความเร็วที่มากขึ้น พวกเขายอมเสียสละความสม่ำเสมอ และเอริค บรูเออร์ คนเดียวกันกับที่บัญญัติคำว่า BASE ได้สร้างสิ่งที่เรียกว่า "ทฤษฎีบท CAP" ตามที่:

สำหรับการใช้งานคอมพิวเตอร์แบบกระจาย เป็นไปได้ที่จะจัดเตรียมคุณสมบัติไม่เกินสองในสามคุณสมบัติต่อไปนี้:

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

หากคุณต้องการคำอธิบายง่ายๆ เกี่ยวกับ CAP เชิญเลย

มีผู้แสดงความคิดเห็นว่าทฤษฎีบท CAP ใช้ไม่ได้ และโดยทั่วไปมีการกำหนดรูปแบบที่เป็นนามธรรมมากเกินไป ไม่ทางใดก็ทางหนึ่ง ฐานข้อมูล NoSQL มักจะปฏิเสธความสอดคล้องในบริบทของทฤษฎีบท CAP ซึ่งอธิบายถึงสถานการณ์ต่อไปนี้: ข้อมูลได้รับการอัปเดตในคลัสเตอร์ที่มีหลายอินสแตนซ์ แต่การเปลี่ยนแปลงยังไม่ได้รับการซิงโครไนซ์กับอินสแตนซ์ทั้งหมด โปรดจำไว้ว่าฉันได้กล่าวถึงตัวอย่าง DynamoDB ข้างต้น ซึ่งบอกฉันว่า: การเปลี่ยนแปลงของคุณจะคงทน - นี่คือ HTTP 200 สำหรับคุณ - แต่ฉันเห็นการเปลี่ยนแปลงหลังจากผ่านไป 10 วินาทีเท่านั้น อีกตัวอย่างหนึ่งในชีวิตประจำวันของนักพัฒนาคือ DNS ซึ่งเป็นระบบชื่อโดเมน หากใครไม่ทราบนี่คือ "พจนานุกรม" ที่แปลที่อยู่ http (s) เป็นที่อยู่ IP

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

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

ฐานข้อมูล NoSQL NoSQL มีสิ่งที่เรียกว่า "สถานะอ่อน" เนื่องจากรูปแบบความสอดคล้องแบบ end-to-end ซึ่งหมายความว่าสถานะของระบบสามารถเปลี่ยนแปลงได้ตลอดเวลา แม้จะไม่มีอินพุตก็ตาม แต่ระบบดังกล่าวมุ่งมั่นที่จะให้การเข้าถึงที่มากขึ้น การจัดเตรียมความพร้อมใช้งาน 100% ไม่ใช่เรื่องเล็กน้อย เรากำลังพูดถึง "ความพร้อมใช้งานพื้นฐาน" และแนวคิดทั้งสามนี้ร่วมกัน: "พร้อมใช้งานโดยทั่วไป" "สถานะอ่อน" ("สถานะอ่อน") และ "ความสอดคล้องในท้ายที่สุด" เป็นตัวย่อ BASE

ตามจริงแล้ว แนวคิดของ BASE สำหรับฉันแล้วดูเหมือนว่าจะเป็นส่วนเสริมทางการตลาดที่ว่างเปล่ามากกว่า ACID เพราะมันไม่ได้ให้อะไรใหม่ ๆ และไม่ได้แสดงลักษณะของฐานข้อมูลแต่อย่างใด และการติดป้ายกำกับ (ACID, BASE, CAP) กับฐานข้อมูลบางแห่งอาจทำให้นักพัฒนาสับสนเท่านั้น ฉันตัดสินใจที่จะแนะนำคุณเกี่ยวกับคำศัพท์นี้ เพราะมันยากที่จะหลีกเลี่ยงเมื่อศึกษาฐานข้อมูล แต่ตอนนี้คุณรู้แล้วว่ามันคืออะไร ฉันต้องการให้คุณลืมมันโดยเร็วที่สุด และกลับไปที่แนวคิดเรื่องความโดดเดี่ยว

6.3 ดังนั้นฐานข้อมูล BASE จึงไม่เป็นไปตามเกณฑ์ของกรดเลย?

โดยพื้นฐานแล้ว การที่ฐานข้อมูล ACID แตกต่างจากที่ไม่ใช่กรด ก็คือการที่ฐานข้อมูลที่ไม่ใช่กรดแยกออกจากกันจริงๆ นี่เป็นสิ่งสำคัญที่ต้องเข้าใจ แต่สิ่งสำคัญยิ่งกว่าคือต้องอ่านเอกสารประกอบของฐานข้อมูลและทดสอบด้วยวิธีที่คนจากโครงการ Hermitage ทำ ไม่สำคัญว่าผู้สร้างฐานข้อมูลนี้หรือฐานข้อมูลนั้นเรียกผลิตผลของพวกเขาอย่างไร - กรดหรือเบส, CAP หรือไม่ใช่ CAP สิ่งสำคัญคือสิ่งนี้หรือฐานข้อมูลนั้นให้อะไรกันแน่

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

• DB ไม่รับประกันความเป็นปรมาณู ในขณะที่ฐานข้อมูล NoSQL บางฐานข้อมูลมี API แยกต่างหากสำหรับการดำเนินการระดับปรมาณู (เช่น DynamoDB)

• DB ไม่รับประกันการแยกตัว ซึ่งอาจหมายความว่าฐานข้อมูลจะไม่เขียนข้อมูลตามลำดับที่เขียนไว้

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

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

6.4 ฐานข้อมูลที่แตกต่างกันจัดทำดัชนีข้อมูลอย่างไร และสิ่งนี้ส่งผลต่อความทนทานอย่างไร และอื่นๆ

มีสองวิธีหลักในการจัดเก็บและเรียกใช้ข้อมูล

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

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

อีกวิธีหนึ่งในการจัดทำดัชนีคือการใช้ B-tree (“B-trees”) ใน B-tree ข้อมูลจะถูกเขียนลงดิสก์ในเพจขนาดคงที่ บล็อกข้อมูลเหล่านี้มักมีขนาดประมาณ 4 KB และมีคู่คีย์-ค่าเรียงตามคีย์ โหนด B-tree หนึ่งโหนดเป็นเหมือนอาร์เรย์ที่มีลิงก์ไปยังหน้าต่างๆ สูงสุด จำนวนของลิงก์ในอาร์เรย์เรียกว่าปัจจัยสาขา แต่ละช่วงของหน้าคือโหนด B-tree อื่นที่มีลิงก์ไปยังช่วงหน้าอื่นๆ

ในที่สุด ที่ระดับแผ่นงาน คุณจะพบแต่ละหน้า แนวคิดนี้คล้ายกับพอยน์เตอร์ในภาษาการเขียนโปรแกรมระดับต่ำ ยกเว้นว่าการอ้างอิงเพจเหล่านี้ถูกจัดเก็บไว้ในดิสก์มากกว่าในหน่วยความจำ เมื่อ INSERT และ DELETE เกิดขึ้นในฐานข้อมูล บางโหนดสามารถแบ่งออกเป็นสองทรีย่อยเพื่อให้ตรงกับปัจจัยการแตกแขนง หากฐานข้อมูลล้มเหลวไม่ว่าด้วยเหตุผลใดๆ ก็ตามในระหว่างกระบวนการ ความสมบูรณ์ของข้อมูลอาจลดลง เพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้น ฐานข้อมูลที่ใช้ B-tree จะรักษา "บันทึกการเขียนล่วงหน้า" หรือ WAL ซึ่งบันทึกธุรกรรมทุกรายการ WAL นี้ใช้เพื่อกู้คืนสถานะของ B-tree หากเกิดความเสียหาย และดูเหมือนว่านี่คือสิ่งที่ทำให้ฐานข้อมูลที่ใช้ B-trees ดีขึ้นในแง่ของความทนทาน แต่ฐานข้อมูลที่ใช้ LSM ยังสามารถรักษาไฟล์ที่ทำหน้าที่เหมือนกับ WAL เป็นหลัก ดังนั้นฉันจะทำซ้ำสิ่งที่ฉันพูดไปแล้วและอาจมากกว่าหนึ่งครั้ง: เข้าใจกลไกการทำงานของฐานข้อมูลที่คุณเลือก

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

อย่างไรก็ตาม การออกแบบดัชนีมีผลโดยตรงต่อประสิทธิภาพของฐานข้อมูล เมื่อใช้ LSM tree การเขียนไปยังดิสก์จะเป็นไปตามลำดับ และ B-tree ทำให้เกิดการเข้าถึงดิสก์แบบสุ่มหลายรายการ ดังนั้น LSM จึงเขียนได้เร็วกว่า B-tree ความแตกต่างมีความสำคัญอย่างยิ่งสำหรับฮาร์ดดิสก์ไดรฟ์แบบแม่เหล็ก (HDD) ซึ่งการเขียนตามลำดับจะเร็วกว่าการเขียนแบบสุ่มมาก การอ่านบนแผนผัง LSM จะช้ากว่าเนื่องจากคุณต้องดูโครงสร้างข้อมูลและตาราง SS ต่างๆ ที่อยู่ในขั้นตอนต่างๆ ของการบดอัด ในรายละเอียดเพิ่มเติมดูเหมือนว่านี้ หากเราสร้างแบบสอบถามฐานข้อมูลอย่างง่ายด้วย LSM เราจะค้นหาคีย์ใน MemTable ก่อน หากไม่มี เราจะดูที่ SSTable ล่าสุด หากไม่มีเราจะดูที่ SSTable สุดท้ายและอื่น ๆ หากไม่มีรหัสที่ขอ LSM จะรู้สิ่งนี้เป็นครั้งสุดท้าย ต้นไม้ LSM ใช้ใน ตัวอย่างเช่น: LevelDB, RocksDB, Cassandra และ HBase

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

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

6.5 วิธีการทำงานของฐานข้อมูลในหน่วยความจำ

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

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

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

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

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