ניהול מקצועי של MongoDB לאפליקציות ווב

ניהול MongoDB מקצועי עבור יישומי אינטרנט

דמיינו שיישום האינטרנט שלכם מתחיל להאט—דפים נטענים תוך 10 שניות, והלוגים מלאים בשאילתות MongoDB איטיות. לקוחות מתלוננים, ואתם לא מצליחים להבין למה. לרוב, הסיבה היא אינדקסים חסרים או תצורת replica set לא אופטימלית. אנו עוזרים לחברות להימנע ממצבים כאלה, ומספקים ניהול MongoDB כולל. צרו קשר לבדיקת MongoDB—נעריך את המצב הנוכחי ונציע תוכנית.

לאחרונה, סייענו לחנות מסחר אלקטרוני עם 50,000 מוצרים. מסד הנתונים היה MongoDB 6.0 עם replica set בעל שלושה צמתים. לאחר הבדיקה, גילינו ש-30% מהאינדקסים לא היו בשימוש, וגודל ה-oplog היה רק 1 GB—תחת כתיבות כבדות, פיגור השכפול הגיע לשעתיים. ייעלנו את האינדקסים, הגדלנו את ה-oplog ל-10 GB, והגדרנו ניטור. זמן התגובה של מסד הנתונים ירד פי עשרה.

כיצד פועלת בדיקת MongoDB?

אנו מתחילים באבחון. אנו אוספים סטטיסטיקות על מסדי נתונים, אוספים ואינדקסים באמצעות db.stats() ו-db.collection.stats(). אנו מזהים אינדקסים שאינם בשימוש או לא יעילים דרך $indexStats. אנו בודקים את תצורת ה-replica set וגודל ה-oplog. התוצאה היא מפת צווארי בקבוק.

הנה סקריפט טיפוסי לאיסוף נתונים ראשוני:

// mongosh use mydb
// Статистика базы
db.stats({ scale: 1024 * 1024 })
// Статистика коллекций
db.runCommand({ listCollections: 1 }).cursor.firstBatch.forEach(c => {
  const stats = db[c.name].stats({ scale: 1024 })
  printjson({ name: c.name, docs: stats.count, size_kb: stats.size, storageSize_kb: stats.storageSize, totalIndexSize_kb: stats.totalIndexSize, nindexes: stats.nindexes })
})
// Индексы коллекции с размерами
db.orders.stats().indexSizes
// Операции, выполняющиеся прямо сейчас (> 1 секунды)
db.currentOp({ "secs_running": { $gt: 1 } })

כיצד אנו מייעלים שאילתות?

השלב הראשון הוא יצירת אינדקסים מתאימים. אנו משתמשים באינדקסים מורכבים לשאילתות טיפוסיות, אינדקסים חלקיים לסינון רשומות פעילות, ואינדקסי TTL למחיקה אוטומטית של נתונים מיושנים. דוגמאות:

// Составной индекс для типичного запроса по пользователю и дате
db.orders.createIndex(
  { user_id: 1, created_at: -1 },
  { background: true, name: "idx_user_date" }
)

// Частичный индекс — только для активных заказов
db.orders.createIndex(
  { created_at: -1 },
  { partialFilterExpression: { status: { $in: ["pending", "processing"] } }, name: "idx_active_orders_date" }
)

// TTL индекс для автоудаления устаревших сессий
db.sessions.createIndex(
  { expires_at: 1 },
  { expireAfterSeconds: 0, name: "ttl_sessions" }
)

