Ключевые понятия для понимания разделения баз данных

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


Подходы, позволяющие отложить шардинг

Вертикальное масштабирование: Использование более мощных отдельных серверов баз данных - больше процессоров, памяти, хранилищ и пропускной способности каналов ввода-вывода. Это гораздо проще в управлении, чем шардинг, и при этом позволяет значительно расширить систему.

Оптимизация SQL: Настройка SQL-запросов и схемы базы данных для достижения максимальной производительности на одном сервере. Требуются соответствующие индексы, эффективный SQL и т.д.

Кэширование: использование кэшей in-memory, например Redis, для снижения нагрузки на базу данных за счет отсутствия необходимости обращаться к ней при каждом запросе.

Реплики чтения + балансировщик нагрузки: Добавляет горизонтальную масштабируемость чтения без полной сложности шардинга. Направляет чтение между репликами.

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

#db

👉 @database_info

Горизонтальное и вертикальное шардирование

Существует два высокоуровневых подхода:

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

Горизонтальное разделение: Разделение базы данных на разделы строк, равномерно распределенные по нескольким серверам.

Некоторые методы горизонтального разделения:

1. На основе диапазона: Сегментирование строк на основе диапазона значений, например возрастных групп. Может привести к неравномерному распределению данных и появлению "горячих точек".

2. На основе каталога: Использование каталога для поиска строк. Обеспечивается гибкость, но возникает риск возникновения единой точки отказа.

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

#db

👉 @database_info

Как базы данных выполняют SQL-запросы?

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

1. Оператор SQL запускается в клиентской программе и передается по сети на сервер базы данных.

2. Когда сервер базы данных получает SQL-оператор, реляционный движок начинает его обработку. Сначала синтаксический анализатор проверяет правильность оператора. Затем он преобразует оператор в дерево запросов, которое представляет собой внутреннюю структуру данных.

3. Оптимизатор запросов просматривает дерево запросов и определяет наиболее эффективный способ выполнения SQL-оператора, создавая план выполнения.

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

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

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

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

8. В то же время менеджер блокировок накладывает блокировки, чтобы несколько транзакций могли выполняться одновременно, не конфликтуя между собой. Таким образом, обеспечивается изоляция и согласованность.

Работая вместе, эти компоненты обеспечивают надежную и эффективную обработку SQL-запросов в системе управления базами данных.

#db

👉 @database_info

Шпаргалка по MSSQL

#db

👉 @database_info

Шпаргалка по MongoDB

#db

👉 @database_info

SQLite: как организовывать таблицы

Поддерживать порядок в данных - все равно что поддерживать порядок на рабочем месте. Так легче понять, где что лежит, и освободить больше места для хранения или работы.

В настоящее время мир баз данных делится на SQL-библиотеки и NoSQL-библиотеки со своими преимуществами и недостатками. В этом материале мы остановимся на SQL-аналоге баз данных.

https://medium.com/swlh/sqlite-keeping-your-tables-organised-4b6bd2ec962e

#db

👉 @database_info

Памятка/шпаргалка по SQL

Изучение настоящей шпаргалки не сделает вас мастером SQL, но позволит получить общее представление об этом языке программирования и возможностях, которые он предоставляет. Рассматриваемые в шпаргалке возможности являются общими для всех или большинства диалектов SQL.

https://habr.com/ru/articles/564390/

#db

👉 @database_info

Как мы продукт на PostgreSQL переводили

Все побежали, и я побежал… Строго говоря, историю о том, как мы научили наше приложение работать с СУБД PostgreSQL и провели первую миграцию боевой системы одного из наших заказчиков, можно было рассказать ещё три года назад. Именно тогда мы это сделали впервые. Сейчас за нашими плечами уже 11 внедрений «Единого клиента» на PostgreSQL. Две миграции на эту СУБД с Oracle пройдут в этом году.

В статье поделюсь нашими наработками. Будет полезно тем, кто только собирается пойти по такому пути. Если тема интересна, можете посмотреть и выступление моего коллеги Вадима Зайцева на CDI Tech Conf.

https://habr.com/ru/companies/hflabs/articles/735000/

#db

👉 @database_info

Как работать с данными в 2024 году? Узнайте на VK Data Meetup!

VK Data Meetup — серия событий для дата-инженеров, разработчиков, администраторов о практиках работы с данными на разных уровнях.

Митап 14 декабря посвящен Databases & Storage. Обсудим тренды наступающего 2024 года, разберем особенности реализации масштабных проектов миграции и трансформации хранилищ и баз данных.

⏰ 14.12.2023, 14:30 МСК
⚡️ Регистрация: https://bit.ly/3RpwoNA

В программе

🔹 Тренды хранения данных, актуальные в 2024 году.
🔹 Миграция хранилища на Greenplum с сохранением уровня SLA.
🔹 Разделение слоев Compute & Storage в Hadoop.
🔹 Перенос большого Hadoop-кластера с bare metal на самописную оркестрацию One-cloud.

Приглашаем дата-инженеров, специалистов по DWH, администраторов, архитекторов и разработчиков.

Регистрация: https://bit.ly/3RpwoNA

Диаграмма SQL

#db

👉 @database_info

Как быстрее всего передавать данные с PostgreSQL на MS SQL

Однажды мне потребовалось забирать регулярно относительно большие объемы данных в MS SQL из PostgreSQL. Неожиданно выяснилось, что самый очевидный способ, через Linked Server на родные ODBC к PostgreSQL, очень медленный.

https://habr.com/ru/articles/553472/

#db

👉 @database_info

Руководство по стилю SQL · SQL Style Guide

Рекомендации, описанные в этом руководстве, во многом пересекаются с описанными в книге Джо Селко «Стиль программирования Джо Селко на SQL» (оригинал: SQL Programming Style). Это, в частности, найдут полезным те, кто уже знаком с этой книгой. Тем не менее автор этого руководства в некоторых аспектах более категоричен, нежели Джо Селко, а в других, напротив, более гибок. И, конечно, нельзя не отметить, что это руководство значительно короче и лаконичнее книги Селко — здесь вы не встретите ни весёлых историй из жизни, наглядно объясняющих, как и почему лучше не делать, ни длинных повествований, мотивирующих на использование той или иной рекомендации.

https://www.sqlstyle.guide/ru/

#db

👉 @database_info

Детализированные стратегии кэширования динамических запросов

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

https://jensrantil.github.io/posts/fast-aggregate-queries-on-dynamic-data/

#db

👉 @database_info