erthink
Newbie | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата:| А для чего предусмотрены эти два режима (в чём преимущества UTTERLY_NOSYNC)? |
В libmdbx МНОГО режимов работы с БД. Точнее говоря, есть 6 флажков, комбинацией которых определяется режим БД (не считая read-only и exclusive). Эти флажки нужно выбирать с полным пониманием различий и последствий. Тут стоит отметить об очевидном недостатке libmdbx - скудности документации. На днях я это поправлю, но недочет этот унаследован от LMDB.
В режиме MDBX_UTTERLY_NOSYNC данные пишутся на диск ядром операционной системы "когда хочется", но при этом сама libmdbx не формирует и не отслеживает точки фиксации данных на диск. Поэтому БД будет (скорее всего) неустранима повреждена при системной аварии (пропадание питания или синий экран). При падении самой миранды БД (скорее всего) цела, при условии что при падении не будет росписи память (ради производительности БД используется c флажком MDBX_WRITEMAP поэтому отображена в память с доступом на запись).
Режим MDBX_UTTERLY_NOSYNC нужен в случаях, когда требуется предельная производительность и допустима потеря всей БД при системной аварии (но не сбое приложения). Например, может быть обеспечено резервирование питания и серверов с БД, одновременно с зеркалированием изменения данных. Иначе говоря, в каких-то случаях можно считать вероятность системной аварии достаточно низкой, чтобы допускать простой на время восстановления из backup-ов. Как вариант, есть области применения где простой из-за пропадания питания или системного сбоя равнозначен потери данных, т.е. если вырубилось питание - начинаем с чистого листа, потому что прежние данные (скорее всего) уже устарели и бесполезны.
С некоторого момента mdbx-драйвер явно вызывает mdbx_env_sync() для принудительного сброса данных на диск. ОДНАКО, в режиме MDBX_UTTERLY_NOSYNC точки фиксации на диск не отслеживаются. Поэтому любое последующее изменение данных (коммит транзакции) _полностью_ обесценивает предыдущий вызов mdbx_env_sync(). Соответственно, БД будет повреждена, если авария случится после коммита транзакции и до завершения очередного mdbx_env_sync(). Короче, использование MDBX_UTTERLY_NOSYNC - не для миранды, совсем.
Цитата:| По словам @ghazan тот второй режим (который Миранда не использует), хоть и безопаснее, но приводит к большим тормозам драйвера dbx_mdbx (в причины я не вдавался, поскольку не программист), поэтому было решено, что пользователей с зависающими компами (что является нештатной ситуацией) намного меньше, чем пользователей с большими базами и большими списками контактов (что вполне штатное явление). |
Чудес не бывает. Вся скорость libmdbx от того, что не делается ничего лишнего. Тем не менее, libmdbx строит БД как дерево страниц (B+Tree) и не использует WAL (Write Ahead Log). В этом есть как плюсы, так и минусы (см https://github.com/leo-yuriev/libmdbx/blob/master/README-RU.md#%D0%A1%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81-%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D0%BC%D0%B8-%D0%B1%D0%B0%D0%B7%D0%B0%D0%BC%D0%B8-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85). В частности, обновление одной записи в B+Tree порождает O*log(N) точечных записей на диск, каждая из которых в случае HDD может занимать от 10 до 250 миллисекунд. При отсутствии WAL приходится ждать завершения всех этих операций с диском при фиксации каждой транзакции (при наличии WAL данных будет записываться больше, но ждать завершения нужно только записи в журнал).
Поэтому в случае миранды есть несколько правильных вариантов:
1) Использовать надежные режимы работы с БД (без MDBX_UTTERLY_NOSYNC, MDBX_NOSYNC, MDBX_MAPASYNC, MDBX_NOMETASYNC, MDBX_WRITEMAP), но при этом не делать "много мелких транзакций", а группировать изменения в "толстые" транзакции (например по 1000 операций и/или раз в 5 секунд).
2) Использовать небезопасные режимы, но только не MDBX_UTTERLY_NOSYNC, и при этом периодически вызывать mdbx_env_sync().
3) Использовать MDBX_UTTERLY_NOSYNC, но вместо вызовов mdbx_env_sync() периодически делать надежную копию БД посредством mdbx_evn_copy(), а при запуске приложения делать обратное - копировать надежную БД во временную.
|
Всего записей: 24 | Зарегистр. 02-09-2019 | Отправлено: 15:37 04-09-2019 | Исправлено: erthink, 16:05 04-09-2019 |
|
