diff --git a/ChangeLog.md b/ChangeLog.md index 75bbe91d..a07c7bf2 100644 --- a/ChangeLog.md +++ b/ChangeLog.md @@ -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 вложенных транзакций из любого треда/потока.