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

Почему владение Django — не предел для разработчика

Особенности Django

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

Основные плюсы:

• Полноценный стек: ORM для работы с базой, мощная система маршрутизации URL, шаблоны для рендеринга, встроенная админка, формы, система аутентификации и авторизации.
• Архитектура MTV (Model-Template-View): похожа на классический MVC, но с особенностями, которые упрощают разделение логики, представления и данных.
• Безопасность: Django автоматически защищает от CSRF, XSS, SQL-инъекций и других распространенных атак. Не нужно писать много дополнительного кода.
• Активное сообщество и экосистема: тысячи сторонних пакетов, расширений и готовых решений.
• Поддержка нескольких баз данных: PostgreSQL, MySQL, SQLite, Oracle и др.

Ограничения:

• Синхронная природа Django.
• Монолитность: архитектура фреймворка ориентирована на создание крупных приложений, но в микросервисах может быть избыточна.
• Ограниченная гибкость ORM: нестандартные SQL-запросы иногда сложно выразить средствами ORM, приходится использовать raw SQL или сторонние библиотеки для запросов.
• Строгие правила организации кода: требуют дисциплины и могут ограничивать свободу в архитектурных решениях.
• Недостаточная производительность: уступает лёгким асинхронным фреймворкам (например, FastAPI), особенно под высокими нагрузками. Но для большинства проектов пока это не критично.

В каком направлении двигаться после изучения Django

Задача — создавать продукт, который будет нужен конечному потребителю.

Первое направление для развития — расширить инструментарий для решения разных задач в веб-разработке

Возможные пути:

• Изучить другие веб-фреймворки (Flask, FastAPI)
• Углубиться в асинхронное программирование (asyncio, aiohttp)
• Работать с API и микросервисами

Flask и FastAPI

Flask — минималистичный микрофреймворк, даёт полную свободу в выборе компонентов. Используют для небольших приложений и микросервисов.

FastAPI — современный асинхронный фреймворк, ориентирован на создание высокопроизводительных API. Поддерживает стандарт OpenAPI и автоматическую генерацию документации. Он быстрее Flask и Django благодаря asyncio и Pydantic.

Асинхронное программирование

Веб-разработка всё активнее использует асинхронные технологии. Django не всегда справляется с задачами высокой конкурентной нагрузки.

Поэтому изучение asyncio — стандартной библиотеки Python для асинхронного программирования — откроет перед вами новые возможности. Вместе с aiohttp или тем же FastAPI вы сможете создавать приложения, которые обрабатывают тысячи одновременных соединений. Это особенно важно для real-time сервисов, чат-приложений и систем с интенсивным обменом данными.

Второе направление — расширить навыки в смежных областях

Можно пойти по пути расширения компетенций за пределы основной специализации. Важно не только уметь писать код, но и понимать, как приложения разворачиваются и работают в продакшене. Знание DevOps-практик помогает наладить эффективное взаимодействие между разработкой и эксплуатацией.

Изучение DevOps и контейнеризации

Контейнеры позволяют запускать приложения в изолированной среде, это упрощает настройку и развертывание. Например, Docker помогает упаковать приложение с зависимостями в один контейнер, а Kubernetes — управлять такими контейнерами в продакшене. Знание этих технологий улучшит взаимодействие с операционной командой и ускорит выпуск новых версий приложений.

CI/CD и автоматизация процессов

Непрерывная интеграция (Continuous Integration) и непрерывное развертывание (Continuous Deployment) — ключевые практики современной разработки ПО. Они позволяют автоматизировать сборку, тестирование и доставку приложений, масштабировать процессы.

Инструменты CI/CD (например, Jenkins, GitLab CI/CD, GitHub Actions) помогают настроить автоматические пайплайны, которые обеспечивают быструю обратную связь и минимизируют человеческий фактор в релизах. Автоматизация процессов снижает количество ошибок и позволяет сосредоточиться на разработке новых функций.

Настройка непрерывной интеграции и доставки (Continuous Integration / Continuous Delivery) снижает поток ошибок при релизах и экономит время. Пример: GitHub Actions для автоматического запуска тестов и сборки проекта при каждом коммите.

Больше знаний в области баз данных

Помимо классических реляционных баз данных (PostgreSQL, MySQL), современные приложения часто используют NoSQL для специфичных задач. MongoDB, Redis, Cassandra обеспечивают гибкость в хранении данных, горизонтальное масштабирование и высокую производительность при работе с большими объемами информации.

Графовые базы данных (Neo4j, ArangoDB) предназначены для эффективного хранения и анализа связей между объектами, что важно для социальных сетей, рекомендательных систем и других приложений с богатой структурой.

Так, Redis хорошо подходит для кэширования данных, а Neo4j — для сложных связей между объектами.

Третье направление — переход к другим аспектам Python-разработки

Рассмотрим четыре варианта карьерного развития для Python-программиста: Data Science и машинное обучение, автоматизация бизнес-процессов, разработка десктопных приложений и встраиваемые системы (IoT).

Почему стоит попробовать?

• Высокий спрос на специалистов. Они востребованы в банках и инвестиционных компаниях, в сфере медицины и биотехнологии, в консалтинге, автомобильной промышленности и т.д..
• Широкий набор библиотек: pandas, NumPy, scikit-learn, TensorFlow, PyTorch.
• Возможность работать с реальными задачами: от бизнеса до науки.

Автоматизация и скрипты для бизнеса

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

Знание таких библиотек, как openpyxl (работа с Excel), requests (HTTP-запросы), BeautifulSoup и Scrapy (парсинг веб-страниц), а также умение писать скрипты под конкретные задачи, делают разработчика ценным специалистом в корпоративной среде.

Примеры задач:

• Автоматическая загрузка данных из Excel и их преобразование
• Скрипты для отправки email-рассылок
• Интеграция с CRM и другими сервисами через API

Разработка десктопных приложений (PyQt, Kivy)

Хотя сейчас популярность уходит к вебу и мобильным платформам, десктопные приложения на Python востребованы в таких сферах: инструменты для анализа, редакторы, утилиты.

Инструменты для создания:

• PyQt — мощный фреймворк для создания кроссплатформенных GUI.
• Kivy — библиотека для разработки приложений с поддержкой сенсорных экранов.

Этот путь подходит тем, кто хочет создавать удобные инструменты с графическим интерфейсом для пользователей на Windows, macOS или Linux.

Встраиваемые системы и IoT

В области IoT и встроенных систем Python набирает популярность благодаря легкости освоения и поддержке на маломощных устройствах. Помогают в этом платформы по типу Raspberry Pi и MicroPython.

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

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

Если рассматривать профессию “Python-разработчик на Django”, то сразу получится сужение до конкретной библиотеки на конкретном языке. Если же в резюме у специалиста стоит, что он “разработчик Python”, возможностей сильно больше. Если написать про себя “разработчик”, будет не понятно, разработчик чего. Но изменив резюме на “DevOps инженера”, становится понятен карьерный трек.

Как работает database sharding

Database sharding (шардирование базы данных) — это техника горизонтального масштабирования, при которой большая база разделяется на несколько частей. Их называют шардами. Эти шарды распределяются по другим серверам и связываются в одну систему. Рассмотрим подробнее.

Принцип: разбиение данных на независимые сегменты (шарды)

Каждый шард работает как отдельная независимая база данных. Ключевым элементом здесь выступает ключ шардирования (shard key). Это правила, которые определяют, в какой именно шард попадёт конкретная строка данных.

Например, мы можем задать правило: если у нас есть user_id и его значение меньше тысячи, то данные попадают в шард 1, если значение больше тысячи, то в шард 2.

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

Так, мы можем параллельно обрабатывать много запросов и увеличивать пропускную способность системы.

Общая архитектура: клиент — роутер — шард

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

Клиент: Программа на стороне пользователя, которая отправляет стандартный запрос к базе данных (например, SELECT * FROM users WHERE user_id = 123).

Маршрутизатор запросов или роутер (Query Router): Это что-то вроде посредника между клиентом и шардом, который выполняет роль диспетчера. Он принимает запрос, при помощи sharding ключа определяет, что это за данные, в какой шард и с какой целью их надо отправить. Далее он отправляет запрос на нужный шард.

Шард (Shard): Получает запрос, выполняет и возвращает результат обратно маршрутизатору, который затем передаёт его клиенту.

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

Основные компоненты: шард, маршрутизатор, реплика-сеты

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

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

Виды шардинга

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

Горизонтальный sharding (по строкам): самый популярный

При горизонтальном шардинге мы «нарезаем» нашу базу данных по строкам. Допустим, у нас таблица с клиентами. Мы задаём диапазон ключу шардирования с user_id от 1 до 1 000 000. Данные в этом диапазоне, построчно будут храниться в шадре 1. Если user_id попадает в диапазон от 1 000 001 до 2 000 000, то эти данные отправляем на шадр 2. И так далее.

Благодаря этому способу мы можем равномерно распределять данные, и нам будет проще масштабировать систему при помощи создания новых шадров и добавления серверов.

Горизонтальный sharding — идеальный вариант, когда основная проблема — это огромное количество строк в таблицах и высокая нагрузка на чтение/запись.

Вертикальный шардинг (по столбцам): разделение по функциональности

Если горизонтальный шардинг режет таблицу поперёк (по строкам), то вертикальный — вдоль, разделяя столбцы. Таблица делится на несколько с меньшим количеством столбцов. Обычно они группируются по частоте использования или по смысловой нагрузке. Например, в таблице юзеров можно выделить часто запрашиваемые user_id, username, email в одну таблицу, а редко используемые — biography, preferences, last_login_details — в другую.

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

Directory-based sharding: использование хеш-таблицы маршрутов

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

Вот пример того, как это работает:

• Клиентское приложение отправляет запрос (например, получить данные для order_id = 98765).
• Маршрутизатор запросов перехватывает его.
• Маршрутизатор обращается к каталогу: с запросом, где найти order_id = 98765.
• Каталог ищет в своей таблице соответствий правило, под которое подпадает order_id = 98765. Для быстрого поиска он часто использует эффективные структуры данных, такие как хеш-таблицы или B-деревья (это внутренняя деталь реализации самого каталога).
• Допустим, каталог находит правило «Диапазон order_id 90000-99999 → Shard-3» и сообщает это маршрутизатору.
• Маршрутизатор перенаправляет исходный запрос на Shard-3.

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

