Структура для большого объема полупостоянных данных?

Мне нужно отслеживать большой объем сообщений inotify для набора файлов, которые в течение своего существования будут перемещаться между несколькими конкретными каталогами с неповрежденными индексными дескрипторами; Мне нужно отслеживать перемещение этих инодов, а также создавать/удалять и изменять содержимое файла. Будет много сотен изменений в секунду.

Из-за ограниченных ресурсов я не могу хранить все это в оперативной памяти (или на диске, или в базе данных).

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

Так что мне кажется, что мне нужна структура данных, которая частично хранится в оперативной памяти, а частично на диске; часть части, сохраненной на диске, необходимо будет отозвать (файлы не будут удалены), но большинство не будет. Мне не нужно будет запрашивать данные, я могу получить к ним доступ только по идентификатору (имя файла, то есть [A-Z0-9]{8}). Было бы полезно иметь возможность настроить, когда данные файла сбрасываются на диск.

Существует ли такой зверь?

Изменить: я задал соответствующий вопрос.


python inotify
person mikewaters    schedule 01.07.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Почему не база данных? Скажи SQLite.

Хотя SQLite не является самым эффективным механизмом хранения с точки зрения занимаемого места, у него есть ряд преимуществ. Первое и главное состоит в том, что является реляционной СУБД SQL. Объем памяти, который SQLite использует (для временного кэширования данных), можно настроить с помощью прагмы cache_size. .

Если SQLite не подходит, как насчет одного из "хранилищ значений ключей"? Они варьируются от распределенных клиент/сервер в памяти (например, memcached) до локальных встроенных дисков (например, BDB) до памяти с постоянной поддержкой переполнения и где-либо между ними и т. д. Они не имеют SQL DDL/DQL (хотя некоторые могут разрешать отношения), но эффективны в том, что они делают — хранят ключи и значения.

Конечно, всегда можно реализовать структуру LRU (скажем, базовый отсортированный список с ограничением) с переполнением в простую расширяемую реализацию хэша на основе диска... но... сначала рассмотрите вышеизложенное :) [Также могут быть некоторые микро -KV библиотеки/исходники там].

Удачного кодирования.

person Community    schedule 01.07.2011
comment
Спасибо! memory-with-a-persistent-backing-for-overflow — это именно то, что я ищу. Немедленно проверю ваши ссылки. - person mikewaters; 01.07.2011
comment
Способен ли SQLite обрабатывать большое количество операций записи в секунду (из одного и того же процесса)? - person mikewaters; 01.07.2011
comment
@threecheeseopera SQLite работает очень быстро в неконфликтном сценарии. В то время как коммиты ограничены скоростью жесткого диска (скажем, 20- 40 в секунду, но гораздо выше на SSD), обновления могут достигать десятков тысяч в секунду (в зависимости, конечно). Просто не забудьте использовать транзакции :) Хотя это и очень старо, вот общая идея: Сравнение скорости. - person ; 02.07.2011