Videos → What's new in MongoDB 8.0

แนะนำวิทยากรและหัวข้อ What's New in MongoDB 8.00:00

เซสชั่นนี้ครับ เราได้ คนที่เป็น น่าจะใกล้ชิดกับโปรดักต์ ของ MongoDB ที่สุดแล้วนะครับ แล้วก็เป็นพนักงาน MongoDB คนเดียวในทีมด้วยนะครับ ที่เหลือไม่ได้เป็น แล้วก็เดี๋ยวเขาจะมาพูดนะครับ ในหัวข้อ What is new in MongoDB 8.0 นะครับ ก็เดี๋ยวมาดูกันครับว่าของใหม่ๆ ที่กำลังจะออกมาหรือว่าออกมาแล้วเนี่ย เป็นยังไงนะครับ คนนี้ import ตรงนะครับ จาก MongoDB สาขาพะเยา ไม่ใช่นะครับ MongoDB สิงคโปร์ ขอเสียงปรบมือให้กับพี่ปิตินะครับ Senior Consulting Engineer จาก MongoDB ครับผม เดี๋ยวเราเข้าเปลี่ยนสายแป๊บนึงนะครับ

เดี๋ยวลองดูนะครับว่าจะเป็นยังไงนะครับ 7.0 นะฮะ โอเค 8.0 นะฮะ

MongoDB เวอร์ชั่นต่างๆ และ ความสำคัญของ Community Edition0:52

ทุกคนน่าจะเคยใช้ MongoDB กันอยู่บ้างใช่ไหมครับ ใครยังใช้ MongoDB รุ่นต่ำกว่า 3 บ้างฮะ คือมันมีนะ ผมเคยเจอ ใครใช้รุ่น 4-5

โอเค 6 ขึ้นไป โอเค โอเคครับ ส่วนที่ไม่ยกก็คือรอใช้รุ่น 9 ซึ่งจะออกในอีก 2 ปีข้างหน้าใช่ไหมครับ โอเคนะครับ เดี๋ยวรอดูนะครับ ครับ มาแล้วครับ ถ้าพี่พร้อมก็เชิญเลยครับ

โอเคนะครับ สวัสดีครับทุกคน ผมตื่นเต้นนิดหน่อยนะครับ

ในวันนี้นะครับ เราจะมาพูดถึงตัวที่เป็น MongoDB Version 8 ซึ่งภายในปีนี้จะออกเป็น GA ก็คือ General Available นะครับ

โอเค อันนี้เป็นสไลด์ที่เรามีการพูดในงาน mongodb.local ซึ่งผมอาจจะ skip บางอันไปนะครับ เพราะว่ามันอาจจะ ไม่ได้มีเนื้อหาอะไรที่ดึงดูดความสนใจ ให้เราสนใจได้มากนะครับ จะเป็นกล่าวประวัติเนาะ แล้วก็ปัจจุบันตอนนี้ มันจะเป็น release candidates เวอร์ชัน 8 นะครับ โอเค อันนี้เราจะเห็นว่า evaluation ก็คือในแต่ละปี มันก็จะค่อยๆ เริ่มต้นมีเวอร์ชันมากขึ้นไป จนถึง ณ ปัจจุบันเนี่ย จะออกเวอร์ชันทั้งหมดเนี่ย ประมาณ 1 ปี 1 เวอร์ชัน นะครับ MongoDB จะออก 1 ปี 1 เวอร์ชัน ซึ่งผมถือว่าค่อนข้างเร็ว นะครับ อันนี้คือเป็นนโยบายพื้นฐาน ซึ่งผมก็ยังไม่แน่ใจนะครับว่าเขาจะ มีการแบบ 2 ปี 1 ครั้งรึเปล่านะครับ แต่ตอนนี้เขาจะผลักดันให้มันเป็น นะครับ 1 ปี 1 เวอร์ชันนะครับ ตรงนี้นะครับ อันนี้จะเป็นตัวเวอร์ชันนะครับ โอเค ต่อไปนะครับ

ฟีเจอร์ใหม่ใน MongoDB 8.0: Search และ Vector Search2:51

ที่จริงแล้วนะครับ สิ่งแรกที่ MongoDB จะมีในเวอร์ชัน 8 เลยนะครับ ก็คือ ปกติแล้วผมเข้าใจว่าทุกท่านเนี่ยใช้ Community Edition อยู่แล้ว ผมเชื่อว่าอย่างนั้นนะครับ เพราะว่าเราเป็น product ที่มีทั้ง open source และตัว commercial นะครับ เพราะฉะนั้นในตัว ตัว open source เนี่ยก็จะมี community ซึ่ง community ต่างกับ EA นะครับ อยู่แค่จุดเดียว

คำว่าจุดเดียวก็คือ อยู่แค่ segment เดียว ก็คือเรื่องของตัว Security Advance นะครับ อันนี้ผมพยายามให้ความรู้ไปด้วย เพราะฉะนั้นเราจะเห็นได้ว่า product ที่เสียเงินกับไม่เสียเงินต่างกันแค่ตรงนี้จุดเดียว ดังนั้นเมื่อเป็น MongoDB เวอร์ชัน 8 ที่กำลังจะเกิดขึ้นนะครับ

ในประมาณปลายปี อีกไม่กี่เดือนนี้นะครับ เวอร์ชัน 8 ที่จะออกมาเนี่ย เขาบอกว่า Community Edition เนี่ยครับ จะมีฟีเจอร์ใหม่ขึ้นมาทันทีนะครับ ฟีเจอร์หนึ่งชื่อว่า Search กับ Vector Search ก็คือปกติแล้วนะครับ MongoDB เนี่ย เป็นเวอร์ชัน Community ใช่ไหมครับ แล้วก็เป็นเวอร์ชันเสียตังค์และเวอร์ชัน Cloud นะครับ มีทั้งหมด 3 เวอร์ชันนะครับ เพราะฉะนั้นในตัวที่เป็น เวอร์ชัน Cloud เนี่ย ปกติแล้วเราจะเรียกว่าเป็น MongoDB Atlas นะครับ ซึ่งใน MongoDB Atlas เนี่ย ก็คือเป็น self-managed นะครับ ก็คือคุณสามารถที่จะเซ็ต config ต่างๆ ได้ deploy Mongo ได้นะครับ ก็จะมีฟีเจอร์หนึ่งที่เราเรียกว่าเป็น Atlas Search นะครับ ในตัว Atlas Search หมายความว่าอะไร หมายความว่าเราสามารถจะทำพวก full-text search ได้ search แบบ string แทนที่เราจะ search แบบ regular expression เราอาจจะไม่จำเป็นต้องทำแบบนั้น มันจะเป็นแบบ full-stream search นะครับ ซึ่งเบื้องหลังของตัว search เนี่ย โดยปกติแล้วก็คือใช้ตัว Apache Lucene ที่เป็นที่นิยมอยู่แล้วนะครับ เพราะฉะนั้น engine เดียวกับตัว Elastic Search หรือ OpenSearch นะครับ engine เดียวกันนะครับ เพราะฉะนั้นตอนนี้เขาก็จะโยกครับ ตัว Atlas Search นะครับ มา deploy อยู่บน on-prem โดยที่เปิดให้ community edition ใช้ก่อน เวอร์ชันเสียตังค์ตามมาทีหลัง

นี่คือคอนเซ็ปต์แรกนะครับ เพราะว่าเขาให้เห็นว่านักพัฒนาทุกคนเนี่ย ให้ความสนใจต่อการใช้ Community มากอยู่แล้ว ดังนั้น เราอยากให้นักพัฒนาได้ลองใช้ feature ที่ง่ายขึ้นนะครับ โดยการโยกตัว Atlas Search นะครับ มา deploy ลงบน Community Edition นั่นเอง ซึ่งจะมาอยู่ในเวอร์ชันที่เป็นเวอร์ชัน 8 แต่ยังคงเป็นลักษณะที่เหมือนเป็น beta

ก็คือมันจะมีการ develop ไปเรื่อยๆ แต่เราจะเริ่มใช้ได้ทันที อันนี้ก็คือเป็นสิ่งที่เขา announce นะครับ เป็น feature ซึ่งถ้าถามตัวผมก็คือผมอ่ะ ยังไม่ได้มีโอกาสเล่นจริงๆ จังๆ เพราะ product เขาค่อนข้างเยอะเนาะ เพราะฉะนั้นในความจริงแล้วผมเล่นแทบ ไม่ได้เล่นครบทุกตัว แต่ก็แบบประมาณ 90 กว่าเปอร์เซ็นต์ที่ผมได้เล่นเพราะว่าลูกค้า จะมีการใช้งานที่หลากหลาย ดังนั้นเราจำเป็นที่จะต้องเรียนรู้ทุก product ก่อนออก เลยทุกตัวนะครับ อันนี้เป็นตัวแรกนะครับที่จะเข้ามาในเวอร์ชั่น 8 นั่นเองนะครับ เรื่องการใส่ search เข้าไป เพราะฉะนั้น search มี 2 ตัว ถ้าเห็นทางรูปก็คือ 1 ก็คือเป็นตัวที่เป็น search ปกติ เราเรียก full text search นะครับ ตัวที่ 2 เรียกว่า vector search เพราะว่าตามสมัยนิยมแน่นอน ตอนนี้ทุกคนทำ generative AI ดังนั้นทุกคนต้องการให้ระบบ search เนี่ย search ได้เร็วขึ้นนะครับ ซึ่งตรง vector search คืออะไรเนี่ยนะครับ เดี๋ยวเราไปคุยใน section ของน้องเจมส์นั่นเองนะครับ

