vault backup: 2024-07-14 20:59:31

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

@@ -24,12 +24,16 @@
   "unresolvedLinks": false,
   "recentFilesStore": [
     {
-      "filepath": "_inbox/Consistent hashing.md",
+      "filepath": "_inbox/Шардирование в БД.md",
-      "timestamp": 1720975722279
+      "timestamp": 1720979905047
     },
     {
-      "filepath": "_inbox/Шардирование в БД.md",
+      "filepath": "Решардинг.md",
-      "timestamp": 1720975721310
+      "timestamp": 1720979834589
+    },
+    {
+      "filepath": "_inbox/Consistent hashing.md",
+      "timestamp": 1720975722279
     },
     {
       "filepath": "_inbox/Range Base Sharding.md",
@@ -38,10 +42,6 @@
     {
       "filepath": "_inbox/Key Based Sharding.md",
       "timestamp": 1720975702126
-    },
-    {
-      "filepath": "_inbox/Directory Based Sharding.md",
-      "timestamp": 1720975669145
     }
   ],
   "bookmarkedFileStore": [],

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

@@ -1,13 +1,17 @@
 {
   "recentFiles": [
-    {
-      "basename": "Consistent hashing",
-      "path": "_inbox/Consistent hashing.md"
-    },
     {
       "basename": "Шардирование в БД",
       "path": "_inbox/Шардирование в БД.md"
     },
+    {
+      "basename": "Решардинг",
+      "path": "Решардинг.md"
+    },
+    {
+      "basename": "Consistent hashing",
+      "path": "_inbox/Consistent hashing.md"
+    },
     {
       "basename": "Range Base Sharding",
       "path": "_inbox/Range Base Sharding.md"
@@ -20,10 +24,6 @@
       "basename": "Directory Based Sharding",
       "path": "_inbox/Directory Based Sharding.md"
     },
-    {
-      "basename": "Решардинг",
-      "path": "Решардинг.md"
-    },
     {
       "basename": "00 Базы Данных",
       "path": "wiki/zero/00 Базы Данных.md"

_inbox/Consistent hashing.md

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

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

@@ -70,14 +70,14 @@ linked:
 Как направлять на шарды:
 - Умный клиент. Приложение само решает в какой шард идти
 	- Нет дополнительной точки отказа. Нет лишнего хопа.
-	- Как обновлять при изменении количества шардов?
+	- Как выполнять [решардинг](Решардинг.md)?
-- Прокси
-	- Сервисы вообще не знают о шардинге
-	- Дополнительная точка отказа. Лишний хоп.
 - Координатор
 	- Сервисы вообще не знают о шардинге.
 	- Дополнительная точка отказа. Лишний хоп.
 	- Не отдает сами данные, а указывает сервису в какой шард сходить.
+- Прокси
+	- Сервисы вообще не знают о шардинге
+	- Дополнительная точка отказа. Лишний хоп.
 
 Реализации в СУБД:
 - [Шардирование в PostgreSQL](Шардирование%20в%20PostgreSQL.md)

Решардинг.md

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