MongoDB ไม่สอดคล้องกับกรดอะไรก่อน v4 หมายถึงอะไร?


226

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

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

แต่เมื่อฉันได้รับการสนทนาเกี่ยวกับ MongoDB พวกเราที่ไม่ทราบรายละเอียดทางเทคนิคเกี่ยวกับวิธีการนำฐานข้อมูลไปใช้จริง ๆ

MongoDB นั้นเร็วกว่า MySQL และ Postgres แต่มีโอกาสเล็กน้อยเช่น 1 ในล้านที่ว่า "จะไม่บันทึกอย่างถูกต้อง"

ส่วน "ไม่บันทึกอย่างถูกต้อง" นั้นอ้างถึงความเข้าใจนี้: หากไฟดับในทันทีที่คุณเขียนถึง MongoDB มีโอกาสสำหรับบันทึกที่เฉพาะเจาะจง (บอกว่าคุณกำลังติดตามจำนวนหน้าที่มีการเปิดในเอกสารที่มี 10 แอตทริบิวต์ แต่ละรายการ) ว่าเอกสารอย่างใดอย่างหนึ่งเท่านั้นบันทึก 5 ของคุณลักษณะ ... ซึ่งหมายความว่าเมื่อเวลาผ่านไปเคาน์เตอร์นับจำนวนการดูหน้าเว็บของคุณจะ "ปิด" เล็กน้อย คุณจะไม่มีทางรู้ได้เลยว่าคุณรู้ว่ามันถูกต้อง 99.999% แต่ไม่ใช่ 100% นี่เป็นเพราะถ้าคุณไม่ได้ทำสิ่งนี้เป็นพิเศษในการปฏิบัติการปรมาณู mongodb การดำเนินการจะไม่รับประกันว่าจะเป็นอะตอม

ดังนั้นคำถามของฉันคืออะไรการตีความที่ถูกต้องของเวลาและทำไม MongoDB อาจไม่ "บันทึกอย่างถูกต้อง" คืออะไร? ส่วนใดของกรดที่ไม่พึงพอใจและภายใต้สถานการณ์ใดและคุณจะรู้ได้อย่างไรว่าข้อมูลของคุณปิดอยู่ที่ 0.001% สิ่งนี้ไม่สามารถแก้ไขได้หรือ ถ้าไม่เช่นนี้หมายความว่าคุณไม่ควรจัดเก็บสิ่งต่าง ๆ เช่นusersตารางของคุณใน MongoDB เพราะบันทึกอาจไม่ได้รับการบันทึก แต่แล้วอีกครั้งผู้ใช้ 1 / 1,000,000 คนอาจต้อง "ลองลงชื่อสมัครใช้อีกครั้ง" ใช่ไหม

ฉันแค่กำลังมองหารายการเมื่อ / ทำไมสิ่งลบเกิดขึ้นกับฐานข้อมูลที่ไม่สอดคล้องกับกรดเช่น MongoDB และถ้ามีวิธีแก้ปัญหามาตรฐาน (เช่นใช้งานพื้นหลังเพื่อล้างข้อมูลหรือใช้ SQL สำหรับสิ่งนี้เท่านั้น) .

คำตอบ:


133

สิ่งหนึ่งที่คุณแพ้ด้วย MongoDB คือการทำธุรกรรมแบบหลายคอลเลกชัน (ตาราง) ตัวดัดแปลงอะตอมมิกใน MongoDB สามารถทำงานกับเอกสารเดียวเท่านั้น

หากคุณต้องการลบรายการออกจากสินค้าคงคลังและเพิ่มลงในคำสั่งซื้อของใครบางคนในเวลาเดียวกัน - คุณไม่สามารถ เว้นแต่ว่ามีสองสิ่ง - สินค้าคงคลังและคำสั่งซื้อ - มีอยู่ในเอกสารเดียวกัน (ซึ่งอาจไม่มี)

