From fa0c71b13223bcb69d655a37857fdb50bb1c79c0 Mon Sep 17 00:00:00 2001
From: Struchkov Mark <mark@struchkov.dev>
Date: Thu, 31 Oct 2024 18:54:23 +0300
Subject: [PATCH] Tombstone.md

---
 dev/Tombstone.md                              | 33 +++++++++++++++++++
 .../highload/Безмастерная репликация.md       |  2 +-
 dev/database/Частичный индекс.md              |  2 +-
 3 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100644 dev/Tombstone.md

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