Range-based sharding: разбиение по диапазонам значений

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

Администратор системы (или автоматизированный инструмент) определяет границы диапазонов для ключа шардинга. Маршрутизатор получает запрос, смотрит на значение этого ключа и сравнивает его с известными диапазонами, чтобы определить целевой шард.

Этот способ простой, логичный и отлично подходит для работы с данными за определённый период. Но у него есть проблема. Допустим, мы запустили форум и проводим шардирование по трём ключам:

• id от 1 до 1000 — шард 1;
• id от 1001 до 2000— шард 2;
• id от 2001 до 3000 — шард 3.

Когда пользователи начнут регистрироваться, у нас будет активен шард 1, потом шард 2. Далее вся нагрузка перейдёт на шард 3. Они не будут одновременно равномерно работать. Это может стать проблемой при оптимизации.

Hash-based sharding: равномерное распределение по хешу ключа

Этот подход помогает добиться максимально равномерного распределения нагрузки по всем шардам. Работает следующим образом:

Берём значение ключа для конкретной строки данных (например, user_id = 2001).

Применяем к нему хеш-функцию. Хеш-функция (например, MD5, SHA-1, MurmurHash) — это алгоритм, который превращает входные данные (наш user_id) в строку или число фиксированной длины (хэш), которое выглядит почти случайно. Даже небольшое изменение на входе (например, user_id = 2001 и user_id = 2002) обычно даёт совершенно разные хеши.

Вычисляем номер шарда. Чаще всего делим значение хеша на количество шардов и берём остаток от деления. Например, 548291 % 3 = 2. Далее в зависимости от остатка распределяем данные по шардам. Значение с остатком 2 пойдёт в шард 2, если остаток 1, то в шард 1 и так далее.

Так мы получаем более равномерное распределение данных. Но из минусов — в такой базе сложно обрабатывать диапазоны и добавлять новые шарды в систему.

Примеры реализации

MongoDB: встроенная поддержка шардинга

MongoDB — это NoSQL база данных, которая была разработана с закосом на горизонтальное масштабирование. То есть она адаптирована к тому, чтобы работать на нескольких серверах и расширять это число по мере необходимости. Поэтому sharding здесь доступен из коробки, нам не надо заморачиваться со внешними расширениями.

Рассмотрим пример, как настроить sharding и работать с ним:

• sh.addShard() — добавляем сервер в кластер как шард. MongoDB понимает, что может использовать этот сервер для хранения части данных.
• use socialApp; sh.enableSharding("socialApp") — переключаемся на базу данных «socialApp». При помощи команды sh.enableSharding() разрешаем шардинг в этой БД.
• sh.shardCollection("socialApp.users", { "user_id": 1 }) — применяем sharding к коллекции users. Мы указываем полное имя коллекции (socialApp.users) и ключ шарда ({ "user_id": 1 }). Цифра 1 означает, что мы используем шардинг по диапазонам. Эти диапазоны не нужно задавать вручную, MongoDB определяет их самостоятельно.
• db.users.insertMany([...]) — вставляем данные в коллекцию users. MongoDB автоматически определяет, на какой шард поместить каждого пользователя.
• db.users.findOne({ user_id: 1 }) — запрашиваем данные пользователя user_id = 1. Mongos сам определит, на каком шарде они находятся.

PostgreSQL + Citus

В PostgreSQL нет поддержки встроенного шардинга, поэтому приходится устанавливать на сервер Citus. Это популярное расширение, которое как раз добавляет возможности горизонтального масштабирования и шардинга. Оно превращает кластер стандартных серверов PostgreSQL в распределённую базу данных.

Посмотрим на пример использования SQL-команд для настройки шардинга с помощью Citus:

• CREATE EXTENSION citus; — активируем Citus в текущей базе данных.
• CREATE TABLE app_logs (...) — создаём таблицу app_logs на узле-координаторе точно так же, как создали бы обычную таблицу в PostgreSQL.
• SELECT create_distributed_table('app_logs', 'service_name'); — при помощи этой команды включаем sharding. Citus понимает, что таблицу app_logs нужно распределить по рабочим узлам, используя поле service_name как ключ шардинга. Citus по умолчанию применяет Hash-based sharding, то есть, равномерно распределяет по шардам при помощи хеш-функций.
• INSERT INTO app_logs — добавляем данные логов. Citus перехватывает запрос, вычисляет хеш от значения service_name для каждой строки и распределяет данные по шардам.
• SELECT ... FROM app_logs — запрашиваем данные. Если фильтруем по service_name (как в первом SELECT), Citus направит запрос на нужный шард.

MySQL + Vitess

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

Vitess вместо прямых команд для шардинга определяет его правила в отдельном JSON-файле, который называется VSchema (Vitess Schema).

Допустим, у нас есть база данных commerce. Вот как она выглядит в виде кода:

А вот так она выглядит в виде таблицы:

В базе данных есть таблица orders, её мы и хотим шардировать по customer_id при помощи хеширования (hash-based sharding).

Файл VSchema (vschema.json) может выглядеть примерно так:

• "sharded": true — указываем, что база данных шардирована.
• "vindexes" — определяем hash_index типа hash, который будет использовать хеш-функцию для распределения.
• "tables" — описываются правила для конкретных таблиц.
• "orders" — настраиваем таблицу orders.
• "column_vindexes" — определяем, какой столбец является ключом ("column": "customer_id") и какой vindex ("name": "hash_customer_id") использовать для него.

Проблемы шардирования

Перераспределение шардов (resharding)

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

При решардинге часто приходится перегонять большие объёмы данных между серверами. Если используется хеш-шардинг, и мы меняем количество шардов, то пересчитываются ключи, по которым распределяются данные.

Например, раньше у нас было 4 шарда. Мы брали user_id, например 9, делили на 4 и получали остаток — 1. Значит, данные шли на шард номер 1. После масштабирования стало 5 шардов, и 9 % 5 = 4 — теперь те же данные должны храниться на шардe 4.

Такое перемещение затратно по ресурсам: грузит сеть, диски, может занять часы или даже дни. Иногда для этого приходится останавливать запись, что делает процесс ещё рискованнее.

Неравномерная нагрузка (hot shards)

Вспомним вид шардирования Range-based sharding. Это когда мы разбиваем данные по диапазонам. У нас был пример выше с форумом и шардингом user_id:

• id от 1 до 1000 — шард 1;
• id от 1001 до 2000— шард 2;
• id от 2001 до 3000 — шард 3.

Мы столкнулись с проблемой, что шард 1 и шард 2 после завершения диапазонов простаивали, а вся новая нагрузка приходилась на шард 3.

Такую проблему называют горячим шардом (hot shards). Производительность всей системы начинает зависеть от самого загруженного шарда. Преимущества шардирования снижаются.

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

Сложности с глобальными транзакциями и агрегациями

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

Но если счёт А находится на одном шарде, а счёт Б — на другом, стандартная транзакция не сработает. Между независимыми серверами нельзя просто так обеспечить ACID-гарантии. Для этого нужны сложные и медленные механизмы координации, например двухфазный коммит (2PC). Либо приходится идти на компромисс и использовать eventual consistency — когда данные приходят в согласованное состояние с небольшой задержкой. Например, деньги уже списались, но ещё не зачислились.

Аналогичная проблема и с агрегациями: посчитать сумму продаж или число пользователей уже не получится одной SQL-командой. Каждый шард сначала считает свою часть, а потом результат нужно собрать и объединить — это требует дополнительной координации и может усложниться при фильтрации или группировках.

Сложность управления и мониторинга

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

Больше компонентов: Вместо одной базы данных появляется множество шардов (часто с репликами), маршрутизаторы запросов, серверы конфигурации. Всё это нужно настраивать, обновлять и обслуживать.

Мониторинг: Требуется отслеживать состояние каждого шарда, равномерность распределения нагрузки, задержки в сети, работу маршрутизаторов. Нужны более сложные инструменты мониторинга.

Отладка: Найти источник проблемы в распределённой системе сложнее. Ошибка может быть где угодно: в приложении, маршрутизаторе, на одном из шардов или в сети.

Резервное копирование: Создание согласованных резервных копий и восстановление данных со множеством независимых шардов требует более сложных процедур.

Когда стоит применять Sharding

Рост объёма данных и нагрузок

Sharding стоит применять, если БД сильно разрослась, хранить её на одном сервере становится сложно и дорого. Серверу приходится обрабатывать много данных, и поэтому увеличивается время отклика.

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

Не справляется один сервер/реплика

Допустим, у нас один сервер и он не справляется с запросами и большими данными. Конечно, мы можем заняться вертикальным масштабированием, поставить CPU производительнее, добавить больше ОЗУ и так далее. Однако у этого подхода есть ограничения. Во-первых, каким бы мощным ни был бы сервер, он со временем упрётся в потолок своей производительности. Во-вторых, иногда дешевле купить несколько новых серверов помощнее, чем прокачивать старый. Поэтому создание кластера и распределение в нём нагрузки при помощи шардинга — часто более выигрышное решение, чем один сервер.

Потребность в геораспределённости или отказоустойчивости

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

Мы можем хранить все данные и обрабатывать запросы на одном сервере и сделать его реплику с копией данных. Если этот сервер падает, то его заменяет реплика. Но что, если эта реплика тоже упадёт? Тогда нам и помогает sharding с репликацией. В случае сбоев отвалятся только отдельные серверы с некоторыми наборами данных. Конечно, здесь тоже, в теории, можно положить весь кластер, включая реплики, но сделать это сложнее.

Шардирование — полезный инструмент при работе с СУБД. А узнать про большее число подобных инструментов можно в нашем телеграм канале!

Структура данных: реляционные таблицы vs. Документо-ориентированные, графовые, ключ-значение базы

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

Рассмотрим пример таблицы ниже:

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

