Схема резервного копирования для энергонезависимых конструкций карт C ++

Question

Я часто использую std :: map или tr1 :: hashed_maps в моем коде C ++. У меня есть предстоящий проект, в котором я обычно по умолчанию использую такие конструкции, однако в этом проекте у меня есть требование, чтобы такие карты были энергонезависимыми. То есть после завершения работы приложения (как безопасно закрытого, так и случайно уничтоженного, например, при отключении питания) данные карты должны быть надежно сохранены на диске и восстановлены при последующем выполнении приложения. Обратите внимание, что это не является обязательным требованием, чтобы каждый бит данных сохранялся до отключения питания, просто все, скажем, за несколько секунд до этого.

Требования по-прежнему состоят в том, что приложение должно иметь высокую производительность с точки зрения как доступа, так и сохранения на картах. Очевидно, что «высокая производительность» субъективна, но в секунду на карту будут приходиться миллионы загрузок / магазинов.

Это заставляет меня «догадываться», что мне следует использовать базу данных SQL, однако я неопытен в базах данных и беспокоюсь, что произойдет значительное снижение производительности при переходе от простых контейнеров C ++ к полной инфраструктуре SQL. Будет ли SQL «кешировать» результаты таким образом, чтобы снизить эффект производительности?

В качестве альтернативы, простым ответом может быть просто часто (скажем, каждые 10-30 секунд) записывать (сериализовать) копию карт на диск. В зависимости от размера карт, которые будут большими (не менее миллионов записей), это может не иметь смысла.

Какие-либо рекомендации?

Спасибо!

Answer 1

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

Похоже, база данных будет вашим лучшим выбором с точки зрения производительности и целостности данных. Они созданы для обработки сценариев, которые вы описываете в своем посте.

Итак, я вижу, что вам нужно сделать две вещи:

• Разработайте надежную модель базы данных для той информации, которую вы хотите хранить. Я не эксперт в этом, но я знаю, что правильно это понять.
• Проведите небольшое исследование на предмет хорошей оболочки C ++. Таким образом, вы можете оставить детали MySQL в библиотеке и сосредоточиться на том, где вы сильнее всего.

Answer 2

Простой C ++ подход хорош, если в будущем нет планов по расширению функциональности. Срединной землей, которая вполне может удовлетворить ваши потребности, являются магазины ключевых ценностей, такие как Redis или Cassandra . Они управляют хранением и прозрачно прерывают, а также расширяют хранилище для нескольких машин, если одного становится недостаточно. Их производительность очень хорошая, в некоторых случаях они могут даже превзойти код C ++. Полноценная база данных SQL будет слишком медленной для ваших целей, если вы не запустите ее на нескольких машинах.

Answer 3

Я не являюсь пользователем вашего приложения, но хранение больших объемов данных при закрытии является плохой идеей по нескольким причинам:

• Когда кто-то хочет закрыть ваше приложение, он хочет, чтобы оно закрывалось довольно быстро, а не болталось целую вечность. Если это не произойдет, они могут его убить.

• Если они "вылетят", ваши данные не будут сохранены.

Поэтому периодическое сохранение является гораздо лучшей идеей, и для этого вы, вероятно, захотите пометить строки как «грязные», когда они в настоящий момент не сохранены, что означает, что вам может потребоваться больше данных, чтобы пометить грязные записи. Это можно сделать с помощью простого набора или вектора ключей, для которых данные являются «грязными», и периодически сохраняйте их и удаляйте их «грязное» состояние.

При закрытии вы пишете все оставшиеся грязные записи, но их будет не много.

Многое зависит от того, как часто меняются ваши карты.

Помните также, что взаимодействие с пользователем всегда должно иметь наивысший приоритет, и любая фиксация ваших «грязных» членов в постоянстве должна происходить в фоновом потоке с низким приоритетом.

Answer 4

Вы по-прежнему можете использовать свою карту, завернутую в операции по обработке объектов на карте.Операции, которые изменяют карту, помимо изменения карты в памяти, также обновляют хранилище на диске.

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

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

Answer 5

Если на карте миллионы хранилищ в секунду, достаточно быстрый SQL-запрос становится довольно сложным для чего-то, что вы, похоже, считаете задним числом.Хранилище ключей может быть лучше для вашего приложения, но если вы действительно выходите за пределы производительности, вы можете просто записать в журнал журнал обновлений, которые вы вносите в свое хранилище в памяти.Вы можете восстановить хранилище в памяти из журнала, чтобы удовлетворить ваши требования к постоянству.