Самое быстрое небольшое хранилище данных в Windows

Question

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

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

• Это очень просто

• Это происходит очень быстро

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

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

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

Есть предложения получше?Куча плоских файлов?

Answer 1

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

Оптимизация SQLite

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

Для баз данных в памяти передайте NULL в качестве аргумента filename в sqlite3_open и убедитесь, что TEMP_STORE определен соответствующим образом

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

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

Answer 2

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

[1]: http://www.sqlite.org/faq.html/ Вопросы и ответы

Answer 3

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

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

• это так нет простой
• это быстро, я бы хотел догадываюсь это быстрее, чем в реестре.
• Состояние отдельного объекта может быть прочитано / записано без необходимости считывать какой-либо более крупный объект.
• Приличного редактора нет, однако есть некоторые реальные базовые материалы (в VC ++ 6.0 был "Просмотрщик DocFile Viewer" в разделе Tools.(да, это то, что сделала эта штука) Я нашел немногие Еще В сети.
• Вы получаете файл вместо ключей реестра.
• Вы получаете репутацию гика-разработчика Windows старой школы.

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

Answer 4

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

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

Answer 5

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