Давайте создадим нашу таблицу при помощи SQL:

Командой CREATE TABLE создаём таблицу, которую называем «Персонажи». В скобках прописываем название столбцов, напротив указываем тип данных, который здесь будет храниться. Например, VARCHAR(50) — это текст до 50 символов, DATE — дата, INT — число. PRIMARY KEY — первичный ключ строки. Он нужен, чтобы у каждой строки таблицы был свой уникальный номер.

Далее заполним нашу таблицу при помощи команды INSERT INTO Персонажи VALUES:

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

А теперь добавим ещё одного персонажа и отфильтруем значения по столбцу «Фильм_Сериал»:

Команда INSERT INTO добавляет нового персонажа в уже существующую базу.

В скобках после INSERT INTO мы перечисляем столбцы, которые хотим заполнить. VALUES — значения для этих столбцов.

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

Далее проводим фильтрацию по сериалу: «Игра престолов»:

• SELECT — выбирает данные из столбцов.
• После SELECTпишем, какие именно столбцы хотим видеть (не всё, а только эти шесть).
• FROM Персонажи — указываем таблицу, из которой берём данные.
• WHERE Фильм_Сериал — выбираем столбец, по которому будем искать данные.

В результате получим вот такие данные:

NoSQL в сравнении с SQL не просто другой язык, а целая философия организации базы данных. Никаких строгих таблиц — всё зависит от того, с чем работаем. В NoSQL есть много видов данных, под каждый из них существуют свои системы управления базами данных (СУБД). Вот основные из них:

Документо-ориентированные базы (MongoDB): данные лежат в виде документов, похожих на JSON, но это не совсем он, а BSON. Различия кроются в том, что это его бинарная версия.

Пример:

Слева в кавычках мы пишем название наших полей, например, «Персонаж». Далее через двоеточие указываем значение (тоже в кавычках) и заканчиваем запись для поля запятой. Всё это внутри фигурных скобок.

Ключ-значение (Redis): это тип NoSQL баз данных, где информация хранится в виде пар «ключ-значение», как в словаре: ключ — уникальный идентификатор, значение — любые данные, связанные с ним. Например, запись Джона Сноу будет выглядеть так:

Внутри фигурных скобок прописываем ключ в кавычках. Далее через двоеточие пишем значение. Отделяем поля между собой при помощи запятой.

Графовые базы (Neo4j): здесь данные — это узлы.

CREATE (Джон:Персонаж {имя: "Джон Сноу", дом: "Старк"});

Создаётся узел с меткой Персонаж, который представляет Джона Сноу. Узел имеет два свойства: имя со значением «Джон Сноу» и дом со значением «Старк». Переменная Джон — временное имя для ссылки на узел.

CREATE (Тирион:Персонаж {имя: "Тирион Ланнистер", дом: "Ланнистер"});

Далее создаётся ещё один узел с меткой Персонаж, представляющий Тириона Ланнистера. У него тоже два свойства: имя — «Тирион Ланнистер» и дом — «Ланнистер». Переменная Тирион позволяет ссылаться на этот узел.

CREATE (Джон)-[:ЛАЙК]->(Тирион);

Затем появляется направленная связь (ребро) между узлами Джон и Тирион. Она имеет тип ЛАЙК и указывает, что Джон «лайкает» Тириона. Скобки () обозначают узлы, а [:ЛАЙК] со стрелкой -> показывает направление отношения.

Гибкость схемы SQL против NoSQL: строгая схема vs динамическая структура

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

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

В этом фундаментальное различие SQL и NoSQL. Первый плохо подходит для работы с неструктурированными данными.

В NoSQL мы можем при помощи MongoDB прописать значение только для одного персонажа, не трогая других:

Сравните данные Илона Маска и Сайтамы, у них есть различия в схеме.

Для такой записи в SQL нам пришлось бы добавлять поле «Чем известен» для всех персонажей в базе. Другие бы тогда получили значение null:

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

У NoSQL, в отличие от SQL, нет строгой схемы, благодаря этому он отлично подходит для работы с плохо структурированными данными.

Транзакции в SQL и NoSQL: ACID (SQL) vs. BASE (NoSQL)

Транзакция — набор тех операций, которые либо выполняются полностью, либо не выполняются совсем. Представим перевод денег: снимаем 500 рублей с нашего счёта и отправляем их на другой. Если что-то сломается на полпути, транзакция либо отменится, либо завершит оба шага. В базах данных транзакции нужны, чтобы данные оставались надёжными. Рассмотрим основные различия транзакций SQL и NoSQL.

ACID (SQL)

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

Атомарность (Atomicity) — транзакция выполняется как единое целое. Если хоть одна операция внутри неё не удалась, всё отменяется. Например, если при переводе денег сервер внезапно отключился, система откатит изменения, и средства не исчезнут.

Согласованность (Consistency) — данные всегда соответствуют правилам базы. Если на счёте 80$, а мы пытаемся перевести 100$, система просто не даст выполнить такую операцию.

Изоляция (Isolation) — параллельные транзакции не мешают друг другу. Пока одна выполняется, другая видит только конечный результат. Например, если один процесс переводит 100$ со счёта A на счёт B, а другой в этот момент проверяет баланс, он увидит либо старое состояние, либо уже обновлённое, но никогда промежуточное.

Долговечность (Durability) — завершённая транзакция остаётся в базе навсегда, даже в случае сбоя. Если мы пополнили счёт на 100$, эта информация будет сохранена, независимо от того, что произойдёт с сервером после.

BASE (NoSQL)

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

Базовая доступность (Basically Available) — система всегда отвечает на запросы, даже если часть данных ещё не синхронизирована. Например, ставя лайк, мы сразу видим его, даже если информация ещё не дошла до сервера.

Мягкое состояние (Soft State) — данные могут временно быть несогласованными. Ради высокой доступности система допускает, что информация изменяется без нашего участия. Например, когда у нового видео на YouTube лайков больше, чем просмотров — это результат того, что одни данные обновились быстрее других.

Конечная согласованность (Eventual Consistency) — если систему оставить в покое, она сама «додумает» и согласует данные между всеми узлами. Допустим, у поста 50 лайков, но у разных пользователей отображаются разные числа: кто-то видит 49, кто-то 53. Через некоторое время система синхронизируется, и у всех будет одинаковое значение.

BASE-жизнь — это про скорость и гибкость. Главное, чтобы данные в итоге сошлись, а не были идеальными в каждый момент времени.

Масштабируемость: вертикальное (SQL) vs горизонтальное (NoSQL) масштабирование

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

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

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

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

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

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

Благодаря этому мы можем распределять нагрузку NoSQL среди множества серверов. Это значит, что если нам не хватает производительности, то можно просто докупить новые устройства.

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

Первое и главное преимущество SQL — строгая структура данных и операций. У базы есть контракт, который ты обязан соблюдать при добавлении, изменении или запросе данных. Правило простое: «Либо всё, либо откат». Второе преимущество — мощный и популярный язык запросов. Сложные аналитические задачи ему по плечу. Уверен, реляционные БД будущего будут опираться на опыт SQL.

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

Плюсы NoSQL в гибкости, лёгкости масштабирования, высокой производительности при больших нагрузках и разнообразии предметно-ориентированных решений. Например, Redis — для кеширования, Firebase — для реалтайм-обновлений и так далее. Структуру данных можно менять на лету, идеально для проектов с частыми изменениями структуры данных.

Минусы в том, что у многих NoSQL свои системы команд и запросов — их приходится учить. Также есть сложности с консистентностью данных.

Где использовать SQL и NoSQL

Сценарии, где SQL незаменим

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

Финансовые и банковские системы

Здесь цена любой ошибки — чьи-то деньги, поэтому важна точность. Транзакции по стандарту ACID гарантируют, что деньги не потеряются при сбоях. Связь между счетами, клиентами и операциями проще строить через реляционные базы данных.

Примеры систем: PostgreSQL, Oracle Database, Microsoft SQL Server.

Аналитика и сложные запросы

В аналитике нужно регулярно вытаскивать данные из таблиц и строить зависимости. В SQL есть операторы JOIN, GROUP BY и оконные функции, которые решают задачи, наподобие расчёта среднего чека за квартал, в пару строк.

Примеры систем: MySQL, Snowflake, Google BigQuery.

Работа с отчётами и BI-системами

Данные для бизнеса — это таблицы, сводки, графики. SQL легко интегрируется с инструментами вроде Power BI или Tableau. Строгая схема помогает избежать путаницы в метриках.

Примеры систем: PostgreSQL, SQL Server, Redshift.

Логирование и аудит данных

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

Примеры систем: SQLite, PostgreSQL, MariaDB.

Управление складом и инвентаризацией

Данные о товарах, поставках и остатках связаны между собой. Реляционная модель идеально описывает такие структуры. Запросы вроде «что заканчивается на складе» пишутся быстро и понятно.

Примеры систем: MySQL, Oracle Database.

Где NoSQL работает лучше?

NoSQL — это про скорость, гибкость и масштабирование. Там, где SQL требует строгих рамок, NoSQL даёт свободу и справляется с хаосом больших данных. Вот сценарии, где он выигрывает:

Высоконагруженные системы и real-time сервисы

Допустим, у нас стриминговый сервис, здесь миллионы запросов в секунду, а задержки недопустимы. Горизонтальное масштабирование размазывает нагрузку по серверам. Данные отправляются быстро, без сложных JOIN’ов.

Примеры систем: Cassandra, MongoDB, DynamoDB.

Гибкие структуры данных и работа с JSON

В реальной жизни данные далеко не всегда приходят в виде строгой схемы. У кого-то может быть указан email, у кого-то его нет, но есть телефон. Поэтому для работы с такой информацией лучше подходят документо-ориентированные базы, которые хранят JSON или BSON без строгой структуры. Если мы добавим новое поле, такая база не сломается.

Примеры систем: MongoDB, CouchDB, Firebase.

Графовые базы для рекомендаций и соцсетей

Иногда связи между объектами важнее самих данных. Графовые базы строят сети вроде «друзья друзей» или «похожие товары» за доли секунды. SQL для этой задачи медленнее.

