2
จริงๆแล้วมี FoundationDB ซึ่งสอดคล้องกับกรด ตอนนี้ Apple คว้ามันไว้
—
ผู้ใช้ที่ไม่มีหมวก
คำตอบ:
ฉันจะโพสต์สิ่งนี้เป็นคำตอบเพื่อสนับสนุนการสนทนาอย่างแท้จริง - Tim Mahy , nawrothและCraigTPได้แนะนำฐานข้อมูลที่ใช้การได้ CouchDBจะเป็นที่ต้องการของฉันเนื่องจากการใช้Erlangแต่มีคนอื่นออกมี
ฉันว่ากรดไม่ขัดแย้งหรือลบล้างแนวคิดของNoSQL ... ในขณะที่ดูเหมือนว่าจะมีแนวโน้มตามความคิดเห็นที่แสดงออกโดยนกพิราบฉันจะโต้แย้งแนวคิดที่แตกต่างกัน
NoSQLเป็นพื้นฐานเกี่ยวกับคีย์ - ค่าอย่างง่าย (เช่น Redis) หรือสคีมาสไตล์เอกสาร (รวบรวมคู่ค่าคีย์ในโมเดล "เอกสาร" เช่น MongoDB) เป็นทางเลือกโดยตรงกับสคีมาอย่างชัดเจนในคลาส RDBMSs มันช่วยให้นักพัฒนาสามารถรักษาสิ่งต่าง ๆ ได้อย่างไม่สมมาตรในขณะที่เอ็นจิ้นแบบดั้งเดิมได้บังคับใช้แบบเดียวกันกับโมเดลข้อมูล เหตุผลนี้น่าสนใจมากเพราะเป็นวิธีที่แตกต่างในการจัดการกับการเปลี่ยนแปลงและสำหรับชุดข้อมูลที่ใหญ่ขึ้นก็ให้โอกาสที่น่าสนใจในการจัดการกับปริมาณและประสิทธิภาพ
ACIDจัดเตรียมหลักการที่ควบคุมวิธีการเปลี่ยนแปลงที่ใช้กับฐานข้อมูล ในวิธีที่ง่ายมากก็ระบุ (รุ่นของฉันเอง):
ได้รับการสนทนาเล็ก ๆ น้อย ๆ ได้ง่ายมากขึ้นเมื่อมันมาถึงความคิดของการขยายพันธุ์และข้อ จำกัด เอ็นจิน RDBMS บางตัวจัดเตรียมความสามารถในการบังคับใช้ข้อ จำกัด (เช่นคีย์ต่างประเทศ) ซึ่งอาจมีองค์ประกอบการแพร่กระจาย (a la cascade ) ในแง่ที่ง่ายกว่า "สิ่ง" หนึ่งอาจมีความสัมพันธ์กับอีกสิ่ง "" ในฐานข้อมูลและถ้าคุณเปลี่ยนคุณลักษณะหนึ่งมันอาจต้องเปลี่ยนอีก (ปรับปรุงลบ ... ตัวเลือกมากมาย) ฐานข้อมูลNoSQLซึ่งส่วนใหญ่มุ่งเน้นไปที่ปริมาณข้อมูลที่สูงและปริมาณการใช้ข้อมูลสูงดูเหมือนว่าจะมีการจัดการกับแนวคิดของการอัพเดทแบบกระจายซึ่งเกิดขึ้นภายในกรอบเวลาที่กำหนดเอง นี่เป็นรูปแบบเฉพาะของการจำลองแบบที่จัดการผ่านทรานแซคชัน - ดังนั้นฉันจะบอกว่าถ้าฐานข้อมูลแบบกระจายสามารถรองรับกรดได้ดังนั้นฐานข้อมูล NoSQL ก็สามารถทำได้
ทรัพยากรบางอย่างสำหรับการอ่านเพิ่มเติม:
UPDATE (27 กรกฎาคม 2555): ลิงก์ไปยังบทความ Wikipedia ได้รับการปรับปรุงเพื่อให้สอดคล้องกับรุ่นของบทความที่เป็นปัจจุบันเมื่อคำตอบนี้ถูกโพสต์ โปรดทราบว่าบทความ Wikipedia ปัจจุบันได้รับการแก้ไขอย่างกว้างขวาง!
ตามบทความ Wikipedia ในเวอร์ชันเก่าบน NoSQL :
NoSQL คือการเคลื่อนไหวที่ส่งเสริมการจัดเก็บข้อมูลที่ไม่ใช่เชิงสัมพันธ์ซึ่งแบ่งออกเป็นฐานข้อมูลเชิงสัมพันธ์และการรับประกัน ACID
และนอกจากนี้ยังมี:
ชื่อนี้เป็นความพยายามที่จะอธิบายถึงการเกิดขึ้นของจำนวนที่เพิ่มขึ้นของที่เก็บข้อมูลแบบกระจายที่ไม่สัมพันธ์กันซึ่งมักจะไม่พยายามให้การรับรองกรด
และ
ระบบ NoSQL มักจะให้การรับรองความมั่นคงที่อ่อนแอเช่นความมั่นคงในที่สุดและการทำธุรกรรม จำกัด รายการข้อมูลเดียวแม้ว่าหนึ่งสามารถกำหนดการรับประกันกรดเต็มรูปแบบโดยการเพิ่มชั้นมิดเดิลแวร์เสริม
ดังนั้นโดยสังเขปฉันจะบอกว่าหนึ่งในประโยชน์หลักของการเก็บข้อมูล "NoSQL" คือการขาดคุณสมบัติของกรด ยิ่งไปกว่านั้น IMHO ยิ่งพยายามใช้และบังคับใช้คุณสมบัติACIDยิ่งห่างไกลจาก "วิญญาณ" ของแหล่งข้อมูล "NoSQL" ที่คุณได้รับและยิ่งใกล้กับRDBMS "จริง" ที่คุณได้รับ )
อย่างไรก็ตามทั้งหมดที่กล่าวว่า "NoSQL" เป็นคำที่คลุมเครือมากและเปิดให้มีการตีความส่วนบุคคลและขึ้นอยู่กับว่าคุณมีมุมมองที่พิถีพิถันมากเพียงใด ยกตัวอย่างเช่นวันที่ทันสมัยที่สุด RDBMS ระบบไม่จริงที่จะปฏิบัติตามทั้งหมดของเอ็ดการ์เอฟ Codd 's 12 กฎของรูปแบบความสัมพันธ์ !
เมื่อใช้แนวทางปฏิบัติมันจะปรากฏว่าCouchDBของ Apache มาใกล้เคียงกับการรวบรวมทั้งความสอดคล้องของกรดในขณะที่ยังคงรักษาความคิด "NoSQL" ที่ไม่สัมพันธ์กัน
โปรดตรวจสอบว่าคุณอ่านการแนะนำมาร์ตินฟาวเลอร์เกี่ยวกับฐานข้อมูล NoSQL และวิดีโอที่เกี่ยวข้อง
ก่อนอื่นเราสามารถแยกแยะความแตกต่างของฐานข้อมูล NoSQL ได้สองประเภท:
จากการออกแบบฐานข้อมูลกราฟส่วนใหญ่เป็นกรด !
แล้วประเภทอื่น ๆ ล่ะ?
ในฐานข้อมูลเชิงรวมเราสามารถวางประเภทย่อยสามประเภท:
สิ่งที่เราเรียกว่าการรวมที่นี่คือสิ่งที่ Eric Evans กำหนดไว้ในการออกแบบโดเมนที่ขับเคลื่อนด้วยตนเองในรูปแบบของหน่วยงานและวัตถุที่คุ้มค่าในบริบทที่กำหนด
ดังนั้นการรวมเป็นชุดของข้อมูลที่เราโต้ตอบด้วยเป็นหน่วย การรวมแบบฟอร์มขอบเขตสำหรับการดำเนินการ ACID กับฐานข้อมูล (Martin Fowler)
ดังนั้นในระดับรวมเราสามารถพูดได้ว่าฐานข้อมูล NoSQL ส่วนใหญ่มีความปลอดภัยเท่ากับ ACID RDBMSด้วยการตั้งค่าที่เหมาะสม แหล่งที่มาถ้าคุณปรับเซิร์ฟเวอร์ของคุณเพื่อความเร็วที่ดีที่สุดคุณอาจเข้าสู่บางสิ่งที่ไม่ใช่กรด แต่การจำลองแบบจะช่วย
ประเด็นหลักของฉันคือคุณต้องใช้ฐานข้อมูล NoSQL ตามที่เป็นอยู่ไม่ใช่เป็นทางเลือก (ถูก) กับ RDBMS ฉันเห็นโครงการมากเกินไปที่ใช้ความสัมพันธ์ระหว่างเอกสารในทางที่ผิด ไม่สามารถเป็นกรดได้ หากคุณอยู่ในระดับเอกสารเช่นในขอบเขตรวมคุณไม่จำเป็นต้องทำธุรกรรมใด ๆ และข้อมูลของคุณจะปลอดภัยเหมือนกับฐานข้อมูล ACID แม้ว่าจะไม่ได้เป็น ACID อย่างแท้จริงเนื่องจากคุณไม่ต้องการธุรกรรมเหล่านั้น! หากคุณต้องการธุรกรรมและอัปเดต "เอกสาร" หลายรายการพร้อมกันคุณไม่ได้อยู่ในโลกของ NoSQL อีกต่อไปดังนั้นให้ใช้เครื่องมือ RDBMS แทน!
บางปรับปรุง 2019: เริ่มต้นในรุ่น 4.0 สำหรับสถานการณ์ที่ต้อง atomicity สำหรับการปรับปรุงเอกสารหลายหรือสอดคล้องระหว่างอ่านเอกสารหลาย MongoDB ให้การทำธุรกรรมเอกสารหลายชุดแบบจำลอง
FoundationDB เป็นไปตามข้อกำหนดของกรด:
มีธุรกรรมที่เหมาะสมดังนั้นคุณสามารถอัปเดตรายการข้อมูลที่หลากหลายในรูปแบบกรด สิ่งนี้ใช้เป็นรากฐานสำหรับการบำรุงรักษาดัชนีในระดับที่สูงขึ้น
ในคำถามนี้บางคนต้องพูดถึงOrientDB : OrientDB เป็นฐานข้อมูล NoSQL หนึ่งในไม่กี่แห่งที่รองรับธุรกรรมกรดอย่างสมบูรณ์ กรดไม่เพียง แต่สำหรับ RDBMS เพราะมันไม่ได้เป็นส่วนหนึ่งของพีชคณิตเชิงสัมพันธ์ ดังนั้นจึงเป็นไปได้ที่จะมีฐานข้อมูล NoSQL ที่สนับสนุนกรด
คุณลักษณะนี้เป็นสิ่งที่ฉันคิดถึงมากที่สุดใน MongoDB
กรดและ NoSQL นั้นมีมุมฉากสมบูรณ์ หนึ่งไม่ได้หมายความถึงอื่น ๆ
ฉันมีสมุดบันทึกบนโต๊ะทำงานฉันใช้เพื่อเก็บบันทึกสิ่งที่ฉันยังต้องทำ สมุดบันทึกนี้เป็นฐานข้อมูล NoSQL ฉันค้นหาโดยใช้การค้นหาเชิงเส้นด้วย "แคชหน้า" ดังนั้นฉันจึงไม่จำเป็นต้องค้นหาทุกหน้า นอกจากนี้ยังเป็นไปตามข้อกำหนดของกรดเนื่องจากฉันรับรองว่าฉันจะเขียนได้ทีละรายการเท่านั้นและไม่เคยอ่านเลย
NoSQL นั้นหมายความว่าไม่ใช่ SQL หลายคนสับสนและคิดว่ามันหมายถึงพื้นที่จัดเก็บที่รวดเร็ว มันไม่ได้ ไม่ได้หมายถึงที่เก็บคีย์ - ค่าหรือความสอดคล้องในที่สุด ทั้งหมดที่ว่าก็คือ "ไม่ SQL" มีจำนวนมากของฐานข้อมูลในโลกนี้และส่วนใหญ่ของพวกเขาไม่ SQL [อ้างจำเป็น]
คุณสามารถค้นหาตัวอย่างมากมายในคำตอบอื่น ๆ ดังนั้นฉันไม่จำเป็นต้องแสดงรายการไว้ที่นี่ แต่มีฐานข้อมูลที่ไม่ใช่ SQL ที่มีความสอดคล้องกับ ACID สำหรับการดำเนินการต่าง ๆ บางอย่างเป็นเพียง ACID สำหรับการเขียนวัตถุเดี่ยวในขณะที่รับประกันบางอย่าง แต่ละฐานข้อมูลแตกต่างกัน
"NoSQL" ไม่ใช่คำที่กำหนดไว้อย่างดี มันเป็นแนวคิดที่คลุมเครือมาก ดังนั้นจึงไม่สามารถแม้แต่จะบอกได้ว่าอะไรคืออะไรและไม่ใช่ผลิตภัณฑ์ "NoSQL" ผลิตภัณฑ์เกือบทั้งหมดที่มีแบรนด์ที่มีฉลากติดกันเป็นร้านค้าคีย์ - ค่า
ใช่ MarkLogic Server เป็นโซลูชัน NoSQL (ฐานข้อมูลเอกสารที่ฉันต้องการเรียก) ที่ทำงานกับธุรกรรม ACID
ปู่ของ NoSQL: ZODB เป็นไปตามข้อกำหนดของกรด http://www.zodb.org/
อย่างไรก็ตามมันเป็น Python เท่านั้น
ในฐานะหนึ่งในผู้เริ่มต้นของ NoSQL (ฉันเป็นผู้สนับสนุนต้นให้กับ Apache CouchDB และเป็นวิทยากรในงานแรกของ NoSQL ที่จัดขึ้นที่ CBS Interactive / CNET ในปี 2009) ฉันรู้สึกตื่นเต้นที่ได้เห็นอัลกอริธึมใหม่ ๆ . โปรโตคอล Calvinเสนอวิธีใหม่ในการคิดถึงข้อ จำกัด ทางกายภาพเช่น CAP และPACELC PACELC
แทน / การจำลองแบบ async ใช้งานเรื่อย ๆ หรืองาน / การใช้งานการจำลองแบบซิงโคร, Calvin เก็บรักษาความถูกต้องและความพร้อมในระหว่างการขาดหายไปของแบบจำลองโดยใช้แพเหมือนโปรโตคอลที่จะรักษาบันทึกการทำธุรกรรม นอกจากนี้การทำธุรกรรมจะถูกดำเนินการอย่างแน่นอนในแต่ละแบบจำลองการลบศักยภาพสำหรับการหยุดชะงักดังนั้นข้อตกลงจะประสบความสำเร็จด้วยความเห็นพ้องเพียงรอบเดียว สิ่งนี้ทำให้รวดเร็วแม้ในการปรับใช้หลายคลาวด์ทั่วโลก
FaunaDBเป็นการใช้ฐานข้อมูลเพียงอย่างเดียวโดยใช้โปรโตคอล Calvin ทำให้เหมาะสำหรับเวิร์กโหลดที่ต้องการความสมบูรณ์ของข้อมูลที่เหมือนเมนเฟรมที่มีสเกล NoSQL และความยืดหยุ่น
หากคุณกำลังมองหาร้านค้าที่สำคัญสอดคล้อง / ค่ากรดมีBerkeley DB ในบรรดาฐานข้อมูลกราฟอย่างน้อยNeo4jและHyperGraphDBให้ธุรกรรม ACID (HyperGraphDB ใช้ Berkeley DB สำหรับการจัดเก็บระดับต่ำในขณะนี้)
ผู้มีส่วนร่วมในแนวคิดนี้Wikipediaกำหนดเป็น:
[... ] คลาสของระบบการจัดการฐานข้อมูลเชิงสัมพันธ์ที่ทันสมัยที่พยายามจัดหาประสิทธิภาพการทำงานที่ปรับขนาดได้ของระบบ NoSQL สำหรับการประมวลผลการอ่านธุรกรรมออนไลน์ (OLTP) ในขณะที่ยังคงรับประกัน ACID ของระบบฐานข้อมูลแบบดั้งเดิม
[1][2][3]
[1]Nancy Lynch และ Seth Gilbert, "การคาดคะเนของ Brewer และความเป็นไปได้ในการให้บริการเว็บที่มีความต่อเนื่อง, พร้อมใช้งาน, รองรับพาร์ติชัน" , ACM SIGACT News, เล่มที่ 33 ฉบับที่ 2 (2002), pg 51-59
[2] "Brewer's CAP Theorem" , julianbrowne.com, สืบค้น 02-Mar-2010
[3] "Brewers CAP ทฤษฎีบทในระบบกระจาย" , royans.net
MongoDB ประกาศว่าเวอร์ชั่น 4.0 จะเป็นไปตามข้อกำหนดของ ACID สำหรับการทำธุรกรรมหลายเอกสาร
เวอร์ชั่น 4.2 ควรที่จะสนับสนุนภายใต้การตั้งค่าที่หักออก
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
FoundationDB ถูกกล่าวถึงและในเวลานั้นไม่ได้เปิดแหล่งที่มา Apple เปิดให้บริการเมื่อสองวันก่อน: https://www.foundationdb.org/blog/foundationdb-is-open-source/
ฉันเชื่อว่าเป็นไปตามข้อกำหนดของกรด
ลองดูทฤษฎีบท CAP
แก้ไข: RavenDB ดูเหมือนว่าจะเป็นไปตามมาตรฐานกรด
Hyperdex Warp http://hyperdex.org/warp/ Warp (คุณสมบัติกรด) เป็นกรรมสิทธิ์ แต่ Hyperdex นั้นฟรี
db4o
ซึ่งแตกต่างจากการคงอยู่ของคุณเองหรือต่อเนื่องม้วน, db4o เป็นธุรกรรมกรดปลอดภัยและช่วยให้การสอบถามการจำลองแบบและการเปลี่ยนแปลงสคีมาในช่วงรันไทม์
Tarantool เป็นฐานข้อมูล NoSQL ACID อย่างสมบูรณ์ คุณสามารถออก CRUD การดำเนินงานหรือขั้นตอนการจัดเก็บทุกอย่างจะทำงานอย่างเคร่งครัดตามคุณสมบัติกรด คุณสามารถอ่านเกี่ยวกับสิ่งนี้ได้ที่นี่: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
MarkLogic ยังเป็นไปตามข้อกำหนดกรด ฉันคิดว่าเป็นหนึ่งในผู้เล่นที่ยิ่งใหญ่ที่สุดในตอนนี้
รอหมดแล้ว
NoSQL DB เป็นไปตามข้อกำหนดของกรดออกมา ----------- ดูที่citrusleaf
BergDBเป็นฐานข้อมูล NoSQL น้ำหนักเบาโอเพ่นซอร์สออกแบบมาตั้งแต่เริ่มต้นเพื่อทำธุรกรรมกรด ที่จริงแล้ว BergDB เป็นกรด "มากกว่า" มากกว่าฐานข้อมูล SQL ส่วนใหญ่ในแง่ที่เป็นวิธีเดียวเท่านั้นจะเปลี่ยนสถานะของฐานข้อมูลคือการเรียกใช้ธุรกรรม ACID ที่มีระดับการแยกสูงสุด (คำศัพท์ SQL: "serializable") จะไม่มีปัญหาใด ๆ กับการอ่านสกปรกการอ่านซ้ำไม่ได้หรือการอ่านผี
ในความคิดของฉันฐานข้อมูลยังคงมีประสิทธิภาพสูง แต่ไม่ไว้ใจฉันฉันสร้างซอฟต์แวร์ ลองด้วยตัวเองแทน
โซลูชัน NoSQL ที่ทันสมัยจำนวนมากไม่สนับสนุนธุรกรรม ACID (การปรับปรุงหลายคีย์แบบอะตอมมิกที่แยกได้) แต่ส่วนใหญ่สนับสนุนการใช้แบบดั้งเดิมซึ่งช่วยให้คุณสามารถทำธุรกรรมในระดับแอปพลิเคชันได้
ถ้าแหล่งข้อมูลสนับสนุนต่อ linearizability ของคีย์และการเปรียบเทียบและการตั้งค่า (ระดับอะตอมของเอกสาร) จากนั้นก็เพียงพอที่จะใช้ธุรกรรมฝั่งไคลเอ็นต์มากกว่าคุณมีตัวเลือกมากมายให้เลือก:
ถ้าคุณต้องการระดับแยก Serializable แล้วคุณสามารถทำตามขั้นตอนวิธีการเดียวกันที่ Google ใช้สำหรับกรองระบบหรือแมลงสาบ Labs สำหรับCockroachDB ฉัน blogged เกี่ยวกับเรื่องนี้และสร้างการสร้างภาพเป็นขั้นตอนฉันหวังว่ามันจะช่วยให้คุณเข้าใจแนวคิดหลักที่อยู่เบื้องหลังอัลกอริทึม
หากคุณคาดว่าจะมีการแข่งขันสูง แต่ก็เป็นเรื่องดีที่คุณจะได้อ่านระดับการแยกแบบมุ่งมั่นแล้วโปรดดูธุรกรรม RAMPของ Peter Bailis
วิธีที่สามคือการใช้การชดเชยการทำธุรกรรมที่รู้จักกันว่ารูปแบบการผจญภัย มันถูกอธิบายในช่วงปลายยุค 80 ในกระดาษSagasแต่กลายเป็นเรื่องจริงมากขึ้นด้วยการเพิ่มระบบกระจาย โปรดดูการพูดคุยเรื่องการปรับใช้ Saga Patternเพื่อหาแรงบันดาลใจ
รายชื่อร้านค้าข้อมูลที่เหมาะสมสำหรับการทำธุรกรรมด้านลูกค้ารวมถึง Cassandra กับการทำธุรกรรมที่มีน้ำหนักเบา Riak พร้อมที่เก็บข้อมูลที่สอดคล้องกัน RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB และอื่น ๆ
YugaByte DBสนับสนุนtxns แบบกระจายที่ได้มาตรฐาน ACIDรวมถึงความเข้ากันได้ของ Redis และ CQL API บนเลเยอร์แบบสอบถาม
ในขณะที่มันเป็นเพียงเอ็นจิ้นที่ฝังตัวไม่ใช่เซิร์ฟเวอร์ แต่leveldbมี WriteBatch และความสามารถในการเปิดใช้งานการเขียนแบบซิงโครนัสเพื่อกำหนดลักษณะการทำงานของกรด
โหนด levelUP เป็นธุรกรรมและสร้างขึ้นบน leveldb https://github.com/rvagg/node-levelup#batch
ไม่เพียง NoSQL ไม่ได้เป็นไปตามข้อกำหนดของการออกแบบ การเคลื่อนไหว NoSQL ยอมรับ BASE (โดยทั่วไป, สถานะซอฟท์, ความสอดคล้องในที่สุด) อ้างว่าตรงกันข้ามกับ ACID ฐานข้อมูล NoSQL มักจะถูกเรียกว่าฐานข้อมูลที่สอดคล้องกันในที่สุด เพื่อทำความเข้าใจความแตกต่างคุณควรเจาะลึกลงไปในทฤษฎีบท CAP (ทฤษฎีบทของ Brewer's)
เยี่ยมชมhttp://www.julianbrowne.com/article/viewer/brewers-cap-theorem