Ответ 1
Эй, Влад, у вас есть пара простых стратегий, касающихся журналов.
Первое, что нужно знать, это то, что Mongo обычно может обрабатывать множество последовательных вставок без большого количества оперативной памяти. Причина этого проста, вы только вставляете или обновляете последние материалы. Таким образом, размер индекса растет, но данные будут постоянно выгружаться.
Другими словами, вы можете разделить использование ОЗУ на две основные части: индекс и данные.
Если вы используете типичное ведение журнала, часть данных постоянно удаляется, поэтому только индекс действительно остается в ОЗУ.
Второе, что нужно знать, это то, что вы можете уменьшить проблему с индексом, поставив журналы на более мелкие ведра. Подумайте об этом так. Если вы соберете все журналы в коллекции с меткой даты (назовите ее logs20101206), вы также можете управлять размером индекса в ОЗУ.
По мере того, как вы переходите через несколько дней, старый индекс будет скрываться из ОЗУ, и он снова не будет доступен, поэтому он просто исчезнет.
но я также рассматриваю использование cron script, который выгружает и удаляет старые данные
Этот метод регистрации по дням также помогает удалять старые данные. Через три месяца, когда вы закончите с данными, вы просто делаете db.logs20101206.drop(), и коллекция моментально уходит. Обратите внимание, что вы не освобождаете место на диске (все предварительно выделенные), но новые данные заполнят пустое место.
Должен ли я также использовать меньшие клавиши, как это было предложено на других форумах?
Да.
Фактически, я встроил его в свои объекты данных. Поэтому я получаю доступ к данным с помощью logs.action или logs->action, но под ними данные фактически сохраняются в logs.a. Это действительно легко потратить больше места на "поля", чем на "ценности", поэтому стоит сжимать "поля" и пытаться отвлечь его в другом месте.