Реестр Windows 10 как база данных
Я хочу хранить данные, около 200 000 пар ключ-значение.
Я знаю, что реестр Windows осуждается за это, но терпите меня, поскольку технологии развиваются ...
Если я сохраню это в реестре, а мое приложение находится внутри контейнера типа App-V (на самом деле оно будет в контейнере UWP), то реестр будет локальным для моего приложения.
Таким образом, только мое приложение может получить доступ к реестру, это подмножество реестра Windows (уменьшенного размера), и у меня есть прямой доступ (например, он не проходит через брокера доступа к файлам в Windows 10).
Есть ли в этом проблема?
- Представление? по сравнению с чем?
- Максимальный размер?
- Многопоточный доступ?
- Коррупция?
Я буду использовать .net 4.7.2 и C#. Альтернативы, такие как SQLite, означают добавление компонентов и построение БД, помимо KVP. Другие мысли - это esent engine, но для этого требуется оболочка .net. Спасибо
Используйте все остальное - даже текстовый файл будет лучше, чем реестр.
Есть ли причина отвращения к внешним компонентам? Зависимости SQLite невелики, и усилия, необходимые для создания БД, будут тривиальными. БД - лучшее, что можно использовать для БД.
Я согласен с вышеизложенным. База данных будет вашим лучшим исполнителем и самым надежным
@juergend - Можете ли вы подробно рассказать, почему что-то еще было бы лучше? это мнение или у вас есть основания для вашей рекомендации? - также текстовый файл не будет записывать одну запись, это запись всего файла, которая не поддерживает многопоточность и неэффективна.
@AlexK. - Хороший вопрос, я отвращаюсь к простоте, зачем использовать стороннюю БД, когда она встроена в Windows - для моих нужд это единственная БД KeyValuePair, которая работает под NoSQL, поэтому SQLite, например, является излишним.
@mjwills - мнение большинства людей о реестре основано на том, что он является центральной БД Windows. Однако движение вперед в данном случае означает, что мы смотрим на виртуализацию, перенаправление и контейнеризацию реестра, а не на традиционную точку зрения.
Вам ничего не мешает сделать это, просто альтернативы лучше imo, например, в реестре нет поддержки индексирования, его единственные возможности запроса - выборка по имени или перечисление всего, это не транзакционный, его не переносимый с точки зрения удобства для пользователя резервного копирования и перемещения ...
@AlexK. - Теперь мы кое-что получим :) - это хорошая, четко определенная причина - без индексации (я думал, что это так). Хорошо, есть какие-нибудь мысли о хорошей альтернативе KVP?
Лично я использую SQLite для подобных вещей.
@AlexK. SQLite - очень распространенный ответ, но это не база данных KVP и немного выше того, что я ищу. Преимущество KVP - это нулевая настройка и простота использования. SQLite требует немного больше настроек, чем мне нужно - возможно, движок ESENT хорош; который предоставляет индексированную БД KVP. Я думаю, что теперь, когда я знаю, что реестр не индексирует, мне нужно изучить альтернативы. ESENT кажется хорошим, SQLite кажется популярным.
Ответы 2
Как указал @AlexK. Реестр Windows, хотя и является базой данных, не индексируется, поэтому производительность будет очень низкой. Это отличная причина не использовать его.
Я исследую ESENT и другие хранилища KVP на базе NoSQL.
Спасибо всем, что разместили.
Оболочка двоичного файла с жестко заданными размерами полей будет работать отлично, но имеет недостаток, связанный с раздуванием r / w. Для этого перейдите к файлам с отображением памяти, которые совершенно потрясающи и быстро работают (ульи reg сделаны таким образом, кстати).
Вы можете использовать pinvoke для функций (Get|Write)PrivateProfile*.. Этот древний материал все еще работает.
В общем, я вижу 3 мотивации: чтение, запись и изменение обнаружения / уведомления.
Для первых двух я подтверждаю, что реестр НЕ является хорошим хранилищем для сохранения состояния, учитывая общую нагрузку на него (проверьте это с помощью фильтра sysinternals procmon 'Path contains HK', и посмотрите, кто забивает (RegRead.*) или татуирует реестр ( RegWrite.*)).
Хранилище конфигурации - это, конечно, нормально, что и было первоначальной целью реестра.
Другое дело - мониторинг. Это было бы хорошо и позволило бы вам использовать хранилище данных, управляемое событиями.
См .: pinvoke.net FindFirstChangeNotification.
Спасибо, Билл, хотя я хотел бы отметить, что реестр будет посвящен приложению, как описано, и к нему нельзя будет получить доступ ни в какой другой службе.
is frowned upon for thisЕсли вы это знаете, почему вы об этом думаете?