Tombstone.md
All checks were successful
continuous-integration/drone/push Build is passing

This commit is contained in:
Struchkov Mark 2024-10-31 18:54:23 +03:00
parent d20df572a6
commit fa0c71b132
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C
3 changed files with 35 additions and 2 deletions

33
dev/Tombstone.md Normal file
View File

@ -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]]
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

View File

@ -45,7 +45,7 @@ linked:
- Last write wins. Кто последний записал, те данные и верные.
- [Happens before](Happens%20before.md).
- Векторы версий.
- [Tombstone](Tombstone.md)
- [Tombstone](../../Tombstone.md)
Такая репликация есть в:
- DynamoDB

View File

@ -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