เผยแพร่ครั้งแรกโดย Tricore: 24 สิงหาคม 2560
ในภาคที่ 1 ของซีรีส์นี้ เราแชร์เคล็ดลับบางประการสำหรับการใช้ MongoDB ในภาคที่ 2 เราจะครอบคลุมหัวข้อ MongoDB เพิ่มเติมหลายประการ รวมถึง การเพิ่มประสิทธิภาพ, ประสิทธิภาพ, ความเร็ว, การสร้างดัชนี, การออกแบบสคีมา และความปลอดภัยของข้อมูล
เคล็ดลับที่ 1: เรียนรู้การใช้ตัวเลือก --notablescan ในการพัฒนา (แต่ไม่ใช่ใน Production)

แหล่งที่มา: www.percona.com
MongoDB มีตัวเลือก --notablescan ที่ส่งคืนข้อผิดพลาดเมื่อคิวรี่ต้องทำ Full Table Scan ตัวเลือกนี้มีประโยชน์ในสภาพแวดล้อมการพัฒนา หากคุณต้องการให้แน่ใจว่าคิวรี่ทั้งหมดใช้ดัชนี อย่างไรก็ตาม เราไม่แนะนำให้ใช้ในสภาพแวดล้อม Production เพราะอาจก่อให้เกิดปัญหาประสิทธิภาพ ปัญหาคือ งานบริหารจัดการง่ายๆ หลายอย่างต้องการ Table Scan ตัวเลือกนี้ช่วยให้คุณเห็นรายการ Collection ในฐานข้อมูลของคุณที่ต้องการ Full Table Scan
เคล็ดลับที่ 2: จัดการเซิร์ฟเวอร์และฐานข้อมูลทั้งหมดจาก Shell เดียว
โดยค่าเริ่มต้น MongoDB เชื่อมต่อกับ localhost: 27017 คุณสามารถเชื่อมต่อกับเซิร์ฟเวอร์ใดก็ได้ตอนเริ่มต้นโดยรัน mongo host: port/database คุณยังสามารถเชื่อมต่อกับหลายเซิร์ฟเวอร์หรือฐานข้อมูลภายใน Shell ได้
ตัวอย่างเช่น สมมติว่าเรามีแอปพลิเคชันที่ใช้ทั้งฐานข้อมูลของ Dealer และ Distributor ด้วย MongoDB เราสามารถสลับไปมาระหว่างสองฐานข้อมูลภายใน Shell เดียวกันได้
เคล็ดลับที่ 3: รู้จัก JavaScript
เมื่อคุณใช้ภาษาที่มี Shell ดีของตัวเอง คุณควรคุ้นเคยกับ JavaScript® ภาษา JavaScript เป็นที่นิยมในหมู่ผู้ใช้ MongoDB เพราะเป็นวิธีที่เร็วที่สุดและดีที่สุดในการเข้าถึงข้อมูล JavaScript เป็นภาษาที่ยืดหยุ่นและทรงพลังมาก มีคุณสมบัติยอดเยี่ยมที่จะช่วยให้คุณได้ประโยชน์สูงสุดจาก Shell
เคล็ดลับที่ 4: สำรองข้อมูลเซิร์ฟเวอร์แบบ Instant-in-time
เพื่อสำรองฐานข้อมูลที่เปิดใช้งาน Journaling คุณสามารถทำได้สองวิธี: สร้าง Snapshot ระบบไฟล์ (File System Snapshot) หรือทำ fsync+lock ตามปกติแล้วตามด้วย Dump โปรดทราบว่าคุณไม่สามารถคัดลอกไฟล์ทั้งหมดโดยไม่มี fsync และการ Lock ได้ เพราะการคัดลอกไม่ใช่การดำเนินการที่เกิดขึ้นทันที (Instantaneous) หากการคัดลอกไฟล์ Journal และไฟล์สำรองอยู่บน Volume ต่างกัน สำรองข้อมูลอาจกลายเป็นไร้ประโยชน์ในเวลาต่อไป
เคล็ดลับที่ 5: พยายามดึงข้อมูลจากคิวรี่เดียว
คำว่า Application Unit ใช้สำหรับบางประเภทของงานแอปพลิเคชัน Application Unit โดยพื้นฐานแล้วคือหน่วยงานที่แยกจากกันของแอปพลิเคชันที่อาจเกี่ยวข้องกับการเข้าถึงฐานข้อมูล คุณควรออกแบบสคีมา MongoDB ให้ทำคิวรี่หนึ่งคิวรี่ต่อหนึ่ง Application Unit
หากคุณมีเว็บหรือแอปพลิเคชันมือถือ คุณสามารถคิดว่า Application Unit คือ Request ไปยัง Backend
นี่คือตัวอย่างอื่นๆ:
-
สำหรับแอปพลิเคชันเดสก์ท็อป Application Unit อาจหมายถึงการโต้ตอบของ User-Client
-
สำหรับระบบวิเคราะห์ (Analytics) Application Unit อาจหมายถึงการโหลดแดชบอร์ด (Dashboard Load)
สรุป
MongoDB เป็นฐานข้อมูลที่รวดเร็ว ทนทาน และขยายได้สูง ทำงานบนหลายแพลตฟอร์ม และมีไดรเวอร์ภาษามากมายสำหรับการใช้งานที่เหมาะสมที่สุด
MongoDB กำลังเป็นที่นิยมมากขึ้นทุกวัน การเข้าใจพื้นฐานของ MongoDB และวิธีใช้งานให้ดี เป็นการกระทำที่ยอดเยี่ยมสำหรับนักพัฒนาทุกคน
คุณกำลังเรียนรู้การใช้ MongoDB อยู่หรือไม่? บอกเราเกี่ยวกับประสบการณ์ของคุณโดยใช้แท็บ Feedback