Устройство хранения данных многих файлов журнала
Неизменяемые объекты
Объект считается неизменным, если его состояние не может измениться после его построения. Максимальная опора на неизменяемые объекты широко принята в качестве разумной стратегии для создания простого и надежного кода.
Неизменяемые объекты особенно полезны в параллельных приложениях. Так как они не могут изменить состояние, они не могут быть повреждены из-за интерференции потоков или обнаружены в несовместимом состоянии.
Программисты часто неохотно используют неизменные объекты, потому что они беспокоятся о стоимости создания нового объекта, а не об обновлении объекта на месте. Воздействие создания объекта часто переоценивается и может быть компенсировано некоторыми из преимуществ, связанных с неизменяемыми объектами. К ним относятся снижение накладных расходов из-за сбора мусора и устранение кода, необходимого для защиты изменяемых объектов от повреждения.
Следующие подразделы берут класс, экземпляры которого являются изменяемыми, и получают класс с неизменяемыми экземплярами из него. При этом они дают общие правила для такого рода преобразования и демонстрируют некоторые преимущества неизменных объектов.
5 ответов
Я бы выбрал самое первое решение.
Я не понимаю, зачем вам БД нужна вообще. Похоже, все, что вам нужно, - это просмотреть данные. Сохраняйте журналы в наиболее «сыром» состоянии, затем обрабатывайте их и создавайте архив на каждый день.
Единственная причина для агрегирования - уменьшить количество файлов. В некоторых файловых системах, если вы помещаете более N файлов в каталог, производительность быстро снижается. Проверьте свою файловую систему и, если это так, организуйте простую двухуровневую иерархию, скажем, используя первые 2 цифры идентификатора производителя в качестве имени каталога первого уровня.
Я бы написал один файл для каждой загрузки и один каталог в день, как вы впервые предложили. В конце дня запустите обработку файлов, а затем tar.bz2 каталога.
Архив по-прежнему будет доступен для поиска и, вероятно, будет довольно маленьким, поскольку журналы обычно могут сжиматься довольно хорошо.
Для общих данных вы говорите о 1 ГБ [исправлено 10 МБ] в день без сжатия. Скорее всего, это будет сжато до 100 МБ или меньше. Я' я видел 200-кратное сжатие моих файлов журналов с помощью bzip2. Вы можете легко хранить сжатые данные в файловой системе в течение многих лет, не беспокоясь. Для дополнительной обработки вы можете писать сценарии, которые могут искать в сжатом архиве и генерировать дополнительную статистику.
Поскольку вы хотите сохранить их, чтобы иметь возможность вычислять разное. статистику по ним каждую ночь, экспорт их (упорядоченный по дате прибытия или содержанию первой строки) ... Вы ожидаете 100 000 файлов в день, всего 10 000 000 строк:
Я бы предложил:
- Хранить все файлы в виде обычных текстовых файлов, используя следующий формат: ггггммдд / productrid / fileno.
- В конце дня очищает базу данных и загружает все текстовые файлы за день.
- После загрузки. файлы, будет легко получить статистику из базы данных и опубликовать ее в любом необходимом формате. (может быть, еще одна "статистика"). Вы также можете создавать графики.
- Чтобы сэкономить место, вы можете сжать ежедневную папку. Поскольку это текстовые файлы, они хорошо сжимаются.
Таким образом, вы могли бы использовать базу данных только для того, чтобы легко агрегировать данные. Вы также можете воспроизвести отчеты за более ранний день, если процесс не сработал, выполнив те же действия.
To my experience, single large table performs much faster then several linked tables if we talk about database solution. Particularly on write and delete operations. For example, splitting one table into three linked tables decreases performance 3-5 times. This is very rough, of course it depends on details, but generally this is the risk. It gets worse when data volumes get very large. Best way, IMO, to store log data is not in a flat text, but rather in a structured form, so that you can do efficient queries and formatting later. Managing log files could be pain, especially when there are lots of them and coming from many sources and locations. Check out our solution, IMO it can save you lots of development time.
(Отказ от ответственности: я работаю над MongoDB.)
Я думаю, что MongoDB - лучшее решение для ведения журнала. Это невероятно быстро, поскольку, вероятно, он может вставлять данные быстрее, чем вы их отправляете. Вы можете выполнять интересные запросы к данным (например, диапазонам дат или уровням журнала), а также к индексу и полю или комбинации полей. Это также приятно, потому что вы можете случайным образом добавлять дополнительные поля в журналы ("ой,