Примеры систем: Neo4j, ArangoDB, OrientDB.

Почему SQL и NoSQL нужно знать вместе?

SQL даёт точность и структуру, данные в NoSQL — это про скорость и гибкость. В реальных проектах их часто используют вместе, чтобы закрыть слабые места друг друга.

Примеры гибридных архитектур: SQL и NoSQL в одном проекте

Работа с каталогами товаров, запросами и системой рекомендаций в интернет-магазинах

Представим интернет-магазин: каталог товаров и заказы лежат в SQL — там важны связи и точность. А рекомендации «похожие товары» или история просмотров — в NoSQL, чтобы быстро отдавать данные и не мучиться со схемой.

Например, PostgreSQL хранит данные о клиентах и транзакциях, а MongoDB — отзывы и пользовательские профили. Всё в одном проекте, каждый инструмент на своём месте.

Кеширование запросов с помощью Redis и SQL

SQL силён в сложных запросах, но в больших базах может тормозить. А если у нас есть операция, которая предполагает повторный подсчёт? Это будет долго. Здесь выручает Redis, NoSQL-база типа «ключ-значение».

Представим аналитику продаж: SQL вычисляет «топ-10 товаров за месяц» Готовый список сохраняем в Redis. Теперь, когда нам нужен этот топ, данные тянутся из Redis за миллисекунды, нам не надо заново проводить вычисления в SQL.

Использование NoSQL для логов, SQL — для отчётности

Логи — это поток данных: миллионы записей, структура не всегда предсказуема. NoSQL вроде Cassandra или MongoDB «переваривает» их без проблем благодаря скорости записи и горизонтальному масштабированию. А потом из этого хаоса SQL, например, MySQL, вытягивает нужное для отчётов: «сколько ошибок за день» или «кто чаще ломает систему». NoSQL собирает сырые данные, SQL их структурирует.

Стоит ли учить SQL? Мнение экспертов

Мы решили спросить у экспертов, что бы они посоветовали молодым разработчикам изучать в первую очередь, SQL или NoSQL. Делимся мнениями:

Мой совет — начинайте с SQL. Вот почему:

1) База знаний. SQL учит вас основам работы с данными — как их хранить и извлекать. Это фундамент, который пригодится в любом проекте, даже если вы потом перейдёте на NoSQL.

2) Широкое применение. SQL встречается повсюду — от стартапов до банков. Знание SQL сразу даёт вам больше шансов найти работу или понять, что происходит в существующем проекте.

Но это не значит, что NoSQL можно просто игнорировать. После SQL я бы рекомендовал изучить хотя бы одну NoSQL базу — например, Redis или MongoDB. Современные проекты часто требуют гибкости и скорости, которые дают NoSQL системы. Зная обе технологии, вы сможете выбирать инструмент под задачу, а не подстраиваться под то, что знаете.

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

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

Не существует как такового единого NoSQL как системы управления базы данных, зачастую это очень сильно различающийся набор решений, поэтому стоит начать с SQL, для разных СУБД он довольно мало отличается синтаксически. SQL — это фундамент. NoSQL даст более полное понимание того, как можно работать с базами данных. Можно отметить, что в SQL добавляются фичи NoSql и наоборот.

SQL и NoSQL желательно знать вместе. Как видно исходя из комментариев экспертов и примеров, SQL — первый ключ к базам данных, NoSQL — второй, для более сложных сценариев.

Это не шутка. Именно такую сумму заплатила американская сеть казино Caesars Entertainment злоумышленникам, которые увели их БД.

База данных –– самое ценное, что есть у каждой компании. Именно в ней хранится вся чувствительная и важная для бизнеса информация. В этой статье расскажем, какие есть базы данных и как правильно с ними работать: подключаться и делать запросы.

Такие разные базы данных

Базы данных — основной инструмент программирования. БД хранят важную информацию о пользователях и позволяют этой информацией управлять.

Они делятся на два основных типа: реляционные и нереляционные.

Реляционная база — как большой шкаф с ящиками. У каждого своя подпись, и в нём лежат только определенные вещи по порядку. Например, один ящик для носков, второй для шапок, третий –– для носовых платков.

Все очень аккуратно, ничего не теряется, но если нужно что-то изменить, например, носки переложить в ящик с платками –– будет не так-то просто.

Чтобы делать запросы к реляционной базе, нужно использовать язык SQL. А обрабатывать эти запросы будет СУБД –– система управления базами данных. Простыми словами –– штука, которая помогает вам управлять самой базой. Что-то из шкафа вытащить, кого-то в него спрятать.

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

Какой тип БД выбрать для проекта –– зависит от целей компании, размера и особенностей бизнеса. Разберём каждый тип.

Реляционные базы данных (SQL)

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

Посмотрим на конкретные примеры.

MySQL

Очень популярная база с открытым исходным кодом. Она надежная, удобная и быстрая. MySQL часто используют для веб-приложений. Например, Airbnb, Netflix и Uber.

Её любят, потому что у неё качественная и подробная документация, а также большое сообщество.

PostgreSQL

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

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

SQLite

Эта однофайловая СУБД мало весит и не требует сервера для работы. Она идеально подходит для небольших приложений, мобильных устройств и тестирования.

Если нужно будет что-то куда-то переносить –– процесс пойдёт быстро. За эту простоту SQLite и любят.

Нереляционные базы

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

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

Разберём самые популярные варианты нереляционных баз.

MongoDB

NoSQL-база данных, которая хранит данные в формате JSON, обеспечивает гибкость и простоту работы. MongoDB часто используется в приложениях, требующих динамической структуры данных, а также в учебных и небольших проектах благодаря своей доступности и лёгкости освоения.

Redis

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

В чём разница между базами данных

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

Структура данных

Масштабируемость

Скорость и производительность

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

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

Подключаемся к MySQL

Для реляционных баз данных используются стандартные операции:

• SELECT — получить данные;
• INSERT — добавить новые данные;
• UPDATE — обновить существующие данные;
• DELETE — удалить данные.

Поработаем с ними на примере MySQL. Представим, что у нас есть база с пользователями нашего блога. Чтобы поработать с ней, нужно настроить соединение с программой. Разберём этот процесс шаг за шагом.

Шаг 1. Устанавливаем библиотеку

Для работы с MySQL в Python нам понадобится библиотека mysql-connector-python.

Дла этого напишем команду в терминале:

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

Шаг 2. Настраиваем подключение

Чтобы подключиться к базе данных MySQL, необходимо знать её параметры:

• Хост: адрес сервера, где находится база данных. Это может быть localhost;
• Порт: номер порта для подключения. По умолчанию для MySQL — 3306-й порт;
• Пользователь: имя пользователя, который имеет доступ к базе;
• Пароль: пароль для этого пользователя;
• Имя базы данных: конкретная база, с которой вы хотите работать.

Как это может выглядеть:

• Хост: localhost
• Порт: 3306
• Пользователь: root
• Пароль: “”
• Имя базы данных: test_db

Шаг 3. Подключаемся к базе данных

Теперь создадим программу, которая установит соединение с MySQL.

Что тут происходит:

1. Импорт нужных библиотек: mysql.connector — это основной модуль для работы с MySQL в Python. Error — класс для обработки ошибок;
2. Настройка подключения: Используем метод mysql.connector.connect, в который передаются параметры: host, user, password и database. Это наши настройки для базы данных;
3. Проверка подключения:Метод is_connected() из переменной connection проверяет, удалось ли установить соединение;
4. Выполнение запросов:Создаём курсор для выполнения SQL-запросов с помощью connection.cursor(). После этого можно делать запросы к базе. Выбираем конкретную базу, получаем все данные, добавляем в неё сущность, а затем удаляем её. Последний запрос — получение одного конкретного юзера;
5. Закрытие соединения:Закрываем соединение с помощью метода connection.close() для того, чтобы избежать утечек ресурсов и проблем с безопасностью.

Вы также можете обернуть код в try-except, чтобы отловить непредвиденные ошибки и не уронить сервер.

С помощью этого подхода можно быстро настроить подключение к MySQL и начать работу с базой данных в Python-проекте.

Подключаемся к MongoDB

Для нереляционных баз используем NoSQL-запросы. Функционал такой же: добавление, удаление, изменение и получение данных. А выглядят они по-другому. Посмотрим на примере MongoDB.

Для работы с MongoDB в Python используется библиотека pymongo. Разберём, как настроить соединение, выбрать базу данных и выполнить простой запрос.

Шаг 1. Устанавливаем библиотеку

Для начала установим библиотеку pymongo на своём компьютере. Введём команду в терминал:

Шаг 2. Настраиваем подключение

Чтобы подключиться к MongoDB, нужно знать параметры базы:

• Хост: адрес сервера;
• Порт: порт, на котором работает MongoDB. По умолчанию — 27017;
• Имя базы данных: название базы, которую вы хотите использовать;

MongoDB автоматически создаст базу данных, если она не существует.

Пример настроенной базы:

• Хост: localhost
• Порт: 27017
• Имя базы данных: test_db

Шаг 3. Подключаемся и выполняем запрос

Нам нужно подключиться к базе данных MongoDB, добавить, удалить и получить данные коллекции:

Разберём подробнее:

1. Импорт библиотеки: Используем MongoClient из библиотеки pymongo, чтобы создать подключение к базе;
2. Создание подключения: Используем данные хоста и порта, где запущен MongoDB;
3. Выбор базы данных и коллекции: Выбираем нужную базу данных. В нашем случае –– test_db. Если базы нет, MongoDB создаст её при добавлении первого документа;
4. Добавление документа: Добавляем новый документ с пользователем с помощью insert_one(). А также выводим в консоль информацию о добавленном пользователе;
5. Удаление. Удаляем юзера и проверяем, получилось ли. Если нет, в консоли увидим запись, что такого юзера не существует;
6. Выполнение запроса: Ищем только что добавленный документ методом find_one() и проверяем, нашли ли. Тут то же самое: если юзера нет, то в консоли мы это увидим;
7. Закрытие подключения: Закрываем вызов через client.close() и оповещаем самих себя в консоли.

