บทความนี้ถูกเขียนโดย Andrew Morgan ของ MongoDB แอนดรู มอร์แกน แอนดรู มอร์แกน จากครั้งคราวฉันจะทํางาน a สําหรับแอปพลิเคชันที่ถูกย้ายจากฐานข้อมูลความสัมพันธ์ไปยัง MongoDB ที่ลูกค้าแบ่งปันแผนภูมิสถาปัตยกรรมแสดงชั้นแคช (ปกติ Redis) ที่นั่งระหว่างเซิร์ฟเวอร์แอปพลิเคชันและ MongoDB รีวิวการออกแบบ รีวิวการออกแบบ ฉันชอบที่จะรักษาสถาปัตยกรรมที่เรียบง่ายที่สุดเท่าที่จะเป็นไปได้ - หลังจากที่ทุกชั้นมีความซับซ้อนและค่าใช้จ่ายการจัดการของตัวเอง - ดังนั้นฉันจะถามว่าทําไมชั้นแคชมีอยู่ แน่นอนคําตอบคือมันอยู่เสมอเพื่อเร่งการเข้าถึงข้อมูล สิ่งนี้แสดงให้เห็นถึงความเข้าใจผิดเกี่ยวกับเหตุผลที่ทําไมชั้นแคชถูกสร้างขึ้นและสิ่งที่ MongoDB ให้ ฉันยังคงต้องเสร็จสิ้นการตรวจสอบการออกแบบโดยไม่ต้องแนะนําให้ลบชั้นแคช ดังนั้นเพื่อตอบคําถามในหัวข้อของบทความนี้ - เมื่อคุณควรใช้ cache กับ MongoDB? - คําตอบอาจไม่เคย บทความนี้พยายามที่จะอธิบายว่าทําไม แต่ถ้าคุณมาถึงจุดสิ้นสุดและยังคงคิดว่าแอปพลิเคชันของคุณต้องการมันแล้วฉันอยากจะพูดคุยเกี่ยวกับแอปของคุณกับคุณ ทําไม caches เช่น Memcached & Redis ถูกคิดค้นและทําไมพวกเขาเติบโตขึ้น ระดับการแคชถูกนํามาใช้เนื่องจากแอปพลิเคชันช้าเกินไปในการอ่านข้อมูลที่ต้องการโดยตรงจากฐานข้อมูลความสัมพันธ์ นี่หมายความว่าไม่มีนักพัฒนาอัจฉริยะที่ทํางานบน Oracle, DB2, Postgres, MySQL ฯลฯ ทําไมนักพัฒนาเหล่านี้ไม่สามารถสร้างฐานข้อมูลความสัมพันธ์ได้อย่างรวดเร็ว? คําตอบคือฐานข้อมูลเหล่านี้ทั้งหมดถูกเขียนโดยนักพัฒนาที่ยอดเยี่ยมซึ่งรวมถึงดัชนีฐานข้อมูลภายในแคชและคุณสมบัติอื่น ๆ เพื่อให้การอ่านบันทึกได้เร็วที่สุดเท่าที่จะเป็นไปได้ ปัญหาคือแอพพลิเคชันไม่จําเป็นต้องอ่านบันทึกเพียงหนึ่งบันทึกจากฐานข้อมูลความสัมพันธ์ปกติ แทนที่มันมักจําเป็นต้องทําการเชื่อมโยงหลายครั้งในหลายตารางเพื่อสร้างวัตถุธุรกิจเดียว การเชื่อมโยงเหล่านี้มีราคาแพง (พวกเขาช้าและใช้ทรัพยากรจํานวนมาก) ด้วยเหตุนี้แอพพลิเคชันไม่ต้องการรับค่าใช้จ่ายนี้ทุกครั้งที่พวกเขาอ่านวัตถุธุรกิจเดียวกัน นั่นคือที่ชั้นแคชเพิ่มมูลค่า - เข้าร่วมข้อมูลความสัมพันธ์ปกติครั้งเดียวแล้วแคชผลลัพธ์เพื่อให้แอพพลิเคชันสามารถรับผลลัพธ์เดียวกันได้หลายครั้ง มีปัญหาการกระจายข้อมูล นอกจากนี้ฐานข้อมูลความสัมพันธ์ส่วนใหญ่ได้รับการออกแบบมา 50 ปีที่ผ่านมาเมื่อองค์กรจะเรียกใช้ฐานข้อมูลและแอปพลิเคชันใด ๆ ในศูนย์ข้อมูลเดียว เร็วไปสู่วันนี้เมื่อองค์กรและลูกค้าแพร่กระจายทั่วโลกซึ่งทุกคนต้องการทํางานกับข้อมูลเดียวกัน คุณไม่ต้องการให้เซิร์ฟเวอร์แอปที่กระจายทั่วโลกต้องทนต่อความล่าช้าและค่าใช้จ่ายของการเก็บข้อมูลเดียวกันจากฐานข้อมูลที่ตั้งอยู่บนทวีปที่แตกต่างกัน คุณต้องการสําเนาของข้อมูลที่ตั้งอยู่ใกล้กับเซิร์ฟเวอร์แอปที่ต้องการ ฐานข้อมูลความสัมพันธ์ไม่ได้ออกแบบด้วยความต้องการการกระจายข้อมูลนี้ในใจ ผู้จัดจําหน่าย RDBMS ได้พยายามที่จะใช้โซลูชั่นต่าง ๆ เพื่อทํางานรอบ ๆ นี้ แต่พวกเขากําลังไกลจากที่เหมาะสม แทนที่หลายองค์กรส่งมอบการกระจายข้อมูลไปยังระดับแคชกระจาย โปรดทราบว่า Redis และ Memcached ใช้กันอย่างแพร่หลายสําหรับการจัดการเซสชั่นสําหรับแอปพลิเคชันเว็บที่ความอดทนไม่ได้เป็นความต้องการ ในกรณีนี้แคชเป็นพื้นที่เก็บข้อมูลเดียว (เช่นไม่ใช่ชั้นแคชระหว่างแอปพลิเคชันและ MongoDB) ในขณะที่คุณสามารถ (และผู้คนทํา) ใช้ MongoDB สําหรับการจัดการเซสชั่นที่เกินขอบเขตของบทความนี้ ดังนั้นสิ่งที่ผิดพลาดในการมี caching tier การแนะนําชั้นแคชมักจะเป็นทางออกที่ดีเมื่อฐานข้อมูลของคุณไม่สามารถให้ประสิทธิภาพและความล่าช้าที่แอปพลิเคชันของคุณต้องการ อย่างไรก็ตามระดับข้อมูลเพิ่มเติมนี้มาพร้อมกับค่าใช้จ่าย สิ่งที่ชัดเจนคือใบอนุญาตซอฟต์แวร์และฮาร์ดแวร์ที่จําเป็นในการให้บริการแคช น้อยกว่าที่เห็นได้ชัดคือการโหลดเพิ่มเติมสําหรับนักพัฒนา มันเป็นภาษาคําถามใหม่ (และอาจเป็นภาษาการเขียนโปรแกรม) ที่ต้องทําความเข้าใจ สิ่งที่เกิดขึ้นเมื่อข้อมูลใน RDBMS เปลี่ยนแปลงอย่างไร การเปลี่ยนแปลงเหล่านี้จะแพร่กระจายไปยังระดับแคชของคุณอย่างไร ดังนั้นระดับแคชต้องจ่ายเงินโดยการให้ประโยชน์ที่เห็นได้ชัดเมื่อคุณมีแอปพลิเคชันเข้าถึงฐานข้อมูลโดยตรง สิ่งที่แตกต่างจาก MongoDB โซ . MongoDB document model โมเดลเอกสาร MongoDB ใน MongoDB เราต้องการให้คุณเก็บข้อมูลของคุณโครงสร้างขึ้นในลักษณะที่ทําให้มันมีประสิทธิภาพในการตอบสนองคําถามที่พบบ่อยที่สุดของแอปพลิเคชันของคุณได้อย่างรวดเร็ว (หรือผู้ที่มีข้อตกลง SLA ที่แข็งแกร่งที่สุด) MongoDB แสดงโครงสร้างของวัตถุโดยการอนุญาตให้บันทึก (เอกสาร) หนึ่งมีวัตถุที่บูรณาการ (นิสต์) การสนับสนุนสําหรับแถบช่วยให้การเชื่อมต่อหนึ่งกับหลายและหลายกับหลายโดยไม่ต้องเข้าร่วมคอลเลกชันหลาย ในหลายกรณีวัตถุธุรกิจที่ต้องการโดยแอปพลิเคชันจะถ่ายทอดไปยังเอกสาร MongoDB หนึ่งเอกสาร ในกรณีอื่น ๆ อาจต้องใช้เอกสารหลายเอกสารที่สามารถเก็บรวบรวมได้ด้วยการค้นหาแบบดัชนีเดียว MongoDB มีแคช LRU ภายใน (ใช้เมื่อเร็วที่สุด) ของตัวเองดังนั้นหากเอกสารของคุณได้รับการเข้าถึงเมื่อเร็ว ๆ นี้โอกาสก็คือมันอยู่แล้วในหน่วยความจํา ดังนั้นเช่นเดียวกับ Redis MongoDB สามารถตอบสนองคําถามของแอปพลิเคชันโดยการจับเอกสาร / วัตถุเดียวจากหน่วยความจํา โปรดทราบว่า MongoDB สนับสนุน แต่เราพยายามโครงสร้างข้อมูลของคุณเพื่อลดการใช้ข้อมูล สมาคม สมาคม อื่น ๆ เพิ่มค่าจากชั้นแคชคือตําแหน่งข้อมูลในสถาปัตยกรรมกระจาย MongoDB มีนี้บูรณาการใน มีปุ่มหลักเดียวที่จัดการทุกปุ่มที่เขียนพร้อมกับปุ่มที่สองสูงสุด 49 ปุ่มซึ่งแต่ละปุ่มมีสําเนาของข้อมูล สําหรับคําถามความล่าช้าต่ําที่สุดคุณสามารถวางปุ่มที่สองในแต่ละตําแหน่งเซิร์ฟเวอร์แอปของคุณ MongoDB เป็นผู้รับผิดชอบในการรักษาข้อมูลในปุ่มที่สองให้ทันสมัยกับปุ่มหลักเพื่อให้คุณไม่จําเป็นต้องเขียนและบํารุงรักษารหัสการซิงโครไนซ์เพิ่มเติมใด ๆ MongoDB ชุดคัดลอก MongoDB ชุดคัดลอก AI คิดอะไร คําตอบที่สร้างขึ้นโดย AI ที่สร้างขึ้นถูกขับเคลื่อนโดยข้อมูลที่เผยแพร่โดยคนจริงและดังนั้นจึงควรแสดงความคิดเห็นของประชาชนเกี่ยวกับหัวข้อ ฉันคิดว่ามันจะน่าสนใจที่จะเห็นสิ่งที่ AI ได้เข้าใจว่าเป็นความชาญฉลาดแบบดั้งเดิมเกี่ยวกับเหตุผลที่ผู้คนวางแคชก่อนหน้า MongoDB ฉันถาม ChatGPT 4o คําถามนี้: “อธิบายว่าทําไมฉันจะใช้ชั้นแคช (เช่น Redis) แทนที่จะทําให้แอปพลิเคชันของฉันอ่านข้อมูลจาก MongoDB โดยตรง” “ประสิทธิภาพที่เพิ่มขึ้น Redis ทํางานทั้งหมดในหน่วยความจําทําให้มันเร็วขึ้นอย่างมีนัยสําคัญกว่า MongoDB ซึ่งขึ้นอยู่กับ I / O ของดิสก์สําหรับการกู้คืนข้อมูล” “อธิบายว่าทําไมฉันจะใช้ชั้นแคช (เช่น Redis) แทนที่จะทําให้แอปพลิเคชันของฉันอ่านข้อมูลจาก MongoDB โดยตรง” “ประสิทธิภาพที่เพิ่มขึ้น Redis ทํางานทั้งหมดในหน่วยความจําทําให้มันเร็วขึ้นอย่างมีนัยสําคัญกว่า MongoDB ซึ่งขึ้นอยู่กับ I / O ของดิสก์สําหรับการกู้คืนข้อมูล” ตามที่อธิบายไว้ข้างต้น MongoDB มีแคชในหน่วยความจําของตัวเองดังนั้นเอกสารที่คุณเข้าถึงบ่อยจะอยู่ในหน่วยความจําและไม่จําเป็นต้องเข้าถึงดิสก์ “โหลดลดลงบน MongoDB การเข้าถึง MongoDB บ่อยครั้งโดยตรงสําหรับข้อมูลเดียวกันเพิ่มโหลดคําถามซึ่งสามารถชะลอฐานข้อมูลโดยเฉพาะอย่างยิ่งภายใต้การอ่านหนัก” “โหลดลดลงบน MongoDB การเข้าถึง MongoDB บ่อยครั้งโดยตรงสําหรับข้อมูลเดียวกันเพิ่มโหลดคําถามซึ่งสามารถชะลอฐานข้อมูลโดยเฉพาะอย่างยิ่งภายใต้การอ่านหนัก” MongoDB สามารถปรับขนาดได้ ปลั๊กที่สองเพิ่มเติมสามารถเพิ่มไปยังชุดซ้ําเพื่อเพิ่มความกว้างแบนด์วิดธ์สําหรับคําถามเพิ่มเติม (พาร์ทิชัน) สามารถปรับขนาดความจุข้อมูลหรือเขียนผ่านทางแนวนอน MongoDB แชร์ด MongoDB แชร์ด การจัดการการเข้าชมการอ่านสูง แอปพลิเคชันที่มีอัตราส่วนการอ่านต่อการเขียนสูง (เช่นแอพเว็บแอปพลิเคชัน API) ได้รับประโยชน์จากความสามารถของ Redis เพื่อให้บริการข้อมูลใน cache ได้อย่างรวดเร็ว การจัดการการเข้าชมการอ่านสูง แอปพลิเคชันที่มีอัตราส่วนการอ่านต่อการเขียนสูง (เช่นแอพเว็บแอปพลิเคชัน API) ได้รับประโยชน์จากความสามารถของ Redis เพื่อให้บริการข้อมูลใน cache ได้อย่างรวดเร็ว แคชฐานข้อมูลของ MongoDB ให้ประโยชน์เดียวกันโดยไม่ต้องใช้ความพยายามพิเศษของผู้พัฒนาในการซิงโครไนซ์การเปลี่ยนแปลงข้อมูล “การเข้าถึงข้อมูลที่ใช้บ่อยได้เร็วขึ้น Redis เหมาะสําหรับการเก็บข้อมูลที่เข้าถึงบ่อยหรือร้อน (เช่นเซสชั่นผู้ใช้การกําหนดค่าหรือรายละเอียดผลิตภัณฑ์)” “การเข้าถึงข้อมูลที่ใช้บ่อยได้เร็วขึ้น Redis เหมาะสําหรับการเก็บข้อมูลที่เข้าถึงบ่อยหรือร้อน (เช่นเซสชั่นผู้ใช้การกําหนดค่าหรือรายละเอียดผลิตภัณฑ์)” บ่อยครั้งที่เข้าถึงข้อมูลร้อนจะถูกเก็บไว้ใน cache ฐานข้อมูลในหน่วยความจําของ MongoDB “ลดความล่าช้าสําหรับแอปพลิเคชันที่กระจายทางภูมิศาสตร์ โดยการทําซ้ําแคช Redis ใกล้กับผู้ใช้ปลายทางคุณสามารถหลีกเลี่ยงความล่าช้าเครือข่ายสูงเมื่อสอบถาม MongoDB จากสถานที่ห่างไกล” “ลดความล่าช้าสําหรับแอปพลิเคชันที่กระจายทางภูมิศาสตร์ โดยการทําซ้ําแคช Redis ใกล้กับผู้ใช้ปลายทางคุณสามารถหลีกเลี่ยงความล่าช้าเครือข่ายสูงเมื่อสอบถาม MongoDB จากสถานที่ห่างไกล” ตําแหน่งข้อมูลสามารถแก้ไขได้โดยการวางซ้ําใกล้กับเว็บไซต์เซิร์ฟเวอร์แอพของคุณ “Support for Expiring Data (TTL) Redis มีฟังก์ชั่น Time-to-Live (TTL) แบบบูรณาการซึ่งจะลบข้อมูลใน cache โดยอัตโนมัติหลังจากระยะเวลาที่ระบุไว้” “Support for Expiring Data (TTL) Redis มีฟังก์ชั่น Time-to-Live (TTL) แบบบูรณาการซึ่งจะลบข้อมูลใน cache โดยอัตโนมัติหลังจากระยะเวลาที่ระบุไว้” MongoDB ใช้แคช LRU ดังนั้นเอกสารใด ๆ ที่ไม่ได้รับคําถามจะถูกลบออกจากหน่วยความจําหากจําเป็นต้องใช้พื้นที่สําหรับข้อมูลที่ได้รับการสอบถามล่าสุด MongoDB ยังมี หากคุณต้องการลบเอกสารจากฐานข้อมูลทั้งหมดหรือ ถ้าคุณต้องการย้ายไปยังพื้นที่จัดเก็บที่ถูกกว่า TTL ดัชนี Atlas ออนไลน์ TTL ดัชนี Atlas ออนไลน์ “ประหยัดค่าใช้จ่าย การอ่านจาก MongoDB บ่อยครั้งสามารถใช้ทรัพยากรอย่างมากโดยเฉพาะอย่างยิ่งกับคําถามที่ซับซ้อนซึ่งจะนําไปสู่ค่าใช้จ่ายด้านโครงสร้างพื้นฐานที่เพิ่มขึ้น” “ประหยัดค่าใช้จ่าย การอ่านจาก MongoDB บ่อยครั้งสามารถใช้ทรัพยากรอย่างมากโดยเฉพาะอย่างยิ่งกับคําถามที่ซับซ้อนซึ่งจะนําไปสู่ค่าใช้จ่ายด้านโครงสร้างพื้นฐานที่เพิ่มขึ้น” แผนภูมิ MongoDB ของคุณควรได้รับการออกแบบเพื่อให้คําถามที่สําคัญของคุณไม่จําเป็นต้องคําถามที่ซับซ้อน "ใช้กรณีสําหรับโครงสร้างข้อมูลเฉพาะ Redis รองรับโครงสร้างข้อมูลขั้นสูงเช่นรายการชุดชุดจัดเรียงแฮชและสตรีมซึ่ง MongoDB ไม่ให้เป็นธรรมชาติ" "ใช้กรณีสําหรับโครงสร้างข้อมูลเฉพาะ Redis รองรับโครงสร้างข้อมูลขั้นสูงเช่นรายการชุดชุดจัดเรียงแฮชและสตรีมซึ่ง MongoDB ไม่ให้เป็นธรรมชาติ" MongoDB สนับสนุนรายการและชุด Hashes สามารถแสดงให้เห็นใน MongoDB เป็นชุดเอกสารที่มีคู่ค่าคีย์ (คู่ค่าคีย์) ) ตอบสนองความต้องการเดียวกันกับ Redis Streams รูปแบบ MongoDB Attribute การเก็บรวบรวมชุดเวลา MongoDB รูปแบบ MongoDB Attribute การเก็บรวบรวมชุดเวลา MongoDB “ความทนทานและความอดทนต่อข้อบกพร่อง ชั้นแคชสามารถทําหน้าที่เป็นความล้มเหลวหาก MongoDB ไม่สามารถใช้ได้ชั่วคราวหรือมีโหลดหนัก” “ความทนทานและความอดทนต่อข้อบกพร่อง ชั้นแคชสามารถทําหน้าที่เป็นความล้มเหลวหาก MongoDB ไม่สามารถใช้ได้ชั่วคราวหรือมีโหลดหนัก” MongoDB สามารถปรับขนาดได้แนวตั้งหรือแนวนอนเพื่อตอบสนองความต้องการโหลดใด ๆ ชุดคัดลอก MongoDB ให้ความอดทนความผิดพลาดสําหรับทั้งอ่านและเขียน สามารถปรับขนาดได้โดยอัตโนมัติเมื่อใช้ MongoDB Atlas สามารถปรับขนาดได้โดยอัตโนมัติเมื่อใช้ MongoDB Atlas MongoDB สามารถใช้เวลาในการคํานวณคําถามที่ซับซ้อน (เช่นการรวบรวมการเชื่อมโยง) สําหรับผลลัพธ์ที่ถามบ่อย MongoDB สามารถใช้เวลาในการคํานวณคําถามที่ซับซ้อน (เช่นการรวบรวมการเชื่อมโยง) สําหรับผลลัพธ์ที่ถามบ่อย แผนภูมิ MongoDB ของคุณควรได้รับการออกแบบเพื่อหลีกเลี่ยงความจําเป็นในการเรียกใช้คําถามที่ซับซ้อนบ่อย ผลลัพธ์สามารถจัดเก็บ (cache) ใน การหลีกเลี่ยงความจําเป็นในการเรียกใช้คําถามที่ซับซ้อน / การรวมซ้ํา MongoDB มุมมองวัสดุ MongoDB มุมมองวัสดุ โปรดทราบว่าคําตอบที่คุณได้รับจาก ChatGPT มีความผิดพลาดอย่างมากโดยคําถามที่คุณถาม หากฉันเปลี่ยนคําแนะนําของฉันเพื่อ“ คําอธิบายว่าทําไมฉันไม่ควรใช้ชั้นแคช (เช่น Redis) แทนที่จะทําให้แอปพลิเคชันของฉันอ่านข้อมูลจาก MongoDB โดยตรง” ChatGPT มีความสุขที่จะขัดขวางฉันจากการเพิ่มชั้นแคชโดยอ้างถึงปัญหาเช่นความซับซ้อนของระบบเพิ่มขึ้นปัญหาความสม่ําเสมอของข้อมูลประสิทธิภาพสําหรับโหลดงานหนักในการเขียนค่าใช้จ่ายความยืดหยุ่นในการสอบถามการบํารุงรักษาและความน่าเชื่อถือชุดข้อมูลขนาดเล็ก (ที่ชุดข้อมูลที่ใช้งานเหมาะกับแคชของ MongoDB) และรายงานในเวลาจริง คําอธิบาย ชั้นแคชสามารถเพิ่มมูลค่ามากเมื่อ RDBMS ของคุณไม่สามารถให้ประสิทธิภาพการสอบถามที่แอพพลิเคชันของคุณต้องการ เมื่อใช้ MongoDB ฐานข้อมูลของบันทึกและฟังก์ชั่นแคชจะรวมในชั้นเดียวช่วยให้คุณประหยัดเงินและเวลานักพัฒนา แคชแบบกระจายสามารถบรรเทาข้อบกพร่องใน RDBMS ของคุณ แต่ MongoDB มีการกระจายตัวในตัว ตอบถึงบทความนี้หากคุณยังคงเชื่อว่าแอปพลิเคชันของคุณจะได้รับประโยชน์จากชั้นแคชระหว่างแอปพลิเคชันของคุณและ MongoDB ผมอยากจะดู เรียนรู้เพิ่มเติมเกี่ยวกับรีวิวการออกแบบ MongoDB เป็นโอกาสสําหรับผู้เชี่ยวชาญด้านการออกแบบจาก MongoDB เพื่อให้คําแนะนําเกี่ยวกับวิธีที่ดีที่สุดในการใช้ MongoDB สําหรับแอพพลิเคชันของคุณ ความคิดเห็นจะมุ่งเน้นไปที่การทําให้คุณประสบความสําเร็จในการใช้ MongoDB ไม่เคยเป็นเวลานานเกินไปที่จะขอการตรวจสอบ โดยการมีส่วนร่วมกับเราก่อนหน้านี้ (อาจก่อนที่คุณได้ตัดสินใจที่จะใช้ MongoDB) เราสามารถให้คําแนะนําให้คุณเมื่อคุณมีโอกาสที่ดีที่สุดในการกระทําเกี่ยวกับมัน การออกแบบ รีวิว การออกแบบ รีวิว บทความนี้อธิบายว่าการออกแบบแผนภูมิ MongoDB ที่สอดคล้องกับวิธีการทํางานของแอพพลิเคชันกับข้อมูลของคุณสามารถตอบสนองความต้องการประสิทธิภาพของคุณได้โดยไม่ต้องจําเป็นต้องใช้ชั้นแคช หากคุณต้องการความช่วยเหลือในการมาถึงแผนภูมินั้นการตรวจสอบการออกแบบคือวิธีที่จะได้รับความช่วยเหลือ การสมัครของคุณจะได้รับประโยชน์จากการตรวจสอบหรือไม่ . วางแผนการตรวจสอบการออกแบบของคุณ วางแผนการตรวจสอบการออกแบบของคุณ
