ISAR/libmdbx
3
0
Fork 0
mirror of https://github.com/isar/libmdbx.git synced 2025-01-19 16:18:21 +08:00
Code Issues Packages Projects Releases Wiki Activity

mdbx: корректировка ChangeLog.

Browse Source
This commit is contained in:
Леонид Юрьев (Leonid Yuriev) 2025-01-14 21:28:01 +03:00
parent 2c3b36da64
commit e529cd7d19
1 changed files with 22 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
ChangeLog.md
View File

@ -14,6 +14,10 @@ and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx
В результате вставка уже присутствующих "дубликатов" не приводит к каким-либо изменениям в БД и принципиально увеличивает производительность в таких сценариях.
В текущем понимании, добавленная проверка не приводит к заметному увеличению накладных расходов и, как следствие, не приводит к снижению производительности в сценариях с обычным/регулярным обновлением и/или вставкой даннaых.
Прочие доработки:
- Существенный рефакторинг с реструктуризацией кода, переименованием внутренних структур, их полей и внутренних функций.
--------------------------------------------------------------------------------
@ -25,24 +29,24 @@ and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx
Запланированные новые возможности 0.14:
1. Ранняя (не-отложенная) очистка GC и рефакторинг обновления GC, самостоятельной видимой для пользователя ценности не имеет, но требуется для последующих пунктов.
Будет реализовано в 0.14.1.
1. Ранняя (не-отложенная) очистка GC и рефакторинг обновления GC. Самостоятельной видимой для пользователя ценности не имеет, но требуется для последующих пунктов.
Будет реализовано в 0.14.1.
2. Явная дефрагментация БД. В API будет добавлена функция с двумя парами параметров:
- минимальный (требуемый) объём дефрагментации (уменьшения БД) и минимальное время, которое следует потратить;
- максимальный (ограничивающий) объём дефрагментации и максимальной время, которое допустимо потратить.
- минимальный (требуемый) объём дефрагментации (уменьшения БД) и минимальное время, которое следует потратить;
- максимальный (ограничивающий) объём дефрагментации и максимальной время, которое допустимо потратить.
Упрощенно, алгоритмически явная дефрагментация сводится к сканированию b-tree с формированием списка страниц расположенных близко к концу БД, а затем копирование этих страниц в не-используемые, но расположенные ближе к началу БД.
В результате, после фиксации дефрагментирующей транзакции оригиналы скопированных страниц становяться не-используемыми, а размер БД может быть уменьшен за счет отсечения ни-используемых страниц в конце используемого пространства.
Будет реализовано в 0.14.2.
Упрощенно, алгоритмически явная дефрагментация сводится к сканированию b-tree с формированием списка страниц расположенных близко к концу БД, а затем копирование этих страниц в не-используемые, но расположенные ближе к началу БД.
В результате, после фиксации дефрагментирующей транзакции оригиналы скопированных страниц становятся не-используемыми, а размер БД может быть уменьшен за счет отсечения ни-используемых страниц в конце используемого пространства.
Будет реализовано в 0.14.2.
3. Нелинейная переработка GC, без остановки переработки мусора на старом MVCC-снимке используемом долгой транзакцией чтения.
После реализации запланированного, любая длительная читающая транзакция по-прежнему будет удерживать от переработки используемый/читаемый MVCC-снимок данных (все образующие его страницы БД), но позволит перерабатывать все неиспользуемые MVCC-снимки, как до читаемого, так и после.
Это позволит устранить [один из основных архитектурных недостатков](https://libmdbx.dqdkfa.ru/intro.html#long-lived-read) унаследованных от LMDB и связанных с ростом размера БД пропорционально объёму производимых изменений данных на фоне долго работающей транзакции чтения.
После реализации запланированного, любая длительная читающая транзакция по-прежнему будет удерживать от переработки используемый/читаемый 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-ветку, но посмотри как пойдут дела.
Будет реализовано предположительно в 0.14.3, 0.14.4 или даже в 0.15.x.
Перенос в 0.15.x оправдан возможностью переноса функционала дефрагментации в stable-ветку, но посмотри как пойдут дела.
********************************************************************************
@ -54,6 +58,11 @@ and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx
в день рождения и в память об [Серге́е Па́вловиче Королёве](https://ru.wikipedia.org/wiki/Королёв,_Сергей_Павлович),
советском учёном и Главном конструкторе ракетно-космических систем.
Одновременно с этим релизом:
- Ветка `0.12.x` перестаёт поддерживаться и отправляется в `архив/0.12`.
- Ветка `0.13.x` получает статус стабильной и вливается в `stable`.
Благодарности:
- [Алексею Костюку (aka Keller)](https://t.me/keller18306) за сообщения об ошибках и недочетах.
@ -115,7 +124,7 @@ and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx
Однако, улучшить ситуацию пока не представляется возможным, как минимум
до доступности boot_id хостовой системы изнутри LXC-контейнера.
- Устранёна ошибка неверной обработки попытки запуска вложенной читающей транзакции.
- Устранена ошибка неверной обработки попытки запуска вложенной читающей транзакции.
Теперь в таких ситуациях возвращается ошибка `MDBX_EINVAL`, так как вложенность
поддерживается только для транзакций чтения-записи.
@ -140,7 +149,7 @@ and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx
Однако, при поиске/позиционировании это не является ошибкой для таблиц с ключами переменного размера.
- Если посредством `mdbx_env_set_option(MDBX_opt_txn_dp_limit)` пользователем не задано собственно значение,
то выполняется подстройка dirty-pages-limit при старте каждой не-вложенной пишущей транзакций,
то теперь выполняется подстройка dirty-pages-limit при старте каждой не-вложенной пишущей транзакций,
исходя из объёма доступного ОЗУ и размера БД.
- Теперь в режиме `MDBX_NOSTICKYTHREADS` допускается commit/abort вложенных транзакций из любого треда/потока.