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

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

1 голос
/ 01 июля 2011

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

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

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

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

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

Редактировать: Я задал связанный вопрос .

1 Ответ

0 голосов
/ 01 июля 2011

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

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

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

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

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

...