vault backup: 2024-06-20 21:59:23
This commit is contained in:
parent
5cc7adae03
commit
d90b7dea40
8
.obsidian/plugins/home-tab/data.json
vendored
8
.obsidian/plugins/home-tab/data.json
vendored
@ -23,6 +23,10 @@
|
||||
"markdownOnly": false,
|
||||
"unresolvedLinks": false,
|
||||
"recentFilesStore": [
|
||||
{
|
||||
"filepath": "Партиционирование в БД.md",
|
||||
"timestamp": 1718909771420
|
||||
},
|
||||
{
|
||||
"filepath": "_inbox/Шардирование в БД.md",
|
||||
"timestamp": 1718909535878
|
||||
@ -35,10 +39,6 @@
|
||||
"filepath": "_inbox/Вертикальное масштабирование.md",
|
||||
"timestamp": 1718909525308
|
||||
},
|
||||
{
|
||||
"filepath": "Партиционирование в БД.md",
|
||||
"timestamp": 1718909422727
|
||||
},
|
||||
{
|
||||
"filepath": "_inbox/Шардирование - OTUS.md",
|
||||
"timestamp": 1718908901467
|
||||
|
@ -1,5 +1,9 @@
|
||||
{
|
||||
"recentFiles": [
|
||||
{
|
||||
"basename": "Партиционирование в БД",
|
||||
"path": "Партиционирование в БД.md"
|
||||
},
|
||||
{
|
||||
"basename": "Шардирование в БД",
|
||||
"path": "_inbox/Шардирование в БД.md"
|
||||
@ -12,10 +16,6 @@
|
||||
"basename": "Вертикальное масштабирование",
|
||||
"path": "_inbox/Вертикальное масштабирование.md"
|
||||
},
|
||||
{
|
||||
"basename": "Партиционирование в БД",
|
||||
"path": "Партиционирование в БД.md"
|
||||
},
|
||||
{
|
||||
"basename": "Шардирование - OTUS",
|
||||
"path": "_inbox/Шардирование - OTUS.md"
|
||||
|
@ -21,16 +21,15 @@ linked:
|
||||
Шардирование — это метод разделения и распределения больших объёмов данных по разным базам данных или узлам в рамках одной распределённой системы, чтобы облегчить их управление, обеспечить масштабируемость и повысить производительность. Каждая часть данных, или "шард", функционирует как отдельная база данных, и все шарды вместе образуют логически единую базу данных.
|
||||
|
||||
Основные принципы шардирования включают в себя:
|
||||
- **Горизонтальное разделение данных**: Вместо того чтобы хранить все данные в одной таблице или базе данных, они разделяются на меньшие, более управляемые части. Каждый шард содержит часть данных, например, пользователей с идентификаторами от 1 до 1000 в одном шарде и от 1001 до 2000 в другом.
|
||||
- **Горизонтальное разделение данных**: Вместо того чтобы хранить все данные в одной таблице или базе данных, они разделяются на меньшие части. Каждый шард содержит часть данных, например, пользователей с идентификаторами от 1 до 1000 в одном шарде и от 1001 до 2000 в другом.
|
||||
- **Распределение нагрузки**: Поскольку запросы к данным могут обрабатываться параллельно разными шардами, это способствует балансировке нагрузки и увеличению производительности системы.
|
||||
- **Масштабируемость**: По мере роста объёмов данных новые шарды могут быть добавлены в систему, что позволяет масштабировать приложение горизонтально.
|
||||
- **Локализация данных**: Шардирование может быть использовано для локализации данных, чтобы уменьшить задержки, связанные с географическим расположением пользователей и баз данных.
|
||||
|
||||
**Плюсы:**
|
||||
- [Горизонтальное масштабирование](Горизонтальное%20масштабирование.md)
|
||||
- **Улучшение производительности**: Единственный мет
|
||||
- **Улучшение производительности**: Единственный метод ускоряющий запись в БД.
|
||||
- **Высокая доступность и устойчивость к отказам**: Отказ одного шарда не приводит к полному сбою системы. Данные в остальных шардах остаются доступными, что повышает общую устойчивость системы к отказам.
|
||||
- **Географическое распределение данных**: Шардирование позволяет располагать данные ближе к пользователям, что может снижать задержки и улучшать взаимодействие с приложением.
|
||||
|
||||
**Минусы:**
|
||||
- **Сложность управления**: Управление множеством шардов и обеспечение их синхронизации может быть сложной задачей, требующей продвинутых решений для мониторинга, резервного копирования и восстановления.
|
||||
|
@ -18,8 +18,10 @@ linked:
|
||||
**Минусы:**
|
||||
- Некоторые запросы могут замедлиться. Кросс-партиционные запросы.
|
||||
- Так как данные лежат на одном сервере, то если уперлись в производительность диска, партиционирование не поможет.
|
||||
- Кажется перестройка партиций дорогостоящая операция.
|
||||
|
||||
**Плюсы:**
|
||||
- Простая реализация. Разработчик продолжает обращаться к таблице, а СУБД понимает в какую партицию ей стоит идти.
|
||||
- Некоторые типы запросов может ускорить за счет уменьшения объема данных в партиции.
|
||||
|
||||
Основные типы разделения:
|
||||
|
Loading…
Reference in New Issue
Block a user