เครื่องมือ Migration: ย้ายข้อมูลจาก Relational Database สู่ MongoDB6:19

ต่อไปนะครับ เราก็จะมีส่วนที่เป็นเวอร์ชันที่ release จริงจังแล้วก็คือ

เวลาที่เราต้องการที่อยากจะย้าย database ที่เป็น relational database ขึ้นมาบน NoSQL หรือ MongoDB นะครับ MongoDB จะมีเครื่องมือที่เราเรียกว่า migration เราเรียกว่า migration มี 2 ตัวหลักๆ ที่ ถือว่าเป็นตัวที่ active อยู่ตลอดเวลา ชื่อว่า mongosync กับ relational migrator mongosync ก็คือเป็นเครื่องมือสำหรับย้าย

database ที่เป็น relational database ก็คือ ก็คือตัว mongosync เนี่ยจะย้ายจากตัวที่เป็นตระกูล NoSQL ด้วยกัน อย่างเช่น Mongo Community หรือ database ที่เป็น NoSQL ที่เป็น JSON ตัวอื่นนะครับ ย้ายขึ้นมาบน MongoDB หรือบน Atlas เราจะเรียกว่าเป็น mongosync นะครับ ซึ่ง mongosync เนี่ยปกติแล้วเนี่ย เวลาเราย้าย migration เนี่ย หลายๆองค์กรจะมองภาพว่า เอ๊ะ ถ้าเราย้ายจาก A ไป B แล้วเกิดล่ม เราสามารถย้ายย้อนกลับจาก B มา A ได้ไหม ตัว mongosync สามารถทำที่เรียกว่าเป็น bi-direction ก็คือ เพราะว่าทุกธุรกิจจะต้องมีคำถามว่า เอ๊ะ ถ้าผมลองย้ายไปแล้วแล้วเกิดพัง ผม rollback ได้ไหม โอเคไหมครับ ทุกคนต้องมีคำถามนี้ เพราะไม่มีใครจะย้ายไปแล้วแบบ เออ พังก็ช่างมัน ก็ไปทำกันบนนั้นน่ะ คงไม่มีทางถูกไหมครับองค์กรทุกองค์กร ดังนั้น แปลว่าเราย้ายจาก A ไป B ปุ๊บ เราสามารถย้อนกลับได้ อันนี้คือตัว mongosync นะครับ ตัว mongosync เนี่ยมีหน้าที่แค่ย้าย data ครับ แต่ถ้าเราบอกว่าต้องการที่อยากจะย้ายจาก relational แล้วต้องการแบบ จะเข้าใจว่า เอ๊ะ ถ้าเราจะย้าย relational ที่เป็นโครงสร้าง table ล่ะ มีความสัมพันธ์ one-to-many, many-to-many, one-to-one เนี่ย เราจะย้ายไป Mongo ยังไง เพราะความรู้ของเราอาจจะ อาจจะยังแบบไม่ได้เต็มที่ที่จะเข้าใจว่าการทำ modeling ของ MongoDB ทำยังไง

relational migrator ก็คือตัวตอบโจทย์ เพราะว่าอะไรครับ เพราะว่ามันคือเครื่องมือที่ เป็นหน้าเหมือน diagram ให้มองภาพเหมือนเราทำตัว ER diagram

เพราะฉะนั้นตัว relational migrator จะเป็นตัวที่ทำการ map relational database ให้เห็นเป็น ER diagram แล้วก็สามารถ map เป็นโครงสร้างของ relational ที่เป็น MongoDB เป็น NoSQL diagram นี่คือสิ่งที่มันสามารถ mapping อัตโนมัติ by default หลังจากนั้นคุณก็สามารถที่จะปรับแต่งได้ตามต้องการ แต่สำคัญกว่านั้นก็คือ เช่น เราต้องการจะย้าย database จาก MySQL จาก Oracle จาก SQL Server ไปบน MongoDB เราใช้เครื่องมือนี้ ข้อดีคือพอคุณสร้าง diagram เสร็จ mapping เรียบร้อยแล้ว คุณสามารถ run ย้าย data ได้ทันที การย้าย data ปกติเรามักจะมี 2 ส่วน ก็คือย้ายครั้งเดียวจบใช่ไหมครับ แต่ส่วนใหญ่ผมเข้าใจว่าระบบทุกคนมีขนาดใหญ่ ดังนั้นเราไม่สามารถจะย้ายครั้งเดียวจบได้ เราต้องย้ายที่เรียกว่า continuous ดังนั้นตัว relational migrator ทำการย้ายข้อมูล continuous ไว้ แล้วสามารถบอกว่า เออ วันนี้ traffic เยอะ หยุด เราสั่ง stop วันนี้ traffic น้อย อ่า run หมายความว่าอะไร หมายความว่าสมมุติว่าผมมี MySQL แล้วผมอยากจะย้ายไปบน MongoDB ผม map เรียบร้อยแล้ว ผมบอกว่า วันนี้ตอนตี 1 ผมต้องการย้ายข้อมูลเฉพาะตี 1 ถึงตี 4 เท่านั้น ผมสามารถตั้ง schedule แล้วก็ย้าย พอย้ายถึงตี 4 ปั๊บ run command API บอกว่า stop วันถัดไป ย้ายตีหนึ่งถึงตีสี่ ซ้ำ ทำอย่างนี้ไปเรื่อยๆ ได้ เราเรียกว่า ตัว continuous sync นะครับ ซึ่ง relational migrator ถูกออกแบบมาให้เราย้าย เหตุผลง่ายๆครับ เราต้องการย้ายลูกค้า relational database ไปอยู่บน Mongo ให้ได้ ดังนั้นเขาจึงสร้างเครื่องมือนี้เป็นเครื่องมือฟรี ที่เหมาะกับการย้าย ปัญหาหนึ่งของการย้าย data

relational database ไม่ใช่มีแค่ data อย่างเดียวจริงไหมครับ เขาจะมีตัวข้างในเรียกว่า stored procedure หรือ query ที่ซับซ้อน ดังนั้น relational migrator ทำการ เรียกว่า mapping ก็คือเขาใส่ tool AI เข้าไปทำการ mapping command ใน function หรือ stored procedure ที่เป็น relational SQL ให้แปลงเป็น Mongo Query Language อันนี้คือความสามารถของเขา ดังนั้นหมายความว่ามันแปลงก็ไม่ใช่ 100% เพราะว่าหมายความว่า พอมันแปลงปุ๊บ แน่นอนคุณต้องเป็นคน adjustment ว่าถูกต้องหรือเปล่า แต่มากกว่า 80% มันจะแปลงได้อย่างถูกต้อง ทำให้เราลดเวลา ในการแปลงคำสั่งที่ฝังอยู่ใน stored procedure นั่นเองนะครับ อันนี้เราเรียกว่าเป็นตัว relational migrator นะครับ

Modernization: อัพเกรดแอปพลิเคชั่นเก่าด้วย AI10:56

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

ที่เรียกว่า Modernization Factory เป็นทีมที่จะช่วยอำนวยความสะดวก โดยใช้ระบบ AI ในการ convert source code ทั้งหมด ซึ่งเขาพัฒนาเองอยู่แล้วภายใน ทำการแปลง source code จากการ mapping เช่น คุณเขียน Java แล้วคุณ call ด้วย JDBC ที่เป็น SQL query คุณแปลง code เนี่ย ให้กลายเป็น MongoDB code ได้เลย เป็น Java connect MongoDB พร้อมกับเขียน Aggregation Framework ได้เลย อันนี้ก็คือฟีเจอร์ที่เราพูดถึงว่าเป็นการทำ AI-enabled application modernization tools นะครับ ซึ่งตัวนี้ก็จะเป็นทีมที่ช่วยในการย้าย แปลว่าอะไรครับ แปลว่า คุณอยากจะย้ายใช้ MongoDB sync relational ทำด้วยตัวเองได้นะครับ ไม่มีปัญหา แต่ถ้าคุณไม่มีทีมในการแก้ source code นะครับ ทาง MongoDB มีทีมและ tool ในการ convert ซึ่งเขาไม่ได้เอา tool ออกมา public เนาะ เป็น tool สำหรับใช้ internal แต่เขารู้ว่า เขาพัฒนามาเพื่อให้ระบบ AI generate code เพราะเราอยู่ในยุคที่ code มัน generate เองได้ ถูกไหมครับ แค่พิมพ์ไปใน prompt เนาะ เพราะฉะนั้นเขาก็สร้าง prompt ด้วยตัวเองขึ้นมานะครับ เพื่อให้ manage ตรงนี้นะครับ อันนี้คือหนึ่งในความสามารถนะครับ ที่มีในตัว MongoDB 8 ที่จะมีเข้ามานะครับ

4 จุดเด่นของ MongoDB 8.0: Optimization, Workload, Scaling, Security12:41

