🦒
System Analyst | Knowledge base
  • Введение
  • Soft skills
    • 📍Продукт
      • Роли в IT продукте
        • Системный аналитик (SA)
        • Бизнес-аналитик (BA)
        • SA vs BA
        • 📎Другие аналитики
      • Жизненный цикл продукта
      • Методологии разработки
        • Waterfall
        • Agile
          • Scrum
          • Kanban
      • 📎Целеполагание
        • SMART
        • Матрица Эйзенхауэра
        • RICE
        • 🔒HADI
    • 📍Требования
      • Классификация требований
        • Уровень: Бизнес
        • Уровень: Пользователь
          • Use case
          • User story
          • 📎Job story
        • Уровень: Продукт
          • Функциональные требования
          • Нефункциональные требования
      • Качества требований
      • Методы сбора требований
      • Техническое задание (ТЗ)
  • Hard skills
    • 📍Базы данных
      • Реляционные
        • Транзакции
          • 🔒CAP
        • Нормальные формы
        • SQL
          • DML
          • DDL/DCL/TCL
          • 📎Представления VIEW
        • Констрейты
        • 📎Типы данных
        • 🔒Middle+
          • Особенности работы с конкертными реляционными БД
      • Нереляционные
        • Примеры использования
        • 🔒Middle+
          • Колоночные
            • Сlickhouse
          • Ключ-значение
          • Матричные
          • Документо-ориентированные
          • Графовые
            • JanusGraph | Neo4j etc
      • Масштабирование БД
      • Оптимизация БД
        • 📎Типы индексов
        • 📎Уникальные индексы
        • 🔒Анатомия плана запроса
      • 📎Какую СУБД выбрать
      • 📎Хранение и анализ данных
        • ETL
        • DWH
          • DWH vs Data Lake vs Data Mart
        • OLAP
          • OLAP vs OLTP
        • BI-аналитика
    • 📍Интеграции
      • Форматы данных
        • JSON + JSON Schema
          • 🔒AVRO
        • JSON vs XML
      • Виды интеграций
        • Синхронное взаимодействие
          • REST
            • RESTful принципы
              • Отсутствие состояния (Авторизация)
                • 🔒OAuth / OpenID Connect
              • Кеширование
              • Единообразие интерфейса (CRUD)
                • Запрос/ответ
              • 🔒Cтепень зрелости REST API
            • Проектирование API
            • 📎Асинхронный REST
          • SOAP
            • XSD
            • WSDL
          • REST vs SOAP
        • Асинхронное взаимодействие
          • Kafka
          • RabbitMQ
          • Kafka vs RabbitMQ
          • ESB
          • gRPC
            • Правила proto-контракта
            • Protobuf vs JSON
            • Сравнительная таблица
          • Другое
          • 🔒WebSocket API
        • Sync vs Async
      • 🔒Middle+
        • Stateful vs Stateless
        • Apache Flink
        • оркестрация и хореография
    • 📍Проектирование
      • Архитектура
        • Монолит
        • Микросервисы
          • Паттерны реализации
        • Монолит vs Микросервисы
        • 🔒Middle+
          • Бессерверная
          • Сервис-ориентированная (SOA)
          • Другое
      • Нотации и диаграммы
        • UML
          • Диаграмма классов
          • Диаграмма последовательности
            • Фреймы
          • Диаграмма прецедентов (use case)
          • 🔒Middle+
            • Диаграмма деятельности/активности
            • Диаграмма состояний
        • BPMN
          • Основные элементы
        • BPMN vs UML
        • ERD
        • 📎IDEF0
      • Прототипирование
        • Figma vs Axure
      • Мониторинг
        • Логирование
        • Метрики
        • Алерты
        • 🔒Инструменты
          • Grafana
          • Prometheus
          • ELK
            • Elasticsearch
            • Logstash
            • Kibana
      • 🔐Системный дизайн
    • 📎DevOps for SA
      • Основы сетей
        • OSI
        • TCP/IP
        • HTTP
        • DNS
      • Git (VCS)
        • GitHub vs GitLab
      • Развертывание приложений
        • CI/CD
        • 🔒Middle+
          • Виртуализация/контеризация
            • ✍️Docker
            • Kubernetes
              • ✍️Openshift
      • Cloud Native
        • Сервисы облачных вычислений
        • Cloud-native app vs Traditional app
      • Командная строка
    • 📎QA for SA
      • Postman | Insomnia
      • Swagger
      • Верификация vs Валидация
      • Идентификация/Аутентификация/Авторизация
    • 📎PM for SA
      • Метрики
        • Метрики привлечения
        • Метрики вовлечённости
          • ARPU
          • LTV
          • NPV
          • ROI
          • NPS
      • Прокси метрики
      • Дерево метрик
      • Фреймворки
      • Юнит-экономика
      • Модель Кано
  • Другое
    • Литература
    • Советы по составлению резюме
    • Общие вопросы на собеседовании
    • Вопросы которые надо задать интервьюеру
  • Контакты
