This commit is contained in:
parent
d20df572a6
commit
fa0c71b132
33
dev/Tombstone.md
Normal file
33
dev/Tombstone.md
Normal 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) -->
|
||||||
|
|
@ -45,7 +45,7 @@ linked:
|
|||||||
- Last write wins. Кто последний записал, те данные и верные.
|
- Last write wins. Кто последний записал, те данные и верные.
|
||||||
- [Happens before](Happens%20before.md).
|
- [Happens before](Happens%20before.md).
|
||||||
- Векторы версий.
|
- Векторы версий.
|
||||||
- [Tombstone](Tombstone.md)
|
- [Tombstone](../../Tombstone.md)
|
||||||
|
|
||||||
Такая репликация есть в:
|
Такая репликация есть в:
|
||||||
- DynamoDB
|
- DynamoDB
|
||||||
|
@ -55,7 +55,7 @@ WHERE fk_id IS NOT NULL;
|
|||||||
![[../../meta/files/images/Pasted image 20241021225124.png]]
|
![[../../meta/files/images/Pasted image 20241021225124.png]]
|
||||||
|
|
||||||
### Для мягкого удаления
|
### Для мягкого удаления
|
||||||
Представьте, что вам нужно поддерживать уникальность данных, например, адресов электронной почты в таблице базы данных. Однако в таблице есть строки, [[../../../../../_inbox/Tombstone|помеченные как удаленные]] с помощью поля `deleted_at`, и они также остаются в базе данных. В такой ситуации создание уникального индекса на поле с электронной почтой становится невозможным из-за дублирующихся значений. Частичный индекс решает эту проблему, позволяя включать в индекс только записи, которые не помечены как удаленные.
|
Представьте, что вам нужно поддерживать уникальность данных, например, адресов электронной почты в таблице базы данных. Однако в таблице есть строки, [[../Tombstone|помеченные как удаленные]] с помощью поля `deleted_at`, и они также остаются в базе данных. В такой ситуации создание уникального индекса на поле с электронной почтой становится невозможным из-за дублирующихся значений. Частичный индекс решает эту проблему, позволяя включать в индекс только записи, которые не помечены как удаленные.
|
||||||
|
|
||||||
В PostgreSQL добавление уникального индекса для активных пользователей выглядит так:
|
В PostgreSQL добавление уникального индекса для активных пользователей выглядит так:
|
||||||
```sql
|
```sql
|
||||||
|
Loading…
Reference in New Issue
Block a user