Здравствуйте! Система категоризации Живого Журнала посчитала, что вашу запись можно отнести к категории: Технологии. Если вы считаете, что система ошиблась - напишите об этом в ответе на этот комментарий. Ваша обратная связь поможет сделать систему точнее. Фрэнк, команда ЖЖ.
А, ну то есть, данные должны переживать перезагрузку? Хмм.
Тогда бы посоветовал реализовать вроде кольцевого буфера, только в дисковом файле, а не в памяти. Есть файл, отдельно хранится адрес начала чтения, и кол-во байтов, доступных для чтения. Как-то так.
Гхм. Кмк, это либо на уровне файловой системы поддерживаться дОлжно (кажется, вдосовском FATe было что-то такое когда-то - для файлов баз данных) - либо на уровне СУБД можно реализовывать. Типо "кластеры" - отдельные записи в таблице + ключевые поля для упорядочивания + мпометка записей как "удалённых" (ну или спесияльное дополнительное поле). И вперёд...
В linux довольно часто используется, например для образов дисков. Ничего особенного, кроме установки нужного offset не требуется. В винде вроде надо при создании файла флажок ставить, но тут я не знаю точно. Однако, это, похоже не то, что вам надо, удалять данные из файла невозможно, только переписывать (да собственно, по-моему, нигде так нельзя делать). Самое подходящее для вас, делать это через копирование нужных данных в другой файл, пропуская ненужные. Ну или, как тут правильно подсказали, организовать кольцевой буфер. Или использовать redis, данные в нём перезагрузку переживают, нужно только проверить настройки, в некоторых сборках пакета это отключают по умолчанию для скорости.
То, что вы описываете - это классическая очередь (persistent queue). Подойдет плюс-минус любая реализация очередей, например RabbitMQ. Если у вас уже есть Redis, Kafka или IBM MQ, можно использовать их, если нет - я бы взял Rabbit.
Comments 14
Система категоризации Живого Журнала посчитала, что вашу запись можно отнести к категории: Технологии.
Если вы считаете, что система ошиблась - напишите об этом в ответе на этот комментарий. Ваша обратная связь поможет сделать систему точнее.
Фрэнк,
команда ЖЖ.
Reply
И во всех Юниксах, и во всех Виндах - есть pipes. Иногда даже named pipes.
Reply
1. емкость около 1 страницы, а не стопицот
2. при перезагрузке данные теряются
Reply
А, ну то есть, данные должны переживать перезагрузку? Хмм.
Тогда бы посоветовал реализовать вроде кольцевого буфера, только в дисковом файле, а не в памяти. Есть файл, отдельно хранится адрес начала чтения, и кол-во байтов, доступных для чтения. Как-то так.
Reply
ага. именно оно. но, как-то так, уже прочитанное начало нужно убирать нахрен, а не хранить вечно.
Reply
Кмк, это либо на уровне файловой системы поддерживаться дОлжно (кажется, вдосовском FATe было что-то такое когда-то - для файлов баз данных) - либо на уровне СУБД можно реализовывать.
Типо "кластеры" - отдельные записи в таблице + ключевые поля для упорядочивания + мпометка записей как "удалённых" (ну или спесияльное дополнительное поле).
И вперёд...
Reply
>> (кажется, вдосовском FATe было что-то такое когда-то
Насколько помню - нет. Нет специального значения в FAT, чтоб показать "в этом кластере нет данных".
Reply
В linux довольно часто используется, например для образов дисков. Ничего особенного, кроме установки нужного offset не требуется. В винде вроде надо при создании файла флажок ставить, но тут я не знаю точно.
Однако, это, похоже не то, что вам надо, удалять данные из файла невозможно, только переписывать (да собственно, по-моему, нигде так нельзя делать). Самое подходящее для вас, делать это через копирование нужных данных в другой файл, пропуская ненужные.
Ну или, как тут правильно подсказали, организовать кольцевой буфер. Или использовать redis, данные в нём перезагрузку переживают, нужно только проверить настройки, в некоторых сборках пакета это отключают по умолчанию для скорости.
Reply
Подойдет плюс-минус любая реализация очередей, например RabbitMQ.
Если у вас уже есть Redis, Kafka или IBM MQ, можно использовать их, если нет - я бы взял Rabbit.
Reply
Leave a comment