Powered by GitBook
On this page
  • Вертикальное масштабирование
  • Горизонтальное масштабирование
  • Репликация
  • Партицирование (секционирование)
  • Шардирование (шардинг/сегментирование)

Was this helpful?

  1. Hard skills
  2. Базы данных

Масштабирование БД

Вертикальное масштабирование

Вертикальное масштабирование предполагает наращивание мощностей сервера. Основным преимуществом метода является его простота. Нет необходимости переписывать код при добавлении мощностей, а управлять одним крупным сервером намного проще, чем целой системой. Это же является и основным недостатком — масштабирование ресурсов одного сервера имеет вполне конкретные аппаратные ограничения. Также стоит учесть стоимость такого решения: сервер с кратным объёмом вычислительных ресурсов в большинстве случаев оказывается дороже, чем несколько менее мощных серверов, дающих в сумме такую производительность.

Горизонтальное масштабирование

Горизонтальное масштабирование означает увеличение производительности за счёт разделения данных на множество серверов. Такой способ предполагает увеличение производительности без снижения отказоустойчивости. Существует три основных типа горизонтального масштабирования.

Область сравнения
Репликация
Партицирование
Шардирование

Основная функция

Повышение стабильности

Повышение управляемости

Ускорение обработки

Метод

Копирование между серверами

Разбиение по функциональности

Разбиение по объему

Распределение

По ведущим и ведомым серверам

Потоковое

Физическое

Репликация

Репликация — это синхронное или асинхронное копирование данных между несколькими серверами. Ведущие серверы часто называют мастерами (master), а ведомые серверы — слэйвами (slave).

Ведущие сервера используются для чтения и изменения данных, а ведомые — только для чтения. В классической схеме репликации обычно один мастер и несколько слэйвов, так как в большей части веб‑проектов операций чтения на несколько порядков больше, чем операций записи. Однако в более сложной схеме репликации может быть и несколько мастеров.

Главное преимущество репликации — большое количество копий данных. Так, если даже головной сервер выходит из строя, любой другой сможет его заменить. Однако как механизм масштабирования репликация не слишком удобна. Причина тому — рассинхронизация и задержки при передаче данных между серверами. Чаще всего репликация используется как средство для обеспечения отказоустойчивости вместе с другими методами масштабирования.

Например, создание нескольких дополнительных slave‑серверов позволяет снять с основного сервера нагрузку и повысить общую производительность системы, а также можно организовать слэйвы под конкретные ресурсоёмкие задачи и таким образом, например, упростить составление серьёзных аналитических отчётов — используемый для этих целей slave может быть нагружен на 100%, но на работу других пользователей приложения это не повлияет.

Партицирование (секционирование)

Партиционирование — это разбиение таблиц, содержащих большое количество записей, на логические части по неким выбранным администратором критериям.

Партиционирование таблиц делит весь объем операций по обработке данных на несколько независимых и параллельно выполняющихся потоков, что существенно ускоряет работу СУБД. Для правильного конфигурирования параметров партиционирования необходимо, чтобы в каждом потоке было примерно одинаковое количество записей.

Например, на новостных сайтах имеет смысл партиционировать записи по дате публикации, так как свежие новости на несколько порядков более востребованы и чаще требуется работа именно с ними, а не со всех архивом за годы существования новостного ресурса.

Шардирование (шардинг/сегментирование)

Шардинг — это прием, который позволяет распределять данные между разными физическими серверами.

Процесс шардинга предполагает разнесения данных между отдельными шардами на основе некого ключа шардинга. Связанные одинаковым значением ключа шардинга сущности группируются в набор данных по заданному ключу, а этот набор хранится в пределах одного физического шарда. Это существенно облегчает обработку данных.

Шардинг является наиболее приемлемым решением для крупномасштабной деятельности, особенно если его использовать в паре с репликацией. Но стоит отметить, что это достаточно сложно организовать, так как необходимо учитывать межсерверное взаимодействие.

Например, в системах типа социальных сетей ключом для шардинга может быть ID пользователя, таким образом все данные пользователя будут храниться и обрабатываться на одном сервере, а не собираться по частям с нескольких.

Источники:

PreviousJanusGraph | Neo4j etcNextОптимизация БД

Last updated 4 months ago

Was this helpful?

📍
https://simpleone.ru/blog/masshtabirovanie-baz-dannyh/
https://web-creator.ru/articles/partitioning_replication_sharding
https://cloud.yandex.ru/ru/docs/glossary/sharding