ในระหว่างทาง มีคำถามอะไรก็คือถามได้หมดนะครับผม เท่าที่ผมสามารถที่จะตอบได้

ต่อไป ฟีเจอร์หลักๆ แบ่งออกเป็น 4 ส่วน

หนึ่งก็คือ MongoDB 8 เนี่ยจะปรับ optimization คือ performance จะดีขึ้น แต่เราเห็นภาพนะ มันจะมีภาพ ฉะนั้นผมเชื่อว่า MongoDB 8 เนี่ย เราเรียกว่าเป็น เมเจอร์เชนจ์มากๆ แล้วมีการวัดผลอย่าง 100% ตามมาตรฐานของสาย database

พวก database เนี่ยจะมีเว็บไซต์สำหรับวัดมาตรฐาน เขาไม่ได้ใช้แบบ load test ทั่วๆ ไป เขาจะมีเว็บไซต์สำหรับ วัดว่า database ยี่ห้อแต่ละยี่ห้อเนี่ย ถ้าคุณต้องใช้ data set แบบนี้แบบนั้นนะ คุณถึงจะวัด แล้วทุกคนก็จะไปวัด ด้วยกันที่ standard ตัวนั้น เพื่อที่จะวัดว่า โอเค ของฉันใช้ speed แบบ ได้เร็วเท่าไหร่นะครับ เดี๋ยวเราจะมีภาพให้ดูนะครับ ซึ่งตัวนี้จะเป็นเว็บไซต์ปกติที่เราเห็นนะครับ อันนี้เรื่องตัว optimization นะครับ สองก็คือเรื่องของการ workload นะครับ workload management นะครับ ก็คือจะทำการ manage ทำให้การโหลดข้อมูลเนี่ยเร็วขึ้นนะครับ มันก็จะมีเรื่อง optimize เรื่อง workload เรื่อง flexible scaling นะครับ แล้วก็ improve ตัว security นะครับ เดี๋ยวเรามาดูกันนะครับ ทั้ง 4 key นะครับ

Optimization: Performance เร็วขึ้น, ยกตัวอย่างคำสั่งที่ปรับปรุง13:54

เริ่มแรกนะครับ ตัว optimization นะครับ Optimization เนี่ยนะครับ

ถ้าใครใช้ MongoDB อยู่แล้ว จะค้นพบว่าการทำ application framework เนี่ยเป็นเรื่องที่งง เพราะทุกคนคุ้นเคยต่อการใช้คำสั่ง SQL ในการ select, join, group by Nested join นะครับ ทำอะไรก็ตามนะครับ ด้วย join เพราะฉะนั้น เวลาการทำตัว aggregation framework เป็นเรื่องที่ยาก แต่ว่าเราไม่ต้องกังวลครับ เพราะว่าถ้าพวกเราใช้ Compass นะครับ ซึ่งเป็น MongoDB Compass เนี่ย พวกเราจะเห็นว่ามันจะมี feature ที่เรียกว่า NLP ก็คือ Gen AI เราสามารถ บอกเขาได้เหมือน prompt เลย ใส่ prompt เข้าไปมันจะ generate query ให้เรา อันนี้คือสิ่งที่ผมก็ใช้อยู่ทุกวันนะ เพราะว่า บางอย่างมันเป็นท่าที่ซับซ้อน ดังนั้นผมก็ไม่สามารถที่จะคิดให้เร็วๆ ได้ ผมก็จะถาม พอเค้าเอามาปุ๊บ ผมก็จะค่อยๆ แปลงมันให้ถูกต้องต่อผลลัพธ์ ซึ่งเป็นการพัฒนามันไป ซึ่งใน performance ของเวอร์ชัน 8 เนี่ยนะครับ สิ่งหนึ่งที่เราบอกว่า raise the bar Raise the bar คือพยายามทำให้มันขึ้นแบบ top level ในส่วนหลักๆ เลยของ performance เมื่อเทียบ เมื่อเทียบกับเวอร์ชัน 7 นะครับ ก็คือ 1.

Group กับ project นะครับ ปกติแล้ว MongoDB เนี่ยเราจะมีการ group by ถูกไหมครับ SQL ทุกคนเนี่ยก็ต้องมีการ group by ผมเชื่อว่าทุกคน group by โปรเจกต์ก็คือการใช้คำสั่ง select ปกติทุกคนคงไม่ใช้ select star หรอกจริงไหมครับ ถ้าเวลาเราใช้ relational database เราจะใช้คำว่า select แล้วก็เลือกคอลัมน์ มันทำให้การดึงง่ายขึ้น แต่ในมุมของ ตัวระบบที่เป็น MongoDB เราใช้คำว่า project ก็คือการ select เพราะฉะนั้นพวกนี้เค้าจะปรับปรุง performance ให้มีประสิทธิภาพดีขึ้น ต่อไปพูดถึงตัว filter แล้วก็ sort ปกติเรา filter ถ้า SQL ก็คือใช้คำว่า WHERE ถ้า MongoDB เราใช้คำว่า $match นะครับ เพราะฉะนั้นคำว่าตัว $match เนี่ยก็คือจะช่วยทำการ filter ให้มีศักยภาพในการ query ให้เร็วขึ้นนะครับ ผมอาจจะไม่ได้ลง detail โดยแบบละเอียดมากนะ เพราะว่าผมมันมีเอกสาร อยู่แล้วที่ผมมาเห็นภาพ แต่ผมรู้ว่าเค้าให้เห็นภาพว่า ตัว operator ตัวไหนบ้าง ที่ performance ดีขึ้น เป็น operator ที่พวกเราต้องใช้อยู่แล้วในสาย MongoDB ก็คือ $match นะครับ ก็คือ $sort นะครับ แล้วก็ตัวสุดท้าย $lookup ซึ่งปกติแล้วผมแนะนำอยู่แล้วว่า เราไม่ควรมี lookup lookup ก็คือการ join เราไม่ควรมี lookup เกิน 2 lookup มันก็เหมือนเราเขียน relational database เราไม่ควร INNER JOIN ๆ ๆ ๆ ถูกไหม

เพราะว่ามันจะทำให้ประสิทธิภาพ… performance ของการโหลดขึ้น memory เนี่ยมันหนักเกินไป นี่คือเหตุผลเดียวนะครับ ว่าบอกว่าถ้าเมื่อไหร่ก็ตามคุณใช้ lookup ทุกครั้งคุณจะใช้ CPU เยอะ ต่อให้คุณมี index แล้วก็ตาม ดังนั้นเขาจึงบอกว่าควรมีการ join เพียงแค่ไม่เกิน 2 ครั้ง ซึ่ง lookup ในท่าของ Excel มันก็คือการทำ left join อันนี้เป็นข้อมูลเพิ่มเติมนะ ถ้าใคร search รอบอยู่แล้ว นี่คือการทำ left join นะครับ เพราะ lookup เขาจะปรับปรุงให้มีประสิทธิภาพมากยิ่งขึ้น อันนี้คือเป็นส่วนที่เน้น query performance

โอเค ต่อไปเราเซ็ต standard ใหม่ครับ เชิญครับ

การทำ Index ใน MongoDB: ESR Rule และ Best Practice17:17

โอเคครับ เป็นคำถามที่ดีครับ แน่นอนครับ ปกติแล้วก็คือ การทำ index มันจะมีทฤษฎีหนึ่งนะครับ ที่อาจจะดูบนเว็บไซต์ก่อนนะครับ ก็คือเรียกว่า ESR Equality นะครับ

แล้วก็ sorting นะครับ แล้วก็ range นะครับ เป็นกฎปกติที่อยู่บนเว็บไซต์นะครับ ซึ่งมันจะมี detail นะครับ ผมอาจจะบอกไม่ได้ในตอนนี้มันเยอะ เพราะ ESR rule จะเป็นตัวบอกนะครับ แล้วปกติแล้วเราควรมี index เขาบอกว่า best practice ควรมี index ต่อหนึ่ง collection ไม่ควรเกิน 4 สถานการณ์จริงผมเห็นสูงสุด 60 สูงสุดของ index ที่มีได้ 64 ตัว โอเคไหมครับ ในหนึ่ง collection นะ แต่ทุกครั้งที่เราทำเวลาโหลดขึ้น RAM RAM ไม่พอ ลองนึกภาพ 64 ตีไปซะว่า index หนึ่งใช้สอง GB ก็​เอา 2×64 แรมเครื่องของคุณก็หมดแล้ว เพราะฉะนั้น โดยปกติแล้ว ค่าเฉลี่ยที่ผมเจอก็คือ โดยพื้นฐานประมาณ 10 เพราะเราควรมี index ไม่เกินประมาณ 10 ให้เต็มที่ และไม่ควรเกิน 20 collection เดียวนะครับ คุณนึกภาพนะ มีอีก 1 collection มี 10 index index ตัวนึงเนี่ย ใช้ RAM เป็นร้อยๆ MB คุณมีซัก 20 collection 100 collection คุณก็ไม่ไหว ปกติแล้ว MongoDB อนุญาตให้เรามี collection ได้ประมาณ ถ้าผมจำตัวเลขไม่ผิดนะครับ เป็นหลักหมื่นขึ้น ใน 1 database เลยนะ อนุญาตให้คุณมีเกิน 10,000 collection เกินกว่านั้นระบบจะยิ่งแบบ very slow มาก คือแบบอาจจะเกิดการพังได้ แต่อนุญาตได้ถึงขนาดนั้น ซึ่ง ผมบอกอย่างนี้ได้ เพราะว่าเราเจอลูกค้า