ฉันพบปัญหาเดียวกันนี้ในแอปพลิเคชันที่ฉันกำลังทำงานและมีวิธีแก้ไขปัญหาที่เป็นไปได้สองแบบให้เลือก:

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

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

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

2) ใช้ฐานข้อมูลการทำธุรกรรมร่วมกับ MongoDB เป็นเรื่องปกติที่จะใช้ MySQL เพื่อทำธุรกรรมสำหรับสิ่งที่ต้องการอย่างยิ่งในขณะที่ให้ MongoDB (หรือ NoSQL อื่น ๆ ) ทำสิ่งที่ดีที่สุด

หากโซลูชันของฉันจาก # 1 ไม่ทำงานในระยะยาวฉันจะตรวจสอบเพิ่มเติมเพื่อรวม MongoDB กับ MySQL แต่ตอนนี้ # 1 เหมาะสมกับความต้องการของฉันเป็นอย่างดี


27
" ตัวดัดแปลงอะตอมมิกใน MongoDB สามารถใช้ได้กับคอลเลกชันเดียวเท่านั้น " => ฉันคิดว่าคุณหมายถึง "เทียบกับเอกสารฉบับเดียว"
assylias

2
ข้อมูลที่ดีเยี่ยมโดยทั่วไปคำตอบที่ดีเยี่ยมยกเว้นการแนะนำให้ใช้ MySQL
Doug Molineux

״ สิ่งหนึ่งที่คุณแพ้ด้วย MongoDB คือการทำธุรกรรมแบบหลายคอลเลกชัน (ตาราง) ตัวดัดแปลงอะตอมมิกใน MongoDB สามารถทำงานกับเอกสารเดี่ยว״ จาก mongo doc ( docs.mongodb.com/v3.2/core/write-operations-atomicity ): "ใน MongoDB การดำเนินการเขียนอยู่ที่ระดับเดียว เอกสารแม้ว่าการดำเนินการจะแก้ไขเอกสารหลายฉบับที่ฝังอยู่ภายในเอกสารเดียวก็ตาม "
yoav.str

5
การขาดการทำธุรกรรม ACID หลายเอกสารนั้นไม่มีอีกต่อไป MongoDB ประกาศว่าจะมาใน v4.0 ดูmongodb.com/blog/post/multi-document-transactions-in-mongodb
Grigori Melnik

1
สำหรับตอนนี้เนื่องจาก MongoDB 4.0 นั้นเป็นไปตามข้อกำหนดของกรดmongodb.com/transactionsกับการทำธุรกรรมหลายเอกสาร ดูได้ที่mongodb.com/blog/post/…
Ratah

134

ที่จริงแล้วมันไม่ถูกต้องที่ MongoDB ไม่สอดคล้องกับกรด ในทางตรงกันข้าม MongoDB เป็นกรด compilant ที่ระดับเอกสาร

การอัปเดตใด ๆ ในเอกสารเดียวคือ

  • อะตอม: มันสมบูรณ์อย่างสมบูรณ์หรือไม่
  • สอดคล้อง: ผู้อ่านจะไม่เห็นการอัปเดต "นำไปใช้บางส่วน"
  • โดดเดี่ยว: อีกครั้งผู้อ่านจะไม่เห็น "สกปรก" อ่าน
  • ทนทาน: (ด้วยความกังวลในการเขียนที่เหมาะสม)

สิ่งที่ MongoDB ไม่มีคือธุรกรรมซึ่งก็คือการอัปเดตหลายเอกสารที่สามารถย้อนกลับได้และเข้ากันได้กับกรด

โปรดทราบว่าคุณสามารถสร้างการทำธุรกรรมด้านบนของการปรับปรุงกรดที่สอดคล้องกับเอกสารฉบับเดียวโดยใช้สองเฟสกระทำ


3
โปรดทราบว่าธุรกรรมของการผูกมัดสองเฟสไม่สอดคล้องกับ ACID ด้วยเหตุผลบางอย่างฉันอนุมานสิ่งที่ตรงกันข้ามจนกระทั่งฉันไปตามลิงก์
Justin C

