vault backup: 2024-07-15 13:55:03

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

@@ -23,9 +23,13 @@
   "markdownOnly": false,
   "unresolvedLinks": false,
   "recentFilesStore": [
+    {
+      "filepath": "Решардинг.md",
+      "timestamp": 1721040878748
+    },
     {
       "filepath": "_inbox/Шардирование в БД.md",
-      "timestamp": 1721040591668
+      "timestamp": 1721040873038
     },
     {
       "filepath": "_inbox/Directory Based Sharding.md",
@@ -38,10 +42,6 @@
     {
       "filepath": "_inbox/Key Based Sharding.md",
       "timestamp": 1721040132060
-    },
-    {
-      "filepath": "_inbox/Партиционирование в БД.md",
-      "timestamp": 1721039353391
     }
   ],
   "bookmarkedFileStore": [],

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

@@ -1,5 +1,9 @@
 {
   "recentFiles": [
+    {
+      "basename": "Решардинг",
+      "path": "Решардинг.md"
+    },
     {
       "basename": "Шардирование в БД",
       "path": "_inbox/Шардирование в БД.md"
@@ -24,10 +28,6 @@
       "basename": "Партиционирование в PostgreSQL",
       "path": "_inbox/Партиционирование в PostgreSQL.md"
     },
-    {
-      "basename": "Решардинг",
-      "path": "Решардинг.md"
-    },
     {
       "basename": "Home",
       "path": "Home.md"

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

@@ -68,21 +68,28 @@ linked:
 Как направлять на шарды:
 - Умный клиент. Приложение само решает в какой шард идти
 	- Нет дополнительной точки отказа. Нет лишнего хопа.
+	- Усложняется разработка. Нужно учитывать шардирование при разработке.
 	- Как выполнять [решардинг](Решардинг.md)?
 - Прокси
 	- Промежуточный сервис между клиентом и БД, который знает о шардинге и передает данные от БД к клиенту.
 	- Сервисы ничего не знают о шардинге
-	- Дополнительная точка отказа. Лишний хоп.
+	- Дополнительная точка отказа.
 		- Но можно попробовать разместить проксю рядом с сервисом.
 	- Увеличивается количество трафика.
+	- Уменьшается [Latency](Latency.md). Лишний хоп.
 - Координатор
 	- Промежуточный сервис между клиентом и БД, но в отличие от прокси не отдает сами данные, а указывает сервису в какой шард сходить.
 	- Сервисы ничего не знают о шардинге.
-	- Дополнительная точка отказа. Лишний хоп.
+	- Дополнительная точка отказа.
+	- Уменьшается [Latency](Latency.md). Лишний хоп.
 - Intra-database routing
 	- Клиент обращается к любому шарду БД, а он уже знает в какой шард сходить.
 	- Так работает [Redis](Redis.md) кластер 
 
+Лучше если количество нод будет равно степени 2 (2,4,8). Формула shard_Id % count.
+- 16 записей на 8 шардов -> 2 записи на шард
+- 16 записей на 16 шардов -> 1 запись на шард
+
 Реализации в СУБД:
 - [Шардирование в PostgreSQL](Шардирование%20в%20PostgreSQL.md)
 ## Заметки

Решардинг.md

@@ -16,9 +16,6 @@ linked:
 - Клиентов, так как в момент решардинга могут возникать ошибки из-за не консистентности данных
 - Сеть, так как по сети передаются данные из одного шарда в другой
 
-Лучше если количество нод будет равно степени 2 (2,4,8). Формула shard_Id % count.
-- 16 записей на 8 шардов -> 2 записи на шард
-- 16 записей на 16 шардов -> 1 запись на шард
 
 ## Заметки
 - Что если не переносить записи сразу, а сначала обращаться по новому значению хэш функции, а потом по старому. Таким образом можно в фоне мигрировать данные.