ที่เกินลิมิต คุณลองนึกภาพว่าออกแบบอย่างไร ให้มี collection เป็นหมื่นๆ collection อยู่ใน database ก้อนนั้น นะครับ อันนี้คือแชร์ให้ฟังเนาะ นะครับ อ๋อ มันออกไลฟ์ด้วยนี่? ไม่เป็นไร ไม่ได้พูดถึงใครนะครับ นั่นคือหมายความว่า อธิบาย index ว่าเราควรทำยังไงนะครับ มันจะมี detail นะครับ

มาตรฐานใหม่ของ Performance: เปรียบเทียบ MongoDB 8.0 กับเวอร์ชั่น 719:18

ต่อไปก็คือ พอเราพูดถึง set standard นะครับ เราก็จะมี standard นะครับ เขาก็จะมีการ improve on industry benchmark ก็คือเราบอกแล้วครับ เวอร์ชัน 8 เนี่ย เป็นเวอร์ชันที่แบบ ชูโรงเรื่อง performance มาก เมื่อเทียบกับ MongoDB เวอร์ชัน 7 เลยนะครับ เขาจะเทียบกับ 3 เจ้านี้ คุณเสิร์ชดูได้ ว่าเป็นเว็บไซต์

หรือเป็นเครื่องมือ ที่คน ที่อยู่ในอุตสาหกรรม database จะต้องใช้เครื่องมือเหล่านี้ วัดประสิทธิภาพ จะ compare กับใครก็ตาม ไม่รู้ แต่คุณควรจะใช้อันนี้ ถ้าคุณพูดถึงเป็น product ประเภท database vendor เนาะนะครับ เราต้องอ้างอิง แต่ในที่นี้เราจะ compare กับ version 7 เรายังไม่ compare กับเจ้าอื่นเนาะนะครับ เพราะฉะนั้นใน performance นี่ครับ เราเทียบนะครับ ให้เห็นภาพนะครับ ว่าเรา bulk load เร็วขึ้น compare กับ version 7 เราเร็วขึ้น 54% นะครับ ในขณะที่ตัวนี้ออกเนี่ยมันออก มันภายในเนี่ยเค้าระบุตัวนี้ออกมาก่อนงานอยู่แล้วตั้งนาน ซึ่งมีคนเนี่ย อย่างเช่น เราเป็น engineer ผมเป็น consult engineer ใช่มั้ย มันจะมี software engineer, consult engineer หรือตัว product engineer นะครับ ทุกคนเมื่อรู้ภาพนี้ปุ๊บ ทุกคนมีการทดสอบเลยเพราะว่าลูกค้า บางกลุ่มจะถูกเรียกมาให้ใช้งาน ดังนั้นเขาจะวัดกัน ทุกคนก็จะเริ่มวัดทุกตัวเลย

นะครับ ข้อดีของการที่เราวัดก็คือว่า เราจะรู้ limitation สิ่งหนึ่งที่สำคัญมาก ก็คือผมเชื่อว่า หลายๆ database ทุกผลิตภัณฑ์นะครับ จำเป็นที่จะต้องระบุว่าตัวเองมีข้อจำกัดอะไร ผมเชื่อว่าทุก database เหมาะกับงานแต่ละงาน ในปริมาณ data ที่แตกต่างกัน

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

เขาจะเห็นภาพว่ามันโหลดเร็วขึ้น มัน read เร็วขึ้น ภาพเห็นก็คือเป็นการ compare based on version 7 นะครับ ขอย้ำนะ เป็นการ based version 7 ไม่ได้เปรียบเทียบ database ยี่ห้อใดๆ แต่เปรียบเทียบของตัวเองนะครับ

ต่อไปนะครับ เรามาพูดถึงตัว

Time Series Collection: จัดเก็บข้อมูล Real-time ได้ดีขึ้น22:11

performance นะครับ เป็นเรื่องของตัว time series ทุกคนรู้จัก time series ไหมครับ

time series ก็คือมันเป็นโครงสร้างของ collection พิเศษนะครับ ที่ถูกออกแบบมาให้เก็บข้อมูลเกี่ยวกับเวลา เรามักจะใช้ time series collection นะครับ ไว้สำหรับเก็บข้อมูลที่มีการ run แบบ real-time แล้วก็ดูเป็นเวลา เช่น พวกกราฟต่างๆ พวกที่เป็น crypto พวกที่เป็น crypto พวกที่เป็นการเงินนะครับ เรามีธุรกิจลักษณะนั้นนะครับ แล้วเราก็ ทำการที่จะออกแบบใส่ time series เข้าไป ซึ่ง time series จะมีปัญหาหนึ่งก็คือเรื่องการ group เพราะว่าเราต้อง group ถูกไหม เช่น ข้อมูลที่เป็นประเภท Internet of Things เซ็นเซอร์ทั้งหมดเนี่ย วิ่งเร็วขนาดไหน เรารู้อยู่แล้วตามโรงงาน เซ็นเซอร์จะวิ่งหรือยิง หรือแบบกระทั่งกล้องวงจรปิดที่เราเห็นอยู่ มันอาจจะส่งข้อมูลไป ดังนั้นข้อมูลมันจะวิ่งเร็วมากเป็นระดับวินาที เพราะฉะนั้นการ grouping ข้อมูลวินาที แปลว่าข้อมูลอาจจะเป็นแบบล้าน document ขึ้นไป

ดังนั้นการ group นะครับ เป็นหนึ่งในคำสั่งที่จะเรียกว่า block

บล็อกการทำงาน แปลว่ามันไม่สามารถจะ run แบบ parallel ได้ มันจะบล็อกให้หยุดการทำงานก่อน ดังนั้นเขาก็บอกว่าเราจะเพิ่มประสิทธิภาพในการทำพวก time series ให้ดีขึ้น ก็ทำให้เร็วขึ้น เพื่อจะเพิ่มประสิทธิภาพ 60% นะครับ อันนี้ผมก็ คิดว่าเขามีตัว proof อยู่แล้วนะ เพียงแต่ว่าผมยังไม่ได้ไปอ่านพวก proof point แต่นี่คือสิ่งที่ถูกพัฒนาให้ดีขึ้น ใน time series ซึ่ง time series จะเป็น collection ที่เหมาะสำหรับข้อมูลที่ เราต้องการเก็บข้อมูลขนาดใหญ่ที่มีระดับแบบเป็น 10 ล้าน document ขึ้นไป แล้วข้อมูลมันจะ size ใหญ่ แล้วเราต้องการที่จะลดขนาด index และขนาด storage เฉพาะ collection นั้น เราถึงจะทำเป็น time series เพราะฉะนั้น time series ไม่ได้บอกว่าเหมาะสำหรับ time series หรือเป็น data time อย่างเดียว หรือเป็น data point ที่จะเหมาะกับข้อมูลใดๆ ก็ตามที่คุณอยากจะเก็บมัน และคุณอยากจะลด size มัน แต่คุณต้องรู้ limitation เหมือนเดิมนะ คุณสามารถเข้าเว็บไซต์แล้วดู limitation เพราะว่าในเว็บไซต์ MongoDB ค่อนข้างที่จะ provide document ค่อนข้างเยอะละกัน เพราะฉะนั้นเราต้องถาม Gen AI ในเว็บไซต์ MongoDB เนี่ย จะมีเมนูที่เป็น Gen AI เพื่อให้เราสอบถามแล้วมันก็จะวิ่งไปที่หน้าต่างต่างๆ ให้เรา แทนที่เราต้องไปนั่งคลิกๆ นะครับ เหนื่อยเสียเวลา เราก็อาจจะใช้วิธีการทำผ่าน Gen AI ของ MongoDB นั่นเองนะครับ

ต่อไปนะครับ

Machine Learning Model ใน MongoDB: ใช้สำหรับ Vector Search24:50

MongoDB ใช้ทุกยี่ห้อ หมายความว่า

ถามเจมส์ เดี๋ยวให้เจมส์ตอบแล้วกัน

AI ที่อยู่ของเราข้างใน มันจะเป็น Machine Learning Model มันไม่ใช่ Language Model มันใช้ Language Model เราไม่มี Language Model อย่างนั้นครับ แต่เราจะมี Machine Learning Model ที่จะไว้ทำพวก Searching Vector Search อะไรอย่างเงี้ยครับ ซึ่งเดี๋ยวจะต่อไปจะพูดให้เดียวก่อนนะครับ ขอบคุณนะครับเจมส์ ก็คือเดี๋ยวรอทางเซคชั่นของคุณเจมส์นะครับ

Query Execution: ลดความซับซ้อน เพิ่มประสิทธิภาพ25:28

ต่อไปนะครับ เรามาพูดถึงตัวที่เป็น Query Execution Improvement นะครับ