1
มีคำถามบางอย่างเกี่ยวกับความทนทานของ MongoDB แบบกระจายที่ระดับเอกสารโดยไม่คำนึงถึงการกำหนดค่าข้อกังวลการเขียน เครื่องมือโอเพนซอร์ส Jepsen พบว่าข้อมูลสามารถสูญหายได้เมื่อเผชิญกับพาร์ติชันเครือข่ายแม้ว่าจะมีข้อกังวลในการเขียน MAJORITY ดูบทความที่นี่: aphyr.com/posts/284-call-me-maybe-mongodb
jrullmann

9
การมี ACID ที่ระดับของเอกสารเดี่ยวซึ่งในทางใดทางหนึ่งเทียบเท่ากับเร็กคอร์ดเดียวใน RDBMS จะไม่มีประโยชน์ในหลายกรณี เงื่อนไขการทำธุรกรรมไม่เกี่ยวข้องกับตารางเดียวและคุณยังสามารถมีกลไกของการกระทำสองขั้นตอนและเกี่ยวข้องกับหลาย XAResource ดังนั้นการอ้างถึงเอกสารเดียวว่าเป็นไปตามมาตรฐาน ACID ค่อนข้างเป็นปัญหา IMHO
Yair Zaslavsky

5
เห็นด้วยกับ Yair "สอดคล้องกับกรดในระดับเอกสาร" ไม่ใช่จุดขาย โดยพื้นฐานแล้วมันหมายถึง "ไม่เข้ากับกรด" กรดไม่เคยมีความหมายว่า "แค่หนึ่งแถว / เอกสาร / เอนทิตี" มันเกี่ยวกับการรักษาข้อมูลของคุณให้สอดคล้องกันตลอดทั้งฐานข้อมูล
joshua.paling

34

คำอธิบายที่ดีที่มีอยู่ใน"สตาร์บัไม่ได้ใช้สองเฟสกระทำ"

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

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


1
มันก็มีข้อ จำกัด เหมือนกัน ในซอฟต์แวร์มันเป็นเรื่องง่ายที่จะสร้าง Array [Cashiers] ใหม่และให้พวกเขาทำธุรกรรมแบบซิงโครนัสในขณะที่ค่าใช้จ่ายในโลกแห่งความเป็นจริงนั้นจะมีราคาแพงอย่างน่าขัน
HRJ

16

