vault backup: 2024-06-20 21:54:23

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

@@ -24,24 +24,24 @@
   "unresolvedLinks": false,
   "recentFilesStore": [
     {
-      "filepath": "Партиционирование.md",
+      "filepath": "_inbox/Шардирование в БД.md",
-      "timestamp": 1718909133656
+      "timestamp": 1718909535878
+    },
+    {
+      "filepath": "_inbox/Горизонтальное масштабирование.md",
+      "timestamp": 1718909530869
+    },
+    {
+      "filepath": "_inbox/Вертикальное масштабирование.md",
+      "timestamp": 1718909525308
+    },
+    {
+      "filepath": "Партиционирование в БД.md",
+      "timestamp": 1718909422727
     },
     {
       "filepath": "_inbox/Шардирование - OTUS.md",
       "timestamp": 1718908901467
-    },
-    {
-      "filepath": "_inbox/Шардирование.md",
-      "timestamp": 1718908873063
-    },
-    {
-      "filepath": "_inbox/Вертикальное масштабирование.md",
-      "timestamp": 1718908853473
-    },
-    {
-      "filepath": "_inbox/Согласованное префиксное чтение.md",
-      "timestamp": 1718908758111
     }
   ],
   "bookmarkedFileStore": [],

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

@@ -1,5 +1,17 @@
 {
   "recentFiles": [
+    {
+      "basename": "Шардирование в БД",
+      "path": "_inbox/Шардирование в БД.md"
+    },
+    {
+      "basename": "Горизонтальное масштабирование",
+      "path": "_inbox/Горизонтальное масштабирование.md"
+    },
+    {
+      "basename": "Вертикальное масштабирование",
+      "path": "_inbox/Вертикальное масштабирование.md"
+    },
     {
       "basename": "Партиционирование в БД",
       "path": "Партиционирование в БД.md"
@@ -8,14 +20,6 @@
       "basename": "Шардирование - OTUS",
       "path": "_inbox/Шардирование - OTUS.md"
     },
-    {
-      "basename": "Шардирование",
-      "path": "_inbox/Шардирование.md"
-    },
-    {
-      "basename": "Вертикальное масштабирование",
-      "path": "_inbox/Вертикальное масштабирование.md"
-    },
     {
       "basename": "Согласованное префиксное чтение",
       "path": "_inbox/Согласованное префиксное чтение.md"
@@ -195,10 +199,6 @@
     {
       "basename": "Java Разработка",
       "path": "knowledge/dev/java/Java Разработка.md"
-    },
-    {
-      "basename": "Adaptive Replacement Cache",
-      "path": "_inbox/Adaptive Replacement Cache.md"
     }
   ],
   "omittedPaths": [],

_inbox/Куб масштабирования приложений.md

@@ -22,7 +22,7 @@ linked:
 
 Маршрутизатор, выставленный впереди, задействует атрибут запроса, чтобы на­ править его к подходящему экземпляру. Для этого, к примеру, можно использовать поле userid.
 
-> Похоже на [Шардирование](Шардирование.md)
+> Похоже на [Шардирование в БД](Шардирование%20в%20БД.md)
 
 ![](Pasted%20image%2020240412202007.png)
 

_inbox/Репликация master-master.md

@@ -23,7 +23,7 @@ linked:
 **Минусы:**
 - Нет консистентности, есть конфликты. 
 - Усложнение логики. Встречается редко.
-- Не масштабирует запись. Для масштабирования нужно использовать [шардирование](Шардирование.md).
+- Не масштабирует запись. Для масштабирования нужно использовать [шардирование](Шардирование%20в%20БД.md).
 
 **Варианты применения:**
 - Географическая распределенность. Репликация между ЦОД.

_inbox/Репликация БД.md

@@ -34,7 +34,7 @@ linked:
 
 **Для чего делают репликацию?**
 - Увеличение [High Availability](High%20Availability.md) БД. Одна БД падает, ее заменяет реплика.
-- Позволяет получить масштабирование чтения, но ==не позволяет получить масштабирование операций вставки.== Для масштабирования вставки используется [Шардирование](Шардирование.md).
+- Позволяет получить масштабирование чтения, но ==не позволяет получить масштабирование операций вставки.== Для масштабирования вставки используется [Шардирование в БД](Шардирование%20в%20БД.md).
 - Чтобы делать асинхронное [резервное копирование БД](Резервные%20копии%20БД.md)
 - Чтобы распределить нагрузку. Например перенести сложные запросы построения отчетов на отдельную реплику.
 

_inbox/Согласованное префиксное чтение.md

@@ -10,7 +10,7 @@ parents:
   - "[[Репликация БД]]"
 linked:
 ---
-Ситуация, которая возникает при наличии нескольких master-ов или при [Шардирование](Шардирование.md). 
+Ситуация, которая возникает при наличии нескольких master-ов или при [Шардирование в БД](Шардирование%20в%20БД.md). 
 
 У нас есть 2 участника чата и один сторонний наблюдатель. Сначала один пользователь пишет в чат, а следом другой пользователь пишет в чат. Далее наблюдатель читает сообщения из реплики, в которую сначала пришло второе сообщение, а потом только первое.
 

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

@@ -10,7 +10,14 @@ zero-link:
   - "[[00 Базы Данных]]"
 parents: 
 linked:
+  - "[[Партиционирование в БД]]"
 ---
+## Тезисы
+- Один из вариантов масштабирования
+- Данные разбиваются на части. Части размещаются на разных серверах.
+- Не является [репликацией](_inbox/Репликация.md) и [партиционированием](Партиционирование%20в%20БД.md)
+***
+
 Шардирование — это метод разделения и распределения больших объёмов данных по разным базам данных или узлам в рамках одной распределённой системы, чтобы облегчить их управление, обеспечить масштабируемость и повысить производительность. Каждая часть данных, или "шард", функционирует как отдельная база данных, и все шарды вместе образуют логически единую базу данных.
 
 Основные принципы шардирования включают в себя:
@@ -20,8 +27,8 @@ linked:
 - **Локализация данных**: Шардирование может быть использовано для локализации данных, чтобы уменьшить задержки, связанные с географическим расположением пользователей и баз данных.
 
 **Плюсы:**
-- **Масштабируемость**: Шардирование позволяет системе расти горизонтально, добавляя больше шардов для управления увеличивающимися объемами данных, что делает его эффективным решением для крупных и растущих систем.
+- [Горизонтальное масштабирование](Горизонтальное%20масштабирование.md)
-- **Улучшение производительности**: Разделение данных на шарды позволяет распределить нагрузку между серверами, что снижает задержки и увеличивает скорость обработки запросов за счет параллельной обработки.
+- **Улучшение производительности**: Единственный мет
 - **Высокая доступность и устойчивость к отказам**: Отказ одного шарда не приводит к полному сбою системы. Данные в остальных шардах остаются доступными, что повышает общую устойчивость системы к отказам.
 - **Географическое распределение данных**: Шардирование позволяет располагать данные ближе к пользователям, что может снижать задержки и улучшать взаимодействие с приложением.
 

wiki/zero/00 HighLoad.md

@@ -35,7 +35,7 @@ parents:
 - Использование толстого клиента
 - [Кэширование](Кэширование.md)
 - [Функциональное разделение](Функциональное%20разделение.md)
-- [Шардинг](Шардирование.md)
+- [Шардинг](Шардирование%20в%20БД.md)
 - Виртуальные шарды
 - Центральный диспетчер
 - [Репликация](_inbox/Репликация.md)

Партиционирование в БД.md

@@ -6,16 +6,18 @@ date:
   - - 2024-06-20
 zero-link:
   - "[[00 Базы Данных]]"
+  - "[[00 HighLoad]]"
 parents: 
 linked:
+  - "[[Шардирование в БД]]"
 ---
 - Берем данные и разделяем по какому-то признаку
 - Разделенные данные физически лежат отдельно. Разные таблицы
 - Но все данные остаются в пределах одного сервера.
 
 **Минусы:**
+- Некоторые запросы могут замедлиться. Кросс-партиционные запросы.
 - Так как данные лежат на одном сервере, то если уперлись в производительность диска, партиционирование не поможет.
-- Некоторые запросы могут замедлиться.
 
 **Плюсы:**
 - Некоторые типы запросов может ускорить за счет уменьшения объема данных в партиции.