ก็คือเราก็จะลดการทำงานที่ช้าให้ทำงานได้เร็วขึ้น

แล้วก็ทำการ improve plan cache นะครับ plan cache คืออะไรนะครับ ตอนก่อนหน้านั้นเนี่ย ผมมาทำ relational database มาก่อนเนาะ ผมก็ใช้ plan cache ดู แต่ผมยังไม่เข้าใจมันอย่าง 100% พอผมมาทำ MongoDB ผมเลยต้องเข้าใจเยอะ เพราะว่าเรามีสิ่งหนึ่งที่ช่วยกระตุ้นทำให้เราเรียนรู้มากขึ้นในเชิงของ expert ในมุมของ product ของเขาก็เพราะว่าลูกค้าจะถามว่า เราทำยังไง ทำไมเวลาที่เรา query แล้วมันไปเลือก index สมมุติว่าเราสร้าง index สองตัวมาใช้สำหรับ query ให้เร็ว index สองตัวเนี้ย query ที่เรารันไปเนี่ย มันเลือก index ตัวที่ 1 แทนที่จะเลือกตัวที่ 2 เราสร้างตัวที่ 2 มาเพราะว่าเราบอกว่า อยากให้ query ของเราเนี่ยไปใช้ index ตัวที่ 2 เพราะว่าประสิทธิภาพ เร็วขึ้น มันก็จะมีคนพบว่า โอเค แสดงว่าทุกครั้งที่เรารันมันจะเก็บสถิติครับ สถิติที่มันเลือกใช้แล้วเหมาะสมมันจะเก็บไว้ที่เรียกว่า plan cache มันจะเก็บสถิติว่า พอเราเก็บปุ๊บ แน่นอนครับ มันมีสถิติใหม่ ถูกไหม แต่มันบางครั้งเนี่ย มันจะไม่ทำการไป overwrite cache เดิม เราเลยต้องทำการเคลียร์มัน เราถึงรู้ว่ามันมี plan cache อยู่ และ plan cache เนี่ย มันจะมี mechanism ในแต่ละ database ที่เหมาะสมว่าเราควรจะ overwrite มันตอนไหน

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

อันนี้คือสิ่งที่มันจะเพิ่มนะครับ ก็คือนอกจากมัน improve ก็คือมันจะ improve เรื่องของ index นะครับ เรื่องของการเช็ค equality predicate ก็คือ การใช้คำว่าเท่ากับ การ find ข้อมูลที่แบบ match จริงๆ เราจะเรียกว่าเป็นตัว equality นะครับ มันจะเพิ่ม stage หนึ่งเรียกว่า express นะครับ คำว่า stage คืออะไรนะ ผมอาจจะบอกคร่าวๆ ว่ามันจะลงลึกไปตรง aggregation framework เวลาเราเขียน framework ของ MongoDB เนี่ย มันคือการเขียนแบบ เป็น stage ก็คือมองภาพเป็น data pipeline แต่ละ data pipeline มีแต่ละฐาน ผมให้มองเป็นฐานเนาะ เพราะฉะนั้นเวลาเราล้อยเรียงกันแต่ละฐานเพื่อออก output คุณก็จะมีขั้นตอนฐานที่ 1 2 3 ทำอะไรถูกไหมครับ เราจะเรียกตรงเนี้ยว่าเป็น stage ซึ่งแต่ละ stage เนี่ยมันคือการเราเขียนคำสั่งแยกเข้าไป

พอเราเขียนเข้าไปแต่ละฐานเนี่ย พอเวลามันไป run อยู่บน MongoDB

มันก็จะบอกว่า โอเค ฐานนี้ใช้ stage แปลว่าเรียกว่าอะไร เช่น fetch stage, merge stage

มันก็จะมี stage ใหม่หรือฐานใหม่ที่ชื่อว่า express เพื่อช่วยทำการปรับปรุง query ที่เราทำ ให้มีประสิทธิภาพเพิ่มขึ้น นั่นเองนะครับ อันนี้เป็นแบบบอกคร่าวๆ นะครับ คือการเพิ่มฐานใหม่ ในการแปลงคำสั่งเรา ชื่อว่า express นะครับ

ซึ่งนะครับ มันก็จะปรับปรุงตัว latency latency คือความช้าของแต่ละฐานนะครับ เขาก็จะปรับปรุงให้มีประสิทธิภาพเร็วขึ้น 17% นะครับ ต่อไปนะครับ เรามาพูดถึงเรื่องของ memory ครับ

Memory Management: การจัดการ RAM และ Data File28:44

อันนี้ก็จะลงลึกนิดนึงนะครับ ผมว่าจะแบบง่ายๆ เพื่อให้ทุกท่านเข้าใจง่ายๆ ก็คือ ปกติเวลาเราอ่านเขียนข้อมูล มันจะอ่านเขียนข้อมูลผ่าน memory สิ่งหนึ่งที่ทำให้เข้าใจก่อนนะครับ ก็คือ MongoDB เรามี RAM 64 GB ไม่ว่าคุณไปตั้ง database MongoDB เวอร์ชันอะไรก็ตาม รุ่นอะไรก็ตาม ที่คอมพิวเตอร์คุณ ถ้าคุณมี RAM 64 GB คุณไม่ได้เซ็ตอะไรเลย มันจะใช้เพียงแค่ 50% นะครับ แล้วก็ลบไป 1

50% แล้วก็ลบไป 1 ก็คือหมายความว่ามันจะใช้ประมาณครึ่งนึง ให้มองภาพ คุณมี 64 มันใช้แค่ 32 มันไม่ใช้เกินกว่านั้นที่เป็นตัวหลัก แต่ว่ามันมีโอกาสไปยืม ผมเรียกว่ายืม ยืมส่วนที่เหลือมาใช้ เพราะว่าเราไปยืมบ่อยๆ ปกติแล้วระบบปฏิบัติการจะมองภาพว่า ให้มองภาพว่าเรามีระบบ OS กับ database ใช่มั้ยครับ แล้วถ้า database ขอจองครึ่งหนึ่ง OS บอกว่า โอเค เอาไปครึ่งหนึ่งพอนะ ขอฉันเป็นอีกครึ่งหนึ่ง คุณใช้ query run ไปแบบ run มากๆ เลย บางคนอาจจะใช้ keyword ที่ผมอาจจะบอกว่าคือ keyword เรียกว่า allow disk use นะ เวลามันจะมี keyword นี้ ถ้าเราได้ใช้ query เยอะ เราจะเข้าใจ ก็คืออยากใช้ RAM เกินแบบ

เกินกว่าที่มีอยู่นะครับ ไปขอยืม OS OS บอกว่า ยืมได้ อ่ะ ฉันให้ ยืมแล้วคืนนะ ยืมแล้วคืน มันจะมีบางครั้งครับ ที่เรายืม ยืมไปถึง 90% พอไปถึง 90 OS บอกว่า เฮ้ย ยืมเกิน 90 แล้ว ผมต้องการจะ ไม่ให้คุณยืม ผมจะหยุดคุณเลย มันก็จะทำการมา stop database ครับ ให้ database หยุดทำงาน นั่นคือการที่มันจะเกิดการ kill process ทิ้ง เพราะฉะนั้นแปลว่า ถ้าเราทำๆ ไปแล้วมัน fail ไม่ต้องตกใจ มันก็คือแปลว่า คุณสามารถตรวจสอบกับ log ดูเลยว่ามันเกิดอะไรขึ้น อันหนึ่งคือคุณใช้ RAM เกิน OS บอกมาห้าม เกินไปแล้ว ไม่งั้นเกินไปกว่านี้เกิดอะไรขึ้นครับ เครื่อง restart ดังนั้น คอมพิวเตอร์ ตัว OS พยายามไม่อยาก restart เครื่องตัวเอง เพราะว่า RAM ไม่พอ ดังนั้นเขาก็เลยตัดปัญหาว่าเกินปุ๊บจัดการ MongoDB ทิ้งเลย ให้ตัวเองพังไป มันก็จะ restart ขึ้นมาใหม่ เราสามารถจะ restart ขึ้นมาใหม่ได้ ตอนนี้คือความหมายของตัว memory ก่อนนะครับ นำมาสู่เรื่องของการเก็บ ข้อมูลนะครับ เพราะฉะนั้น MongoDB จะอ่านเขียนผ่าน memory ก่อนเสมอ