Вы могли заметить, что мы везде заканчиваем код закрытием соединения. Это важно по нескольким причинам:

1. Подключение к базе данных –– ресурсы сервера и клиента. Если соединение не закрыть, ресурсы останутся занятыми. Значит, их нельзя будет использовать для более нужных вещей;
2. Неиспользуемые открытые соединения приводят к утечкам памяти;
3. Открытое соединение может стать уязвимостью для атак, несанкционированного доступа или SQL-инъекций.

В этом фрагменте кода реализовано то же самое, но с улучшениями. Мы обернули его в блок try-except, чтобы защитить сервер от ошибок и предотвратить его аварийное завершение работы.

В этой статье мы лишь поверхностно коснулись темы баз данных. Если у вас ещё нет лишних денег на выкуп своих данных, рекомендуем инвестировать время в изучение основ и тонкостей работы с БД.

Качественно спроектированная база данных не только повысит эффективность и прибыльность бизнеса, но и защитит его от серьёзных рисков. Кроме того, вы значительно прокачаете свои навыки программирования.

Удачи в разработке и безопасности ваших данных! 🚀

Что такое графовые базы данных и зачем они нужны

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

В этом случае на помощь приходят графовые базы данных. Они основаны на графовой модели, где граф состоит из вершин (узлов) и соединяющих их ребер.

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

Графовую базу данных можно изобразить как социальную сеть, в которой люди, относящиеся к различным группам, связаны друг с другом. Человека можно представить в виде узла c маркером «Person». У таких узлов есть свойства «Name», «Gender», «Location» и «Email». Типом отношений в такой базе выступает статус дружбы между людьми — «:FRIENDS_WITH», у которого также есть свойство «YearsOfFriendship» (продолжительность дружбы). Человек (узел «Person») связан со своим местом нахождения (узел «Location») через отношение «:LIVES_IN».

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

Для того чтобы определиться, подходит ли графовая база именно под задачи вашего текущего проекта, полезно будет ответить на следующие вопросы:

• Являются ли данные в системе высоко связанными? Графовые базы удобны в тех случаях, когда данные имеют высокую степень связности и требуют значительного анализа внутренних отношений.

• Является ли извлечение данных более приоритетным по сравнению с их хранением? Графовые базы оптимизированы для извлечения данных. Если вам часто нужно это действие, графовые базы для вас предпочтительны.

• Насколько часто меняется модель данных? Если модель данных неустойчива и требует частых изменений, удобно использовать графовые базы – они ориентированы на сами данные, что делает их достаточно гибкими.

Еще одним важным термином, связанным с графовыми базами данных, является RDF (Resource Description Framework, среда описания ресурса) — модель представления данных в виде, пригодном для машинной обработки.

Ресурсом в RDF может быть любая сущность — как информационная (веб-сайт или изображение), так и неинформационная (человек, город и т.д.). Утверждение, высказываемое о ресурсе, является триплетом «Субъект — Предикат — Объект». Множество таких триплетов образуют ориентированный граф, в котором вершинами (узлами) являются субъекты и объекты, а ребрами (отношениями) — предикаты.

Для работы с RDF-данными существуют специальные языки. Один из самых распространенных — SPARQL (Simple Protocol and RDF Query Language).

Основные запросы для данного языка:

• SELECT (извлечение необработанных значений и их представление в виде таблицы),

• CONSTRUCT (извлечение информации в формате RDF и преобразование результатов к определенной форме),

• ASK (формирование запроса типа Истина/Ложь),

• DESCRIBE (получение описания RDF-ресурса).

Существует несколько ключевых терминов, относящихся к типам узлов и ребер в RDF-графе:

• IRI (Internationalized Resource Identifier) — строка, однозначно идентифицирующая тот или иной узел и ребро. Использование IRI позволяет избежать повторения имен и возможных коллизий на этой почве.

• Blank node (bnode, Пустой узел) — этот узел используется, когда нет необходимости прямой ссылки на него. Он может быть достигнут через направленное ребро от других узлов.

• Literals (Литералы) — определенные значения, используемые для представления данных разных типов (строки, числа и даты). В отличии от IRIs и Blank Nodes, в триплете литералы могут быть только объектами. Примером литерала может служить обозначение даты: “YYYY-MM-DD”^^xsd:date, или указание языка строки: “some string”@en. В некоторых случаях литерал может опускаться. Например, для записи целочисленного значения полная запись с литералом выглядит следующим образом: 100^^xsd:integer. Без явного обозначения литерала будет записано лишь само число — 100.

Творчество The Beatles в виде графа

На рисунке изображен фрагмент графа, относящегося к творчеству группы The Beatles:

Схематическое представление является наглядным и визуально понятным, но, если мы имеем дело с большим объемом данных и выполняем над ними некоторые действия (обмен, загрузка), оно может оказаться непригодным, поэтому существует несколько вариантов синтаксиса представления RDF-графа в текстовом формате. Описанный фрагмент в так называемом Turtle формате будет иметь вид списка, в котором на отдельной строке перечислены все триплеты, отделенные друг от друга символом «.».

PREFIX :

PREFIX rdf:

PREFIX xsd:

:The_Beatles rdf:type :Band .

:The_Beatles :name “The Beatles” .

:The_Beatles :member :John_Lennon .

:The_Beatles :member :Paul_McCartney .

:The_Beatles :member :Ringo_Starr .

:The_Beatles :member :George_Harrison .

:John_Lennon rdf:type :SoloArtist .

:Paul_McCartney rdf:type :SoloArtist .

:Ringo_Starr rdf:type :SoloArtist .

:George_Harrison rdf:type :SoloArtist .

:Please_Please_Me rdf:type :Album .

:Please_Please_Me :name “Please Please Me” .

:Please_Please_Me :date “1963-03-22″^^xsd:date .

:Please_Please_Me :artist :The_Beatles .

:Please_Please_Me :track :Love_Me_Do .

:Love_Me_Do rdf:type :Song .

:Love_Me_Do :name “Love Me Do” .

:Love_Me_Do :length 125 .

:Love_Me_Do :writer :John_Lennon .

:Love_Me_Do :writer :Paul_McCartney .

Список PREFIX в начале записи определяет общую часть IRIs для сущностей в данном графе. Указав ее один раз, мы избавляемся от необходимости каждый раз добавлять эту запись. Например, полная запись IRI, соответствующая сущности «группа “The Beatles”» выглядела бы следующим образом: <http://stardog.com/tutorial/The_Beatles>, однако замена общей части <http://stardog.com/tutorial/> на символ «:» делает обозначение данной сущности значительно более компактным и удобным для восприятия — «:The_Beatles».

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

Как выглядит наша CRM-система

Мы используем микросервисную архитектуру, микросервисы в основном написаны на Java. Маршрутизатором трафика работает Traefik: он собирает в себя все запросы и определяет, в какой микросервис, в какой API, отправлять реквест. Схема работы выглядит так:

Клиент —> Traefik —> (mcp-api-cleaner, mcp-reseration, mcp-proressing)

Микросервисы взаимодействуют с NoSQL и Redis, из которой информация попадает в топики Kafka и дальше в mySQL. Данные хранятся до 90 дней и после удаляются.

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

Redis взяли по нескольким причинам

Первая: в банковском секторе нужна скорость. Вторая — у Redis быстрое и удобное взаимодействие с Java. Третья — это очень популярная система управления базами данных и применяется во многих компаниях.

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

Мы тоже столкнулись со сложностями

При экспоненциальном росте нагрузки на CRM-систему Redis переполнялся и падал с неопределенной периодичностью. Изучив проблему, мы поняли, что в базе копятся записи с одинаковым ключом.

Например, мы провели тренинг, на котором сотрудники выполняли одни и те же действия: зашли в профиль, выполнили задачи А и Б и так далее. Система проанализировала контакты и объединила пользователей по интересам. В результате мы получили дерево из тысяч записей с одинаковым ключом. Мало того что это увеличило нагрузку на аналитическую систему и замедлило работу приложения, так еще и подвергло риску отказоустойчивость внутри контура банка.

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

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

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

Не найдя комфортного решения на текущей архитектуре, мы начали и тестировать другие инструменты

Взяли MongoDB, это тоже NoSQL база данных, которая хранит информацию не в кэше, а в формате BSON, в виде документов, содержащих пары ключ-значение. Мы сравнили скорость работы с Redis и выяснили, что MongoDB работает медленнее. Поэтому остановились на компиляции Redis и MongoDb с помощью паттерна Cache aside. На тестирование ушло несколько месяцев.

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

Клиент в это время получает информацию из MongoDB (да, информация придет чуть позже, это медленнее процентов на 15, но решает проблему с нагрузкой).

На перформансе, при частых запросах, потерь в скорости почти нет: даже если данные успели стереться из Redis, они не превышают 10%. В дальнейшем данные уже попадают в Redis, и скорость возвращается.

Так мы решили проблемы с нагрузкой

Было приятно поделиться этой информацией, если хотите погрузиться в тему детальнее, пишите вопросы в комментариях.

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

Теория

Что такое СУБД?

Допустим, есть большая база данных, которой пользуются многие сотрудники: кто-то ищет информацию, а кто-то изменяет или даже удаляет её. Чтобы правильно обрабатывать все эти запросы, нужно специальное программное обеспечение, и именно такое ПО получило название системы управления базами данных (СУБД). Эта статья — часть нашего полного путеводителя по SQL.

Какие типы СУБД в соответствии с моделями данных вы знаете?

Этот вопрос по SQL предполагает не просто назвать, но и дать краткое описание каждому типу.Существует несколько типов СУБД:

