From 3a1ac35009d2d5cbc04ee30386e869bf226e78af Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=9B=D0=B5=D0=BE=D0=BD=D0=B8=D0=B4=20=D0=AE=D1=80=D1=8C?= =?UTF-8?q?=D0=B5=D0=B2=20=28Leonid=20Yuriev=29?= Date: Mon, 13 Jan 2025 14:26:56 +0300 Subject: [PATCH] =?UTF-8?q?mdbx:=20=D0=B4=D0=BE=D0=BF=D0=BE=D0=BB=D0=BD?= =?UTF-8?q?=D0=B5=D0=BD=D0=B8=D0=B5=20ChangeLog.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ChangeLog.md | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/ChangeLog.md b/ChangeLog.md index 8c65dec5..75bbe91d 100644 --- a/ChangeLog.md +++ b/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-ветку, но посмотри как пойдут дела.