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

This commit is contained in:
Struchkov Mark 2024-06-20 21:54:23 +03:00
parent 7da4fb8506
commit 5cc7adae03
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C
9 changed files with 43 additions and 34 deletions

View File

@ -24,24 +24,24 @@
"unresolvedLinks": false,
"recentFilesStore": [
{
"filepath": "Партиционирование.md",
"timestamp": 1718909133656
"filepath": "_inbox/Шардирование в БД.md",
"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": [],

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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