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

.obsidian/plugins/home-tab/data.json

@@ -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": [],

.obsidian/plugins/recent-files-obsidian/data.json

@@ -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": [],

_inbox/Consistent hashing.md

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

_inbox/Directory Based Sharding.md

@@ -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). Можно использовать когда кдюч шардирования имеет мало значений.
 
 **Плюсы:**
 - Более контролируемый способ распределения по шардам.

_inbox/Key Based Sharding.md

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

_inbox/Шардирование в БД.md

@@ -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).
 
 Как выбрать ключ для шардирования и хэш функцию:
 - Определиться, какой функционал для вашего бизнеса самый полезный. Какие запросы нужно выполнить, чтобы этот функционал работал. Как разбить данные так, чтобы данные запросы стали быстрее.