vault backup: 2024-07-14 19:49:48

This commit is contained in:
Struchkov Mark 2024-07-14 19:49:48 +03:00
parent d207621582
commit 59af2f41a0
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C
6 changed files with 38 additions and 35 deletions

View File

@ -24,24 +24,24 @@
"unresolvedLinks": false,
"recentFilesStore": [
{
"filepath": "Решардинг.md",
"timestamp": 1720975443590
"filepath": "_inbox/Consistent hashing.md",
"timestamp": 1720975722279
},
{
"filepath": "_inbox/Шардирование в БД.md",
"timestamp": 1720975442585
"timestamp": 1720975721310
},
{
"filepath": "_inbox/Range Base Sharding.md",
"timestamp": 1720975717429
},
{
"filepath": "_inbox/Key Based Sharding.md",
"timestamp": 1720975310997
"timestamp": 1720975702126
},
{
"filepath": "wiki/zero/00 Базы Данных.md",
"timestamp": 1720974391295
},
{
"filepath": "Home.md",
"timestamp": 1720974288934
"filepath": "_inbox/Directory Based Sharding.md",
"timestamp": 1720975669145
}
],
"bookmarkedFileStore": [],

View File

@ -1,17 +1,29 @@
{
"recentFiles": [
{
"basename": "Решардинг",
"path": "Решардинг.md"
"basename": "Consistent hashing",
"path": "_inbox/Consistent hashing.md"
},
{
"basename": "Шардирование в БД",
"path": "_inbox/Шардирование в БД.md"
},
{
"basename": "Range Base Sharding",
"path": "_inbox/Range Base Sharding.md"
},
{
"basename": "Key Based Sharding",
"path": "_inbox/Key Based Sharding.md"
},
{
"basename": "Directory Based Sharding",
"path": "_inbox/Directory Based Sharding.md"
},
{
"basename": "Решардинг",
"path": "Решардинг.md"
},
{
"basename": "00 Базы Данных",
"path": "wiki/zero/00 Базы Данных.md"
@ -40,10 +52,6 @@
"basename": "Шардирование в PostgreSQL",
"path": "_inbox/Шардирование в PostgreSQL.md"
},
{
"basename": "Consistent hashing",
"path": "_inbox/Consistent hashing.md"
},
{
"basename": "Согласованное префиксное чтение",
"path": "_inbox/Согласованное префиксное чтение.md"
@ -191,14 +199,6 @@
{
"basename": "6706110398",
"path": "meta/files/6706110398.jpg"
},
{
"basename": "S6d1773a36e954bf1b0458135ecbb9f9eA.jpg",
"path": "meta/files/S6d1773a36e954bf1b0458135ecbb9f9eA.jpg.webp"
},
{
"basename": "Pasted image 20231008174024",
"path": "meta/files/Pasted image 20231008174024.png"
}
],
"omittedPaths": [],

View File

@ -18,7 +18,7 @@ linked:
Минусы:
- Данные могут быть распределенны не равномерно, если между шардами будет различное расстояние на круге.
## Virtual Nodes
## Virtual Nodes (Bucket)
Можно попытаться решить проблему неравноморного распределения. Для этого мы добавим виртуальные шарды: для одной ноды высчитывается несколько точек на круге.
Такой подход используется в [Cassandra](Cassandra.md)

View File

@ -13,7 +13,7 @@ linked:
---
![](Pasted%20image%2020240630110840.png)
Похож на [Key Based Sharding](Key%20Based%20Sharding.md). Можно использовать когда Shard Key имеет мало значений.
Похож на [Key Based Sharding](Key%20Based%20Sharding.md). Можно использовать когда кдюч шардирования имеет мало значений.
**Плюсы:**
- Более контролируемый способ распределения по шардам.

View File

@ -22,8 +22,3 @@ linked:
**Минусы:**
- Добавление/удаление шарда всегда боль. Так как хэш функция начинает возвращать другие результаты даже для уже имеющихся данных.
Популярные формулы хэширования:
- Если ключ цифровой, то можно просто поделить его на количество серверов, получив остаток от деления. Если это строка, то можно взять хэш функцию, которая даст число и уже его делить на количество серверов.
- Алгоритм crc32.
- какой-то мур-мур

View File

@ -49,11 +49,19 @@ linked:
- Держать нужные данные на одном шарде
- Делать вычисления в одном сервисе
Обычно для распределения по шардам используется какая-то функция шардирования, в которую передается ключ шарда. Наиболее популярные стратегии распределения данных по шардам:
Обычно для распределения по шардам используется какая-то функция шардирования, в которую передается ключ.
Популярные формулы хэширования:
- Если ключ цифровой, то можно просто поделить его на количество серверов, получив остаток от деления. Если это строка, то можно взять хэш функцию, которая даст число и уже его делить на количество серверов.
- При изменении количества серверов будет большая головная боль с [решардингом](Решардинг.md), так как придется перетаскивать данные практически со всех шардов.
- Алгоритм crc32.
- какой-то мур-мур
Стратегии распределения данных по шардам:
- [Key Based Sharding](Key%20Based%20Sharding.md). Наиболее распространенный способ.
- [Range Base Sharding](Range%20Base%20Sharding.md).
- [Range Base Sharding](Range%20Base%20Sharding.md). Не использует хэш функцию.
- [Directory Based Sharding](Directory%20Based%20Sharding.md)
- [Consistent hashing](Consistent%20hashing.md). Уменьшает боль от [решардинга](Решардинг.md)
- [Consistent hashing](Consistent%20hashing.md). Уменьшает боль от [решардинга](Решардинг.md).
Как выбрать ключ для шардирования и хэш функцию:
- Определиться, какой функционал для вашего бизнеса самый полезный. Какие запросы нужно выполнить, чтобы этот функционал работал. Как разбить данные так, чтобы данные запросы стали быстрее.