1. Реляционные, которые поддерживают установку связей между таблицами с помощью первичных и внешних ключей. Пример — MySQL.Flat File — базы данных с двумерными файлами, в которых содержатся записи одного типа и отсутствует связь с другими файлами, как в реляционных. Пример — Excel.Иерархические подразумевают наличие записей, связанных друг с другом по принципу отношений один-к-одному или один-ко-многим. А вот для отношений многие-ко-многим следует использовать реляционную модель. Пример — Adabas.Сетевые похожи на иерархические, но в этом случае «ребёнок» может иметь несколько «родителей» и наоборот. Примеры — IDS и IDMS.Объектно-ориентированные СУБД работают с базами данных, которые состоят из объектов, используемых в ООП. Объекты группируются в классы и называются экземплярами, а классы в свою очередь взаимодействуют через методами. Пример — Versant.Объектно-реляционные обладают преимуществами реляционной и объектно-ориентированной моделей. Пример — IBM Db2.Многомерная модель является разновидностью реляционной и использует многомерные структуры. Часто представляется в виде кубов данных. Пример — Oracle Essbase.Гибридные состоят из двух и более типов баз данных. Используются в том случае, если одного типа недостаточно для обработки всех запросов. Пример — Altibase HDВ.

Что такое первичный ключ?

Первичный ключ или PRIMARY KEY предназначен для однозначной идентификации каждой записи в таблице и является строго уникальным (UNIQUE): две записи таблицы не могут иметь одинаковые значения первичного ключа. Нулевые значения (NULL) в PRIMARY KEY не допускаются. Если в качестве PRIMARY KEY используется несколько полей, их называют составным ключом.Пример:

Здесь в качестве первичного ключа используется поле id.

Когда используется PRIMARY KEY?

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

А что такое внешний ключ?

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

В данном случае внешний ключ, привязанный к полю user_id в таблице order, ссылается на первичный ключ id в таблице users, и именно по этим полям происходит связывание двух таблиц.

Какие ещё ограничения вы знаете, как они работают и указываются?

SQL-ограничения (constraints) указываются при создании или изменении таблицы. Это правила для ограничения типа данных, которые могут храниться в таблице. Действие с данными не будет выполнено, если нарушаются установленные ограничения.

• UNIQUE — гарантирует уникальность значений в столбце;
• NOT NULL — значение не может быть NULL;
• INDEX — создаёт индексы в таблице для быстрого поиска/запросов;
• CHECK — значения столбца должны соответствовать заданным условиям;
• DEFAULT — предоставляет столбцу значения по умолчанию&

Для чего используется ключевое слово ORDER BY?

Для сортировки данных в порядке возрастания (ASC) или убывания (DESC).Пример использования:

Выбираются пользователи, которые будут отсортированы по имени в порядке убывания. Дополните ответ на этот вопрос по SQL тем, что без указания DESC данные были бы отсортированы по умолчанию — в порядке возрастания. Подробнее о сортировке читайте в статье SQL — сортировка данных.

Назовите четыре основных типа соединения в SQL

Чтобы объединить две таблицы в одну, следует использовать оператор JOIN. Соединение таблиц может быть внутренним (INNER) или внешним (OUTER), причём внешнее соединение может быть левым (LEFT), правым (RIGHT) или полным (FULL).

• INNER JOIN — получение записей с одинаковыми значениями в обеих таблицах, т.е. получение пересечения таблиц.
• FULL OUTER JOIN — объединяет записи из обеих таблиц (если условие объединения равно true) и дополняет их всеми записями из обеих таблиц, которые не имеют совпадений. Для записей, которые не имеют совпадений из другой таблицы, недостающее поле будет иметь значение NULL.
• LEFT JOIN — возвращает все записи, удовлетворяющие условию объединения, плюс все оставшиеся записи из внешней (левой) таблицы, которые не удовлетворяют условию объединения.
• RIGHT JOIN — работает точно так же, как и левое объединение, только в качестве внешней таблицы будет использоваться правая.

Рассмотрим пример соединения SQL таблиц с использованием INNER JOIN. Следующий запрос выбирает все заказы с информацией о клиенте:

А что такое Self JOIN?

Такой вопрос тоже может прозвучать на собеседовании по SQL. Это выражение используется для того, чтобы таблица объединилась сама с собой, словно это две разные таблицы. Чтобы такое реализовать, одна из таких «таблиц» временно переименовывается.Например, следующий SQL-запрос объединяет клиентов из одного города:

Для чего нужен оператор UNION?

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

Как работают подстановочные знаки?

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

Какими бывают подстановочные знаки?

• % — заменить ноль или более символов;
• _ — заменить один символ.

Примеры:

Данный запрос позволяет найти данные всех пользователей, имена которых содержат в себе «test».

А в этом случае имена искомых пользователей начинаются на «t», после содержат какой-либо символ и «est» в конце. Ещё практика — 5 заданий с реальных собеседований.

Что делают псевдонимы Aliases?

SQL-псевдонимы нужны для того, чтобы дать временное имя таблице или столбцу. Это нужно, когда в запросе есть таблицы или столбцы с неоднозначными именами. В этом случае для удобства в составлении запроса используются псевдонимы. SQL-псевдоним существует только на время запроса.Пример:

Для чего нужен оператор INSERT INTO SELECT?

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

Что такое нормализация и денормализация?

Нормализация отношений в SQL призвана организовать информацию в базе данных таким образом, чтобы она не занимала много места и с ней было удобно работать. Это удаление избыточных данных, устранение дублей, идентификация наборов связанных данных через PRIMARY KEY, etc.Соответственно, денормализация является обратным процессом, который вносит в нормализованную таблицу избыточные данные.Подробнее о пяти нормальных формах и форме Бойса-Кодда можно узнать из данного видеокурса.

Объясните разницу между командами DELETE и TRUNCATE”

Команда DELETE — это DML-операция, которая удаляет записи из таблицы, соответствующие заданному условию:

При этом создаются логи удаления, то есть операцию можно отменить.А вот команда TRUNCATE — это DDL-операция, которая полностью пересоздаёт таблицу, и отменить такое удаление невозможно:

Чем VARCHAR отличается от NVARCHAR?

Главное отличие в том, что VARCHAR хранит значения в формате ASCII, где символ занимает один байт, а NVARCHAR хранит значения в формате Unicode, где символ «весит» 2 байта. Тип VARCHAR следует использовать, если вы уверены, что в значениях не будет Unicode-символов. Например, VARCHAR можно применить к адресам электронной почты, состоящих из ASCII-символов.

Практика

Как выбрать записи с нечётными Id?

Один из самых распространённых вопросов на собеседовании. SQL запрос для выбора записей с нечётными id должен выглядеть следующим образом:

Если остаток от деления id на 2 равен нулю, перед нами чётное значение, и наоборот.

Как найти дубли в поле email?

Функция COUNT() возвращает количество строк из поля email. Оператор HAVING работает почти так же, как и WHERE, вот только применяется не для всех столбцов, а для набора, созданного оператором GROUP BY.

При выборке из таблицы прибавьте к дате 1 день

Функция DATE_ADD() прибавляет к дате заданный промежуток времени. Синтаксис выглядит следующим образом:

Выберите только уникальные имена

SELECT DISTINCT возвращает разные значения, даже если в выбранном столбце есть дубли.

Найдите в таблице среднюю зарплату работников

Функция AVG() применяется только к числовым типам данных и возвращает среднее значение по столбцу.

А теперь получите список сотрудников с зарплатой выше средней

Даны таблицы workers и departments. Найдите все департаменты без единого сотрудника

Замените в таблице зарплату работника на 1000, если она равна 900, и на 1500 в остальных случаях

Замена значений — одна из наиболее часто встречаемых задач по SQL на собеседованиях. Решить её несложно:

Оператор UPDATE используется для изменения существующих записей. Но ответы на подобные вопросы с собеседований по SQL должны быть более развёрнутыми. Уточните,что после UPDATE следует указать, какие записи должны быть обновлены. В противном случае обновятся все записи в таблице.В нашем примере условие задаётся через оператор CASE: если текущая зарплата равна 900, изменяем её на 1000, в остальных случаях — на 1500.

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

Функция CONCAT() используется для конкатенации (объединения) строк, неявно преобразуя при этом любые типы данных в строки.

Переименуйте таблицу

С помощью оператора ALTER TABLE можно добавлять, удалять, изменять столбцы, а также изменять название таблицы.

Часто задаваемые вопросы

Какие вопросы по SQL чаще всего задают на собеседованиях?

Чаще всего спрашивают про типы JOIN, разницу между WHERE и HAVING, первичные и внешние ключи, нормализацию и подзапросы. Практические задания обычно включают поиск дублей, агрегатные функции и работу с датами.

Достаточно ли знать только SELECT для собеседования по SQL?

Нет. Помимо SELECT на собеседованиях проверяют знание DDL-команд (CREATE, ALTER, DROP), DML-операций (INSERT, UPDATE, DELETE), ограничений (PRIMARY KEY, FOREIGN KEY, UNIQUE) и умение работать с подзапросами.

Как лучше всего готовиться к SQL-собеседованию?

Разберите теорию (ключи, JOIN, нормализация), а затем решайте практические задачи на платформах вроде LeetCode, HackerRank или SQLBolt. Пишите запросы руками — простое чтение ответов не закрепляет навык. Для углублённого изучения рекомендуем материалы по основам PostgreSQL, SQL-индексам и оптимизации SQL-запросов. Также полезно понимать, какие навыки ожидают от разработчика на каждом грейде. Оконные функции часто спрашивают — разбор с примерами.

Эта статья — отправная точка для разработчиков, инженеров и ИТ-специалистов, которые хотят изучить InfluxDB, его концепции, случаи использования и реальные приложения.

Для начала поговорим в целом о базах данных временных рядов. О том, что они из себя представляют и чем отличаются от традиционных реляционных баз данных (РБД). После этого рассмотрим концепции, которые определяют InfluxDB. Не знакомы с измерениями, тегами или полями? Всё будет объяснено.

Что такое база данных временных рядов?

БД временных рядов, исходя из названия, представляют собой системы баз данных, специально предназначенные для обработки информации, связанной со временем.

В основном все имеют дело с реляционными базами данных (MySQL или SQL Server). Возможно, вы также имели дело с базами данных NoSQL (MongoDB или DynamoDB). Все они основаны на том, что у вас есть таблицы. Эти таблицы содержат столбцы и строки, каждая из которых определяет запись в вашей таблице. Часто эти таблицы специально предназначены для определённой цели. Одна может быть предназначена для хранения пользователей, другая — для фотографий или видео. Такие системы эффективны, масштабируемы и используются множеством гигантских компаний с миллионами запросов на своих серверах.

