บทความนี้ถูกเขียนโดย Andrew Morgan ของ MongoDB
จากครั้งคราวฉันจะทํางาน a
ฉันชอบที่จะรักษาสถาปัตยกรรมที่เรียบง่ายที่สุดเท่าที่จะเป็นไปได้ - หลังจากที่ทุกชั้นมีความซับซ้อนและค่าใช้จ่ายการจัดการของตัวเอง - ดังนั้นฉันจะถามว่าทําไมชั้นแคชมีอยู่ แน่นอนคําตอบคือมันอยู่เสมอเพื่อเร่งการเข้าถึงข้อมูล สิ่งนี้แสดงให้เห็นถึงความเข้าใจผิดเกี่ยวกับเหตุผลที่ทําไมชั้นแคชถูกสร้างขึ้นและสิ่งที่ MongoDB ให้
ฉันยังคงต้องเสร็จสิ้นการตรวจสอบการออกแบบโดยไม่ต้องแนะนําให้ลบชั้นแคช
ดังนั้นเพื่อตอบคําถามในหัวข้อของบทความนี้ - เมื่อคุณควรใช้ cache กับ MongoDB? - คําตอบอาจไม่เคย บทความนี้พยายามที่จะอธิบายว่าทําไม แต่ถ้าคุณมาถึงจุดสิ้นสุดและยังคงคิดว่าแอปพลิเคชันของคุณต้องการมันแล้วฉันอยากจะพูดคุยเกี่ยวกับแอปของคุณกับคุณ
ทําไม caches เช่น Memcached & Redis ถูกคิดค้นและทําไมพวกเขาเติบโตขึ้น
ระดับการแคชถูกนํามาใช้เนื่องจากแอปพลิเคชันช้าเกินไปในการอ่านข้อมูลที่ต้องการโดยตรงจากฐานข้อมูลความสัมพันธ์
นี่หมายความว่าไม่มีนักพัฒนาอัจฉริยะที่ทํางานบน Oracle, DB2, Postgres, MySQL ฯลฯ ทําไมนักพัฒนาเหล่านี้ไม่สามารถสร้างฐานข้อมูลความสัมพันธ์ได้อย่างรวดเร็ว? คําตอบคือฐานข้อมูลเหล่านี้ทั้งหมดถูกเขียนโดยนักพัฒนาที่ยอดเยี่ยมซึ่งรวมถึงดัชนีฐานข้อมูลภายในแคชและคุณสมบัติอื่น ๆ เพื่อให้การอ่านบันทึกได้เร็วที่สุดเท่าที่จะเป็นไปได้
ปัญหาคือแอพพลิเคชันไม่จําเป็นต้องอ่านบันทึกเพียงหนึ่งบันทึกจากฐานข้อมูลความสัมพันธ์ปกติ แทนที่มันมักจําเป็นต้องทําการเชื่อมโยงหลายครั้งในหลายตารางเพื่อสร้างวัตถุธุรกิจเดียว การเชื่อมโยงเหล่านี้มีราคาแพง (พวกเขาช้าและใช้ทรัพยากรจํานวนมาก) ด้วยเหตุนี้แอพพลิเคชันไม่ต้องการรับค่าใช้จ่ายนี้ทุกครั้งที่พวกเขาอ่านวัตถุธุรกิจเดียวกัน นั่นคือที่ชั้นแคชเพิ่มมูลค่า - เข้าร่วมข้อมูลความสัมพันธ์ปกติครั้งเดียวแล้วแคชผลลัพธ์เพื่อให้แอพพลิเคชันสามารถรับผลลัพธ์เดียวกันได้หลายครั้ง
มีปัญหาการกระจายข้อมูล นอกจากนี้ฐานข้อมูลความสัมพันธ์ส่วนใหญ่ได้รับการออกแบบมา 50 ปีที่ผ่านมาเมื่อองค์กรจะเรียกใช้ฐานข้อมูลและแอปพลิเคชันใด ๆ ในศูนย์ข้อมูลเดียว เร็วไปสู่วันนี้เมื่อองค์กรและลูกค้าแพร่กระจายทั่วโลกซึ่งทุกคนต้องการทํางานกับข้อมูลเดียวกัน คุณไม่ต้องการให้เซิร์ฟเวอร์แอปที่กระจายทั่วโลกต้องทนต่อความล่าช้าและค่าใช้จ่ายของการเก็บข้อมูลเดียวกันจากฐานข้อมูลที่ตั้งอยู่บนทวีปที่แตกต่างกัน คุณต้องการสําเนาของข้อมูลที่ตั้งอยู่ใกล้กับเซิร์ฟเวอร์แอปที่ต้องการ
ฐานข้อมูลความสัมพันธ์ไม่ได้ออกแบบด้วยความต้องการการกระจายข้อมูลนี้ในใจ ผู้จัดจําหน่าย RDBMS ได้พยายามที่จะใช้โซลูชั่นต่าง ๆ เพื่อทํางานรอบ ๆ นี้ แต่พวกเขากําลังไกลจากที่เหมาะสม แทนที่หลายองค์กรส่งมอบการกระจายข้อมูลไปยังระดับแคชกระจาย
โปรดทราบว่า Redis และ Memcached ใช้กันอย่างแพร่หลายสําหรับการจัดการเซสชั่นสําหรับแอปพลิเคชันเว็บที่ความอดทนไม่ได้เป็นความต้องการ ในกรณีนี้แคชเป็นพื้นที่เก็บข้อมูลเดียว (เช่นไม่ใช่ชั้นแคชระหว่างแอปพลิเคชันและ MongoDB) ในขณะที่คุณสามารถ (และผู้คนทํา) ใช้ MongoDB สําหรับการจัดการเซสชั่นที่เกินขอบเขตของบทความนี้
ดังนั้นสิ่งที่ผิดพลาดในการมี caching tier
การแนะนําชั้นแคชมักจะเป็นทางออกที่ดีเมื่อฐานข้อมูลของคุณไม่สามารถให้ประสิทธิภาพและความล่าช้าที่แอปพลิเคชันของคุณต้องการ
อย่างไรก็ตามระดับข้อมูลเพิ่มเติมนี้มาพร้อมกับค่าใช้จ่าย สิ่งที่ชัดเจนคือใบอนุญาตซอฟต์แวร์และฮาร์ดแวร์ที่จําเป็นในการให้บริการแคช
น้อยกว่าที่เห็นได้ชัดคือการโหลดเพิ่มเติมสําหรับนักพัฒนา มันเป็นภาษาคําถามใหม่ (และอาจเป็นภาษาการเขียนโปรแกรม) ที่ต้องทําความเข้าใจ สิ่งที่เกิดขึ้นเมื่อข้อมูลใน RDBMS เปลี่ยนแปลงอย่างไร การเปลี่ยนแปลงเหล่านี้จะแพร่กระจายไปยังระดับแคชของคุณอย่างไร
ดังนั้นระดับแคชต้องจ่ายเงินโดยการให้ประโยชน์ที่เห็นได้ชัดเมื่อคุณมีแอปพลิเคชันเข้าถึงฐานข้อมูลโดยตรง
สิ่งที่แตกต่างจาก MongoDB
โมเดลเอกสาร MongoDB
ใน MongoDB เราต้องการให้คุณเก็บข้อมูลของคุณโครงสร้างขึ้นในลักษณะที่ทําให้มันมีประสิทธิภาพในการตอบสนองคําถามที่พบบ่อยที่สุดของแอปพลิเคชันของคุณได้อย่างรวดเร็ว (หรือผู้ที่มีข้อตกลง SLA ที่แข็งแกร่งที่สุด) MongoDB แสดงโครงสร้างของวัตถุโดยการอนุญาตให้บันทึก (เอกสาร) หนึ่งมีวัตถุที่บูรณาการ (นิสต์) การสนับสนุนสําหรับแถบช่วยให้การเชื่อมต่อหนึ่งกับหลายและหลายกับหลายโดยไม่ต้องเข้าร่วมคอลเลกชันหลาย
ในหลายกรณีวัตถุธุรกิจที่ต้องการโดยแอปพลิเคชันจะถ่ายทอดไปยังเอกสาร MongoDB หนึ่งเอกสาร ในกรณีอื่น ๆ อาจต้องใช้เอกสารหลายเอกสารที่สามารถเก็บรวบรวมได้ด้วยการค้นหาแบบดัชนีเดียว
MongoDB มีแคช LRU ภายใน (ใช้เมื่อเร็วที่สุด) ของตัวเองดังนั้นหากเอกสารของคุณได้รับการเข้าถึงเมื่อเร็ว ๆ นี้โอกาสก็คือมันอยู่แล้วในหน่วยความจํา ดังนั้นเช่นเดียวกับ Redis 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 สามารถปรับขนาดได้ ปลั๊กที่สองเพิ่มเติมสามารถเพิ่มไปยังชุดซ้ําเพื่อเพิ่มความกว้างแบนด์วิดธ์สําหรับคําถามเพิ่มเติม
การจัดการการเข้าชมการอ่านสูง แอปพลิเคชันที่มีอัตราส่วนการอ่านต่อการเขียนสูง (เช่นแอพเว็บแอปพลิเคชัน 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 ยังมี
“ประหยัดค่าใช้จ่าย การอ่านจาก MongoDB บ่อยครั้งสามารถใช้ทรัพยากรอย่างมากโดยเฉพาะอย่างยิ่งกับคําถามที่ซับซ้อนซึ่งจะนําไปสู่ค่าใช้จ่ายด้านโครงสร้างพื้นฐานที่เพิ่มขึ้น”
“ประหยัดค่าใช้จ่าย การอ่านจาก MongoDB บ่อยครั้งสามารถใช้ทรัพยากรอย่างมากโดยเฉพาะอย่างยิ่งกับคําถามที่ซับซ้อนซึ่งจะนําไปสู่ค่าใช้จ่ายด้านโครงสร้างพื้นฐานที่เพิ่มขึ้น”
แผนภูมิ MongoDB ของคุณควรได้รับการออกแบบเพื่อให้คําถามที่สําคัญของคุณไม่จําเป็นต้องคําถามที่ซับซ้อน
"ใช้กรณีสําหรับโครงสร้างข้อมูลเฉพาะ Redis รองรับโครงสร้างข้อมูลขั้นสูงเช่นรายการชุดชุดจัดเรียงแฮชและสตรีมซึ่ง MongoDB ไม่ให้เป็นธรรมชาติ"
"ใช้กรณีสําหรับโครงสร้างข้อมูลเฉพาะ Redis รองรับโครงสร้างข้อมูลขั้นสูงเช่นรายการชุดชุดจัดเรียงแฮชและสตรีมซึ่ง MongoDB ไม่ให้เป็นธรรมชาติ"
MongoDB สนับสนุนรายการและชุด Hashes สามารถแสดงให้เห็นใน MongoDB เป็นชุดเอกสารที่มีคู่ค่าคีย์ (คู่ค่าคีย์)
“ความทนทานและความอดทนต่อข้อบกพร่อง ชั้นแคชสามารถทําหน้าที่เป็นความล้มเหลวหาก MongoDB ไม่สามารถใช้ได้ชั่วคราวหรือมีโหลดหนัก”
“ความทนทานและความอดทนต่อข้อบกพร่อง ชั้นแคชสามารถทําหน้าที่เป็นความล้มเหลวหาก MongoDB ไม่สามารถใช้ได้ชั่วคราวหรือมีโหลดหนัก”
MongoDB สามารถปรับขนาดได้แนวตั้งหรือแนวนอนเพื่อตอบสนองความต้องการโหลดใด ๆ
MongoDB สามารถใช้เวลาในการคํานวณคําถามที่ซับซ้อน (เช่นการรวบรวมการเชื่อมโยง) สําหรับผลลัพธ์ที่ถามบ่อย
MongoDB สามารถใช้เวลาในการคํานวณคําถามที่ซับซ้อน (เช่นการรวบรวมการเชื่อมโยง) สําหรับผลลัพธ์ที่ถามบ่อย
แผนภูมิ MongoDB ของคุณควรได้รับการออกแบบเพื่อหลีกเลี่ยงความจําเป็นในการเรียกใช้คําถามที่ซับซ้อนบ่อย ผลลัพธ์สามารถจัดเก็บ (cache) ใน
โปรดทราบว่าคําตอบที่คุณได้รับจาก ChatGPT มีความผิดพลาดอย่างมากโดยคําถามที่คุณถาม หากฉันเปลี่ยนคําแนะนําของฉันเพื่อ“ คําอธิบายว่าทําไมฉันไม่ควรใช้ชั้นแคช (เช่น Redis) แทนที่จะทําให้แอปพลิเคชันของฉันอ่านข้อมูลจาก MongoDB โดยตรง” ChatGPT มีความสุขที่จะขัดขวางฉันจากการเพิ่มชั้นแคชโดยอ้างถึงปัญหาเช่นความซับซ้อนของระบบเพิ่มขึ้นปัญหาความสม่ําเสมอของข้อมูลประสิทธิภาพสําหรับโหลดงานหนักในการเขียนค่าใช้จ่ายความยืดหยุ่นในการสอบถามการบํารุงรักษาและความน่าเชื่อถือชุดข้อมูลขนาดเล็ก (ที่ชุดข้อมูลที่ใช้งานเหมาะกับแคชของ MongoDB) และรายงานในเวลาจริง
คําอธิบาย
ชั้นแคชสามารถเพิ่มมูลค่ามากเมื่อ RDBMS ของคุณไม่สามารถให้ประสิทธิภาพการสอบถามที่แอพพลิเคชันของคุณต้องการ เมื่อใช้ MongoDB ฐานข้อมูลของบันทึกและฟังก์ชั่นแคชจะรวมในชั้นเดียวช่วยให้คุณประหยัดเงินและเวลานักพัฒนา
แคชแบบกระจายสามารถบรรเทาข้อบกพร่องใน RDBMS ของคุณ แต่ MongoDB มีการกระจายตัวในตัว
ตอบถึงบทความนี้หากคุณยังคงเชื่อว่าแอปพลิเคชันของคุณจะได้รับประโยชน์จากชั้นแคชระหว่างแอปพลิเคชันของคุณและ MongoDB ผมอยากจะดู
เรียนรู้เพิ่มเติมเกี่ยวกับรีวิวการออกแบบ MongoDB
บทความนี้อธิบายว่าการออกแบบแผนภูมิ MongoDB ที่สอดคล้องกับวิธีการทํางานของแอพพลิเคชันกับข้อมูลของคุณสามารถตอบสนองความต้องการประสิทธิภาพของคุณได้โดยไม่ต้องจําเป็นต้องใช้ชั้นแคช หากคุณต้องการความช่วยเหลือในการมาถึงแผนภูมินั้นการตรวจสอบการออกแบบคือวิธีที่จะได้รับความช่วยเหลือ
การสมัครของคุณจะได้รับประโยชน์จากการตรวจสอบหรือไม่
