Накопилось 800GB в MongoDB, индексы не лезут в RAM — что делать?

[jbosco]

MongoDB 7, коллекция разрослась до 800GB, рабочий набор индексов уже не помещается в RAM сервера (64GB). Запросы по холодным данным проседают в разы. Шардить, апгрейдить железо или резать данные? Бюджет ограничен.

[ronox]

800GB на одном инстансе с 64GB RAM — ты уже за пределами комфортной зоны. Либо вертикально докинуть память (это дешевле шардинга в обслуживании), либо TTL-индекс и архивировать старое в холодное хранилище.

[asynclover]

Часть данных реально старше года и почти не читается. TTL вариант, но удалять жалко, нужно для аудита.

[kernel_veteran]

Тогда не TTL а online archive: выгружай старьё в S3/Parquet через mongodump или Atlas Online Archive, в горячей базе оставляй только свежак. Аудит по холодному хвосту делается раз в год, ему скорость не нужна.

[tatiankake]

А не проще ли просто на постгрес с партиционированием уехать раз уж данные аудитные и схема стабильная?

[qcdeed]

Если схема устаканилась и нужна аналитика по аудиту — да, PostgreSQL с partition by range по дате тут будет уместнее и дешевле в эксплуатации. Старые партиции можно вообще detach и на медленный диск.

[pythonfan]

Хорошо, план такой: чищу мёртвые индексы прямо сейчас (быстрая победа), а параллельно делаю PoC выгрузки холодного хвоста в архив. Спасибо, разложили по полочкам!

[TcpAdmin]

800 ГБ с индексами которые не влезают в 64 ГБ — это сигнал что пора смотреть на архивирование холодных данных ещё до шардинга. Сначала сделай db.collection.stats() и смотри на totalIndexSize. Скорее всего там несколько compound-индексов которые дублируют друг друга или покрывают запросы которые давно не используются. Через explain("executionStats") прогони топ медленных запросов и выброси индексы которые не попадают ни в один IXSCAN. У нас на аналогичном объёме это дало минус 30% от размера индексов.

[tiger31]

Если чистка индексов не помогает — Time-Series collections в MongoDB 7 дают встроенное compressed-хранение для временных данных с гораздо меньшим footprint индексов. Если у тебя есть timestamp-поле и данные старше 6-12 месяцев нужны редко — мигрируй исторические данные в отдельную TS-коллекцию с TTL или просто в архивную без индексов. Горячая коллекция с 90 днями данных влезет в RAM гораздо лучше.

[grahamd]

Шардинг при ограниченном бюджете — боль, потому что нужны минимум 3 конфиг-сервера + 2 шарда. Но есть промежуточный вариант: Atlas Online Archive (если готов к облаку) или просто MongoDB Atlas M30 с авто-индексированием. Если self-hosted — смотри на WiredTiger cache size, по умолчанию он берёт 50% RAM минус 1 ГБ, то есть у тебя 31.5 ГБ кэша. Проверь через db.serverStatus().wiredTiger.cache что eviction не слишком агрессивный — если "pages evicted by application threads" растёт, это и есть твои просадки.