แล้วค่อยในประมาณไม่กี่วินาที ไม่กี่มิลลิวินาที หรือระดับวินาที เราจะทำการเซฟจาก memory ลงบนไฟล์ MongoDB สุดท้ายแล้วต้องเซฟบนไฟล์ สุดท้ายแล้วผมเชื่อว่า ผมเห็น database หลายๆ ยี่ห้อที่เคย run อยู่บน memory สุดท้ายต้องบอกตัวเองว่า ฉันเซฟเป็น memory ไม่ไหวเหมือนกัน ฉันก็ต้องเซฟบนไฟล์ด้วย สุดท้ายทุกคนเซฟบนไฟล์ครับ เพราะไฟล์คือสิ่งที่การันตีได้ว่าข้อมูลของคุณอยู่ถาวร ถ้า hard disk ไม่พัง ไฟล์ไม่เสียจริงไหม เพราะฉะนั้น นั่นคือเหตุผลที่ทุกคนจะอ่าน memory เร็วขนาดไหนก็ตาม ทุกคนต้องลงไฟล์ครับ ดังนั้น MongoDB ก็เหมือนกันครับ เราอ่านเขียนอยู่บน RAM สุดท้ายเราก็ต้องเอาลงบนไฟล์ เพราะฉะนั้นเขาก็จะบอกว่าวิธีการจัดการ data file— data เนี่ยจะอยู่บน RAM เขาก็จะบอกว่ามันจะมีช่องว่างนะครับเวลาที่ เราเก็บข้อมูลเป็นไฟล์ๆ เนี่ย มันก็จะอ่านเขียนไฟล์นะ เหมือนเราอ่าน Excel ครับ ให้มองภาพว่า มี Excel 1 Excel แล้วมีประมาณ 10 sheet แต่ละ sheet เป็น row โอเคไหมครับ 1 document ก็คือ 1 row เพราะฉะนั้นเราลบข้อมูล เราอ่านข้อมูลมันก็จะแบบเติม row เข้า row อย่างเงี้ยนะครับ MongoDB ก็จะเป็นแบบนั้นคือ มันจะทดแทนชดเชย row ที่หายไปสลับไปสลับมา เราจะเรียกส่วนนั้นว่าเป็นพวก data page นะ ถ้าเรามองภาพ data page เพราะฉะนั้นมันจะมี gap นิดนึง เราพยายามจะลดช่องว่างของ gap ลงนะครับ เพื่อจะ improve performance นะครับ ลดช่องว่างตรงนั้นลงประมาณ 18%

เพื่อให้มันง่ายขึ้นนะครับ อันนี้เป็นแบบ เป็นอธิบายที่ง่ายนะ มันมี technical ค่อนข้างละเอียดนะครับ อันนี้คือการ improve นะครับ ต่อไปนะครับ

…แล้วก็ตัวเซิร์ฟเวอร์ที่มี primary database เนี่ย ใช้แรมอยู่ประมาณ 500 GB แล้วเราเห็นว่า memory เนี่ยขึ้นไป 50%

เรากำลังคิดว่าเวลาที่มันช้าเป็นบางช่าง เนื่องจากว่ามันเป็น lag ที่ตัวฮาร์ดดิสก์ หรือ SSD ถ้าเราจ่ายเงินเพื่อซื้อแรมเป็น 1TB ไปเลย เราคิดว่ามันจะเพิ่มความเร็ว

แบบมีนัยยะไหม

การเพิ่ม RAM ช่วยแก้ปัญหาความเร็วได้จริงหรือ? + วิธีวิเคราะห์ปัญหา33:15

ต้องเรียนอย่างนี้ครับ อย่างแรกเลย

สิ่งที่จะต้อง verify เพราะว่าปัญหาเนี่ย เราจะ verify ได้หลายส่วน การจ่ายเงินอาจจะไม่สามารถช่วยตรงนั้นได้ หากเราไม่รู้ตัวคอขวด เพราะฉะนั้นหลักการง่ายๆ คือเราต้องอ่าน log ก่อน ประเด็นแรกนะครับ เพราะโดยปกติแล้ว MongoDB ก็เหมือน database ทั่วไป

ครับ

…ดังนั้นเราจึง…

ทดสอบ ทดสอบ

(…จำนวนของ collection ที่ว่าห้ามเกิน…) (กี่ collection ต่อ 1 database ทีนี้ถ้าเกิดในเคสที่ว่าใน 1 node หรือ 1 replica) (ผมอาจจะมีอยู่ซัก 20,000 database ใน 1 node นะครับ)

(ในแต่ละดาต้าเบสก็จะจะมีคอลเลคชั่นซักประมาณ 1000 กว่าตัว) (โดยรวมรวมก็เป็นแสน) (อย่างนี้จะมีปัญหาไหมครับ) ที่จริงแล้วถ้าถามผมก็คือมันจะมีปัญหาแน่นอน ในเรื่องที่เราต้องดูว่า ที่เราต้องดูว่ามันเป็นเรื่องของตัว memory ครับ ปกติแล้ว data ที่ช้า นอกจาก collection ที่ใหญ่แล้ว เราต้องมีการคำนวณดูว่า ปกติแล้วมันจะใช้อัตราการ write ครับ อัตราการ write ประมาณ 30% ของขนาด sizing ทั้งหมด หมายความว่าถ้า 1 terabyte ครับ เราจะใช้ RAM อยู่ประมาณ 300 GB เนอะ 300 GB เพื่อให้ประสิทธิภาพเยี่ยมที่สุด ดีที่สุด ในความเป็นจริงไม่มีทาง ถูกไหม นั่นจึงเป็นเหตุผลที่ MongoDB ออกแบบให้เรามีการ scale out ออกไปทำ sharding อันนี้เป็นเรื่องปกติเลยนะครับ เพราะว่าลูกค้าทุกคนเนี่ยเวลาที่เขาถามว่า เออ ผมต้องทำ sharding ผมก็บอกว่า โอเค คุณต้องดูก่อนนะว่าต้องดูตัวเดียวคือดู collection ถ้า collection ใหญ่ถึงประมาณเกิน 500 GB แล้วเนี่ย คุณควรพิจารณาเอา collection นั้นเริ่มทำ sharding เพราะว่าคุณมองภาพว่า database ใช้ RAM สำหรับ write และ read ไม่ใช่แค่ read อย่างเดียวนะ write และ read เราต้องมี RAM ที่สำรองในการ manage ของเขาประมาณอย่างต่ำ 30% นั่นแปลว่าคอมพิวเตอร์เซิร์ฟเวอร์ 1 เครื่อง คงอัด RAM มากมายขนาดนั้นไม่ได้ จริงไหมครับ ดังนั้นมันจะมีประสบปัญหาเรื่องความช้า แล้วก็ช้าทั้ง read และ write โดยปริยายในอนาคต นะครับ ตรงนี้นะครับ

สาเหตุหลักของ Database ช้า + แนะนำเครื่องมือวิเคราะห์ Log37:28

ที่จริงแล้วมันจะดูด้วย 2 แบบ ปกติเราสามารถจะดูได้ก็คือ ปกติแล้วนะครับเวลามันช้าเนี่ย เหตุผลหลักๆ เลยก็คือ index ไม่มี ใช้ index ผิด มันจะขึ้นประโยคที่ว่า slow query เราสามารถอ่านใน log ประเด็นแรกก่อนเลยครับ เราใช้ใน log เพราะฉะนั้นเราจะมี tool ตัวหนึ่ง ที่เป็น open source tool ซึ่งเป็น senior เป็น staff engineer ของ MongoDB สร้างไว้ชื่อว่า Hatchet H-A-T-C-H-E-T

เป็น tool ที่พัฒนาเป็น open source พัฒนาด้วยภาษา Go ฉะนั้น tool ตัวนี้จะเป็นตัว analysis ครับ และทำให้เราเอา log มา analyze และขึ้นเป็น graph เลย แล้วก็จะเป็นคำพูดเป็นประโยชน์เหมือน AI พูด เป็นเหมือนชื่อภาษาอังกฤษผู้หญิงผู้ชายสักตัวหนึ่ง พูดเป็นภาษาอังกฤษว่า ตอนนี้เครื่องของคุณ ฉันอ่าน log ของคุณจากวันที่ A เวลานี้ ถึงวันที่ B เวลานี้ คุณพบว่าช้าขนาดไหน มี collection นี้ run ให้ยากลำบากแค่ไหน RAM ของคุณเป็นยังไง driver ของคุณไม่ compatible แล้วหรือยัง

อันนี้จะเป็นส่วนที่ทำให้เรา analyze ได้ เพราะฉะนั้นในนั้นจะบอก สุดท้ายเราจะเอาพวกนี้ไป proof หมด เพราะบางคนผมเจอว่าดีเหมือนทุกอย่างเลย แต่ driver เก่า แล้วเขาก็ไม่เปลี่ยนหากไม่มีหลักฐานยืนยัน เราก็ต้องใช้ tool พวกนี้แล้วให้ tool มันบอก เพราะเราไม่บอกเอง เราบอกว่า โอเค tool เราพัฒนา เราบอกแล้วว่า driver ของคุณเก่า ช่วยเปลี่ยนเถอะ เพื่อมันจะ compatible กับ database ที่คุณเป็นเวอร์ชันใหม่ อย่างนี้เป็นต้น ทุกอย่างมีหลักฐาน อันนี้น่าจะตอบคำถามด้วยดูใน log

ต่อไปนะครับ เขาก็จะ performance ในเรื่องนะครับ

Replica Set: ลด Lag Time เพิ่มประสิทธิภาพ HA39:06

กลับมาตรงนี้เนอะ ก็คือปกติแล้วทุกคนรู้จัก replica เนาะ replica จะมีปัญหาหนึ่งก็คือเรื่อง lag time lag time ก็คือหมายความว่าเวลาเราสร้าง server เราจะวางบน VM คุณจะวางไว้ที่ region เดียวกันประเด็นแรก วางไว้บนตัว AZ ตัวเดียวกันแบบใกล้เคียงกันคือเช่น

