модуль журнала с предварительно выделенной памятью

Question

Я пишу механизм регистрации, который будет использоваться остальной частью кода для записи буквенно-цифровых данных в файл. Каждый другой модуль в системе будет отправлять буквенно-цифровые предложения (пару слов в макс.), Которые будут записываться в файл непрерывно. Уловка: мне было предоставлено небольшое количество предварительно выделенной памяти для использования в моих структурах данных и в хранении этих сообщений журнала. Если поток больше того, что можно записать на диск, сообщения журнала будут отброшены.

Я хочу установить механизм сжатия между клиентом и хранилищем в памяти в моем модуле журнала, чтобы я мог сохранять как можно больше сообщений.

Мой текущий дизайн до сих пор:

КЛИЕНТ ------> LOG МОДУЛЬ ---->компресс и хранить в памяти в буфер 1

Автор Тема: Когда его время для записи, переключите буфер 1 с буфером 2 и напишите буфер 1 в файл. Клиент будет писать в буфер 2 за это время.

Script вне: Decompress и показать сообщения журнала

Вопрос: Что такое хороший буквенно-цифровой алгоритм сжатия можно использовать или хорошая структура данных, я могу использовать, чтобы захватить как можно больше данных, насколько это возможно (во время стадии сжатия выше)?

Если возможно, мне нужен алгоритм, который не хранит код сжатия в промежуточной структуре данных - то есть, если система выходит из строя, я хочу иметь возможность распаковывать все, что было записано в файл до сих пор.

Попытка до сих пор: присваивать код каждому используемому charecter. Не кажется таким гибким.

Большинство из журнала сообщений представляют собой простые текстовые предложения

Answer 1

Вопрос: Что такое хороший буквенно-цифровой алгоритм сжатия можно использовать или хорошая структура данных, я могу использовать, чтобы захватить как можно больше данных, насколько это возможно (при сжатии этап выше)?

В общем, чем медленнее и голоднее, тем лучше коэффициент сжатия. Различные кодеки делают разные компромиссы, и даже в некоторых кодеках вы можете настроить различные параметры для получения разных компромиссов.

Кодеки также имеют тенденцию работать по-разному с разными данными. Есть несколько ориентиров, плавающих вокруг, но это даст вам общее представление о производительности; чтобы действительно выбрать лучший, вам нужно попробовать их с вашими данными и провести собственные измерения.

Что касается предотвращения потери данных при сбое процесса, то с вашим текущим дизайном вам нужен потоковый кодек, поддерживающий промывку. Каждый раз, когда вы завершаете протоколирование сообщения, вы хотите сказать, что кодек скрыт.API для этого, будет зависеть от кодека, но, как правило, вы будете в конечном итоге с чем-то вроде

foo_compress(stream, output, input); 
foo_flush(stream); 
fwrite(stream->output, 1, stream->output_size, file); 
fflush(stream); 

Несколько библиотек предоставляют API для чтения/записи на диск (что позволяет пропустить fwrite/fflush). Приходят на ум сквош, gzip и lzham, но, вероятно, есть и другие. Однако по большей части библиотека просто сжимается до буфера, и вы несете ответственность за запись буфера в файл.

Ваше главное препятствие здесь состоит в том, что многие алгоритмы не поддерживают промывку. Сверху моей головы, gzip, lzham, brotli, bzip2, lzma, zstd, и я думаю lz4f поддержка промывки. bzip2, вероятно, не будет работать очень хорошо, если вы сделаете много промывки, и если это новая система, вероятно, не так много причин для использования gzip или lzma (zstd превосходит gzip, а brotli и lzham превосходят lzma почти в каждом путь).

Это означает, что если вы просто пытаетесь избежать потери данных из-за сбоев в ваш код (т. Е. Вы хотите сохранить данные, когда ваша программа выйдет из строя, но вы не слишком беспокоитесь о сбое ОС) вы можете рассмотреть возможность разделения сжатия и ввода-вывода на отдельный процесс. В этот момент вы получаете нечто похожее на syslog или более новые структурированные API ведения журналов, такие как journald, ASL или удивительно неприятный Windows Event Log API.