Базы данных временных рядов работают иначе. Данные по-прежнему хранятся в «коллекциях», но эти коллекции имеют общий знаменатель: они объединены со временем. Это означает, что для каждой точки, которую вы можете сохранить, у вас есть связанная с ней временная метка.

Возникает вопрос: нельзя ли использовать реляционную базу данных и просто включить в неё столбец с именем «время»? Например, в Oracle есть тип данных TIMESTAMP, который можно было бы использовать для этой цели. Конечно, такое возможно, но это неэффективно.

Зачем нужны базы данных временных рядов?

Три слова: быстрый приём данных.

Системы баз данных временных рядов построены так, чтобы быстро и эффективно принимать данные. Реляционные базы данных тоже имеют большую скорость загрузки данных (от 20 000 до 100 000 строк в секунду). Тем не менее, приём не постоянен во времени. У реляционных баз данных есть один ключевой аспект, который делает их медленными при росте данных — индексы.

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

База данных временных рядов оптимизирована для быстрого приёма данных. Такие системы используют индексацию данных, объединённых со временем. Как следствие, скорость загрузки не уменьшается со временем и остается достаточно стабильной (от 50 до 100 тыс. строк в секунду на одном узле).

Специфичные концепции баз данных временных рядов

Кроме высокой скорости приёма, базы данных временных рядов вводят специфичные для этих технологий концепции.

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

Системы вроде InfluxDB могут позаботиться об удалении данных через определённое время, используя концепцию, называемую политикой хранения. Вы также можете выполнять непрерывные запросы к оперативным данным для выполнения определённых операций. В реляционной БД можно найти эквивалентные операции (например «задания» в SQL), которые могут выполняться по заданному расписанию.

Совершенно другая экосистема

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

Часто база данных ассоциируется с одной системой. Клиенты подключаются к веб-сайту, который обращается к базе данных для получения информации. БД временных рядов созданы под множество клиентов (программ). Здесь нет простого сервера, обращающегося к БД, но есть куча разных сенсоров (к примеру), выполняющих вставку данных одновременно.

Как следствие, её инструменты были разработаны для того, чтобы предоставить эффективные способы потребления или производства данных.

Потребление данных

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

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

Производство данных

Производство данных осуществляется агентами, которые нацеливаются на специальные элементы в инфраструктуре и извлекают из них метрики. Такие агенты называются «агентами мониторинга». Вы можете легко настроить их для запроса данных за определённый промежуток времени. Примерами являются Telegraf (который является официальным агентом мониторинга), CollectD или StatsD.

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

Концепции InfluxDB

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

Язык запросов InfluxDB

Прежде чем начать, важно знать, какую версию InfluxDB вы используете в настоящее время. По состоянию на октябрь 2019 года InfluxDB выпускается в двух версиях: v1.7+ и v2.0.

InfluxDB v2.0 в настоящее время (на октябрь 2019 года) является альфа-версией и использует язык Flux. InfluxDB v1.7 оснащён языком InfluxQL (а также Flux, если его активировать). Пока лучше использовать InfluxQL, так как Flux не полностью установлен в текущей версии платформы.

InfluxQL — это язык запросов, который очень похож на SQL, и позволяет любому пользователю запрашивать свои данные и фильтровать их. Вот пример запроса InfluxQL:

Дальше будут рассмотрены ключевые концепции InfluxDB, предоставляемые с соответствующими запросами IQL (InfluxQL).

Ключевые концепции InfluxDB

Рассмотрим список основных терминов, которые необходимо знать для работы с InfluxDB в 2019 году.

База данных

База данных — само по себе простое для понимания понятие, потому что вы привыкли использовать этот термин в реляционных базах данных. В SQL-среде БД будет содержать набор таблиц и схем и будет представлять один экземпляр самостоятельно.

В InfluxDB БД содержит набор измерений. Однако один экземпляр InfluxDB может содержать несколько баз данных. В этом его отличие от традиционных систем. Эта логика подробно представлена на графике ниже:

Наиболее распространённые способы взаимодействия с базами данных — это либо их создание (CREATE DATABASE “devconnected”;), либо переход в них (USE devconnected;) для просмотра коллекций (вы должны быть «в базе данных», чтобы запрашивать коллекции, иначе это не сработает).

Измерение

Как показано выше, база данных хранит несколько измерений (measurement). Для простоты восприятия думайте об измерении как о таблице SQL. Она хранит данные и даже метаданные в разные моменты времени. Данные, которые должны сосуществовать вместе, должны храниться в одном измерении.

Теги и поля

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

Для тех, кто впервые начинает работать с InfluxDB, будет трудно понять, чем отличаются теги и поля. Они похожи на «столбцы», где вы можете хранить точно такие же данные. Определяя новый «столбец» в InfluxDB, вы можете либо объявить его как тег, либо как значение, и между ними есть различия.

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

Вернёмся к примеру cpu_metrics. Допустим, вы хотите добавить столбец с именем «location», определяющий местоположение датчика.

Что вам выбрать: тег или поле?

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

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

Теперь, когда мы добавили метку местоположения в измерение, немного углубимся в таксономию.

Набор тега называется «tag set». Имя столбца в теге называется «tag key». Значения тега называются «tag values». Та же систематика повторяется для полей. Вернёмся к чертежам.

Временная метка

Временная метка (timestamp) — наверное, самое простое для определения ключевое слово. В InfluxDB — это дата и время, определённые в формате RFC3339. При использовании InfluxDB очень часто определяют столбец времени как метку в Unix-времени, выраженную в наносекундах.

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

Политика хранения

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

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

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

Предположим, вы используете InfluxDB для IoT, например для сбора данных, поступающих из резервуара для воды. Позже вы захотите поделиться своими данными с группой научных специалистов, чтобы они могли их проанализировать. В этом случае вы можете хранить данные дольше: например пять лет.

Точка

Точка (point) — это просто набор полей с одинаковой отметкой времени. В SQL это будет выглядеть как строка или как уникальная запись в таблице. Здесь нет ничего особенного.

Случаи использования InfluxDB

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

Чтобы узнать больше о мониторинге DevOps, ознакомьтесь со статьёй «Monitoring systemd services in realtime with Chronograf».

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

IoT

Развитие IoT, вероятно, будет революцией, которая произойдёт в ближайшие несколько лет. Предполагается, что к 2020 году более 30 миллиардов устройств будут считаться устройствами IoT. Независимо от того, осуществляете ли вы мониторинг одного устройства или гигантской сети таких девайсов, вам необходимо иметь точные и мгновенные показатели, чтобы вы могли принимать наилучшие решения.

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

Промышленные и умные заводы

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

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

Ваше собственное воображение

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

Идём дальше

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

Хороший совет — создайте что-то сами. Установите InfluxDB, поиграйте с инструментами. Создайте информационную панель, поиграйтесь с запросами, настройте некоторые оповещения. Только так вы сможете сами «пощупать» эту технологию и составить о ней своё мнение.

Что изменится для пользователей MongoDB

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

Server Side Public License не сильно отличается от GNU AGPLv3, под которой MongoDB распространялась раньше. Разработанный создателями базы данных стандарт затрагивает модель распространения SaaS (Software-as-a-Service), ставшую в последнее время популярной. Элиот Горовиц (Eliot Horowitz), сооснователь компании, считает, что использование новой лицензии поможет защитить и вдохновить ещё больше разработчиков открытого исходного кода.

Причины изменения лицензии

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

У подобного подхода, однако, могут найтись и противники. MongoDB является коммерческой организацией, и, несмотря на открытую лицензию, работает для извлечения прибыли. Часть адептов Open Source считает, что такие действия идут вразрез с самой концепцией открытого ПО.

Open Source Initiative насчитывает уже некоторое количество различных лицензий для открытого ПО. Однако технологии не стоят на месте, и SSPL может оказаться востребованной среди разработчиков.

Всего есть 4 основных типа:

1. Хранилище «ключ-значение» — в нём есть большая хеш-таблица, содержащая ключи и значения. Примеры: Riak, Amazon DynamoDB;
2. Документоориентированное хранилище — хранит документы, состоящие из тегированных элементов. Пример: CouchDB;
3. Колоночное хранилище — в каждом блоке хранятся данные только из одной колонки. Примеры: HBase, Cassandra;
4. Хранилище на основе графов — сетевая база данных, которая использует узлы и рёбра для отображения и хранения данных. Пример: Neo4J.

База данных типа «ключ-значение»

Отсутствие схемы в базах данных «ключ-значение», например, Riak, — это как раз то, что вам нужно для хранения данных. Ключ может быть синтетическим или автосгенерированным, а значение может быть представлено строкой, JSON, блобом (BLOB, Binary Large Object, большой двоичный объект) и т.д.

Такие базы данных как правило используют хеш-таблицу, в которой находится уникальный ключ и указатель на конкретный объект данных. Существует понятие блока (bucket) — логической группы ключей, которые не группируют данные физически. В разных блоках могут быть идентичные ключи.

Производительность сильно вырастает за счёт кеширующих механизмов, которые работают на основе маппингов. Чтобы прочитать значение, вам нужно знать как ключ, так и блок, поскольку на самом деле ключ является хешем (блок + ключ).

В модели «ключ-значение» нет ничего сложного, так как реализовать её проще простого. Не лучший способ, если вам нужно только обновить часть значения или сделать запрос к базе данных.

Если поразмыслить о теореме CAP, то становится довольно очевидно, что такие хранилища хороши в плане доступности (Availability) и устойчивости к разделению (Partition tolerance), но явно проигрывают в согласованности данных (Consistency).

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

База данных такого типа позволяет читать и записывать значения с помощью ключа следующим образом:

• Get(key) возвращает значение, связанное с переданным ключом;
• Put(key, value) связывает значение с ключом;
• Multi-get(key1, key2, ..., keyN) возвращает список значений, связанных с переданным ключами;
• Delete(key) удаляет запись для ключа из хранилища.