คุณวางสิงคโปร์ 1 สิงคโปร์ 2 สิงคโปร์ 3 โอเค ยังคงมีระยะทางที่ได้ หรือถ้าคุณไปวางแบบสิงคโปร์ที อเมริกาที นะครับ ญี่ปุ่นที ซึ่งตรงนี้ก็มีเหตุผลเป็นเรื่องปกติ ที่มันจะเกิดเรื่อง performance หรือ lag time คำว่า lag time performance จะเกิดตอนไหน เกิดตอนที่คุณต้องการจะ เกิดหนึ่ง เวลาระบบล่ม เวลาระบบล่มที่สิงคโปร์มันจะ switch

สมมุติว่าไปที่ฮ่องกง การ switch ไปเนี่ยมันช้าหรือเร็วเพราะตัว latency กว่ามันจะ switch แอปพลิเคชันคุณต้องแก้ config ให้ถูกต้อง ในการ run อยู่ภายใน 10 วินาทีนะ มันก็จะทำได้ ตรงนี้เราจะ improve เรื่อง lag time มากขึ้น เพื่อให้การันตีได้ว่าเกิด lag น้อยลงนะครับ อันนี้เป็นเรื่องของการทำ HA ของตัว replica set นะครับ

อ่า นี่นะครับ เขาก็จะเขียนว่า จะมีเรื่อง decrease replication การ acknowledge ที่เร็วขึ้นนะครับ ถ้าบางคนไม่รู้จัก acknowledge ก็คือว่า database ทุกตัวครับ ควรจะมีเรื่องนี้ ก็คือเรื่อง acknowledge MongoDB ใช้ acknowledge เราจะเรียก acknowledge หรือว่าเป็นตัว w เวลามันจะเป็นการ set ที่ connection string ของ application ที่ใช้ driver official ของ MongoDB ที่อยู่ภายในนั้นนะครับ

Acknowledge (Write Concern): การันตีความถูกต้องของข้อมูล40:40

w แปลว่า write concern คำว่า w ก็คือเป็นการบอกว่า เราจะ acknowledge เร็วแค่ไหน เช่น สมมุติว่า w เท่ากับ 0 ก็คือว่าคุณจะ acknowledge แบบเร็วเลยทันที ไม่ต้อง replica set หรือเราใช้ w เท่ากับ majority แปลว่ามี 3 เครื่อง จะต้องมี 2 เครื่องที่มี copy data แล้วค่อย acknowledge ไป นี้เป็นต้นนะครับ อันนี้คือเป็นเรื่องของตัว acknowledge ที่จะพัฒนาให้เร็วขึ้นนั่นเองนะครับ โอเค จะเพิ่ม 20% นะครับ ต่อไปนะครับ นี่คือเป็นการเพิ่ม enhanced performance เนาะนะครับ อันนี้ก็จะผ่านไปก่อนเนาะ เพราะมันเป็นเรื่องของภายใน ก็คือพูดง่ายๆ Atlas จะปรับปรุงกับตัว self-manage จะปรับปรุงมากขึ้น ในเรื่องของ lag ต่างๆ นะครับ โอเค นะครับ โห เยอะ…

Atlas Search: เครื่องมือวิเคราะห์ Query บน Cloud41:25

ตัวนี้ก็คือจะเป็นเรื่องของตัวจัดการเรื่องพวก plan cache นะครับ ตัวนี้ก็ improve ครับ ก็คืออันนี้พูดที่ Atlas ผมจะไปที่จุดสำคัญ มันอาจจะค่อนข้างเยอะนะครับ ส่วนที่เป็น Atlas นะ Atlas จะมีหน้าจอหนึ่งบน Atlas ก็คือ cloud service ของ MongoDB จะมีเรียกว่า query insight จะบอกว่า query ตัวไหน run ช้า run เร็ว run collection ตัวไหนบ้าง จะละเอียดกว่าเดิม เมื่อก่อนจะไม่ใช่ตัวนี้ เมื่อก่อนจะเป็นแค่แบบ profiler ธรรมดา ตอนนี้จะเป็นแบบ query insight เลย เห็นชัดๆ เลยว่าเป็นตัวไหนนะครับ เพื่อช่วยลดปัญหานะครับ เขาจะพัฒนามาเพื่อสุดท้ายแล้ว อยากให้ developer มีความรู้แล้วก็แบบ อ่านเห็นได้ง่าย เพราะ MongoDB บน cloud เราเรียกว่าเป็น developer data platform เป็นแพลตฟอร์มสำหรับ developer ทำงานแทน DBA ได้ พูดตรงๆ ก็คือเขาพยายามให้ developer ทำงานมี skill DBA ได้ด้วยในตัว เพราะฉะนั้นเขาจะทำเรื่อง monitor ให้ง่ายขึ้นนะครับ อันนี้เราก็สามารถ compare ได้นะครับ แล้วก็สามารถดู query trend ได้ด้วยนะครับ เป็น plot graph เป็น data point นะครับ แล้วก็สามารถดู shape ได้นะครับ โอเค ต่อไป

Query Shape: บล็อค Query รูปแบบเฉพาะ ป้องกันปัญหา42:30

มาถึงเรื่องที่ผมคิดว่าน่าสนใจก็คือ query shape นะครับ query shape ก็คือเวลาเรา query เราดู plan มันจะมี shape นะครับ shape จะเข้ารหัสแบบนี้ เราสามารถ block block บอกว่า query เนี้ยหากมี application ยิงมา ถ้าเป็น query shape นี้นะ คำว่า shape นี้ไม่ใช่แปลว่า query command อะไรนะ มันจะ detect shape นั้น query อาจจะมีหลาย style แต่มันตรงกับ shape เนี้ย มันก็ยังคงเป็น shape นี้เสมอ งั้นพอมันเป็น shape นี้เรา block shape นี้ได้ ข้อดีก็คือว่า เราไม่ต้องแก้แอปครับ เราแค่ command เข้าไปบอกเค้าว่า block แอปพลิเคชันที่ยิงเข้ามาด้วย shape เดิมจะเกิด error เข้าไปบอกว่า เอ้ย คุณโดน block เพราะว่า คุณโดนบล็อกเพราะว่าคุณ เขาเรียกว่าอะไร คุณโดนบล็อกเพราะว่า query ของคุณเนี่ยมีปัญหา มันทำการบล็อกคุณ จะมี error ไป detect ทันที อันนี้เรียกว่าเป็น query shape

เพราะฉะนั้นอันนี้ก็จะเป็นคำบอกนะ ผมลงรายละเอียดไปนิดนึง ก็คือเป็นการบอกว่าเราต้องการ reject query ที่รันมาแล้วเป็น collection scan เราต้องการบล็อก query นี้ แล้วก็เข้าไปแก้เลยครับ พิมพ์ command ปุ๊บ กดทำ อันนี้ก็คือสิ่งที่สามารถจะบล็อกได้ทันที

Timeout: ตั้งค่า Max Time ป้องกัน Query ค้าง43:36

ต่อไปก็คือเราจะทำเรื่องของพวก timeout ต่างๆ เรามักจะมีคนถามปัญหาบ่อยว่า connect แล้วเกิด timeout timeout แบบนี้แบบนั้นเราจะทำยังไง หนึ่งนั้นก็คือเราสามารถ set default max time time ได้นะครับผม เพื่อช่วยให้นะครับ การ read เนี่ยมี timeout ได้ด้วยนะครับ ตรงนี้เป็นสิ่งที่เพิ่มเติมขึ้นมา ตรงนี้นะครับ

อ่า ต่อไปนะครับ ส่วนนี้คือเป็นส่วนที่เราบอกว่าเราสามารถที่จะเซ็ต query pattern ได้

Force Index: บังคับ Query ให้ใช้ Index ที่ต้องการ44:06

ปกติเรามีปัญหาครับ ทุกคนเคย force index ไหมครับ เวลาเราเขียน query เรามักจะ force ว่า index มี 3 ตัว แต่เราบอกว่าเราฉากใช้ตัวที่ 3 อ่ะ เราบอกว่า query เราไม่แตะตัวที่ 3 เลย เราบอกว่าเราใช้ hint หรือ force ให้มันใช้ index ตัวที่ 3 ตลอด แต่ตอนนี้เราไม่ต้องทำแบบนั้นนะครับ ไม่ต้องไปแก้ application เราบอกเลยว่า ตอนเนี้ยใช้ shape เนี้ย ถ้าคุณมา index ตัวนี้ คุณใช้ shape นี้เลย

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

มันจะไม่ reset index plan ต่างๆ นะครับ ไม่เซ็ตเลยนะครับ

โอเค นะครับ

Scaling: ย้าย Collection ใน Sharding ได้ง่ายขึ้น44:48

ส่วน scaling นะครับ พูดง่ายๆ ว่า ทำ sharding สามารถ move

