vault backup: 2024-07-13 20:30:17

This commit is contained in:
Struchkov Mark 2024-07-13 20:30:17 +03:00
parent 00f118d336
commit 1fbe045ced
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C
4 changed files with 53 additions and 36 deletions

View File

@ -24,20 +24,24 @@
"unresolvedLinks": false,
"recentFilesStore": [
{
"filepath": "_inbox/Партиционирование в PostgreSQL.md",
"timestamp": 1720890853115
},
{
"filepath": "_inbox/Партиционирование в БД.md",
"timestamp": 1720890608382
"filepath": "_inbox/Шардирование в PostgreSQL.md",
"timestamp": 1720891812342
},
{
"filepath": "_inbox/Шардирование в БД.md",
"timestamp": 1720889891582
"timestamp": 1720891792171
},
{
"filepath": "Home.md",
"timestamp": 1720887753090
"filepath": "_inbox/Согласованное префиксное чтение.md",
"timestamp": 1720891715978
},
{
"filepath": "_inbox/Партиционирование в БД.md",
"timestamp": 1720891574502
},
{
"filepath": "_inbox/Партиционирование в PostgreSQL.md",
"timestamp": 1720890853115
}
],
"bookmarkedFileStore": [],

View File

@ -1,16 +1,24 @@
{
"recentFiles": [
{
"basename": "Партиционирование в PostgreSQL",
"path": "_inbox/Партиционирование в PostgreSQL.md"
"basename": "Шардирование в PostgreSQL",
"path": "_inbox/Шардирование в PostgreSQL.md"
},
{
"basename": "Шардирование в БД",
"path": "_inbox/Шардирование в БД.md"
},
{
"basename": "Согласованное префиксное чтение",
"path": "_inbox/Согласованное префиксное чтение.md"
},
{
"basename": "Партиционирование в БД",
"path": "_inbox/Партиционирование в БД.md"
},
{
"basename": "Шардирование в БД",
"path": "_inbox/Шардирование в БД.md"
"basename": "Партиционирование в PostgreSQL",
"path": "_inbox/Партиционирование в PostgreSQL.md"
},
{
"basename": "Home",
@ -191,14 +199,6 @@
{
"basename": "Pasted image 20231008173416",
"path": "meta/files/Pasted image 20231008173416.png"
},
{
"basename": "b1503c029e1089a75e5b8578b117ced9.png",
"path": "meta/files/b1503c029e1089a75e5b8578b117ced9.png.webp"
},
{
"basename": "maxresdefault",
"path": "meta/files/maxresdefault.jpg"
}
],
"omittedPaths": [],

View File

@ -0,0 +1,13 @@
---
aliases:
tags:
- зрелость/🌱
date:
- - 2024-07-13
zero-link:
- "[[00 PostgreSQL]]"
parents:
- "[[Шардирование в БД]]"
linked:
---
В [PostgreSQL](00%20PostgreSQL.md) есть шардирование из коробки, но оно реализовано на базе [партиционирования](Партиционирование%20в%20БД.md). Фактически партиции уезжают на отдельные сервера. Решардинг это боль, так как должен выполняться вручную.

View File

@ -13,10 +13,10 @@ linked:
- "[[Партиционирование в БД]]"
---
## Тезисы
- Один из вариантов масштабирования.
- Данные разбиваются на части. Части размещаются на разных серверах.
- Один из вариантов горизонтального масштабирования.
- Данные разбиваются на части. В отличии от [партиционирования](Партиционирование%20в%20БД.md) эти части размещаются на разных серверах.
- Не является [репликацией](_inbox/Репликация.md) и [партиционированием](Партиционирование%20в%20БД.md).
- Шардирование последняя мера по улучшению производительности.
- ==Шардирование последняя мера по улучшению производительности.==
***
Шардирование — это метод разделения и распределения больших объёмов данных по разным базам данных или узлам в рамках одной распределённой системы, чтобы облегчить их управление, обеспечить масштабируемость и повысить производительность. Каждая часть данных, или "шард", функционирует как отдельная база данных, и все шарды вместе образуют логически единую базу данных.
@ -29,15 +29,21 @@ linked:
**Плюсы:**
- [Горизонтальное масштабирование](Горизонтальное%20масштабирование.md)
- **Улучшение производительности**: Единственный метод ускоряющий запись в БД.
- **Улучшение производительности**: Единственный способ операции вставки в БД.
- **Высокая доступность и устойчивость к отказам**: Отказ одного шарда не приводит к полному сбою системы. Данные в остальных шардах остаются доступными, что повышает общую устойчивость системы к отказам.
**Минусы:**
**Минусы**
- **Сложность управления**: Нет стандартных механизмов по управлению шардами. В случае добавления или удаления шардов может потребоваться перераспределение больших объемов данных, что может быть ресурсоемкой операцией и повлиять на производительность системы.
- **Трудности с транзакциями и согласованностью**: Шардирование может затруднить обеспечение атомарности и согласованности транзакций, охватывающих несколько шардов, что может потребовать дополнительных усилий для поддержания целостности данных.
**Проблемы**
**Проблемы:**
- [Согласованное префиксное чтение](Согласованное%20префиксное%20чтение.md)
- Данные неравномерно распределились.
- Попробовать подобрать лучше ключ шардирования/кэш функцию
- Решардинг
- [JOIN SQL](JOIN%20SQL.md)
- Держать нужные данные на одном шарде
- Делать вычисления в одном сервисе
Стратегии разбиения на шарды
- [Key Based Sharding](Key%20Based%20Sharding.md). Наиболее распространенный способ.
@ -56,13 +62,8 @@ linked:
- Дополнительная точка отказа. Лишний хоп.
- Не отдает сами данные, а указывает сервису в какой шард сходить.
Проблемы:
- Данные неравномерно распределились.
- Попробовать подобрать лучше ключ шардирования/кэш функцию
- Решардинг
- [JOIN SQL](JOIN%20SQL.md)
- Держать нужные данные на одном шарде
- Делать вычисления в одном сервисе
Реализации в СУБД:
- [Шардирование в PostgreSQL](Шардирование%20в%20PostgreSQL.md)
## Решардинг
При добавлении/удалении ноды нужно провести решардинг. Перенести старые данные на новые узлы.
@ -77,4 +78,3 @@ linked:
- Запросы не по ключу пройдут по всем узлам.
- Запросы по диапазону ключей хэширования могут обойти все шарды.
- Можно создавать различные индексы на узлах. При этом может оказаться так, что индексы на исходной таблице могут не подойди для шардирования.
- В [PostgreSQL](00%20PostgreSQL.md) есть шардирование из коробки, но оно реализовано на базе [партиционирования](Партиционирование%20в%20БД.md). Фактически партиции уезжают на отдельные сервера. Решардинг это боль, так как должен выполняться вручную.