mirror of
https://github.com/isar/libmdbx.git
synced 2025-01-19 12:48:20 +08:00
mdbx: дополнение ChangeLog.
This commit is contained in:
parent
3c60e1e94c
commit
3a1ac35009
23
ChangeLog.md
23
ChangeLog.md
@ -4,6 +4,19 @@ ChangeLog
|
||||
English version [by liar Google](https://libmdbx-dqdkfa-ru.translate.goog/md__change_log.html?_x_tr_sl=ru&_x_tr_tl=en)
|
||||
and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx.dqdkfa.ru/md__change_log.html).
|
||||
|
||||
## v0.14.1 в активной разработке без конкретизации даты выпуска
|
||||
|
||||
Первый выпуск в новом кусте/линейке версий с добавлением функционала, расширением API и внутренними переработками.
|
||||
|
||||
Изменение поведения:
|
||||
|
||||
- Теперь при вставке данных в dupsort-таблицу CoW копирование целевых страниц выполняется после провеки отсутствия добавляемого значения среди уже присутствующих multi-значений (aka дубликатов).
|
||||
В результате вставка уже присутствующих "дубликатов" не приводит к каким-либо изменениям в БД и принципиально увеличивает производительность в таких сценариях.
|
||||
В текущем понимании, добавленная проверка не приводит к заметному увеличению накладных расходов и, как следствие, не приводит к снижению производительности в сценариях с обычным/регулярным обновлением и/или вставкой даннaых.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
|
||||
## v0.14.0 от 2023-03-13
|
||||
|
||||
@ -16,14 +29,18 @@ and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx
|
||||
Будет реализовано в 0.14.1.
|
||||
|
||||
2. Явная дефрагментация БД. В API будет добавлена функция с двумя парами параметров:
|
||||
- минимальный (требуемый) объем дефрагментации (уменьшения БД) и минимальное время, которое следует потратить;
|
||||
- максимальный (ограничивающий) объем дефрагментации и максимальной время, которое допустимо потратить.
|
||||
- минимальный (требуемый) объём дефрагментации (уменьшения БД) и минимальное время, которое следует потратить;
|
||||
- максимальный (ограничивающий) объём дефрагментации и максимальной время, которое допустимо потратить.
|
||||
|
||||
Упрощенно, алгоритмически явная дефрагментация сводиться к сканированию b-tree с формированием списка страниц расположенных близко к концу БД, а затем копирование этих страниц в не-используемые, но расположенные ближе к началу БД.
|
||||
Упрощенно, алгоритмически явная дефрагментация сводится к сканированию b-tree с формированием списка страниц расположенных близко к концу БД, а затем копирование этих страниц в не-используемые, но расположенные ближе к началу БД.
|
||||
В результате, после фиксации дефрагментирующей транзакции оригиналы скопированных страниц становяться не-используемыми, а размер БД может быть уменьшен за счет отсечения ни-используемых страниц в конце используемого пространства.
|
||||
Будет реализовано в 0.14.2.
|
||||
|
||||
3. Нелинейная переработка GC, без остановки переработки мусора на старом MVCC-снимке используемом долгой транзакцией чтения.
|
||||
|
||||
После реализации запланированного, любая длительная читающая транзакция по-прежнему будет удерживать от переработки используемый/читаемый MVCC-снимок данных (все образующие его страницы БД), но позволит перерабатывать все неиспользуемые MVCC-снимки, как до читаемого, так и после.
|
||||
Это позволит устранить [один из основных архитектурных недостатков](https://libmdbx.dqdkfa.ru/intro.html#long-lived-read) унаследованных от LMDB и связанных с ростом размера БД пропорционально объёму производимых изменений данных на фоне долго работающей транзакции чтения.
|
||||
|
||||
Будет реализовано предположительно в 0.14.3, 0.14.4 или даже в 0.15.x.
|
||||
Перенос в 0.15.x оправдан возможностью переноса функционала дефрагментации в stable-ветку, но посмотри как пойдут дела.
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user