collection ที่ไม่ shard ได้ ด้วย command ของมันเอง อัตโนมัติ แล้วก็ทำงานได้เร็ว มีประสิทธิภาพ เราจะเรียกตัวนี้ว่าเป็นการ move shard นะครับ นี่เขาเรียกว่าเป็นการ move collection เนาะ อัตโนมัติ นะครับ ลักษณะก็คือนะครับ ก็คือเราสามารถ move shard ได้เลยเนาะ อันนี้ก็คือเป็น ตัว feature นึงนะครับ เมื่อก่อนเรา move ยากนะ เดี๋ยวนี้เรา move ง่ายนะครับ แค่พิมพ์ command ว่า move collection ไปอยู่ shard ไหน เรา move ได้เลย เพื่อทำให้มัน balance ครับ ทำให้ เอ่อ ตัว shard แต่ละ shard มีความ balance ทั้ง collection ที่ shard และ uncollection เอ่อ unsharding collection นะครับ โอเค ต่อไปก็คือเขาแค่เพิ่มนะครับ ความเร็วในการ ประสิทธิภาพในการทำ reshard คำว่า reshard ก็คือ ทำ shard

หมายความว่า อันนี้ลงนิดเดียวนะครับ การทำ shard ต้องมีการระบุ key ว่าเราจะแบ่ง data ไปแต่ละ ไปแต่ละ server ใช้อะไรเป็นตัวแบ่ง พูดง่ายๆ เจ้าตัวแบ่งเนี่ยนะครับ เวลาเราเลือกผิด เรามักจะต้องสร้างตัวแบ่งนี้ใหม่ สร้างตัวแบ่งนี้ใหม่ ข้อมูลเป็นระดับ 10 terabyte เนี่ย ใช้เวลาหลายวัน เคยทำด้วย key นี้ 10TB เสร็จละ วันนี้คือ อ้าว ผิด เลือก key ผิดอ่ะ ขอเปลี่ยน key ใหม่ reshard ใหม่นะครับ ใช้เวลาอีก 10 กว่าวัน ในระหว่างทำ time performance drop อยู่แล้ว ดังนั้นเขาก็เลยออกแบบให้มีระบบกระบวนการที่เรียกว่า faster resharding ให้เร็วขึ้น คือการเพิ่ม performance นั่นเองนะครับ อันนี้คือภาพที่เห็นนะครับ จากเมื่อก่อน 1TB นะครับ มีการใช้ครับ 220 ชั่วโมงนะ เวอร์ชันนี้

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

Faster Resharding: ลดเวลา Reshard ลง 10 เท่า46:41

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

ต่อไปนะครับ แบบนี้ก็คือเป็นสิ่งที่อำนวยความสะดวก

ลดค่าใช้จ่าย Server ด้วยการยุบ Config Server47:00

ปกติแล้วเวลาเราทำ shard จะมีเซิร์ฟเวอร์อย่างน้อยๆ เพิ่มอีก 3 เครื่อง 1 shard ก็คือมี 3 node อยู่แล้ว แล้วก็มีอีกสามเครื่อง ดังนั้น การทำเซิร์ฟเวอร์ที่เพิ่มเติมขึ้นมา มันทำให้เราเสีย cost มากขึ้น ดังนั้นระบบ shard เลยบอกว่าเราต้องการ ยุบ ค่าใช้จ่ายของบาง server ลง เราเรียก server ตัวนั้นว่า config นะครับ อันนี้อาจจะเป็น detail ไปก่อนนะ ก็คือมันชื่อว่า config config จะเป็น server ที่เราต้องตั้ง ไม่ว่ายังไงเราต้องตั้ง server ไว้ 1 ไว้ 1 set เรียกว่า config ดังนั้นเค้าบอกว่ามี config เพิ่มก็มีค่าใช้จ่ายเพิ่ม เค้าเลยบอกว่าเราย้าย config ครับ มาอยู่ภายใต้ shard สักเครื่องนึง

ที่มี performance น้อยลง แปลว่าแทนที่เราจะต้องสร้างเครื่องคอมพิวเตอร์มา มาทำ config server เราไม่ต้องแล้ว เรารวมมา รวมมาอยู่เป็นส่วนหนึ่งของ shard เลยได้เลยนะครับ เหมาะกับข้อมูลที่มีขนาดอยู่ประมาณไม่เกิน 4TB อันนี้ผมสามารถบอกได้เลยนะ ไม่เกิน 4TB นะครับ ต่อไปนะครับ เรื่อง

Security: เชื่อมต่อ OpenID, Federation ได้ง่ายขึ้น47:59

น่าจะสุดท้ายนะครับ ก็คือตัว security

เพิ่มฟีเจอร์หนึ่ง ปกติแล้วเวอร์ชัน 7 จะมีฟีเจอร์เรื่องการทำ OpenID เราสามารถที่จะทำ connect กับ OpenID

ในการทำ เช่น เราต่อ Azure ID นะ สำหรับทำ single sign-on เราสามารถ manage ตรงนั้นได้ เพื่อเราระบุว่าแอปพลิเคชันเรา base on user role อันไหนที่อยู่ใน MongoDB เราสามารถ manage ในระดับนั้นได้นะครับ เพราะฉะนั้นนี่คือ นี่คือสิ่งที่ เพิ่มความสามารถตรงนั้นลงไปนะครับผม ก็คือการทำ workforce หรือ workload นะครับ ก่อนหน้านี้เราต้องสร้าง user แบบ one by one ปกตินะ หรือแม้กระทั่งต่อพวก Azure แต่ตอนนี้เราสามารถจะทำแบบ link ไปที่พวกตัวที่เป็น OAuth ได้แล้วโดยตรง หรือพวกที่เป็นตัว service support ที่เป็นตัว federation ของ Azure หรือของ GCP ได้นะครับ

ส่วนนี้ก็คือเรียกว่าการ query ผมไม่แน่ใจว่าทุกท่าน

เคยใช้หรือเปล่า ว่าเรามีการ encrypt data ระดับ field ได้

Queryable Encryption: ค้นหาข้อมูลที่เข้ารหัสแบบ Range ได้แล้ว49:01

ซึ่ง encrypt ไม่ใช่เรื่องแปลกนะทุกคน encrypt database ทุกตัว encrypt ได้ แต่ encrypt แล้วไม่ต้องแกะ ไม่ต้อง decrypt แต่ query ได้ ไม่ decrypt แต่ query ได้

เบื้องหลังง่ายมากครับ ก็คือ มันก็คงไม่ง่าย แต่ผมเข้าใจแบบมุมง่ายๆ คือ มันใช้วิธีการ เอ่อ ใช้ index ไป compare

เพราะฉะนั้นเค้าไม่ถอดรหัสนะ ข้อมูลที่คุณเห็นจะเป็นดาวๆ นะครับ ก็คือแสดงผลไม่ได้ นอกจากคุณมี key ไปถอดให้อ่าน ดังนั้นไม่มีใครอ่านได้ แต่ query ได้ เมื่อก่อนมัน query ได้ คือเช่นผมเก็บเลขบัตรประชาชนว่า 1 2 3 นะครับ พอผมเข้ารหัสปุ๊บมันจะกลายเป็นดาวๆ ๆ ผมต้องการ where ว่าต้องการอ่านข้อมูลที่เป็น ID เท่ากับ 1 2 3 ที มันไม่ได้ไปแกะไอ้ดาวๆ ๆ มาเป็น 1 2 3 นะครับ มันใช้เทคนิค อื่นในการจัดการเรื่อง index แล้วมันก็ไปค้นแบบ record เนี้ยเป็นเลข 1 2 3 4 มาโชว์ให้เราเห็น โดยที่ไม่ต้องถอดรหัสเลย เมื่อก่อนมันทำได้แค่ compare แบบเท่ากับ ตอนนี้ feature เพิ่มขึ้นก็คือ compare แบบ range ครับ ก็คือสามารถทำได้ก็คือมากกว่าน้อยกว่านี่นะครับ

หรือว่ามากกว่าเท่ากับ หรือว่าน้อยกว่าเท่ากับได้นะครับ อันนี้เป็น feature แรกที่ MongoDB ชูเมื่อตอนเป็นเวอร์ชัน 7 เนาะ ตอนเวอร์ชัน 8 ก็เลยเพิ่ม feature ในการทำเรื่อง range นะครับ อันนี้เราเรียกเป็นตัว QE เนาะ ก็คือ queryable encryption นะครับ

Log Format: รองรับมาตรฐาน Open Cybersecurity50:26

ต่อไปก็คือ เพิ่มมาตรฐานของเรื่อง log format ครับ อันนี้ก็เป็นไปตามมาตรฐานนะ ถ้าใครใช้มาตรฐาน open cybersecurity ครับ format เราสามารถจะเซ็ต ให้ log ที่ run ออกมานะครับ เข้ามาตรฐานนั้นเพื่อเอาไปใช้งานต่อ หรือไป approve ตามมาตรฐาน เพราะว่าเรามีหน่วยงานหลายๆ หน่วยงานที่ต้อง comply ตามมาตรฐานนั่นเองนะครับ

สรุป What's New in MongoDB 8.050:51

โอเค นะครับ อันนี้ก็คือ สิ่งที่จะเข้ามานะครับ ในเวอร์ชั่น 8 อาจจะเร็วไปนิดนึง

เพราะ content มันค่อนข้างเยอะมาก จะมีอีกหลายส่วนมากนะครับ ก็จะประมาณนี้นะครับผม มีคำถามไหมครับ

ทำเวลามาก เนื้อหาหนักมากครับ