diff --git a/dev/Tombstone.md b/dev/Tombstone.md new file mode 100644 index 00000000..3f99d6d9 --- /dev/null +++ b/dev/Tombstone.md @@ -0,0 +1,33 @@ +--- +aliases: + - софт-удаление + - мягкое удаление + - soft-удаление +tags: + - maturity/🌱 +date: 2024-10-31 +--- +**Tombstone** — это маркер, указывающий, что запись удалена логически, но физически все еще находится в базе данных. Такой подход позволяет системе лучше справляться с репликацией и конфликтами данных, а также обеспечивает корректное выполнение запросов к данным, которые могли быть удалены. + +**Плюсы:** +- **Репликация данных**: Tombstones упрощают [[architecture/highload/Репликация БД|репликацию]]. Поскольку данные могут реплицироваться между множеством узлов, простое удаление записи на одном узле не гарантирует, что она будет удалена на всех узлах. Tombstone помогает согласовать состояние данных между узлами. +- **История данных**: В системах, где данные удаляются, но запросы могут возвращаться к старым версиям данных, tombstones позволяют системе правильно обрабатывать такие запросы, показывая, что данные были удалены, а не просто отсутствуют. + +**Особенности:** +- **Процесс Compaction**: Со временем, когда гарантируется, что все узлы системы обновили свое состояние и больше не требуется хранение информации об удалении, tombstones могут быть удалены, чтобы освободить место и улучшить производительность системы. Этот процесс называется compaction. +- **Проблема накопления tombstones**: Накопление большого количества tombstones может замедлить производительность базы данных, так как системе приходится пропускать эти маркеры при выполнении запросов. Это особенно актуально для систем с высокой частотой удаления записей. + - [[database/Частичный индекс|Частичный индекс]] + +*** +## Мета информация +**Область**:: [[../meta/zero/00 Базы Данных|00 Базы Данных]] +**Родитель**:: +**Источник**:: +**Создана**:: [[2024-10-31]] +**Автор**:: [[2024-10-31]] +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/architecture/highload/Безмастерная репликация.md b/dev/architecture/highload/Безмастерная репликация.md index 0459ef33..3dc7bc35 100644 --- a/dev/architecture/highload/Безмастерная репликация.md +++ b/dev/architecture/highload/Безмастерная репликация.md @@ -45,7 +45,7 @@ linked: - Last write wins. Кто последний записал, те данные и верные. - [Happens before](Happens%20before.md). - Векторы версий. -- [Tombstone](Tombstone.md) +- [Tombstone](../../Tombstone.md) Такая репликация есть в: - DynamoDB diff --git a/dev/database/Частичный индекс.md b/dev/database/Частичный индекс.md index 6f25a483..80a83ce2 100644 --- a/dev/database/Частичный индекс.md +++ b/dev/database/Частичный индекс.md @@ -55,7 +55,7 @@ WHERE fk_id IS NOT NULL; ![[../../meta/files/images/Pasted image 20241021225124.png]] ### Для мягкого удаления -Представьте, что вам нужно поддерживать уникальность данных, например, адресов электронной почты в таблице базы данных. Однако в таблице есть строки, [[../../../../../_inbox/Tombstone|помеченные как удаленные]] с помощью поля `deleted_at`, и они также остаются в базе данных. В такой ситуации создание уникального индекса на поле с электронной почтой становится невозможным из-за дублирующихся значений. Частичный индекс решает эту проблему, позволяя включать в индекс только записи, которые не помечены как удаленные. +Представьте, что вам нужно поддерживать уникальность данных, например, адресов электронной почты в таблице базы данных. Однако в таблице есть строки, [[../Tombstone|помеченные как удаленные]] с помощью поля `deleted_at`, и они также остаются в базе данных. В такой ситуации создание уникального индекса на поле с электронной почтой становится невозможным из-за дублирующихся значений. Частичный индекс решает эту проблему, позволяя включать в индекс только записи, которые не помечены как удаленные. В PostgreSQL добавление уникального индекса для активных пользователей выглядит так: ```sql