Tombstone.md

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) -->
+

dev/architecture/highload/Безмастерная репликация.md

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

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