אנו מוודאים שימוש באינדקסים דרך // mongosh use mydb // Статистика базы db.stats({ scale: 1024 * 1024 }) // Статистика коллекций db.runCommand({ listCollections: 1 }).cursor.firstBatch.forEach(c => { const stats = db[c.name].stats({ scale: 1024 }) printjson({ name: c.name, docs: stats.count, size_kb: stats.size, storageSize_kb: stats.storageSize, totalIndexSize_kb: stats.totalIndexSize, nindexes: stats.nindexes }) }) // Индексы коллекции с размерами db.orders.stats().indexSizes // Операции, выполняющиеся прямо сейчас (> 1 секунды) db.currentOp({ "secs_running": { $gt: 1 } }) ומנתחים תוכניות שאילתות עם // Составной индекс для типичного запроса по пользователю и дате db.orders.createIndex( { user_id: 1, created_at: -1 }, { background: true, name: "idx_user_date" } ) // Частичный индекс — только для активных заказов db.orders.createIndex( { created_at: -1 }, { partialFilterExpression: { status: { $in: ["pending", "processing"] } }, name: "idx_active_orders_date" } ) // TTL индекс для автоудаления устаревших сессий db.sessions.createIndex( { expires_at: 1 }, { expireAfterSeconds: 0, name: "ttl_sessions" } ) . אם אנו רואים COLLSCAN עם מספר גדול של מסמכים, יש צורך דחוף באינדקס. מידע נוסף על יצירת אינדקסים ניתן למצוא בתיעוד הרשמי של MongoDB.

אינדקס מורכב יכול להאיץ שאילתות פי 100 בהשוואה לסריקת אוסף מלאה, בעוד אינדקסים חלקיים תופסים 60% פחות מקום ומאיצים כתיבות.

כיצד להגדיר Replica Set וניטור?

הגדרת replica set מורכבת מ-4 שלבים:

1. אתחול הסט עם מזהה.
2. הוספת חברים: primary, secondary, arbiter.
3. הגדרת עדיפויות לניהול בחירות primary.
4. בדיקת סטטוס ובדיקת failover.

הנה דוגמה לאתחול:

rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongo1:27017", priority: 2 },
    { _id: 1, host: "mongo2:27017", priority: 1 },
    { _id: 2, host: "mongo3:27017", arbiterOnly: true }
  ]
})

מדוע גודל Oplog נכון חשוב?

ה-oplog הוא יומן פעולות המאפשר לצמתים משניים לסנכרן עם ה-primary. אם ה-oplog קטן מדי, הצמתים המשניים עלולים לפגר ולאבד סנכרון. אנו ממליצים על גודל oplog המכסה לפחות 6 שעות של פעילות כתיבה שיא. לחישוב: גודל oplog = (קצב כתיבה ממוצע בבתים/שנייה) × 3600 × 6. במקרה של חנות המסחר האלקטרוני, הגדלת ה-oplog מ-1 GB ל-10 GB פתרה את בעיית פיגור השכפול.

כיצד אנו מטפלים בגיבויים ושחזורים?

עבור מסדי נתונים עד כמה GB, אנו משתמשים ב-$indexStats מצומת משני עם rs.initiate({ _id: "rs0", members: [ { _id: 0, host: "mongo1:27017", priority: 2 }, { _id: 1, host: "mongo2:27017", priority: 1 }, { _id: 2, host: "mongo3:27017", arbiterOnly: true } ] }) לעקביות. עבור מסדי נתונים גדולים יותר (>100 GB), אנו משתמשים בתמונות מערכת קבצים (LVM, EBS). אנו בודקים שחזורים מדי חודש כדי להבטיח שלמות נתונים.

השוואת שיטות גיבוי:

סיכום: מה כלול

כמה זמן זה לוקח?

לוחות הזמנים תלויים במורכבות: בדיקה בסיסית אורכת 2–3 ימים, הגדרת replica set מלאה עם אינדקסים וניטור אורכת 5–7 ימים. אנו מעריכים פרויקטים באופן אישי—צרו קשר להצעת מחיר מדויקת.

מדוע לסמוך עלינו בניהול MongoDB?

עם ניסיון של 7+ שנים ולמעלה מ-40 פרויקטים מוצלחים של אופטימיזציית MongoDB, אנו לא רק מגדירים את מסד הנתונים—אנו מבטיחים שהוא מתמודד עם העומס. אנו משתמשים רק בגרסאות יציבות (MongoDB 7.0+, WiredTiger) ומיישמים תבניות כמו Repository ו-BFF להפחתת עומס. המהנדסים שלנו מחזיקים בהסמכות MongoDB.

קבלו ייעוץ לפרויקט שלכם—נעריך את המצב הנוכחי ונציע תוכנית.