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. Кто последний записал, те данные и верные.
|
||||
- [Happens before](Happens%20before.md).
|
||||
- Векторы версий.
|
||||
- [Tombstone](Tombstone.md)
|
||||
- [Tombstone](../../Tombstone.md)
|
||||
|
||||
Такая репликация есть в:
|
||||
- DynamoDB
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user