И хотя базы данных типа «ключ-значение» могут пригодиться в определённых ситуациях, они не лишены недостатков. Первый заключается в том, что модель не предоставляет стандартные возможности баз данных вроде атомарности транзакций или согласованности данных при одновременном выполнении нескольких транзакций. Такие возможности должны предоставляться самим приложением.

Второй недостаток в том, что при увеличении объёмов данных, поддержание уникальных ключей может стать проблемой. Для её решения необходимо как-то усложнять процесс генерации строк, чтобы они оставались уникальными среди очень большого набора ключей.

Riak и Dynamo от Amazon — самые популярные СУБД данных такого типа.

Документоориентированная база данных

Данные, представленные парами ключ-значение, сжимаются как хранилище документов схожим с хранилищем «ключ-значение» образом, с той лишь разницей, что хранимые значения (документы) имеют определённую структуру и кодировку данных. XML, JSON и BSON — некоторые из стандартных распространённых кодировок.

В следующем примере можно увидеть данные в виде «документа» который отображает названия определённых магазинов. Обратите внимание, что, хотя все три примера содержат местоположение, они отображают его по-разному:

Одним из ключевых различий между хранилищем «ключ-значение» и документоориентированным является то, что последний включает метаданные, связанные с хранимым содержимым, что даёт возможность делать запросы на основе содержимого. Например, в указанном примере можно попробовать найти все документы, в которых «City» равно «Noida», что вернёт все документы, связанные с магазинами в этом городе.

Apache CouchDB — пример документоориентированной СУБД. CouchDB использует JSON для хранения данных, JavaScript в качестве языка запросов с использованием MapReduce и HTTP для API. Данные и отношения не хранятся в таблицах так, как в традиционных реляционных базах данных, а по сути являются набором независимых документов.

Тот факт, что такие базы данных работают без схемы, делает простой задачей добавление полей в JSON-документы без необходимости сначала заявлять об изменениях.

Couchbase и MongoDB — самые популярные документоориентированные СУБД.

Колоночная база данных

В колоночных NoSQL базах данных данные хранятся в ячейках, сгруппированных в колонки, а не в строки данных. Колонки логически группируются в колоночные семейства. Колоночные семейства могут состоять из практически неограниченного количества колонок, которые могут создаваться во время работы программы или во время определения схемы. Чтение и запись происходит с использованием колонок, а не строк.

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

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

Модель данных

• Колоночное семейство — структура, которая может легко группировать колонки и суперколонки;
• Ключ — постоянное имя записи. У ключей может быть разное количество колонок, поэтому база данных может расширяться неравномерно;
• Пространство ключей — определяет самый внешний уровень организации, как правило, имя приложения/базы данных.
• Колонка — имеет упорядоченный список элементов — кортежей с именами и значениями.

Самыми известными примерами являются Google BigTable и HBase с Cassandra, вдохновлённые BigTable.

BigTable представляет собой высокопроизводительное, сжатое и проприетарное хранилище данных от Google.  У него есть следующие атрибуты:

• Разреженность — некоторые ячейки могут быть пустыми;
• Распределённость — данные разделены между многими узлами;
• Постоянство — хранится на диске;
• Многомерность — более 1 измерения;
• Сопоставление — ключ и значение;
• Отсортированность — сопоставления обычно не сортируются, но этот случай — исключение.

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

Эту таблицу можно представить в виде BigTable-сопоставления следующим образом:

• Внешние ключи «3PillarNoida», «3PillarCluj», «3PillarTimisoara» и «3PillarFairfax» являются аналогами строк.
• «address» и «details» — колоночные семейства.
• В колоночном семействе «address» есть колонки «city» и «pincode».
• В колоночном семействе «details» есть колонки «strength» и «projects».

На колонки можно ссылаться с помощью колоночного семейства.

Графовая база данных

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

• Такие базы данных используют рёбра и узлы для представления данных.
• Узлы связаны между собой определённым отношениями, представленными рёбрами между ними.
• У узлов и отношений есть некоторые свойства.

Далее описаны некоторые особенности графовой базы данных на основе примера ниже:

Помеченный, направленный, атрибутированный мультиграф: граф содержит узлы, которые помечены определёнными свойствами и которые имеют связи друг с другом, что представлено направленными рёбрами. Например, связь «Элис знает Боба» выражена ребром с некоторыми свойствами.

Хотя реляционные базы данных могут скопировать поведение графовых, рёбрам потребуется соединение (JOIN), что дорого обойдётся.

Пример использования

Любой рейтинг «Рекомендовано вам», который можно увидеть на разных сайтах, зачастую составляется исходя из того, как другие пользователи оценили продукт. Графовые базы данных отлично подходят для такого случая.

InfoGrid и Infinite Graph — самые популярные графовые базы данных. InfoGrid позволяет соединять множество рёбер (Relationships) и узлов (MeshObjects), что упрощает представление набора информации со сложными взаимными ссылками.

InfoGrid предлагает два типа баз данных:

• MeshBase — подходящий вариант для автономного развёртывания;
• NetMeshBase — подойдёт для больших распределённых графов и имеет дополнительные возможности для взаимодействия с другими похожими NetMeshBase.

Смотрите также: SQL против NoSQL на примере MySQL и MongoDB

Основные различия

Язык

Представьте себе город — пусть он называется Город А, где все говорят на одном языке. Все дела ведутся на нём, он используется в любой форме коммуникации — в целом это единственное средство взаимодействия и взаимопонимания для обитателей города. Изменение языка в любой из сфер деятельности собьёт всех с толку.

Теперь представьте Город Б, где все обитатели говорят на разных языках. Они совершенно по-разному взаимодействуют с окружающим миром, и для них не существует «универсального» средства общения.

Эти два примера наглядно демонстрируют различия между реляционными и нереляционными базами данных, и за этими различиями скрываются ключевые особенности обеих СУБД.

Реляционные базы данных используют структурированный язык запросов (Structured Query Language, SQL) для определения и обработки данных. С одной стороны, это открывает большие возможности для разработки: SQL один из наиболее гибких и распространённых языков запросов, так что его выбор позволяет минимизировать ряд рисков, и будет особенно кстати, если предстоит работа с комплексными запросами. С другой стороны, в SQL есть ряд ограничений. Построение запросов на этом языке обязывает предопределять структуру данных и, как в случае с Городом А, последующее изменение структуры данных может быть губительным для всей системы.

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

• Вы можете создавать документы, не задавая их структуру заранее;
• Каждый документ может обладать собственной структурой;
• У каждой базы данных может быть собственный синтаксис;
• Вы можете добавлять поля прямо во время работы с данными.

Масштабируемость

В большинстве случаев SQL базы данных вертикально масштабируемые, то есть вы можете увеличивать нагрузку на отдельно взятый сервер, наращивая мощность центральных процессоров, объёмы ОЗУ или системы хранения данных. А NoSQL базы данных горизонтально масштабируемы. Это означает, что вы можете увеличивать трафик, распределяя его или добавляя больше серверов к вашей СУБД. Всё равно, что добавлять больше этажей к вашему зданию, либо добавлять больше зданий на улицу. Во втором случае, система может стать куда больше и мощнее, делая выбор NoSQL базы данных предпочитаемым для больших или постоянно меняющихся структур данных.

Структура

В реляционных СУБД данные представлены в виде таблиц, в то время как в нереляционных — в виде документов, пар «ключ-значение», графов или wide-column хранилищ. Это делает SQL базы данных лучшим выбором для приложений, которые предполагают транзакции с несколькими записями — как, например, система учётных записей — или для устаревших систем, которые были построены для реляционных структур.

В число СУБД для SQL баз данных входят MySQL, Oracle, PostgreSQL и Microsoft SQL Server. Для работы с NoSQL подойдут MongoDB, BigTable, Redis, RavenDB Cassandra, HBase, Neo4j и CouchDB.

SQL vs. NoSQL: MySQL или MongoDB

Разобравшись с ключевыми структурными различиями SQL и NoSQL баз данных, стоит внимательно рассмотреть их функциональные особенности на примере MySQL и MongoDB.

MySQL: реляционная СУБД

Преимущества MySQL:

• Проверено временем: MySQL — крайне развитая СУБД, что означает наличие большого сообщества вокруг неё, множество примеров и высокую надёжность;
• Совместимость: MySQL доступна на всех основных платформах, включая Linux, Windows, Mac, BSD и Solaris. Также у неё есть библиотеки для языков вроде Node.js, Ruby, C#, C++, Java, Perl, Python и PHP;
• Окупаемость: Это СУБД с открытым исходным кодом, находящаяся в свободном доступе;
• Реплицируемость: Базу данных MySQL можно распределять между несколькими узлами, таким образом уменьшая нагрузку и улучшая масштабируемость и доступность приложения;
• Шардинг: В то время как шардинг невозможен на большинстве SQL баз данных, MySQL является исключением.

MongoDB: нереляционная СУБД

Преимущества MongoDB:

• Динамическая схема: Как упоминалось выше, эта СУБД позволяет гибко работать со схемой данных без необходимости изменять сами данные;
• Масштабируемость: MongoDB горизонтально масштабируема, что позволяет легко уменьшить нагрузку на сервера при больших объёмах данных;
• Удобство в управлении: СУБД не нуждается в отдельном администраторе базы данных. Благодаря достаточному удобству в использовании, ей легко могут пользоваться как разработчики, так и системные администраторы;
• Скорость: Высокая производительность при выполнении простых запросов;
• Гибкость: В MongoDB можно без вреда для существующих данных, их структуры и производительности СУБД добавлять поля или колонки.

Какую СУБД выбрать?

MySQL — верный выбор для любого проекта, который может положиться на предопределённую структуру и заданные схемы. С другой стороны, MongoDB — отличный вариант для быстрорастущих проектов без определённой схемы данных. В особенности если вы не можете определить схему для своей базы данных, вам не подходит ни одна из предлагаемых другими СУБД или в вашем проекте она постоянно меняется, как, например, в случае с мобильными приложениями, системами аналитики в реальном времени или контент-менеджмента.