ฉันคิดว่าคนอื่นให้คำตอบที่ดีอยู่แล้ว อย่างไรก็ตามฉันต้องการเพิ่มว่ามี ACID NOSQL DBs (เช่นhttp://ravendb.net/ ) ดังนั้นมันจึงไม่ใช่แค่การตัดสินใจ NOSQL - ไม่มีกรดกับความสัมพันธ์กับกรด ....


1
ขอบคุณ @ subGate ใครบ้างที่สามารถแบ่งปันประสบการณ์กับ ravenDB และหากเป็นไปตามข้อกำหนดหรือไม่
Nir Pengas

12

"จะไม่บันทึกอย่างถูกต้อง" อาจหมายถึง:

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

  2. ไม่มีการอัปเดต "อะตอมมิก" ที่ง่ายต่อการรวบรวมหลายครั้งและแม้แต่เอกสารหลายฉบับในคอลเล็กชันเดียวกัน ในกรณีส่วนใหญ่จะไม่เกิดปัญหาเพราะสามารถหลีกเลี่ยงได้ด้วยTwo Phase Commitหรือปรับโครงสร้างสคีมาของคุณใหม่ดังนั้นการอัพเดตจะทำกับเอกสารเดียว ดูคำถามนี้: ฐานข้อมูลเอกสาร: ข้อมูลซ้ำซ้อน, การอ้างอิง ฯลฯ (เฉพาะ MongoDB)


10

ในฐานะของ MongoDB v4.0 ธุรกรรม ACID หลายเอกสารได้รับการสนับสนุน ธุรกรรมจะให้มุมมองข้อมูลที่สอดคล้องกันทั่วโลกและบังคับใช้การดำเนินการทั้งหมดหรือไม่ดำเนินการใด ๆ เพื่อรักษาความถูกต้องของข้อมูล

พวกเขารู้สึกเหมือนการทำธุรกรรมจากโลกสัมพันธ์เช่น:

with client.start_session() as s:
    s.start_transaction()
    try:
        collection.insert_one(doc1, session=s)
        collection.insert_one(doc2, session=s)
        s.commit_transaction()
    except Exception:
        s.abort_transaction()

ดูhttps://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb


ผู้สมัครรุ่นแรกของ MongoDB4.0 หมดแล้ว - linkedin.com/pulse/mongodb-40-rc0-now-available-grigori-melnik
Grigori Melnik

5

โปรดอ่านเกี่ยวกับคุณสมบัติของกรดเพื่อทำความเข้าใจให้ดีขึ้น

นอกจากนี้ในเอกสาร MongoDB คุณสามารถค้นหาคำถามและคำตอบได้

MongoDB ไม่สอดคล้องกับกรด อ่านด้านล่างสำหรับการสนทนาเกี่ยวกับการปฏิบัติตามข้อกำหนดของ ACID

  1. MongoDB เป็นแบบATomic ในระดับเอกสารเท่านั้น ไม่สอดคล้องกับคำจำกัดความของอะตอมที่เรารู้จักจากระบบฐานข้อมูลเชิงสัมพันธ์โดยเฉพาะลิงก์ด้านบน ในแง่นี้ MongoDB ไม่สอดคล้องกับ A จากกรด
  2. MongoDB เป็นConsitent โดยค่าเริ่มต้น อย่างไรก็ตามคุณสามารถอ่านจากเซิร์ฟเวอร์รองในชุดแบบจำลอง คุณสามารถมีความสอดคล้องในที่สุดในกรณีนี้ สิ่งนี้มีประโยชน์หากคุณไม่ต้องการอ่านข้อมูลที่ล้าสมัยเล็กน้อย
  3. MongoDB ไม่รับประกันการIsolation (อีกครั้งตามคำนิยามข้างต้น):
  1. สำหรับระบบที่มีตัวอ่านและตัวเขียนพร้อมกันหลายตัว MongoDB จะอนุญาตให้ไคลเอ็นต์อ่านผลลัพธ์ของการดำเนินการเขียนก่อนที่การดำเนินการเขียนจะกลับมา
  2. หาก mongod สิ้นสุดก่อนที่เจอร์นัลจะส่งถึงแม้ว่าการเขียนจะส่งคืนสำเร็จเคียวรีอาจอ่านข้อมูลที่จะไม่มีอยู่หลังจากที่ mongod รีสตาร์ท

อย่างไรก็ตาม MongoDB แก้ไขเอกสารแต่ละรายการแยก (สำหรับส่วนแทรกและอัพเดต) ในระดับเอกสารเท่านั้นไม่ได้อยู่ในการทำธุรกรรมหลายเอกสาร

  1. ในเรื่องที่เกี่ยวกับความสามารถใช้งานได้D- คุณสามารถกำหนดค่าพฤติกรรมนี้ด้วยwrite concernตัวเลือก แต่ไม่แน่ใจ อาจจะมีคนรู้ดีกว่า

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


4

เหตุผลเดียวที่ทำให้การดัดแปลงอะตอมมิกเซอร์กับคอลเลคชั่นเดี่ยวเป็นเพราะนักพัฒนา mongodb เพิ่งแลกเปลี่ยนล็อกฐานข้อมูลกับคอลเลกชันการเขียนล็อกกว้าง การตัดสินใจว่าการเห็นพ้องด้วยกันที่เพิ่มขึ้นในที่นี้คุ้มค่ากับการแลกเปลี่ยน ที่เป็นแกนหลัก mongodb เป็นไฟล์ที่แม็พหน่วยความจำ: พวกเขาได้มอบหมายการจัดการบัฟเฟอร์พูลให้กับระบบย่อย vm ของเครื่อง เพราะมันอยู่ในหน่วยความจำเสมอพวกเขาสามารถออกไปได้ด้วยการล็อคเม็ดเล็ก ๆ อย่างแน่นอน: คุณจะทำการดำเนินการในหน่วยความจำเพียงอย่างเดียวในขณะที่ถือมันซึ่งจะเร็วมาก สิ่งนี้แตกต่างจากระบบฐานข้อมูลแบบดั้งเดิมซึ่งบางครั้งถูกบังคับให้ใช้ I / O ในขณะที่ถือ pagelock หรือ rowlock


คุณช่วยอธิบายได้ไหมว่าทำไมการทำงานพร้อมกันนี้เพิ่มขึ้น ขออภัยหากฉันพลาดที่นี่อย่างชัดเจน
batbrat

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

2

"ใน MongoDB การดำเนินการกับเอกสารเดียวคืออะตอม" - นั่นคือสิ่งที่ผ่านมาแล้ว

ใน MongoDB 4.0เวอร์ชั่นใหม่คุณสามารถ:

อย่างไรก็ตามสำหรับสถานการณ์ที่ต้องการ atomicity สำหรับการอัปเดตไปยังเอกสารหลายฉบับหรือความสอดคล้องกันระหว่างการอ่านไปยังเอกสารหลายฉบับ MongoDB ให้ความสามารถในการทำธุรกรรมหลายเอกสารกับชุดแบบจำลอง การทำธุรกรรมหลายเอกสารสามารถนำมาใช้ในการดำเนินงานหลายคอลเลกชันฐานข้อมูลและเอกสาร การทำธุรกรรมหลายเอกสารให้ข้อเสนอ“ all-or-nothing” เมื่อมีการทำธุรกรรมการเปลี่ยนแปลงข้อมูลทั้งหมดในการทำธุรกรรมจะถูกบันทึกไว้ หากการดำเนินการใด ๆ ในธุรกรรมล้มเหลวธุรกรรมจะถูกยกเลิกและการเปลี่ยนแปลงข้อมูลทั้งหมดที่เกิดขึ้นในธุรกรรมจะถูกยกเลิก จนกว่าการทำธุรกรรมจะไม่ปรากฏการดำเนินการเขียนในการทำธุรกรรมนอกการทำธุรกรรม

แม้ว่าจะมีข้อ จำกัด เล็กน้อยสำหรับการดำเนินการอย่างไรและอะไรที่สามารถทำได้

ตรวจสอบ Mongo Doc https://docs.mongodb.com/master/core/transactions/


1

คุณสามารถใช้การอัปเดตหลายอะตอมมิกคีย์ (ธุรกรรมที่ทำให้เป็นอนุกรม) ในฝั่งไคลเอ็นต์หากหน่วยเก็บข้อมูลของคุณรองรับการทำงานแบบ linearizability ของคีย์และเปรียบเทียบและตั้งค่า (ซึ่งเป็นจริงสำหรับ MongoDB) วิธีการนี้ใช้ในPercolator ของ GoogleและในCockroachDBแต่ไม่มีอะไรป้องกันคุณจากการใช้ MongoDB

ฉันสร้างการสร้างภาพข้อมูลเป็นขั้นเป็นตอนของการทำธุรกรรมดังกล่าว ฉันหวังว่ามันจะช่วยให้คุณเข้าใจพวกเขา

หากคุณพอใจกับระดับความมุ่งมั่นในการอ่านที่แยกต่างหากจากนั้นคุณควรพิจารณาการทำธุรกรรม RAMPของ Peter Bailis พวกเขายังสามารถนำมาใช้สำหรับ MongoDB ในฝั่งไคลเอ็นต์

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.