Общая информация: система клиент-серверная, сервер на джава, клиент нынешний -- на дельфи. Предполагается, что протокол будет открытым, и когда-нибудь информация, предоставляемая через него сервером будет использоваться разными клиентами для разных целей. Система уже существовала в виде версии 1.0, можно считать -- прототипа. Сейчас идет полное переписывание с 0 серверной части, и значительное -- клиентской.
Сервер мониторит некоторую систему, и, по результатам мониторинга, пишет логи. Логи -- текстовые файлы, роллятся каждый день. Логи эти в дальнейшем доступны через сетевой интерфейс, на их основе делается анализ функционирования мониторимой системы.
Амбула: обсуждаем формат записи в логе. Унаследованный от прототипа формат такой: каждое измерение одной строкой, в строке время, и, через запятую -- числа-результаты. Время -- в формате hh:mm -- 19:30. Например: 19:30, 123564, 5634565, 345645654, 1233
Первый вопрос, который у меня возник: почему только время? Где дата? Оказывается -- дата берется из названия файла (файлы роллятся каждый день, помните? и дата сохраняется в имени файла). Ок, говорю, но ведь так получается, что запись в логе несамодостаточна -- мало иметь саму строчку, надо знать еще, из какого файла она взялась. Давай вместо (или вместе -- чтобы сохранить обратную совместимость) времени будем писать timestamp -- например, в unix-time. Ответ -- "ну это же лишние 11 байт! Да и парсер надо будет переписывать."
На мой взгляд, это хороший пример того, как
- Не надо экономить на спичках. Примерный размер лога за день -- 100Кб. Timestamp может нам сэкономить примерно 10% от этого размера -- 10Кб в день. При том, что сервер, предполагается, мониторит промышленную систему с террабайтами данных -- копейки. Но этого мало: если действительно стоит вопрос оптимизации размера (а его на повестке дня не стояло, и не стоит до сих пор. И при проектировании прототипа, когда этот формат файла создавался, такого вопроса тоже не стояло) то простейшее сжатие логов зипом уменьшит их размер раза в 3-4 -- при полном сохранении данных.
- Форматы и протоколы надо стараться разрабатывать с возможностью расширения. Почему ради добавления одной колонки надо переделывать парсер?