Быстрое маленькое хранилище данных в Windows

Question

Мое приложение отслеживает состояние около 1000 объектов. Эти объекты считываются и записываются в постоянное хранилище (сериализованное) без особого порядка.

Приложение теперь использует реестр для хранения состояния каждого объекта. Это хорошо, потому что:

• Это просто

• Это очень быстро

• состояние

  индивидуального объекта может быть прочитана/записана без необходимости читать некоторые больший объект (например, вытаскивая сниппет из большого файла XML)

• Существует достойный редактор (RegEdit), которые позволяют легко манипулировать отдельные элементы

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

Любые лучшие предложения? Куча плоских файлов?

Answer 1

Если вы начнете экспериментировать с SQLite, вы должны знать, что «из коробки» не может кажется, так быстро, как хотелось бы, но это быстро можно сделать гораздо быстрее, применяя некоторые установленные советы по оптимизации:

SQLite optimization

в зависимости от размера данных и объема доступной оперативной памяти, один из лучшая производительность будет достигнута путем установки sqlite для использования базы данных «все в памяти», а не записи на диск.

Для баз данных в памяти, передать NULL в качестве имени файла аргумента sqlite3_open и make sure that TEMP_STORE is defined appropriately

С другой стороны, если вы скажете SQLite использовать жесткий диск, то вы получите такое же преимущество для вашего тока использование RegEdit для управления данными программы «на лету».

То, как вы могли бы имитировать вашу технику RegEdit с помощью sqlite, было бы использовать инструмент командной строки sqlite для подключения к базе данных на диске.Вы можете запускать инструкции UPDATE по SQL-данным из командной строки, пока ваша основная программа работает (и/или пока она приостановлена ​​в режиме разрыва).

Answer 2

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

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

Answer 3

Если вы имеете в виду «несколько читателей/многократных писателей», вы сохраняете много потоков, записывающих в хранилище одновременно, SQLite является потокобезопасным (вы можете иметь одновременные SELECT, а одновременная запись обрабатывается прозрачно). Смотрите [FAQ [1]] и Grep для «многопоточной»

[1]: http://www.sqlite.org/faq.html/ FAQ

Answer 4

Если вы выполняете сериализацию/десериализацию отдельных объектов (без причудливых запросов), используйте базу данных btree, например Berkeley DB. Это очень быстро при хранении и извлечении фрагментов данных по ключу (я предполагаю, что ваши объекты имеют некоторый идентификатор, который можно использовать в качестве ключа), и поддерживается доступ несколькими процессами.

Answer 5

Я сомневаюсь, что любой здравомыслящий человек пойдет по этому маршруту в эти дни, однако некоторые из того, что вы описали, можно сделать с помощью Window Structured/Compound Storage. Я только упоминаю об этом, так как вы спрашиваете о Windows - и это/был официальным способом Windows для этого.

Вот как файлы DOC были объединены (но не новый формат DOCX). Из MSDN это будет выглядеть очень сложно, но я использовал его, это не худший API в Win32.

• это не простой
• это быстро, я бы догадаться это быстрее, чем реестр.
• Состояние отдельного объекта может быть прочитано/записано без необходимости чтения более крупного объекта.
• Там нет достойного редактора, однако есть некоторые реальные основные вещи (VC++ 6.0 был «DocFile Viewer» под инструментами. (Да, это то, что вещь сделала) я нашел fewmore онлайн.
• Вы получаете файл вместо ключей реестра
• Вы получаете некоторые старой школы разработчиков Windows, Компьютерщик-креди

Другие случайные мысли:.. Я думаю, что XML является путь (несмотря на случайный вопрос доступа). Heck, файлы INI могут работать. В реестре вы получаете очень мелкое зерно люди, если вам это нужно, люди, похоже, забывают об этом, когда претензия с использованием файлов лучше. Встроенная БД кажется излишним , если Я понимаю, что вы делаете.