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

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

Допустим, команда решила переписать модуль заказов в e-commerce-продукте. В старой версии есть корзина, промокоды, доставка и оплата. Команда планирует за полгода сделать новый сервис заказов. Но за эти полгода бизнес добавляет подписки, подарочные сертификаты, частичную оплату бонусами и новую логику возвратов. В итоге новая система, которую проектировали под старые требования, к моменту релиза уже нуждается в доработке.

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

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

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

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

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

Feature toggles, или фича-флаги, — один из главных инструментов безопасной миграции. Они позволяют включать и выключать новую логику без деплоя.

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

Последний пункт особенно важен. Если флаги не удалять, система быстро превращается в набор ветвлений, где никто уже не понимает, какая логика актуальна.

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

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

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

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

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

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

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

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

Откатить миграцию, в которой ещё не было записи в БД, легко: достаточно переключить фича-флаг, и трафик снова идёт через старую реализацию. Откатить миграцию, в которой новая система уже неделю писала данные в новые таблицы, — отдельный, гораздо более тяжёлый разговор.

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

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

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

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

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

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

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

Четвертая ошибка — не договариваться с бизнесом. Модернизация не должна быть невидимой «инженерной активностью в стол». Её нужно встраивать в roadmap, объяснять эффект и договариваться о приоритетах. Если бизнес не понимает, зачем команда тратит время на миграцию, работа будет постоянно проигрывать новым фичам.

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

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

Компромиссы, к которым нужно быть готовыми

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

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

Но это контролируемая сложность. Она распределена во времени и управляется инженерными практиками. В отличие от Big Bang-риска, где команда долго работает с минимальной обратной связью, а потом выкатывает один большой релиз с максимальной неопределенностью.

Когда Strangler Fig особенно оправдан

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

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

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

Когда модернизацию лучше не делать

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

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

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

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

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

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

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

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

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

Индекс в базе данных — это вспомогательная структура (чаще всего B-дерево; хеш-индексы, GiST, GIN и другие типы применяются в узких специфических сценариях), которая ускоряет выборку строк по заданным колонкам. По аналогии с оглавлением книги: вместо перелистывания всех страниц СУБД сразу переходит к нужной главе. Но если оглавление построено плохо, пользы от него нет — а вот накладные расходы на поддержку остаются.

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

Индексы — это налог на запись: каждый INSERT, UPDATE и DELETE обновляет все индексы таблицы.

Индекс на колонке с низкой селективностью (boolean, статус) почти бесполезен — используйте частичные (partial) индексы.

В составном индексе порядок колонок критичен: PostgreSQL может использовать (a, b, c) только если условие начинается с a.

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

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

Внешние ключи в PostgreSQL не индексируются автоматически — после каждого FOREIGN KEY создавайте индекс вручную.

Без EXPLAIN ANALYZE индексы создаются вслепую. Проверяйте реальный план выполнения перед деплоем.

Ошибка 1. Индексировать всё подряд «на всякий случай»

Самая распространённая ошибка — не недостаток индексов, а их избыток из тревожности. Особенно часто в неё попадают junior-разработчики: добавляют индекс на каждую колонку, которая встречается в WHERE, «на всякий случай». Кажется ответственным, но на самом деле вредно.

Каждый индекс — это налог на запись. При INSERT, UPDATE и DELETE PostgreSQL (или MySQL) вынуждена обновлять все индексы таблицы. На таблице с 8 индексами каждая запись трогает 8 структур данных. При низкой нагрузке это невидимо, но при 10 000 записей в минуту это становится узким местом.

Аудит неиспользуемых индексов в PostgreSQL:
Запрос к pg_stat_user_indexes покажет, сколько раз каждый индекс применялся с момента сброса статистики. Если idx_scan = 0 — индекс кандидат на удаление.

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

Ошибка 2. Не понимать селективность

Индекс на булеву колонку — почти всегда бесполезен. Селективность измеряет, сколько различных значений содержится относительно общего числа строк. У boolean всего два значения. Если 95% строк имеют is_active = true, планировщик запросов проигнорирует индекс и сделает Seq Scan — и будет прав.

Правило большого пальца: если у колонки меньше 10–20 уникальных значений относительно размера таблицы, простой индекс по ней один не справится. Используйте частичные или составные индексы.

Ошибка 3. Неверный порядок колонок в составном индексе

Составные индексы мощны, но часто неправильно понимаются. PostgreSQL может использовать индекс (a, b, c) для фильтрации по a, a и b, a, b и c. Но не может эффективно использовать его, если запрос фильтрует только по b или c — ведущая колонка пропущена.

Решение: первыми ставьте колонки с equality-условиями, затем — по селективности, и проектируйте индексы вокруг реальных паттернов запросов, а не вокруг схемы таблицы. Также учитывайте ORDER BY и необходимость покрывающего индекса. Перед созданием обязательно запускайте EXPLAIN ANALYZE.

Ошибка 4. Игнорировать раздутие индексов

Индексы деградируют со временем. Многие инженеры воспринимают их как «поставил и забыл», но это заблуждение. В PostgreSQL при обновлении или удалении строки старые записи в индексе устаревают и накапливаются как раздутие (bloat); их физическое удаление происходит при выполнении VACUUM. На высокоизменяемых таблицах (заказы, события, логи, сессии) раздутие накапливается стремительно.

Таблица с 1 млн живых строк может иметь индекс, раздутый до размеров 8 млн записей. Каждый запрос через такой индекс делает в 8 раз больше работы, чем должен.

REINDEX CONCURRENTLY — ключевое слово. Обычный REINDEX блокирует таблицу, а в production-SaaS это прямой путь к инциденту. CONCURRENTLY перестраивает индекс без блокировок, хотя и медленнее.

Также убедитесь, что autovacuum настроен под вашу реальную нагрузку на запись. Значения по умолчанию в PostgreSQL консервативны и часто недостаточны для SaaS с высокой интенсивностью записи.

Ошибка 5. Индексы на колонках с малым числом уникальных значений в мультитенантных системах

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

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

Ошибка 6. Не индексировать внешние ключи

В PostgreSQL внешние ключи не индексируются автоматически. При удалении родительской строки СУБД должна проверить все дочерние таблицы на наличие ссылающихся записей — и без индекса на внешнем ключе это Seq Scan по каждой дочерней таблице. На таблице orders с 50 млн строк удаление пользователя вызывает полное сканирование.

Сделайте это командным соглашением: в чек-листе миграций обязательный пункт «после каждого FOREIGN KEY — CREATE INDEX».

Ошибка 7. Не использовать EXPLAIN ANALYZE перед деплоем

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

На что обращать внимание:
• Seq Scan на большой таблице при выборке малой доли строк — возможно, пропущен индекс или планировщик не может использовать существующий индекс.
• Rows Removed by Filter в десятки тысяч — индекс есть, но неправильные колонки или низкая селективность.
• Buffers: shared hit=0 read=45000 — данные не закэшированы (cold cache), страницы читаются с диска. Для диагностики раздутия смотрите общее число буферов и сравнивайте размер индекса с ожидаемым.
• Высокое actual time — проверьте раздутие, актуальность статистики, количество буферов, дисковую подсистему и наличие блокировок. Запустите ANALYZE tablename, чтобы обновить статистику планировщика.

Чек-лист индексации для SaaS

• У каждой колонки внешнего ключа есть индекс?
• Составные индексы упорядочены по селективности, а не по удобству?
• Булевы и низкокардинальные фильтры используют частичные индексы вместо полных?
• Вы запускали EXPLAIN ANALYZE на 10 самых медленных запросов за неделю?
• Есть процесс поиска и удаления неиспользуемых индексов?
• Высокоизменяемые таблицы регулярно проходят REINDEX CONCURRENTLY?
• Autovacuum настроен под реальный объём записи, а не под значения по умолчанию PostgreSQL?
• В мультитенантных таблицах индексы начинаются с tenant_id и включают диапазон времени?

Выводы

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

База данных, которая быстра на 10 000 строках и быстра на 50 миллионах, — не случайность. Это результат того, что кто-то считал планирование запросов первоклассной инженерной задачей, а не рутинным дополнением.

Проверьте свои самые медленные запросы этой недели — возможно, одна из этих семи ошибок уже сидит в вашей production-базе.

Источник и материалы:
• Database Indexing Mistakes That Kill SaaS Performance at Scale — оригинальная статья OutworkTech
• PostgreSQL Index Types — официальная документация
• REINDEX — документация по перестроению индексов

Если верить статистике, сейчас ежедневно создается около 402,74 миллионов терабайт данных.

Согласитесь, довольно внушительная цифра.

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

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

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

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

Вот почему мы подыскали аналог Nextcloud – ownCloud. В отличие от более функционального Nextcloud, ownCloud заточен исключительно на работу с файлами. И при этом он поддерживает подключение облачного объектного хранилища S3. Поэтому для нас в сравнении Nextcloud vs ownCloud выбор был очевиден.

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

Что может ownCloud

Для начала – буквально несколько слов об ownCloud и его возможностях.

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

OwnCloud позволяет:

1. получать доступ к данным из любой точки мира и хранить файлы на собственном сервере – под вашим полным контролем;
2. синхронизировать данные между устройствами – доступ к файлам возможен с компьютеров (Windows, macOS, Linux), смартфонов (iOS, Android) и через браузер, изменения на одном устройстве мгновенно появляются на всех остальных;
3. делиться файлами и папками по ссылке, настраивая права доступа, пароли и срок действия ссылок;
4. совместно работать с документами, отслеживать историю изменений и возвращаться к любой предыдущей версии файла.

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

Сегодня ownCloud используют компании (Philips, Nationwide, Zeppelin и др.) в самых разных сферах (IT, машиностроение, медицина и т. д.).

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

С ownCloud мне не нужно слепо доверять какой-то неопределенной организации. Я контролирую, как происходит обмен файлами, и ownCloud помогает мне на каждом этапе.

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

Для каких задач мы используем ownCloud и S3

1. Централизованное управление материалами

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

В итоге каждый член команды может видеть версии файлов (это важно для правок), нет хаоса в почте и мессенджерах.

2. Безопасное взаимодействие с подрядчиками

Связка ownCloud и S3 позволяет выгружать внешним специалистам материалы и получать результаты работ без прямого доступа к внутренней сети компании. Мы создали папку с публичной ссылкой, но жесткими ограничениями – паролем, сроком жизни ссылки в течение нескольких дней и разрешением на загрузку файлов без права просмотра папки.

На практике это работает так: менеджер создает ссылку и отправляет подрядчику, подрядчик переходит по ссылке и загружает архив с готовыми материалами, файл попадает в ownCloud, а его содержимое сохраняется в S3. Таким образом, подрядчик не видит, какие еще файлы лежат в папке, а мы контролируем, кто, что и когда загрузил.

3. Долгосрочный архив креативов и отчетов

По закону (152-ФЗ в РФ или GDPR в Европе) компания обязана хранить персональные данные клиентов, а также отчеты о рассылках и рекламных акциях на протяжении определенного времени.

Для решения этой задачи мы настроили правило: файлы старше 90 дней автоматически перемещаются в S3 Glacier (холодное хранилище) – этот класс снижает стоимость хранения, а если, например, юристу понадобится скачать какой-нибудь отчет спустя 2–3 года, он просто выгрузит его из ownCloud буквально за 5–10 минут.

Теперь – в деталях и по шагам о том, как начать использовать ownCloud в связке с S3.

Как развернуть ownCloud и подключить S3

OwnCloud удобно использовать с объектным хранилищем S3 – таким образом можно:

1. масштабировать систему – S3 расширяется автоматически и не имеет ограничений по объему и количеству размещаемых данных и файлов;
2. оптимизировать затраты – можно платить не за дорогую конфигурацию виртуального сервера с большим объемом диска, а лишь за фактически занимаемое место, по модели pay as you go (оплата по мере потребления);
3. повысить надежность хранения – за счет встроенной в S3 тройной репликации данных (файлы хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности данных).

Итак, разберем, как настроить связку ownCloud и S3.

Разработчики ownCloud предлагают два варианта установки. Можно скачать ownCloud и установить его вручную или использовать Docker-контейнеры. Мы выберем второй вариант.

Для размещения ownCloud в нашем примере создадим виртуальный сервер на базе готового решения Docker.

Можно подключиться к серверу по SSH или с помощью терминала в панели управления.

Для размещения файлов создайте бакет объектного хранилища S3. Реквизиты доступа к нему будут в карточке бакета в панели:

Создайте директорию для размещения конфигурационных файлов проекта и перейдите в нее:

Затем вставьте в файл docker-compose.yml следующее содержимое с помощью любого текстового редактора:

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

Теперь необходимо отредактировать эти строки:

1. ownCloud_DOMAIN и ownCloud_TRUSTED_DOMAINS – укажите домен (так как ownCloud будет размещен за обратным прокси, указывать рабочий порт здесь не требуется);
2. ADMIN_USERNAME – логин администратора;
3. ADMIN_PASSWORD – пароль администратора.

Обратите внимание! Изменение ADMIN_USERNAME и ADMIN_PASSWORD уже после развертывания контейнеров не возымеет эффекта. Изменить пароль администратора вы можете в настройках пользователя в веб-интерфейсе.

Далее необходимо указать параметры подключения к S3.

• ownCloud_OBJECTSTORE_BUCKET – имя бакета S3;
• ownCloud_OBJECTSTORE_ENDPOINT – эндпоинт хранилища (например, https://s3.ru1.storage.beget.cloud);
• ownCloud_OBJECTSTORE_REGION – регион (ru1 для Beget);
• ownCloud_OBJECTSTORE_KEY – Access key бакета;
• ownCloud_OBJECTSTORE_SECRET – Secret key бакета.

Сохраните файл.

Остается лишь добавить файл конфигурации для Caddy – обратного прокси, через который пользователи будут получать доступ к ownCloud.

Создайте директорию config:

После чего создайте в ней файл конфигурации Caddyfile. Добавьте в него следующее содержимое, указав вместо ownCloud.betutorial.ru ваш домен ownCloud:

Обратите внимание! Caddy выпустит SSL-сертификат на домен автоматически.

Все запросы к домену будут проксироваться в контейнер ownCloud_server.

На этом настройка конфигурационных файлов завершена, можно запускать контейнеры:

Потребуется несколько минут, чтобы docker загрузил образ и развернул контейнеры.

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

Выполните вход со стандартными доступами.

Обратите внимание! Если ownCloud недоступен или вы получаете ошибку при входе со стандартными доступами, проверьте корректность конфигурационных файлов. После внесения изменений перезапустите контейнеры.

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

Теперь проверим работу объектного хранилища – перейдем на главную страницу и загрузим файлы:

Файлы также появились и в объектном хранилище:

Обратите внимание! Файлы, которые вы удалите в ownCloud, будут перемещены в корзину и останутся в S3. Для их полного удаления очистите корзину ownCloud.

Чтобы делиться паролями с новыми пользователями, необходимо настроить отправку почты в ownCloud, сделать это можно в разделе Settings>General.

В нашем примере мы настроим отправку через SMTP:

После указания данных введите тестовый email и нажмите “Send email”. Если отправка успешна, вы получите уведомление об этом:

А на почтовый ящик поступит письмо:

На этом настройка завершена – можно начинать работать с файлами, используя связку ownCloud и S3.

Заключение

Если вы ловите себя на мысли, что данных стало настолько много, что поиск нужного файла порой происходит дольше, чем работа с ним (особенно если одни файлы хранятся на почте или в мессенджере, а другие – на ноутбуке или флешке), облачное хранилище может вам помочь.

Подобное ПО пригодится как для личных целей, так и для бизнеса – недаром в 2025 году в нашей стране был зафиксирован рост интереса крупного и среднего бизнеса к технологии облачного хранилища.

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

Однако недавно проект получил второе дыхание. Разработчик Александр Тишов (Amro) — создатель CMS Seditio и основатель веб-студии «Авего» — выпустил Denwer SE (Second Edition). Это не просто обновление, а полный реинжиниринг с сохранением классической философии: портативность, скорость работы и привычная структура каталогов.

В этой статье разберём, что изменилось под капотом, почему панель управления переехала с Perl на Python, как работает автоматический HTTPS с собственным корневым сертификатом и зачем нужен зоопарк версий PHP от 5.6 до 8.5.

Краткий экскурс: от Denwer 3 до Denwer SE

Оригинальный Denwer (сокращение от Джентельменский Набор Веб-разработчика) появился в начале 2000-х. Он представлял собой связку Apache + PHP + MySQL, упакованную в самораспаковывающийся архив. Главные фишки:

• Виртуальный диск (по умолчанию Z:), который монтировался через subst.
• Автоматическое создание виртуальных хостов по именам папок в home.
• Консольные exe-файлы (Run, Stop, Restart) без графического окна.

Проблемы оригинала:

• Управление на Perl — медленно, тяжело поддерживать в Windows.
• Только 32-битные компоненты.
• Невозможно быстро переключать версии PHP или БД.
• Отсутствие нормального HTTPS (только самоподписанные сертификаты с ошибками в браузере).
• Поддержка прекратилась в 2016 году.

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

Архитектура: Python вместо Perl

Denwer SE — панель управления написана на Python и скомпилирована в один EXE-файл (через PyInstaller).

Внутри служебной папки denwer\ лежат:

• DLL-версия Python — интерпретатор, который использует основной исполняемый файл.
• Скомпилированные модули .pyd — в том числе GUI на базе Tcl/Tk для оконного интерфейса и системного трея.
• Минимальный набор библиотек для управления службами, правки hosts и генерации сертификатов.

Это даёт несколько преимуществ:

• Портативность — панель ищет соседние папки home и usr, поэтому каталог со стеком можно переносить куда угодно без переустановки.
• Скорость — Python-скрипты запускаются быстрее, чем Perl, особенно на холодном старте.
• Читаемость кода — разработчику проще поддерживать и расширять функционал.

Полный переход на x64

Оригинальный Denwer навсегда остался 32-битным, что в современных реалиях просто неприемлемо. Denwer SE собирается исключительно под x64:

• Apache (версия 2.4.x) — 64-битный.
• Все модули PHP (от 5.6 до 8.5) — Thread Safe x64.
• MySQL / MariaDB — 64-битные сборки.

Системные требования — Windows 7/8/10/11 (x64). Для работы компонентов потребуются Microsoft Visual C++ Redistributable (VC11, VC12, VC14, VC15). Разработчик положил установщики этих пакетов в папку vcredist\ — при необходимости можно доустановить вручную.

Структура каталогов: преемственность и гибкость

Denwer SE сохранил классическую структуру, чтобы старые пользователи не ломали голову:

Главный конфиг — usr\configuration.txt. В нём задаются пути без жёсткой привязки к букве диска, например:

При старте панель монтирует виртуальный диск (по умолчанию Z:) и динамически подставляет путь через переменную subst_drive.

Управление версиями PHP и БД без танцев с бубном

В Denwer SE встроен менеджер версий. Вы просто выбираете из выпадающего списка нужную версию PHP (например, 8.3 или 5.6) — панель сама правит конфигурацию Apache.

Как это работает под капотом:

В папке usr/local/apache/php лежат подкаталоги php5.6, php7.4, php8.3 и т.д..

В каждом из них есть файл php-denwer.conf— шаблон для подключения модуля к Apache. При выборе версии этот файл копируется в conf/extra/httpd-denwer.conf, который затем включается в основной httpd.conf.

Если вы хотите добавить свою сборку PHP (например, PHP 8.4-rc), достаточно:

• Распаковать x64 Thread Safe версию в отдельный каталог внутри php\.
• Создать php-denwer.conf по образцу.
• Убедиться, что все DLL от VC++ установлены.

Аналогично для баз данных: переключение между MySQL 5.7 и MariaDB 11.8 происходит через тот же интерфейс. В каталоге СУБД может лежать файл db-denwer.conf, который при старте копируется в my.ini.

HTTPS, который не бесит: локальный Root CA

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

Denwer SE решает проблему элегантно — он создаёт собственный корневой центр сертификации (CA) и подписывает им сертификаты для всех ваших локальных доменов.

Как это работает:

1. При первом запуске (если найден OpenSSL) панель генерирует ключи denwer-ca.key и сертификат denwer-ca.crt в папку usr/local/apache/conf/cert/denwer-ca/.
2. Для каждого виртуального хоста (папки в home/) автоматически создаётся сертификат в conf/cert/<domain>/.
3. Все сертификаты хостов подписаны локальным CA.

Чтобы браузер доверял им, нужно один раз установить denwer-ca.crt в хранилище «Доверенные корневые центры сертификации» Windows. Для этого в панели есть специальная кнопка (требует прав администратора).

После этого любые HTTPS-запросы к локальным хостам работают без единого предупреждения.

Удобства для разработчика (DX)

В версии 1.2.4 добавили несколько фич, которые экономят время каждый день:

• Лог с таймштампами — каждая строка в окне панели имеет префикс [чч:мм:сс]. Теперь видно, сколько секунд сервер поднимается и где возможны задержки.
• Прямой доступ к php.ini и my.cnf — рядом со списками версий появились кнопки, открывающие конфигурацию именно активной версии.
• Автоматическое ведение hosts — панель в реальном времени сканирует home/, находит новые домены и прописывает их в C:\Windows\System32\drivers\etc\hosts. Журнал добавляемых записей сохраняется в usr\AddedHosts.txt. При остановке стека лишние строки удаляются.
• Для смены версии PHP или базы данных панель требует полной остановки всех служб. Вы нажимаете «Стоп», меняете версию в списке, затем «Старт» — и стек поднимается уже с новыми настройками. Автоматический перезапуск без вашего участия работает только для Apache: когда вы добавляете новый домен в папку home/, панель сама переписывает vhosts.conf и перезапускает веб-сервер, не трогая БД.

Почему не Open Server или Docker?

Этот вопрос закономерно возникает у всех, кто видит очередной локальный веб-сервер. Ведь есть уже давно Open Server Panel, Laragon, XAMPP, а для продвинутых — Docker. Зачем ещё один?

Open Server — мощный и удобный комбайн с десятками версий PHP и настройками «на века». Но он разворачивается в системе не портативно: создаёт папки в ProgramData, пишет в реестр, а запуск может занимать 5–10 секунд. Denwer SE, напротив, полностью переносим: скопировал папку на флешку или в облачный каталог — и всё работает. Запуск стека — буквально 1–2 секунды, что критично, когда вы десятки раз за день перезапускаете сервер для тестов.

Docker — индустриальный стандарт для изоляции и воспроизводимости окружений. Но для локальной разработки простого сайта он часто избыточен. Вам нужно разобраться в образах, контейнерах, пробросе портов, volume’ах и docker-compose.yml. А в Denwer SE вы просто создали папку в home/ — и готово. Никакой работы с командной строкой, никакого потребления гигабайт ОЗУ на фоновую службу Docker Desktop.

Laragon — быстрый, портативный, поддерживает не только PHP, но и Node.js, Python, Go. Но он ориентирован на современные фреймворки, особенно Laravel. Denwer SE же сделан для тех, кто вырос на классическом Денвере: виртуальный диск Z:, папка home/имя_домена/www, минимум настроек. Не нужно переучиваться — просто распаковал и работаешь как 10 лет назад, но с новыми версиями PHP и HTTPS.

Как начать пользоваться Denwer SE

1. Скачать архив с официального сайта автора.
2. Распаковать в любое место, например C:\web\DenwerSE\.
3. Запустить DenwerSE.exe — если нет прав администратора, попросит их для монтирования диска и правки hosts.
4. Нажать «Запустить» — появится виртуальный диск Z:, а в системном трее иконка.
5. Создать папку сайта — например, home\myproject.local и положить туда index.php.
6. Открыть в браузере http://myproject.local/ (или https://myproject.local/). HTTPS будет работать сразу после установки корневого сертификата (кнопка в панели).

По умолчанию пароль к MySQL/MariaDB — пустая строка (пользователь root). При желании его можно сменить через phpMyAdmin.

Заключение

Denwer SE — это не просто ностальгический проект. Это действительно современный инструмент, который доказывает, что концепция «локального сервера в одну папку» всё ещё актуальна. Отказ от Perl в пользу Python, менеджер версий PHP/БД, нормальный HTTPS, портативность и мгновенный запуск — всё это делает его отличным выбором для быстрого прототипирования, тестирования легаси-кода или обучения веб-разработке.

Если вы устали ждать, пока Open Server применит настройки, или не хотите разбираться в Docker Compose — попробуйте Denwer SE. Вероятно, он напомнит вам старые добрые времена, но уже без боли устаревших технологий.

• Автор проекта: Александр Тишов (Amro), разработчик CMS Seditio.
• Лицензия: Freeware.
• Совместимость: Windows 7/8/10/11 x64.

Исходники панели управления не открыты (распространяется скомпилированный EXE), но архитектура и конфиги полностью прозрачны. В планах — добавить поддержку Nginx в качестве альтернативы. Следите за обновлениями.

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

— SQL — фундаментальный навык для любого, кто работает с данными: от джуна до архитектора

— Основные команды (SELECT, JOIN, GROUP BY) покрывают 80% повседневных задач

— Порядок выполнения запроса (FROM → WHERE → GROUP BY → SELECT) — ключ к пониманию SQL

— Транзакции, ACID и уровни изоляции гарантируют надёжность данных

— Оконные функции, CTE и хранимые процедуры — продвинутый уровень для карьерного роста

— PostgreSQL — СУБД №1 в 2024 по Stack Overflow Survey, обогнавшая MySQL

— SQL не устареет: стандарт развивается, появляются JSON-запросы и графовый SQL

Что такое SQL и зачем его учить

SQL (Structured Query Language) — декларативный язык для работы с реляционными базами данных. «Декларативный» означает, что вы описываете что хотите получить, а не как это сделать. Вы пишете «дай мне все заказы за март», а СУБД сама решает, в каком порядке обходить таблицы и какие индексы использовать.

Краткая история: в 1970 году Эдгар Кодд из IBM опубликовал реляционную модель данных. В 1974 Дональд Чемберлин и Рэймонд Бойс создали язык SEQUEL (Structured English Query Language) для работы с этой моделью. Позже его переименовали в SQL из-за торговой марки. В 1986 году ANSI принял SQL как стандарт, а последняя версия — SQL:2023 — добавила поддержку JSON и графовых запросов.

Его используют бэкендеры, аналитики, дата-инженеры и даже тестировщики. И в обозримом будущем SQL никуда не денется — язык продолжает развиваться вместе со стандартом.

Как работает SQL: от запроса до результата

Когда вы отправляете SQL-запрос, внутри СУБД происходит цепочка шагов:

1. Парсинг — СУБД разбирает текст запроса, проверяет синтаксис и строит дерево разбора
2. Анализ — проверяет, существуют ли таблицы и столбцы, есть ли у пользователя права доступа
3. Оптимизация — самый важный этап. Оптимизатор строит несколько вариантов плана выполнения и выбирает самый дешёвый по стоимости (I/O, CPU, память)
4. Выполнение — движок исполняет выбранный план: сканирует таблицы, применяет фильтры, объединяет результаты
5. Возврат результата — СУБД формирует набор строк и отправляет клиенту

Логический порядок выполнения запроса

SQL-запрос пишется в одном порядке, а выполняется в другом. Вот реальная последовательность обработки:

1. FROM / JOIN — определяется источник данных, выполняются соединения
2. WHERE — фильтрация строк (до группировки)
3. GROUP BY — группировка
4. HAVING — фильтрация групп (после группировки)
5. WINDOW — вычисление оконных функций
6. SELECT — выбор столбцов, вычисление выражений и алиасов
7. DISTINCT — удаление дублей
8. ORDER BY — сортировка (по стандарту SQL единственное место, где гарантированно работает алиас из SELECT (в PostgreSQL и MySQL алиасы также работают в GROUP BY))
9. LIMIT / OFFSET — ограничение количества строк

Из-за этого порядка нельзя использовать алиас из SELECT в WHERE — на момент фильтрации SELECT ещё не выполнен. А HAVING работает после GROUP BY, поэтому в нём доступны агрегатные функции.

Именно благодаря оптимизатору SQL остаётся эффективным: вы пишете простой запрос, а СУБД сама выбирает, использовать ли индекс, в каком порядке объединять таблицы, нужна ли сортировка. Увидеть план выполнения можно командой EXPLAIN ANALYZE — это один из главных инструментов оптимизации.

Основные команды SQL

Любое знакомство с SQL начинается с четвёрки CRUD: SELECT (чтение), INSERT (создание), UPDATE (изменение), DELETE (удаление). К ним добавляются DDL-команды для управления структурой: CREATE TABLE, ALTER TABLE, DROP TABLE, TRUNCATE TABLE (быстрое удаление всех строк без логирования каждой).

Реальная мощь SQL раскрывается в объединениях через JOIN (INNER, LEFT, RIGHT, FULL), группировке с GROUP BY и фильтрации агрегатов через HAVING. Пример: найти средний чек по городам, где было больше 100 заказов: А также CROSS JOIN (декартово произведение всех строк) и SELF JOIN (соединение таблицы с собой — например, для поиска сотрудников и их руководителей).

На практике эти команды покрывают примерно 80% задач. Полный разбор с примерами — в нашем гайде по основным командам SQL. Статью прочитали полтора миллиона раз.

Типы данных и ограничения SQL

Правильный выбор типов данных — основа производительной и надёжной базы. Базовые типы SQL:

• Числовые: INTEGER, BIGINT, DECIMAL(10,2), FLOAT
• Строковые: VARCHAR(255), TEXT, CHAR(10)
• Дата и время: DATE, TIMESTAMP, INTERVAL
• Логический: BOOLEAN
• JSON: JSON / JSONB (PostgreSQL) — для полуструктурированных данных

Ограничения (constraints) — это правила, которые СУБД проверяет автоматически при каждой вставке и обновлении:

PRIMARY KEY гарантирует уникальность строки. FOREIGN KEY связывает таблицы и не даёт создать «висячие» ссылки. NOT NULL запрещает пустые значения. CHECK валидирует данные по условию. Вместе эти ограничения защищают целостность данных на уровне структуры — СУБД не позволит вставить строку, нарушающую правила.

Операторы и выражения

За базовыми командами идут операторы, которые делают запросы по-настоящему гибкими. WHERE фильтрует строки, LIKE ищет по шаблону с подстановочными знаками (% — любая подстрока, _ — один символ), IN проверяет вхождение в список, BETWEEN задаёт диапазон.

Отдельного внимания заслуживает CASE WHEN — условная логика прямо внутри запроса:

Подробный разбор LIKE с примерами — в отдельной статье.

NULL: подводные камни

NULL — не значение, а отсутствие значения. NULL = NULL возвращает не TRUE, а NULL. Единственный способ проверки — IS NULL / IS NOT NULL.

Функции даты и времени

Работа с датами — повседневная задача аналитика:

• NOW() / CURRENT_DATE — текущий момент / дата
• DATE_TRUNC('month', ts) — округление до начала периода
• EXTRACT(YEAR FROM ts) — извлечение части даты
• ts + INTERVAL '7 days' — арифметика с датами

Строковые и математические функции

Помимо дат и агрегатов, SQL предоставляет богатый набор функций для работы со строками и числами. Строковые функции: CONCAT — склейка строк, SUBSTRING — извлечение подстроки, LENGTH — длина строки, UPPER / LOWER — смена регистра, REPLACE — замена подстроки, TRIM — удаление пробелов по краям. Математические: ROUND — округление, ABS — модуль числа, CEIL / FLOOR — округление вверх и вниз. Эти функции работают одинаково в PostgreSQL, MySQL и других СУБД (с минимальными различиями в именах).

Операторы множеств: UNION, INTERSECT, EXCEPT

Эти операторы объединяют результаты нескольких запросов:

• UNION — объединение с удалением дубликатов. UNION ALL — без удаления (быстрее)
• INTERSECT — пересечение (строки из обоих запросов)
• EXCEPT — разность (строки из первого, которых нет во втором)

Агрегатные функции SQL

Агрегатные функции вычисляют одно значение по набору строк: COUNT, SUM, AVG, MIN, MAX. Работают в связке с GROUP BY.

Нюансы, которые часто путают:

• COUNT(*) считает все строки (включая NULL). COUNT(column) — только строки, где column не NULL
• COUNT(DISTINCT column) — количество уникальных значений
• AVG игнорирует NULL — если NULL означает «0», результат будет завышен

Подзапросы, CTE и представления

Когда запрос становится сложным, его нужно декомпозировать. Для этого есть три инструмента.

Подзапросы

Запрос внутри запроса. Бывают скалярные (возвращают одно значение), табличные (набор строк) и коррелированные (ссылаются на внешний запрос):

CTE (Common Table Expressions)

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

Рекурсивные CTE

Рекурсивные CTE обходят деревья и графы — например, оргструктуру компании или вложенные категории:

Представления (Views)

CREATE VIEW создаёт «виртуальную таблицу» — именованный запрос, к которому можно обращаться как к обычной таблице. Это удобно для инкапсуляции сложной логики и разграничения доступа. Материализованные представления (MATERIALIZED VIEW в PostgreSQL) хранят результат физически и обновляются по команде — полезно для тяжёлых аналитических запросов.

Хранимые процедуры и функции

Хранимые процедуры и функции — SQL-код, сохранённый на сервере СУБД. Функция возвращает значение и вызывается в SELECT, процедура выполняет действия и вызывается через CALL.

Когда использовать:

• Инкапсуляция бизнес-логики на уровне базы (расчёт скидок, начисление бонусов)
• Повторяющиеся многошаговые операции (ежемесячные отчёты, архивация)
• Безопасность: SECURITY DEFINER позволяет давать доступ к функции, не давая доступ к таблицам

Когда не использовать:

• Логику приложения лучше держать в коде — её проще тестировать и деплоить
• Тяжёлые вычисления: масштабировать сервер СУБД дороже, чем сервер приложения
• Бизнес-логика, которая часто меняется — миграции хранимых процедур болезненнее, чем код

Триггеры — особый тип: они срабатывают автоматически при INSERT/UPDATE/DELETE. Полезны для аудита (логировать все изменения) и автоматических вычислений, но злоупотреблять не стоит — скрытая логика усложняет отладку.

Оконные функции SQL

Оконные функции — это то, что отделяет новичка от уверенного SQL-разработчика. Они выполняют вычисления по «окну» строк, не сворачивая результат как GROUP BY. Вы получаете и агрегат, и исходные строки одновременно.

Ключевые функции: ROW_NUMBER() для нумерации, RANK() / DENSE_RANK() для ранжирования, LAG() / LEAD() для сравнения с соседними строками, агрегатные функции с OVER() для скользящих средних и нарастающих итогов.

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

RANK() пропускает позиции после одинаковых значений (1, 2, 2, 4), а DENSE_RANK() — нет (1, 2, 2, 3). Для скользящих агрегатов используется конструкция ROWS BETWEEN — например, ROWS BETWEEN 6 PRECEDING AND CURRENT ROW для скользящего среднего за 7 дней.

Детальный разбор с визуальными примерами — в нашей статье об оконных функциях SQL.

Транзакции и ACID в SQL

Транзакция — группа операций, которые выполняются как единое целое: либо всё, либо ни одна. Классический пример — перевод денег:

Если между двумя UPDATE произойдёт сбой, ROLLBACK откатит обе операции — деньги не потеряются и не удвоятся. Для частичного отката используется SAVEPOINT: можно откатить транзакцию не целиком, а до определённой точки (ROLLBACK TO SAVEPOINT имя).

Свойства ACID гарантируют надёжность транзакций:

• Atomicity (атомарность) — транзакция неделима: либо выполнена полностью, либо отменена целиком
• Consistency (согласованность) — после транзакции база остаётся в корректном состоянии, все ограничения соблюдены
• Isolation (изоляция) — параллельные транзакции не мешают друг другу. Уровни: от READ UNCOMMITTED (быстро, но грязные чтения) до SERIALIZABLE (безопасно, но медленно)
• Durability (долговечность) — после COMMIT данные сохранены даже при аварии сервера

ACID — фундамент надёжности реляционных баз данных. Именно эти свойства гарантируют, что данные не потеряются и не «рассинхронятся» даже при сбоях и параллельных запросах.

Уровни изоляции

Свойство Isolation на практике настраивается через уровни изоляции. Каждый уровень — компромисс между корректностью и производительностью:

• READ UNCOMMITTED — самый слабый: видны незакоммиченные изменения других транзакций (dirty reads). Практически не используется
• READ COMMITTED — видны только закоммиченные данные. По умолчанию в PostgreSQL. Достаточно для большинства приложений
• REPEATABLE READ — повторное чтение строки всегда даёт тот же результат. По умолчанию в MySQL. Защищает от non-repeatable reads
• SERIALIZABLE — максимальная изоляция, транзакции ведут себя как последовательные. Нужен для финансовых операций и бронирований

Нормализация и проектирование схем

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

Три ключевые нормальные формы:

1. 1NF — каждая ячейка содержит одно атомарное значение. Никаких «Москва, Питер» в одном поле — разносим по строкам или связанным таблицам
2. 2NF — все неключевые столбцы зависят от всего первичного ключа, а не от его части. Актуально для составных ключей
3. 3NF — неключевые столбцы не зависят друг от друга. Если город определяет страну, нужна отдельная таблица городов

Пример: таблица заказов до и после нормализации до 3NF:

В этом примере мы устранили дублирование данных клиента (2NF). Для полной 3NF нужно было бы вынести и города в отдельную таблицу, если город определяет дополнительные атрибуты (страну, регион).

На практике большинство баз проектируют в 3NF. Но иногда данные намеренно денормализуют — например, в аналитических хранилищах (OLAP), где скорость чтения важнее экономии места. Схемы «звезда» и «снежинка» в data warehouse — это контролируемая денормализация.

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

Когда таблица вырастает до миллионов строк, наивные запросы начинают тормозить. Первый инструмент диагностики — EXPLAIN ANALYZE: он показывает, какой план выбрал оптимизатор, сколько строк просканировал и где узкое место.

Типичные антипаттерны:

• SELECT * вместо конкретных столбцов — читает больше данных, чем нужно
• Отсутствие индекса на столбцах в WHERE и JOIN — приводит к полному сканированию таблицы (Seq Scan)
• Функции на индексированных столбцах: WHERE UPPER(email) = ... — индекс не используется
• N+1 запросы из ORM — 1 запрос за список + N запросов за детали каждой записи

Индексы — главный способ ускорения. B-tree индекс (по умолчанию) подходит для большинства задач: точные совпадения, диапазоны, сортировка. PostgreSQL также поддерживает GiST (геоданные), GIN (полнотекстовый поиск, JSONB) и BRIN (временные ряды).

Глубокий разбор типов индексов и их применения — в нашей статье об индексах PostgreSQL.

Безопасность: SQL-инъекции

SQL-инъекция — одна из самых опасных уязвимостей веб-приложений, стабильно входящая в OWASP Top 10. Суть: если пользовательский ввод подставляется в запрос без обработки, злоумышленник может изменить логику запроса.

Классический пример — форма логина:

Защита проста и надёжна — параметризованные запросы (prepared statements):

Пароли в реальных приложениях никогда не хранят и не сравнивают в открытом виде — их хешируют (bcrypt, argon2), а проверку выполняет код приложения, не SQL-запрос.

При использовании ORM (SQLAlchemy, Django ORM, Prisma) параметризация происходит автоматически. Если пишете raw SQL — никогда не вставляйте пользовательский ввод через конкатенацию строк или f-строки.

Управление доступом: GRANT и REVOKE

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

REVOKE отзывает права. В PostgreSQL также доступна Row-Level Security (RLS) — ограничение видимости строк в зависимости от роли: каждый менеджер видит только своих клиентов.

Современный SQL: JSON, диалекты и стандарт SQL:2023

SQL — не замороженный язык из 80-х. Стандарт активно развивается, и последняя версия SQL:2023 (опубликована в июне 2023) принесла два крупных нововведения:

• SQL/JSON — стандартизированные функции для работы с JSON прямо в SQL-запросах. PostgreSQL поддерживает JSONB с 2014 года, а теперь аналогичные возможности появляются и в других СУБД
• SQL/PGQ (Property Graph Queries) — графовые запросы внутри SQL. Можно искать пути и паттерны в связанных данных без отдельной графовой базы

На практике каждая СУБД имеет свой диалект:

• PostgreSQL — PL/pgSQL, JSONB, массивы, расширения (PostGIS, pg_trgm). Ближе всего к стандарту
• MySQL — оконные функции появились поздно — только в версии 8.0 (2018), LIMIT вместо FETCH FIRST
• T-SQL (Microsoft SQL Server) — TOP вместо LIMIT, IDENTITY вместо SERIAL, мощные CTE
• PL/SQL (Oracle) — ROWNUM, CONNECT BY для иерархий, пакеты (packages)
• Cloud SQL — BigQuery, Redshift, Snowflake имеют свои расширения, но базовый SQL везде одинаков

Хорошая новость: базовый синтаксис (SELECT, JOIN, GROUP BY, оконные функции) одинаков во всех диалектах. Освоив стандартный SQL на PostgreSQL, вы легко перейдёте на любую другую СУБД.

PostgreSQL и MySQL

PostgreSQL

PostgreSQL — самая популярная реляционная СУБД для новых проектов. Полная поддержка SQL-стандарта, JSONB для полуструктурированных данных, расширения (PostGIS для геоданных, pg_trgm для нечёткого поиска), продвинутая система типов и отличная производительность.

15 самых полезных команд PostgreSQL — от размера базы до профилирования запросов — в нашей подборке. А для оптимизации больших таблиц — разбор индексов PostgreSQL.

MySQL

MySQL — одна из старейших популярных open-source СУБД, движок WordPress и множества legacy-систем. Проще в настройке, но имеет подводные камни: неявное приведение типов, особенности GROUP BY, различия между InnoDB и MyISAM.

Самые частые ошибки — от кодировок до потери данных — в нашей статье о типичных ошибках MySQL.

Выбор СУБД: SQL vs NoSQL

SQLite — для встраиваемых сценариев: мобильные приложения, Electron, edge computing, прототипы (вся база в одном файле). MySQL — проверенный выбор для веб-приложений, на нём работают GitHub и Booking.com. PostgreSQL — универсальный вариант для новых проектов, от стартапов до enterprise. Детальное сравнение с бенчмарками — в нашем обзоре трёх СУБД.

Когда данные неструктурированные или нужна горизонтальная масштабируемость, рассмотрите NoSQL: MongoDB (документы), Redis (ключ-значение), Cassandra (колонки), Neo4j (графы). Подробнее — в статье о моделях баз данных.

SQL на собеседованиях

SQL-вопросы — обязательная часть собеседований для бэкенд-разработчиков, аналитиков и дата-инженеров. Типичный формат: дают схему из 2–3 таблиц и просят написать запрос. Темы: JOIN-ы, GROUP BY, оконные функции, подзапросы, нормализация.

Ключ к успеху — практика на реальных задачах. Интервьюеры оценивают умение декомпозировать задачу, выбрать правильный тип JOIN и грамотно обработать NULL.

27 самых распространённых вопросов с ответами — в нашей подборке. Для практики — 5 заданий с реальных собеседований с разбором решений.

Куда двигаться дальше

SQL — это фундамент, но не потолок. Направления для роста:

1. Администрирование БД — репликация, бэкапы, мониторинг, настройка производительности
2. Дата-инженерия — ETL-пайплайны, dbt, Airflow, data warehouse (BigQuery, Snowflake)
3. Аналитика данных — SQL + Python (pandas), визуализация, A/B-тесты
4. Бэкенд-разработка — ORM (SQLAlchemy, Prisma, GORM), миграции, проектирование схем
5. Data Science — feature engineering, работа с большими датасетами

Главный совет: практикуйтесь на реальных данных. Поднимите PostgreSQL локально, загрузите публичный датасет и решайте задачи. Ресурсы для старта:

• SQLBolt — интерактивные уроки SQL в браузере, от нуля
• PostgreSQL Exercises — задачи на реальной схеме (клуб, бронирования)
• LeetCode / HackerRank — SQL-задачи для подготовки к собеседованиям
• Kaggle Datasets — открытые датасеты для импорта в PostgreSQL и экспериментов

SQL (Structured Query Language) — это декларативный язык запросов для управления реляционными базами данных. С его помощью можно создавать таблицы, добавлять, изменять и удалять данные, а также делать выборки по заданным условиям. SQL стандартизирован организацией ISO и поддерживается всеми основными СУБД: PostgreSQL, MySQL, SQLite, Microsoft SQL Server и Oracle.

- SQL расшифровывается как Structured Query Language — язык структурированных запросов.

- Язык создан в 1973 году в IBM, стандарт ISO принят в 1987 году.

- SQL используют 51,5% профессиональных разработчиков по всему миру (Stack Overflow, 2023).

- Основные операции: SELECT, INSERT, UPDATE, DELETE — охватывают 90% повседневных задач.

- SQL работает с реляционными базами данных, где данные хранятся в связанных таблицах.

- Один SQL-запрос может обработать миллионы строк за доли секунды.

Зачем нужен SQL — где используется и кому пригодится

SQL нужен везде, где есть структурированные данные. Вот лишь несколько примеров из реальной практики:

• Веб-разработка — интернет-магазины, блоги, социальные сети хранят пользователей, товары и записи в реляционных БД.
• Аналитика данных — аналитики используют SQL для агрегации, фильтрации и построения отчётов.
• Backend-разработка — серверные приложения взаимодействуют с PostgreSQL или MySQL через SQL-запросы.
• Data Science — учёные по данным выгружают датасеты из хранилищ (Redshift, BigQuery) с помощью SQL.
• DevOps и администрирование — DBA оптимизируют запросы, настраивают индексы, следят за производительностью.

SQL востребован как у начинающих разработчиков, так и у опытных инженеров. По данным Glassdoor, знание SQL входит в топ-3 навыков для вакансий Data Analyst и Backend Developer в 2024 году. Даже фронтендеры, которые редко работают напрямую с БД, рано или поздно сталкиваются с SQL при отладке или настройке.

Основные команды SQL

Все команды SQL делятся на группы. Самые важные — это DDL (Data Definition Language) для создания структур и DML (Data Manipulation Language) для работы с данными. Рассмотрим ключевые команды подробнее.

SELECT — выборка данных

SELECT — самая используемая команда SQL. Она позволяет извлекать данные из одной или нескольких таблиц. Базовый синтаксис:

Звёздочка * означает «все столбцы», но на практике лучше перечислять нужные явно — это ускоряет запрос и делает код читаемым. Чтобы отфильтровать дубликаты, используют SELECT DISTINCT.

Можно также ограничить количество строк в результате:

INSERT, UPDATE, DELETE — изменение данных

Три команды, отвечающие за создание, изменение и удаление записей:

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

CREATE TABLE — создание таблиц

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

SERIAL (или AUTO_INCREMENT в MySQL) автоматически генерирует уникальный числовой идентификатор. PRIMARY KEY — уникальный ключ строки. REFERENCES создаёт внешний ключ — связь между таблицами.

JOIN — объединение таблиц

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

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

WHERE, ORDER BY, GROUP BY — фильтрация и сортировка

Три важнейших инструмента для управления результатом выборки. Подробный разбор ORDER BY с примерами читайте в нашем гайде по сортировке в SQL.

Ключевое отличие: WHERE фильтрует строки до группировки, HAVING — после. Агрегатные функции (COUNT, SUM, AVG, MIN, MAX) работают с группами строк.

Типы данных в SQL

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

• Числовые: INT / INTEGER — целые числа; BIGINT — большие целые; DECIMAL(p,s) — дробные с фиксированной точностью; FLOAT — числа с плавающей запятой.
• Строковые: VARCHAR(n) — строка до n символов; TEXT — строка без ограничений; CHAR(n) — строка фиксированной длины.
• Дата и время: DATE — дата (YYYY-MM-DD); TIME — время; TIMESTAMP — дата и время; INTERVAL — интервал.
• Логический: BOOLEAN — значения TRUE / FALSE / NULL.
• Специальные: UUID — уникальный идентификатор; JSON / JSONB — JSON-данные (PostgreSQL); ARRAY — массив значений.

Практическое правило: используйте наименьший подходящий тип. Для возраста достаточно SMALLINT, для идентификатора пользователя — INT, для финансовых сумм — DECIMAL, а не FLOAT (чтобы избежать ошибок округления).

SQL vs NoSQL — когда что использовать

SQL-базы данных хранят данные в таблицах с фиксированной схемой. NoSQL-базы (MongoDB, Redis, Cassandra) используют другие модели: документы, ключ-значение, графы, колонки. Вот когда выбирать каждый подход:

• SQL подходит, когда: данные структурированы и схема стабильна; важна целостность и транзакции (банки, интернет-магазины); нужны сложные запросы с JOIN и агрегацией; команда умеет работать с реляционными БД.
• NoSQL подходит, когда: структура данных гибкая или меняется часто; нужна горизонтальная масштабируемость под огромные объёмы; данные неструктурированы (логи, события, JSON); требуется сверхнизкая латентность (кэш в Redis).

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

Популярные СУБД: PostgreSQL, MySQL, SQLite, MS SQL

SQL-синтаксис стандартизирован, но каждая СУБД добавляет свои расширения. Вот краткое сравнение четырёх самых популярных:

• PostgreSQL — мощная open-source СУБД с богатым набором типов данных, поддержкой JSON, полнотекстового поиска и оконных функций. Лучший выбор для серьёзных проектов. Подробнее читайте в нашем руководстве по PostgreSQL для начинающих.
• MySQL / MariaDB — самая распространённая СУБД для веб-приложений, особенно в связке с PHP (WordPress, Drupal). Простая в настройке, быстрая для чтения.
• SQLite — встроенная база данных в одном файле, без сервера. Идеально подходит для мобильных приложений, тестирования и небольших проектов. Используется в Android, iOS, браузерах.
• Microsoft SQL Server — корпоративная СУБД от Microsoft, тесно интегрированная с экосистемой .NET и Azure. Популярна в крупных компаниях.

Если вы только начинаете, рекомендуем PostgreSQL или SQLite. PostgreSQL — для полноценной разработки, SQLite — для обучения без установки сервера.

Как начать учить SQL — ресурсы, песочницы, советы

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

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

• SQLiteOnline.com — онлайн-песочница без регистрации. Запустите первый запрос прямо в браузере за 30 секунд.
• SQLBolt.com — интерактивный курс с упражнениями от SELECT до сложных JOIN. Полностью бесплатный, на английском.
• Stepik.org — бесплатный курс «Введение в базы данных» на русском языке с практическими заданиями.
• LeetCode / HackerRank — задачи на SQL для подготовки к техническим собеседованиям.
• Официальная документация PostgreSQL — самый полный и точный источник по возможностям СУБД.

Советы для эффективного обучения: практикуйтесь на реальных данных (импортируйте CSV-файл в SQLite), сразу изучайте индексы — они кардинально влияют на производительность. Читайте наш материал об SQL-индексах за 10 минут и 10 советов по оптимизации запросов.

Выводы

SQL — фундаментальный навык для любого, кто работает с данными. За полвека существования язык не только не устарел, но и стал ещё более востребованным: облачные хранилища BigQuery и Redshift, аналитические инструменты, современные ORM — всё это работает поверх SQL или совместимо с ним.

Что делать дальше:

1. Установите PostgreSQL или откройте SQLiteOnline.com и напишите первый SELECT.
2. Пройдите интерактивный курс на SQLBolt.com — займёт 3–5 часов.
3. Попрактикуйтесь на реальных данных: загрузите любой CSV-датасет с Kaggle.
4. Изучите индексы — это самый быстрый способ ускорить запросы.
5. Посмотрите нашу дорожную карту SQL и двигайтесь по ней системно.

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

Теперь Bun официально позиционируется как full-stack платформа для фронтенда и бэкенда. И она объединяет сервер, сборщик, менеджер пакетов вместе с тест-раннером в одном инструменте.

В новую версию добавлены десятки ключевых функций: встроенные клиенты для Redis, MySQL, PostgreSQL и SQLite, единый SQL API, улучшенные WebSocket-модули, переработанный тест-раннер и поддержка VSCode Test Explorer.

Full-stack по-умному

Главное новшество — режим full-stack Bun.serve() с поддержкой роутинга, cookies и WebSockets.

Теперь фронтенд и бэкенд можно запускать в одном процессе без проблем с CORS, а приложение собрать в единый исполняемый файл с помощью bun build --compile.

Разработчики могут напрямую импортировать HTML, запускать React-приложения с хот-перезагрузкой и собирать проект одной командой bun init --react. По данным команды, скомпилированные React-приложения в Bun работают до 1,8 раза быстрее, чем через nginx.

Новый SQL и встроенный Redis

Bun 1.3 представил унифицированный Bun.SQL API — теперь один и тот же код работает с MySQL, PostgreSQL, SQLite и MariaDB. Добавлен хелпер sql.array() для работы с массивами в PostgreSQL, улучшена поддержка JSON и Unix-сокетов.

Кроме того, в рантайм встроен Redis-клиент, который поддерживает 66 команд, автоматическое переподключение, очереди сообщений и Pub/Sub. По данным разработчиков, он значительно быстрее ioredis, а поддержка кластеров и Lua-скриптов появится в будущих релизах.

Новые возможности

Среди прочих улучшений — Zstandard-сжатие, нативная поддержка YAML, API для безопасного хранения секретов (Bun.secrets), и серьезный прирост производительности: операции с криптографией ускорены до 400х, установка пакетов — до 2,5х.

Также обновлен менеджер пакетов с интерактивным bun update, изолированными установками и API для проверки безопасности зависимостей.

Почему это важно

Bun 1.3 превращает экспериментальный рантайм в полноценную платформу для веб-разработки, способную заменить Node.js, Vite и Redis-CLI одновременно.

Разработчики называют релиз «началом новой эпохи», цель которой — сделать Bun лучшим способом писать и развертывать JavaScript-приложения.

Владение 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 инженера”, становится понятен карьерный трек.

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

1. ИХЦ (Интернет ХостингЦентр): конфигурации под нагрузку с NVMe, CPU до 5 ГГц и трафиком без ограничений

Один из самых гибких по конфигурациям хостеров в обзоре. Работает с 2009 года. Поддерживает разные типы виртуализации (KVM и Virtuozzo), предлагает линейки с SSD и NVMe, российские и европейские площадки, разные уровни мощности — от базовых до высоконагруженных.

Линейки VPS и конфигурации

1. ssdVPS — базовая линейка для России. Позволяет собирать конфигурации от 1 до 32 ГБ оперативной памяти, от 1 до 10 виртуальных CPU и от 20 до 300 ГБ SSD-диска.
2. NVMe/ — линейка на базе KVM с более высокой производительностью ввода-вывода. Доступны конфигурации от 1 до 24 ГБ RAM, от 1 до 12 vCPU, SSD от 15 до 300 ГБ.
3. EU-NVMe/ — аналог NVMe-линейки, но размещённый в Амстердаме. Конфигурации расширены: от 1 до 64 ГБ оперативной памяти, от 1 до 18 CPU, от 15 до 1000 ГБ SSD, скорость порта — от 200 до 500 Мбит/с.
4. VPS 5 ГГц — отдельная линейка на KVM, ориентированная на проекты с высокой частотной нагрузкой, до 5 ГГц на ядро, порт до 1000 Мбит/с.

VPS Windows — выделенная категория для задач на Windows.

Особенности и инфраструктура

В ИХЦ можно выбрать между двумя видами виртуализации: KVM и Virtuozzo. Виртуализация KVM подходит для задач, где нужна изоляция ресурсов, стабильность под нагрузкой и совместимость с Linux и Windows. Virtuozzo — более экономный вариант с быстрой настройкой, но с возможной перераспределённой нагрузкой между соседними VPS.

Связь с поддержкой доступна через тикеты, онлайн-чат на сайте, телеграм-бота, телефон и сообщения ВКонтакте. Поддержка работает 24/7. На всех тарифах включена базовая DDoS-защита.

Примеры использования VPS от IHC

Компания предоставляет конкретные кейсы. Примеры:

• Проект 1: VPS NVMe/24 (24 ГБ RAM, ~200 ГБ SSD) используется под бэкенд iOS-приложения. Стек: nginx, PHP, MySQL. Нагрузка: 12 000 уникальных пользователей в сутки. Утилизация CPU — 25%.
• Проект 2: VPS NVMe/12 (12 ГБ RAM, ~120 ГБ SSD) для развлекательного сайта. Стек: nginx, Docker, Node.js. Нагрузка: 7 000 уникальных пользователей в сутки, загрузка CPU — около 20%.

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

Дополнительные опции

ИХЦ предлагает тестовый период в 3 дня, безлимитный трафик, бесплатный первый месяц ispmanager 6 в подарок, а также предустановку панелей управления (ispmanager, FastPanel) или VPN-шаблонов по выбору при заказе. Также доступны бэкапы, SLA и автоснапшоты.

Цены

Что касается ценовой политики, стоимость VPS в России (линейка «ssdVPS») начинается от 380 руб/мес или 3800 руб/год (12 месяцев по цене 10). Европейские VPS («EU-NVMe/») и VPS на KVM («NVMe/») стартуют от 440 руб/мес или 4400 руб/год, а каждый дополнительный гигабайт памяти стоит 6 рублей.

2. FirstVDS: мощные VDS на AMD EPYC и Ryzen

FirstVDS — хостинг-провайдер с опытом на рынке более 20 лет. Предлагают VPS и VDS с виртуализацией KVM для проектов любого размера. Все серверы работают на современном оборудовании. Трижды победитель в номинации «Хостер года» Национальной премии «ЦОДы.РФ».

Есть VPS для разных сценариев нагрузки — от стандартных сайтов до тяжёлых веб-приложений и проектов с высокими требованиями к CPU и отказоустойчивости. Отдельные решения для Битрикс, установка ОС семейства Linux, FreeBSD и Windows Server.

Линейки VPS: от базовой мощности до кластера Ceph

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

1. VDS Форсаж — гибкая конфигурация сервера на базе AMD EPYC, до 128 ядер (до 3,7 ГГц), до 512 Гб оперативной памяти и до 4 000 Гб быстрого NVMe-накопителя. Локации Москва и Амстердам. Стартовая стоимость такой конфигурации составляет от 749 руб/мес.
2. Для нагруженных проектов — CPU.Турбо — гибкая конфигурация сервера на базе AMD Ryzen с частотой до 5,7 ГГц, DDR5 и с быстрыми NVMe-накопителями. Идеально для Битрикс. Локация Москва. Начальная цена CPU.Турбо — от 624 руб/мес. При покупке лицензии Битрикс (1С-Битрикс: Управление сайтом или Битрикс24) есть дополнительная скидка 30% на 3 месяца аренды этого тарифа.
3. Отказоустойчивый VDS Атлант — гибкая конфигурация сервера на базе AMD EPYC — до 192 ядер (до 3,5 ГГц), до 768 Гб оперативной памяти и до 8 Тб быстрого NVMe-накопителя. Репликация данных между узлами кластера Ceph и дублирование сетевого оборудования. Локация Москва. Его стартовая стоимость от 1619 руб/мес, при этом бесплатные автобэкапы уже включены.

Компания использует два центра обработки данных в Москве: IXcellerate (уровень Tier III) и Web DC. Для тарифа Форсаж и готовых тарифов также доступен ЦОД euNetworks (уровень Tier III) в Амстердаме.

Сетевые возможности, трафик и безопасность

В стоимость каждого сервера входит бесплатный выделенный IP-адрес. Клиенты могут выбрать между 100 Мбит/с с безлимитным трафиком или портом 1 Гбит/с с включёнными 32 Тб трафика.

Защита от DDoS-атак и система безопасности BitNinja для сервера и сайта доступны как подключаемые опции. Также предоставляются объектное хранилище S3, автобэкапы и Кибер-бэкап. Для безопасности коммуникаций используются SSL-сертификаты GlobalSign.

Управление, ПО и поддержка

При заказе сервера клиент получает лицензию ispmanager 6  lite: первый месяц панель предоставляется бесплатно, дальше оплачивается по тарифу самой панели. Предлагается гибкий выбор операционных систем, включая Linux, FreeBSD и Windows Server. Под разовые задачи доступны готовые рецепты установки — от Битрикс и GitLab до TeamSpeak, LAMP‑стека и других популярных наборов ПО.

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

Клиентские бонусы и программы

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

1) При переходе от другого хостера FirstVDS бесплатно переносит до 10 сайтов. Дополнительно предоставляется скидка 40% на первый месяц аренды VPS при оплате сервера на 1, 3 или 6 месяцев, либо 3 месяца бесплатной аренды VPS при оплате на год.

2) Клиенты с возрастом аккаунта от 5 лет получают постоянную скидку на аренду VPS, начиная от 5% и увеличиваясь ежегодно до 20%.

3) Действует реферальная программа, по которой партнёр получает 10% от расходов привлечённых клиентов, а привлечённый пользователь — скидку 25% на первый месяц аренды VPS.

4) Стоимость продления домена у FirstVDS равна актуальной стоимости его регистрации.

3. InCloud: VPS‑площадки для бизнеса, где важен SLA

InCloud продаёт виртуальные серверы, работающие в отказоустойчивом кластере на базе enterprise хранилищ NetApp и HPE 3PAR. Позиционируется как решение для 1С, малого/среднего бизнеса и аутсорс компаний, которым нужны предсказуемые ресурсы и техподдержка профессиональных инженеров, а не чат‑ботов.

Тарифные планы и ценообразование

InCloud предлагает две основные линейки тарифов:

1. Стандартный тариф: внутри процессоры Intel Xeon 2600v4 2ГГц и оперативная память DDR4 2400 МГц.Стоимость: 1 CPU – 200 рублей, 1 Гб RAM – 200 рублей.
2. Производительный тариф: использует процессоры AMD EPYC до 3.8 ГГц и оперативной памяти DDR5 4800 МГц. Стоимость: 1 CPU – 250 рублей, 1 Гб RAM – 250 рублей.

Стоимость дискового пространства: SATA диски: 3 рубля за 1 Гб. SSD и NVMe диски: 13 рублей за 1 Гб.

Архитектура и поддержка

Теперь про то, что упрощает жизнь и добавляет надежности нашим развернутым сервисам:

• Ежедневные бэкапы: данные ваших серверов будут копироваться каждый день, и храниться они могут до 30 дней.
• Удобная панель управления: через нее можно делать снапшоты и клонировать серверы. Для разработчиков это просто золото – быстро накатить тестовую среду, попробовать новую фичу, а потом откатиться или создать идентичные рабочие среды.
• SLA-договор: есть возможность заключить SLA-договор, чтобы получить гарантированный уровень доступности услуг.
• Новейшие мощные серверы — на базе AMD EPYC 4 поколения.

Одна из фишек – это возможность напрямую проконсультироваться с сертифицированными инженерами InCloud по сложным проектам.

А что с клиентскими кейсами

1. Кейс Vamkamin: производственная компания, которая ускорила работу своей системы 1С и сократила IT-расходы на 35%. У них была проблема с медленной работой 1С при одновременном доступе бухгалтерии, склада и отдела продаж, а также с частыми простоями на локальных серверах. InCloud предложил перенести все сервисы в облако, используя серверы на базе AMD EPYC 9554, что обеспечило прирост производительности более 40% по сравнению с предыдущими решениями. Также были внедрены гибкое масштабирование ресурсов и ежедневное резервное копирование.
2. Кейс Веб-студии 100UP: компания занимается разработкой и поддержкой сайтов для крупных торговых сетей и e-commerce проектов. 100UP переехала к облачному провайдеру InCloud, выбрав тарифы на базе AMD EPYC 9554 с высокой тактовой частотой и большим количеством ядер. Благодаря разнообразию тарифов команда легко распределила проекты по нужным по производительности виртуальным серверам. После переезда 100UP смогла сократить время отклика клиентских сайтов в среднем на 45%, обеспечить бесперебойную работу даже в периоды высокой сезонной нагрузки, ускорить запуск новых проектов, фокусироваться на разработке и маркетинге и улучшить качество предоставляемых услуг.

4. SmartApe: быстрые VPS на NVMe‑SSD

SmartApe подойдет проектам, где дисковая подсистема и CPU работают без простоя: интернет‑магазины, порталы с большим количеством контента, внутренние корпоративные системы, высоконагруженные API. Если нужен быстрый старт — сервер создаётся за одну‑две минуты; если понадобится масштабирование, тариф можно увеличить без миграции.

Преимущества этих VPS

Используются современные серверные NVMe SSD диски в RAID массиве, которые в 600 раз быстрее обычных HDD. Скорость чтения достигает 8000 Мбайт/с, а записи — 2000 Мбайт/с.

Серверы работают на мощных процессорах Intel Xeon Gold или AMD EPYC (до 3.7 ГГц) и быстрой памятью DDR4. Используется полноценная виртуализация KVM с выделенными ресурсами для гарантии их предоставление. Дата-центры уровня TIER-III и TIER-IV обеспечивают Uptime 99.982%. Данные хранятся в хранилище RAID-10.

Дополнительно клиенты получают полный root-доступ (по SSH для Linux и RDP для Windows), возможность установки любых операционных систем (более 20, включая Ubuntu, CentOS, Debian, Windows Server) и ПО, а также полную изоляцию от других клиентов.

Удобство и поддержка

• Бесплатная панель управления (Hestia) или платная ISPmanager для простого управления сервером.
• Бесплатное базовое администрирование и помощь в переносе сайтов.
• Круглосуточная квалифицированная поддержка 24/7.
• Бесплатный тестовый период 10 дней без оплаты и ввода карты.
• Защита от DDoS-атак включена в стоимость.
• Выделенный внешний IP-адрес (возможность купить до 10 IP).

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

Пример использования: интернет‑магазин

VPS c 2 vCPU, 4 ГБ RAM, 80 ГБ SSD и портом 100 Мбит/с; при обычном трафике сайт обслуживает 300–500 уникальных посетителей в день, одновременно на страницах бывает 10–20 человек, а в пиковую распродажу до 50; средняя нагрузка 5–10 запросов в секунду, короткими всплесками до 20; заявленный аптайм 99,982 %, реальные замеры отклика после кэширования — 200–300 мс; счёт за такой сервер выходит около 1 300 рублей в месяц.

Пример использования: API на Node.js

4 vCPU, 8 ГБ RAM, 160 ГБ NVMe и канал 200 Мбит/с; сервис стабильно обрабатывает 50–100 запросов в секунду, на пике достигает 200, одновременно подключены 500–1 000 клиентов, максимум 2 500; трафик близок к 200 ГБ в месяц; при том же аптайме 99,982 % средняя задержка ответа укладывается в 50–100 мс; ежемесячная стоимость в зависимости от опций колеблется в диапазоне 2 600–3 000 рублей.

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

5. PSB Hosting: что даёт их VPS‑платформа

PSB Hosting продвигает VPS-хостинг как решение для сайтов, приложений и SaaS-сервисов, которым нужна предсказуемая мощность и высокий SLA. Провайдер делает упор на новое оборудование, пропускную способность без ограничений и инфраструктуру уровня Tier III+.

Локации и тарификация

Серверы разворачиваются в четырёх точках: Нидерланды, США, Германия и Финляндия. Для каждой площадки доступен одинаковый конструктор конфигураций. Базовый план NL‑100, который включает 1 vCPU, 2 ГБ RAM и 30 ГБ SSD, стоит 6 долларов в месяц. Линейка поднимается ступенчато:

Слайдеры позволяют довести параметры до 32 ядер, 64 ГБ RAM и 510 ГБ SSD; верхняя планка оплаты — 220 $ в месяц.

Трафик безлимитный на любых конфигурациях — дополнительной оплаты за гигабайты нет.

Аппаратная платформа, ОС и предустановки

В хост-узлах применяются процессоры последних линеек AMD и Intel. Оперативная память — DDR5, что снижает задержки при обращении к ОЗУ. Дисковая подсистема полностью на NVMe, объединена в RAID 10: чтение и запись выше, чем у классических SSD, а отказ одного накопителя не выводит хранилище из строя. К каждому VPS подключён выделенный канал с пропускной способностью до 10 Гбит/с.

Сервер можно поднять сразу с Windows Server, Ubuntu, Debian, CentOS или FreeBSD. Для быстрого старта доступны готовые образы: Bitrix, Django-стек, Docker, FastPanel, Hestia CP, Keitaro, LAMP, Node, OpenVPN, Outline, Portainer, Vesta CP и другие.

Управление и поддержка

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

Как выбрать VPS под свой проект

Для сайта с пиковыми нагрузками подойдёт SmartApe, где дисковая подсистема на NVMe-SSD в RAID-10 обеспечивает скорость чтения до 8000 Мбайт/с и записи до 2000 Мбайт/с, а сайт на конфигурации с 2 vCPU, 4 ГБ RAM и 80 ГБ SSD выдерживает 300–500 уникальных посетителей в день с пиком до 50 одновременных пользователей и нагрузкой 5–10 запросов в секунду (короткими всплесками до 20).

Если проект включает высоконагруженный API, например, на Node.js, то оптимален SmartApe с конфигурацией 4 vCPU, 8 ГБ RAM и 160 ГБ NVMe, которая стабильно обрабатывает 50–100 запросов в секунду (пики до 200) при 500–1000 одновременных подключениях (максимум 2500) и трафике до 200 ГБ в месяц.

Для задач с 1С, где важна стабильность и сокращение IT-расходов, выбирайте InCloud на базе AMD EPYC 9554: в кейсе Vamkamin это ускорило работу системы на 40%, сократило расходы на 35% и минимизировало простои, с ежедневными бэкапами до 30 дней и SLA-договором.

Если нужен VPS для Битрикс с высокой частотой CPU, подойдёт FirstVDS на AMD Ryzen (CPU.Турбо) с частотой до 5,7 ГГц и DDR5: скидка 30% на 3 месяца при покупке лицензии Битрикс, плюс отказоустойчивость на кластере Ceph с репликацией данных.

Для веб-студий с разработкой и поддержкой сайтов для e-commerce, где требуется распределение проектов по производительности и бесперебойная работа в сезонные пики, подойдёт InCloud на AMD EPYC 9554: в кейсе 100UP это сократило время отклика на 45% и обеспечило стабильность под высокой нагрузкой.

Если проект ориентирован на международный трафик с предсказуемыми ресурсами и высоким SLA, выбирайте PSB Hosting с локациями в Нидерландах, США, Германии или Финляндии, безлимитным трафиком и каналом до 10 Гбит/с на DDR5 и NVMe в RAID 10.

Для бэкенда мобильного приложения с нагрузкой до 12 000 уникальных пользователей в сутки (утилизация CPU 25%) подойдёт ИХЦ на NVMe/24 с 24 ГБ RAM и ~200 ГБ SSD, стеком nginx, PHP, MySQL.

Если развлекательный сайт с более чем 5000 уникальных пользователей в сутки (загрузка CPU ~20%), то подходит ИХЦ на NVMe/12 с 12 ГБ RAM и ~120 ГБ SSD, стеком nginx, Docker, Node.js. Он обеспечит стабильность с безлимитным трафиком и DDoS-защитой.

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

Рассказываем про 7 команд, влияющие на скорость работы в терминале. Вы узнаете:

• про встроенные bash-операции, которые заменяют пайплайны,
• про способы работы с файловыми дескрипторами,
• про wildcards, которые избавляют от сложных конструкций с find.

Каждая команда в подборке решает конкретную проблему:

• массовая обработка файлов,
• отладка скриптов,
• работа с длинными путями.

1. Bash variable expansions

Вместо basename, cut для простых операций со строками можно использовать встроенные возможности Bash:

% режет справа до первого совпадения, %% — до последнего. Символ # работает слева направо.

В реальной работе это помогает при массовой обработке файлов. Например, есть 1000 логов, и нужно каждый переименовать.

Если использовать basename, запустится 1000 отдельных процессов. Variable expansions работают без fork/exec, без задержек на создание процессов.

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

2. Here-string (<<<)

Here-string упрощает передачу строковых данных в команды без создания временных файлов или использования echo с пайпом.

Реальная экономия времени проявляется при отладке и модификации скриптов. Например, когда SQL-запрос или конфигурация зашиты в here-документ. С here-string данные собраны в одном месте, легко редактируются и переиспользуются.

Работает не только с базами данных. Отправка в API, конфигурирование сетевых устройств через expect, передача команд в Docker — через <<< код будет понятнее, а сопровождение проще.

3. /proc/$$/fd

Каждый процесс имеет стандартные дескрипторы 0 (stdin), 1 (stdout), 2 (stderr), которые представлены как символические ссылки. Директория /proc/$$/fd предоставляет доступ к файловым дескрипторам текущего процесса:

Переменная $$ содержит PID текущего процесса, поэтому /proc/$$/fd ведет к дескрипторам именно вашего шелла.

Практическое применение — отладка перенаправлений и работа с дескрипторами в сложных скриптах:

4. Wildcards с диапазонами

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

Wildcards автоматически раскрываются шеллом в список подходящих файлов — это их основная функция. Кавычки нужны только когда передаете символы [, ] как литеральные:

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

5. sudo !!

Набрали длинную команду, нажали Enter, получили «Permission denied». Рука на рефлексе тянется к стрелке вверх и Home, чтобы добавить sudo в начало.

Вот способ в разы быстрее:

Двойное восклицание !! — это ссылка на предыдущую команду целиком. Bash подставит всю строку со всеми аргументами и ключами. Кажется мелочью, но для админа, который 10 раз в день забывает sudo, это серьезная оптимизация.

Двойное восклицание универсально и работает не только с sudo:

• time !! для замера времени выполнения,
• nohup !! & для запуска в фоне,
• strace !! для отладки.

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

6. ^старое^новое

Основной способ исправления опечатки — стрелка вверх, поиск ошибки, исправление. Смотрите, как можно сделать это побыстрее:

Символ ^ ищет первое вхождение слова и заменяет его. Работает с последней командой.

Заменяется только первое вхождение. Если ошибочное слово встречается несколько раз, способ не сработает. В таких случаях придется использовать классическое редактирование или history expansion.

7. Alt+.

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

Комбинация Alt+. (Alt + точка) вставляет последний аргумент предыдущей команды в текущую позицию курсора. Повторное нажатие перебирает аргументы из более ранних команд.

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

Еще этой комбинацией вставляются:

• имена пользователей,
• IP-адреса,
• названия сервисов,
• параметры конфигурации.

Alt + точка работает в большинстве шеллов. Привыкнув к ней, начинаешь использовать на автомате.

Что запомнить

• ${filename%.*} и встроенные операции со строками работают быстрее внешних утилит. % режет справа, # — слева. Полезно при работе с циклами для массовой обработки файлов.
• <<< — here-string удобен для передачи коротких строковых данных в команды. С многострочными данными лучше использовать here-document или переменные.
• /proc/$$/fd — доступ к файловым дескрипторам текущего процесса. Ускоряет отладку перенаправлений и работу с дескрипторами.
• file[1-5] и [^b]* — диапазоны в wildcards для точного отбора файлов. Кавычки нужны только для передачи литеральных символов.
• sudo !! — повторяет последнюю команду с sudo. Также работает с time !!, nohup !! &. Если между нужной командой и !! выполнялись другие операции, используйте !строка для поиска конкретной команды в истории.
• ^старое^новое — заменяет первое вхождение в предыдущей команде. Работает только с последней командой и заменяет первое совпадение.
• Alt+. — вставляет последний аргумент предыдущей команды. Повторное нажатие перебирает аргументы из истории команд. Экономит время при работе с длинными путями.

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

Посмотрим, кто из них есть в этом списке, и определим особенности хостингов для сайта.

1. FirstVDS: профессиональные решения для любых проектов

FirstVDS — хостинг-провайдер с опытом на рынке более 20 лет. Предлагают VPS и VDS с виртуализацией KVM для проектов любого размера. Все серверы работают на современном оборудовании. Трижды победитель в номинации «Хостер года» Национальной премии «ЦОДы.РФ».

Хостинг подойдет бизнесу любого масштаба: для любых сайтов — от визиток до высоконагруженных интернет-магазинов, для разработки и тестирования, для сервисов и других проектов. Отдельные решения для Битрикс, установка ОС семейства Linux и Windows Server.

Особенности хостинга

Надёжность

FirstVDS обеспечивает аптайм 99,97–99,99% в 2025 году, подтверждённый замерами (например, отклик из Москвы — 27 мс в апреле 2025). Серверы размещены в трёх дата-центрах уровня Tier III: два в Москве (IXcellerate и Web DC) и один в Амстердаме (euNetworks). Отказоустойчивый кластер Ceph гарантирует работу даже при сбоях точки или канала.

Инфраструктура

Серверы работают на процессорах Intel Xeon и AMD EPYC (до 5,7 ГГц в линейке CPU.Турбо), с быстрыми NVMe-дисками объёмом до 8 ТБ и оперативной памятью DDR5 (до 768 ГБ в VDS Атлант). Это обеспечивает высокую производительность для ресурсоёмких задач, таких как Битрикс или высоконагруженные приложения.

Гибкость

Тарифы масштабируются: от базовых конфигураций (1 CPU, 1 ГБ RAM, 40 ГБ SSD) до мощных серверов (192 ядра, 768 ГБ RAM, 8 ТБ NVMe). Линейки:

• VDS Форсаж: AMD EPYC, до 128 ядер, 512 ГБ RAM, 4 ТБ NVMe, от 749 ₽/мес (Москва/Амстердам).
• CPU.Турбо: AMD Ryzen до 5,7 ГГц, DDR5, от 624 ₽/мес (Москва).
• VDS Атлант: отказоустойчивый, до 192 ядер, 8 ТБ NVMe, от 1619 ₽/мес (Москва).
• VDS Storage: хранилище, от 704 ₽/мес (Москва).Горячее масштабирование (hot-resize) позволяет добавлять CPU, RAM или диск без перезагрузки.

Автоматизация

Шаблоны для быстрого развёртывания: Django, Redmine, Tomcat, Teamspeak, Nextcloud, LAMP, LEMP, Forgejo Git, GitLab, Битрикс. Поддерживаются ОС Linux (Ubuntu, Alma, Debian, Rocky, CentOS, Oracle), FreeBSD, Windows Server. API и панель ispmanager 6 lite (бесплатно на месяц) упрощают управление.

Безопасность

Включена защита от DDoS-атак на сетевом уровне, BitNinja для защиты сервера и сайта, SSL-сертификаты GlobalSign. Доступны автобэкапы, снапшоты, Кибер-бэкап и объектное хранилище S3 для больших данных.

Поддержка

Круглосуточная поддержка 24/7 без чат-ботов, ответ до 15 минут через чат, личный кабинет или телефон. Бесплатно: помощь с активацией и первичной настройкой. Платно: установка ПО, администрирование. Экспертная линия для мониторинга и устранения сбоев.

Бонусы

• Тестовый период 3 дня.
• Бесплатный перенос до 10 сайтов с другого хостера.
• Скидки: 40% на первый месяц при оплате на 1/3/6 месяцев или 3 месяца бесплатно при оплате за год.
• Лояльность: скидка 5–20% для клиентов от 5 лет.
• Реферальная программа: 10% от расходов привлечённых клиентов для партнёра, 25% скидка для нового пользователя на первый месяц.
• Домены: продление по цене регистрации.

Тарифы и условия

Тестовый период 3 дня, после него подключаете один из основных тарифов:

• Линейка готовых конфигураций от 1 CPU, 1 Гб RAM, 40 Гб SSD-накопителя и от 219 руб/мес. до сервера с 8 CPU, 12 Гб RAM, 150 Гб NVMe-накопителя. Локация в РФ и Нидерландах.
• VDS Форсаж: на AMD Epyc от 749 ₽/мес. Локации: РФ и Нидерланды.
• CPU.Турбо: гибкая конфигурация на базе высокочастотных AMD Ryzen 9 от 624 ₽/мес. При покупке лицензии Битрикс дополнительная скидка 30% на 3 месяца аренды CPU.Турбо. Локация в РФ.
• VDS Атлант: отказоустойчивый с автобэкапами от 1 619 ₽/мес. Локация: РФ.
• VDS Storage: сервис как хранилище с гибкой конфигурацией от 704 ₽/мес. Локация: РФ

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

2. UltraVDS: для малого бизнеса и стартапов

Компания UltraVDS, провайдер услуг виртуальных серверов (VPS/VDS), работает на рынке с 2014 года — предлагает решения для разных операционных потребностей. Сервисы UltraVDS можно использовать для развертывания торговых роботов, запуска чат-ботов, хостинга веб-сайтов, а также для создания FTP-хранилищ данных. Есть предложения для фрилансеров, цифровых агентств, корпоративных пользователей и стартапов, которым требуются функциональные инфраструктурные решения.

Технические особенности

Серверы UltraVDS размещены в современном дата-центре, расположенном в Москве. Доступность сервиса (аптайм) составляет 99,98%, что обеспечивает высокую стабильность работы. Сетевая пропускная способность превышает 200 Мбит/с, при этом трафик предоставляется без ограничений.

Система защиты от DDoS-атак способна обрабатывать трафик до 1,5 Тбит/с и поддерживает стабильность работы сервера даже при интенсивном внешнем воздействии. Лицензия на Windows Server входит в стоимость обслуживания в данном предложении. Это упрощает развертывание сервера: вам не нужно отдельно покупать и устанавливать лицензию. Плюс снижает общие операционные расходы для пользователей этой операционной системы.

Тарифные планы

Для новых пользователей UltraVDS предусмотрена возможность 3-дневного тестового периода, позволяющего оценить функциональность и производительность сервиса.

После тестового периода стоимость тарифов начинается от 119 рублей в месяц. На сайте доступен онлайн-калькулятор, позволяющий подобрать конфигурацию сервера и рассчитать итоговую стоимость.

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

Поддержка и обслуживание

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

3. RUVDS: 10 лет на рынке облачных решений

RUVDS — облачный провайдер, имеющий десятилетний опыт работы на рынке услуг виртуальных серверов (VPS/VDS). Является официальным партнером Huawei в России, работает по SLA. Компания предоставляет инфраструктурные решения, которые могут быть применены для широкого спектра задач, включая хостинг высоконагруженных интернет-магазинов, корпоративных порталов, игровых серверов, сложных backend-систем и чат-ботов.

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

Тарифная политика и варианты оплаты

RUVDS предлагает различные тарифные планы. Например, стоимость конфигурации Linux-сервера (1 CPU, 512 МБ RAM, 10 ГБ HDD, 1 IPv4) начинается от 139 ₽/месяц. Это может быть рассмотрено как экономичное решение для запуска небольших проектов и проведения тестирования.

Клиентам доступны разные опции оплаты:

1. Ежемесячные платежи или предоплата на срок от 3 до 12 месяцев, при которой предоставляются скидки до 20%, зависящие от продолжительности периода.
2. Для проектов с динамической нагрузкой предусмотрена посекундная тарификация, оплата по которой взимается только за фактически использованные ресурсы. Неиспользованный остаток средств в рамках этой модели возвращается на баланс пользователя

Дополнительно, до конца 2025 года панель управления ISP Manager для сервера и сайта предоставляется без дополнительной платы при создании любого VPS.

Глобальная инфраструктура и стабильность

Инфраструктура включает 17 дата-центров уровня Tier III, расположенных по всему миру. Это один из самых больших показателей по количеству геолокаций среди российских провайдеров. Для работы используются корпоративное оборудование и накопители (HDD, SSD, NVMe), чтобы обеспечить стабильную работу и производительность размещенных проектов.

Поддержка клиентов и доступные ресурсы

Техническая поддержка RUVDS доступна круглосуточно, 7 дней в неделю. Среднее время ответа на запросы через тикет-систему или онлайн-чат составляет 15 минут. Клиентам предоставляются полные административные права и консультации по вопросам запуска и настройки серверов. Для самостоятельного изучения доступна база знаний, включающая инструкции и руководства.

Безопасность и масштабирования

В контексте безопасности данных, RUVDS предлагает несколько решений:

- Встроенная защита от DDoS-атак, способствующая поддержанию бесперебойной работы серверов при внешнем воздействии.

- Стандартный IPv4-адрес включен в стоимость каждой виртуальной машины, с опцией аренды дополнительных IP-адресов.

- API, соответствующий OpenAPI 3.0.0, предоставляет возможности для интеграции и автоматического масштабирования серверных ресурсов в зависимости от нагрузки.

- Компания официально подтверждает соответствие требованиям ФСТЭК и ФЗ-152 по защите персональных данных, что обеспечивает соблюдение соответствующих законодательных норм.

4. McHost: решения для бизнеса разного масштаба

McHost предоставляет комплексные хостинговые решения, включая виртуальный хостинг и VPS/VDS с NVMe-накопителями. Сервис поддерживает популярные CMS (WordPress, Joomla, 1С-Битрикс) с оптимизированными настройками и автоматической установкой через панель управления.

McHost ориентирован на широкий круг клиентов:

• владельцы сайтов-визиток, блогов и лендингов — благодаря низким тарифам и полному набору опций;
• интернет-магазины с небольшой нагрузкой — тарифы с SSD-накопителями и автоматическим резервным копированием обеспечивают стабильную работу;
• разработчики, которым нужны
  VPS/VDS с root-доступом — работают серверы на KVM-виртуализации с ОС Linux и Windows;
• госучреждения и компании,
  работающие с персональными данными — соответствие 152-ФЗ и размещение в дата-центрах Tier III в Москве.

Особенности сервиса

McHost поддерживает стабильную работу с аптаймом 99.9% за счет размещения оборудования в дата-центрах уровня Tier III — в Москве и Нидерландах.

Сервис предоставляет защиту от DDoS-атак, автоматическое резервное копирование раз в два дня с хранением данных в течение 30 дней для виртуального хостинга и 14 дней для VPS, а также поддержку российских криптографических стандартов. Клиентам доступны различные варианты размещения: от виртуального хостинга с SSD (от 157.5 ₽/мес) до выделенных серверов с NVMe-накопителями.

Технические параметры и условия

Инфраструктура McHost базируется на серверах Dell с NVMe-накопителями и процессорами Intel Xeon (частота ядер от 2.35 ГГц). Для виртуального хостинга используется CloudLinux с технологией CageFS, обеспечивающей изоляцию аккаунтов. Поддержка российских ОС («Альт») подтверждена для VPS-тарифов.

В техподдержку можно обратиться по телефону, через тикет или в Telegram-боте. Время ответа — до 10 минут.

Текущие тарифы:

• Виртуальный хостинг: от 157 ₽/мес
  (3 ГБ SSD, 1 сайт).
• VPS: от 396 ₽/мес (15 ГБ SSD, 1
  ядро CPU).
• Выделенные серверы: от 3 000 ₽/мес
  (32 ГБ RAM, 2×1 ТБ HDD).

5. UFO Hosting: VPS/VDS и выделенные серверы с портом до 10 Гбит/с и безлимитным трафиком

UFO Hosting предлагает VPS/VDS и выделенные серверы на партнёрской инфраструктуре IXcellerate (Tier III). В портфолио — недорогие виртуальные машины и серверы с портом 10 Gbps для проектов, которым нужна стабильность без завышенных цен.

Сервис подходит для пользователей разных масштабов: от фрилансеров и веб‑студий до средних и крупных компаний. Для DevOps‑специалистов доступны API и инструменты автоматизации.

Основные сценарии использования

• корпоративные сайты, CRM‑системы и веб‑приложения;
• аналитические сервисы и SaaS‑продукты;
• инфраструктура для разработки и тестирования;
• задачи фрилансеров, агентств и digital‑команд.

Формат работы, особенности и интеграции

Серверы установлены в российском дата‑центре Tier III (IXcellerate), что означает резервирование по питанию и каналам связи. Заявленный аптайм — 99,98 %. Поддержка работает круглосуточно в тикетах, чате и по телефону; среднее время ответа 5–10 минут.

Сервис UFO Hosting делает акцент на безопасности и гибкости. Есть сеть с защитой от DDoS, возможность горячего расширения ресурсов, автоматическое развёртывание из шаблонов и API для интеграции. Поддерживаются популярные фреймворки и CMS, есть интеграции с GitLab, Telegram и DockerHub. Бэкапы, снапшоты и резервирование входят в стандартный набор, так что восстанавливать тестовую среду не придётся вручную.

В панели управления можно автоматически установить популярные CMS, панели управления, хранилища и DevOps‑инструменты. Это экономит время на настройку и подходит тем, кто не хочет поднимать всё с нуля.

Условия использования и тарифы

Базовые конфигурации начинаются от 577 руб./месяц. Заявленная скорость порта — до 10 Gbps, что подходит для проектов, где много трафика.

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

В целом, UFO Hosting выглядит как практичное решение для тех, кому нужны производительные VPS/VDS и выделенные серверы в России. При выборе стоит оценить, насколько конфигурации подходят под конкретные нагрузки и есть ли необходимость в интеграциях из коробки.

6. Timeweb: хостинг для веб-проектов

Timeweb предоставляет услуги хостинга для различных типов веб-проектов. Сервис поддерживает популярные CMS, включая WordPress, 1C-Битрикс и Joomla, что делает его подходящим как для личных блогов, так и для корпоративных сайтов.

Платформа использует собственную панель управления с инструментами для работы с сайтами, базами данных и резервными копиями. Ежедневное автоматическое резервное копирование с хранением данных до 30 дней включено во все тарифные планы. Базовая защита от DDoS-атак доступна для всех клиентов без дополнительной платы.

Инфраструктура Timeweb размещена в дата-центрах уровня Tier III в России (Санкт-Петербург) и Казахстане (Алматы). Гарантированный показатель uptime составляет 99.98%. Поддерживаются современные технологии: PHP версий от 5.3 до 8.4, MySQL от 5.6 до 8.0, а также Perl, Python, SSH, FTP и Cron.

Тарифные планы:

• Year+: от 164 ₽/мес (2 сайта, 15
  ГБ NVMe, 2 БД);
• Optimo+: от 248 ₽/мес (15 сайтов,
  40 ГБ NVMe, безлимитные БД);
• Century+: от 347 ₽/мес (35 сайтов,
  50 ГБ NVMe, безлимитные БД);
• Millennium+: от 482 ₽/мес (60
  сайтов, 60 ГБ NVMe, безлимитные БД).

Все тарифы включают бесплатный SSL-сертификат, 10 ГБ почтовой квоты с неограниченным количеством ящиков и DNS-хостинг. При оплате годового тарифа предоставляется домен в зонах .RU/.РФ в подарок.

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

7. Reg.ru: комплексные решения для сайтов и доменов

Reg.ru сочетает услуги хостинга и регистрации доменов, что упрощает управление веб-проектами. Компания работает с 2005 года, имеет статус аккредитованного регистратора доменных имён в зонах .RU и .РФ.

Функциональные возможности

Платформа предоставляет доступ к трём панелям управления: ISPmanager, cPanel и Plesk. Это позволяет выбрать наиболее удобный интерфейс для работы с сайтами. Все тарифы включают бесплатный SSL-сертификат от Let’s Encrypt, который автоматически устанавливается при создании сайта.

Начинающим пользователям доступен конструктор сайтов с готовыми шаблонами. Поддерживаются популярные CMS, включая WordPress, Joomla и 1С-Битрикс. Ежедневное резервное копирование данных с хранением копий в течение 30 дней входит в стандартный набор услуг.

Техническая инфраструктура

Серверы размещены в дата-центрах уровня Tier III в Москве. Средний показатель uptime составляет 99.9%, что подтверждается ежемесячной статистикой. Подключение к сети осуществляется по выделенным каналам со скоростью до 1 Гбит/с на выделенных серверах.

Поддержка и тарифы

Техническая поддержка доступна 24/7 через онлайн-чат и тикет-систему. Среднее время ответа составляет 15-20 минут. Для срочных вопросов можно обратиться по телефону.

Тарифы — от 151 ₽/мес (7 ГБ SSD, 15 сайтов). При регистрации домена в зонах .RU или .РФ предоставляется скидка на другие доменные имена.

8. Спринтхост: хостинг с персональным подходом

Sprinthost предлагает услуги хостинга с акцентом на индивидуальную поддержку клиентов. Сервис работает с 2011 года и специализируется на VPS-решениях для различных веб-проектов.

Особенности сервиса

Компания предоставляет персонального менеджера для каждого клиента, который помогает с настройкой сервера и решением технических вопросов. А если вы остались недовольны услугами, то в течение 30 дней сервис вернёт деньги. Sprinthost проводит бесплатные обучающие вебинары по DevOps и администрированию серверов.

Технические характеристики и тарифы

Инфраструктура размещена в дата-центрах Москвы и Санкт-Петербурга с аптаймом 99.9%. Поддерживаются современные технологии разработки, включая Ruby on Rails, Node.js, Python и Docker. Все серверы используют SSD-накопители с гарантированной скоростью чтения/записи.

Тарифные планы:

• Start: 290 ₽/мес (1 ядро, 1 ГБ
  RAM, 15 ГБ SSD);
• Turbo: 1 900 ₽/мес (4 ядра, 8 ГБ
  RAM, 100 ГБ NVMe).

Поддержка

Техническая помощь доступна 24/7 через тикет-систему и онлайн-чат. Среднее время ответа составляет 10-15 минут. Для корпоративных клиентов предусмотрена приоритетная поддержка по телефону.

Как выбрать хостинг в 2025 году

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

Для высоконагруженных сервисов и интернет-магазинов лучше рассматривать VPS или выделенные серверы. Обратите внимание на тип накопителей (SSD/NVMe), возможность масштабирования ресурсов и аптайм дата-центров (рекомендуется от 99.9%).

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

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

FAQ

Что такое виртуальный хостинг и когда его выбирать?

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

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

Что такое VPS/VDS и для каких проектов он подходит?

VPS (Virtual Private Server) или VDS — это виртуальный сервер с выделенными ресурсами (процессор, память, диск), предоставляющий доступ для полной настройки. Идеален для проектов среднего масштаба: интернет-магазинов, API, SaaS, чат-ботов, корпоративных порталов или приложений с умеренным трафиком.

Преимущества: гибкость конфигураций, выбор ОС, изоляция ресурсов. Минусы: требует базовых навыков администрирования, стоимость выше, чем у виртуального хостинга.

Что такое выделенный сервер и когда его использовать?

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

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

В чём основные различия между виртуальным хостингом, VPS и выделенным сервером?

Виртуальный хостинг — самый дешёвый и простой, но ресурсы делятся между пользователями, что ограничивает производительность (до 1000–2000 посетителей в сутки).

VPS обеспечивает выделенные ресурсы и гибкость, справляясь с нагрузкой до 5000–10 000 пользователей в сутки.

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

Выбор зависит от масштаба: виртуальный для старта, VPS для роста, выделенный для enterprise.

Нужны ли навыки администрирования для хостинга?

Для виртуального хостинга навыки не нужны — управление идёт через интуитивные панели, а провайдеры обеспечивают обновления и базовую поддержку. Для VPS желательны базовые знания (настройка ОС, установка ПО), хотя многие провайдеры предлагают помощь. Для выделенного сервера навыки администрирования необходимы, так как вы полностью отвечаете за сервер, хотя провайдеры могут предлагать платное администрирование.

1. Pandas

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

Библиотека строится вокруг двух ключевых структур: Series (одномерный массив с индексами); DataFrame (таблица с индексами и колонками).

Какие задачи решает библиотека

Pandas полезна для следующих задач:

• Сам анализ данных: можно быстро фильтровать, группировать, агрегировать и строить сводные таблицы.
• Очистка данных: удаляем пустые строки, заменяем значения, приводим типы.
• Загрузка данных из CSV, Excel, SQL.
• Визуальная разведка данных (EDA) перед построением моделей.
• Подготовка данных для ML и отчётов.
• Автоматизация отчётов и ETL-пайплайнов.

Благодаря Pandas аналитик превращается в инженера данных, а ML-специалист может сосредоточиться на моделях, а не на ручной подготовке датасетов.

Как пользоваться

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

Почему это меняет карьеру

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

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

Для ML-инженера владеть Pandas — значит уметь готовить датасеты качественно; быстро очищать и приводить данные к нужному виду, что напрямую влияет на результат моделей. Без этого работа над проектами машинного обучения часто превращается в бесконечную возню с данными.

Наконец, даже для разработчиков Pandas может стать неожиданным бустом в карьере. Например, когда нужно автоматизировать отчёты для бизнеса или быстро анализировать логи и данные из БД без поднятия дашбордов — Pandas даёт гибкость и скорость, которые редко даёт что-то ещё в экосистеме Python.

2. Django

Django — фреймворк для веб-разработки на Python, который позволяет быстро создавать надежные и масштабируемые веб-приложения. Он следует принципам DRY (Don’t Repeat Yourself — не повторяй себя), предоставляя разработчику ORM, роутинг, систему авторизации, админку, работу с формами, шаблонами и инструментами безопасности из коробки.

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

Какие задачи решает библиотека

Каркас, действительно, каркасный. Задачи следующие:

• Создание веб-приложений и API любой сложности.
• Быстрая разработка MVP, прототипов и коммерческих проектов.
• Упрощение работы с базами данных через ORM, без написания сырого SQL.
• Построение административных панелей для управления данными без ручной разработки.
• Гибкая маршрутизация и работа с формами, валидацией и шаблонами.
• Реализация аутентификации, авторизации и защиты приложений.

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

Как пользоваться

Устанавливаем:

Создаем проект и приложение:

Пример модели:

Миграция базы данных:

Создание админки:

После этого можно запустить сервер:

И перейти по адресу http://127.0.0.1:8000/admin для управления записями через готовую админ-панель.

3. PyTorch

PyTorch — мощная библиотека Python. Она позволяет строить и обучать нейронные сети, проводить вычисления с автоматическим дифференцированием и работать с GPU для ускорения самих вычислений.

Главное отличие PyTorch от других ML-фреймворков — динамическая вычислительная графика (define-by-run): модель строится и изменяется во время выполнения кода, что даёт гибкость при создании и отладке сложных моделей.

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

Какие задачи решает библиотека

В функционал PyTorch входят:

• Построение нейронных сетей любой сложности (CNN, RNN, трансформеры);
• Обучение и тестирование моделей на CPU и GPU;
• Реализация кастомных слоёв и loss-функций;
• Разработка и деплой ML/AI моделей в продакшен;
• Быстрая итерация гипотез с удобной отладкой.

С PyTorch можно начать с простых нейронных сетей, а затем перейти к реализации современных архитектур.

Как пользоваться

Установим PyTorch (на CPU, для GPU потребуется версия с CUDA):

Рассмотрим кейс обучения простой нейронной сети для классификации рукописных цифр MNIST.

После обучения можно использовать torch.save() для сохранения модели и torch.load() для загрузки в продакшн.

Почему это меняет карьеру

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

Для начинающего ML/AI-специалиста PyTorch помогает лучше понять, как устроены нейронные сети, и под капотом увидеть, как происходят вычисления. Это ускоряет рост навыков и делает разработчика востребованным в исследованиях и R&D-проектах.

Для дата-сайентистов PyTorch позволяет превратить исследовательские ноутбуки в готовые к деплою модели, благодаря PyTorch Lightning, TorchScript и ONNX.

Для разработчиков, которые хотят выйти на рынок AI, PyTorch — это мастхев: проекты в стартапах и крупных компаниях всё чаще строятся вокруг него. Умение писать кастомные loss-функции, проектировать сложные пайплайны обучения, настраивать обучение на кластерах и GPU — компетенции, которые существенно бустят зарплату.

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

4. Polars

Polars — современная библиотека для обработки данных в Python, созданная как альтернатива Pandas. Она использует колоночную архитектуру и многопоточность, что позволяет работать с большими объёмами данных значительно быстрее и с меньшим потреблением памяти.

Polars вдохновлена Pandas, но её API оптимизировано для производительности и удобства, а также даёт разработчику возможность писать цепочки ленивых вычислений, которые оптимизируются перед выполнением. Это делает её отличным инструментом для аналитиков, дата-инженеров и дата-сайентистов, которым нужно обрабатывать данные быстро.

Какие задачи решает библиотека

Polars явно есть, чем гордиться:

• Загрузка, очистка и преобразование больших датасетов;
• Анализ данных с использованием цепочек преобразований;
• Быстрая агрегация и группировка данных;
• Ленивые вычисления: построение пайплайнов преобразования данных, которые выполняются только при вызове collect().
• Обработка данных, которые не помещаются в память, за счёт эффективности и колоночной архитектуры.

Если Pandas начинает притормаживаться на данных в несколько гигабайт, Polars обычно продолжает работать быстро, позволяя без боли обрабатывать большие CSV.

Как пользоваться

Установка:

Давайте загрузим данные и проведем базовые трансформации:

А вот и пример ленивых вычислений:

В чем особенность:

• pl.read_csv загружает данные сразу.
• pl.scan_csv создаёт план вычислений для последующей оптимизации.
• Используются выражения (pl.col, .with_columns, .agg), которые композируются без создания промежуточных копий, это ускоряет процесс.

Почему это меняет карьеру

Polars меняет карьеру, потому что даёт преимущество в скорости и эффективности при работе с данными. Там, где Pandas уже не справляется, полярный медведь приходит на помощь.

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

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

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

5. FastAPI

FastAPI — современный фреймворк для создания API на Python, заточенный под скорость, асинхронность и валидацию данных из коробки. Он построен на Starlette и Pydantic, автоматически создаёт OpenAPI-документацию, поддерживает асинхронное программирование и позволяет писать производительные REST и WebSocket API с минимальным количеством кода.

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

Какие задачи решает

Задач, действительно, много:

• Быстрая разработка REST API для мобильных и веб-приложений;
• Создание бэкенда для ML/DS моделей (деплой моделей в виде API);
• Построение микросервисов с хорошей производительностью;
• Реализация websocket-серверов и асинхронных API;
• Подготовка внутренних инструментов или бэкендов для MVP.

FastAPI помогает быстро запускать API и уверенно масштабировать его в полевых условиях. Это один из немногих фреймворков Python, который по скорости работы сопоставим с Node.js и Go.

Как пользоваться

Во-первых, нужно установить FastAPI и Uvicorn (используем ASGI-сервер для запуска):

Простейший API-пример с эндпоинтом GET /:

Запускаем сам сервер:

После запуска API будет доступен по адресу http://127.0.0.1:8000/. Автоматически доступна интерактивная документация Swagger по адресу http://127.0.0.1:8000/docs.

FastAPI поддерживает валидацию параметров запроса, тел запросов и путей прямо через типы Python. Например, простой эндпоинт с параметром:

При вызове http://127.0.0.1:8000/items/10?q=test FastAPI автоматически проверит, что item_id — это число, и распарсит q как строку.

Почему это меняет карьеру

FastAPI — билет в мир бэкенда, где скорость и чистота кода имеют довольно высокое значение. Для Python-разработчика это возможность быстро освоить создание API и микросервисов, не увязнув в громоздкой настройке, как в Django, и при этом получить систему, готовую к продакшену.

Для ML-специалиста FastAPI становится инструментом для деплоя моделей: можно обернуть пайплайн предсказаний в API, подключить авторизацию или логирование и получить работающий сервис за считанные дни.

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

6. Typer

Typer — современная библиотека для создания CLI-приложений на Python с минимальным количеством кода и автоматической генерацией документации. Автор библиотеки — Себастьян Рамирес, создатель FastAPI.

Главная особенность Typer — использование type hints для автоматического парсинга аргументов командной строки. Вы получаете удобную и читаемую CLI с поддержкой автодополнения и цветного вывода за считанные минуты.

Какие задачи решает библиотека

Список задач такой:

• Создание CLI-утилит любого уровня сложности.
• Быстрое прототипирование и упаковка Python-скриптов в удобные инструменты для продакшена.
• Генерация подробной справки (--help) и автодополнения команд.
• Облегченная поддержка и масштабирование CLI за счёт структуры и читаемого кода.
• Организация CLI с подкомандами, вложенными аргументами и обработкой ошибок.

Typer использует аннотацию типов и минимум шаблонного кода.

Как пользоваться

Установка:

Пример минимальной CLI:

Теперь можно запустить из консоли:

Результат будет такой: Привет, Алиса! Тебе 25 лет.

Почему это меняет карьеру

Typer меняет карьеру тем, что открывает путь к созданию удобных CLI-инструментов, которые автоматизируют рутину и повышают продуктивность.

С Typer можно быстро превращать свои Python-скрипты в надежные утилиты, которыми удобно пользоваться и другим разработчикам, и сотрудникам из других отделов. CLI-приложения часто становятся клеем инфраструктуры: они позволяют автоматизировать деплой, миграции БД, сбор данных, интеграцию с внешними API и локальную разработку.

Если вы Data Scientist или ML-инженер, Typer позволяет оборачивать пайплайны в CLI, которые легко запускать из Jenkins, Airflow или вручную. Если вы DevOps или Backend-инженер, можете создавать CLI для работы с инфраструктурой и сервисами без сложных зависимостей.

Кроме того, работа с Typer улучшает навык структурирования кода, понимание CLI, использования type hints и разработки инструментов, которые делают работу проще для других. А это, очевидно, ценится в любой команде и повышает востребованность специалиста.

7. Rich

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

Rich создана для того, чтобы «оживить» консоль Python, сделать логи удобными для восприятия, а CLI-инструменты — профессионально выглядящими без лишних усилий. Это библиотека, которая улучшает и UX, и DX.

Какие задачи решает

Про красоту не забываем! Задачи следующие:

• Цветное и структурированное логирование, понятное при чтении логов в реальном времени.
• Отображение прогресс-баров для долгих операций.
• Вывод таблиц, деревьев каталогов, JSON прямо в терминале.
• Подсветка синтаксиса кода для CLI-инструментов.
• Создание CLI-интерфейсов, которые выглядят профессионально и современно.
• Улучшение читаемости при отладке скриптов.

С помощью Rich можно быстро сделать понятными даже сложные данные при отладке или демонстрации.

Как пользоваться

Установка Rich:

Для примера выведем таблицу с подсветкой в консоли:

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

Почему это меняет карьеру

Rich — это библиотека, которая помогает быстро повысить качество любого CLI-инструмента или дев-опыт в команде. Разработчик, который использует Rich, делает свои инструменты удобными не только для себя, но и для коллег: логирование становится понятным, а отладка скриптов — наглядной.

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

Кроме того, Rich позволяет быстро создавать CLI-интерфейсы, которые выглядят как продакшен-продукты, даже если это внутренние инструменты. Руководство будет радоваться и думать о вас как о крутом разрабе.

Для дата-инженеров и разработчиков DevOps Rich полезна при создании админ-утилит и при мониторинге пайплайнов, для Python-разработчиков — при создании библиотек и фреймворков с CLI.

8. LangChain

LangChain — фреймворк для создания приложений на базе LLM, например, GPT, Claude, Mistral, Gemini. Он позволяет строить цепочки обработки запросов, интегрировать LLM с данными и инструментами, добавлять память и управление состояниями, а также связывать работу модели с внешними API и базами знаний.

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

Какие задачи решает

Список внушительный:

• Интеграция LLM в Python-приложения без необходимости писать тот самый клеевой код вручную.
• Построение цепочек с последовательной обработкой сообщений, включая преобразования и вызовы внешних функций.
• Добавление памяти в чат-боты для сохранения истории общения и контекста.
• Использование агентов для динамического вызова инструментов (веб-поиск, базы данных, API).
• Создание RAG-систем с интеграцией LLM и векторных БД.
• Быстрая сборка прототипов LLM-приложений, которые можно развернуть в продакшен.

Как пользоваться

Установка:

Создадим простую цепочку с чатом GPT:

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

Почему это меняет карьеру

LangChain меняет карьеру, потому что открывает новый пласт Python-разработки в AI и LLM-инженерии, быстро превращая пользователя GPT в создателя полноценных AI-приложений. Вместо того чтобы писать хаотичный клеевой код, вы начинаете системно проектировать цепочки запросов, учитесь строить продуманные промпты и объединять их с инструментами, памятью и внешними API.

Работа с LangChain погружает в практическую LLM-инженерию: вы начинаете создавать RAG-приложения, которые умеют искать и анализировать данные перед генерацией ответа и строить агентов. Это востребовано в продуктах, где нужно подключать ИИ к базам знаний, автоматизировать задачи и разрабатывать интерактивные системы, которые реально используют модели в продакшене.

LangChain позволяет быстро собирать и запускать MVP AI-продуктов, что дает конкурентное преимущество при создании стартапов или внутренних сервисов. А ещё учит мыслить структурами и проектировать масштабируемую архитектуру LLM-приложений и видеть, как генеративный ИИ можно превратить в рабочий инструмент.

9. SQLAlchemy

SQLAlchemy — это мощная ORM и toolkit для работы с базами данных в Python, позволяющая писать SQL-запросы декларативно, создавать модели таблиц и управлять транзакциями в Python-коде без ручного написания SQL.

Библиотека даёт разработчику два уровня контроля:

• Core: низкоуровневая работа с SQL выражениями и соединениями;
• ORM: высокоуровневая декларативная работа с моделями, классами и связями между таблицами.

SQLAlchemy поддерживает PostgreSQL, MySQL, SQLite, Oracle и другие СУБД, давая единую абстракцию, без привязки к конкретному движку.

Какие задачи решает

Пул задач следующий:

• Описание таблиц в виде Python-классов и управление ими через сессии;
• Создание, чтение, обновление и удаление данных;
• Миграция SQL на декларативный стиль без потери гибкости;
• Полный контроль над транзакциями и выполнением запросов;
• Работа с асинхронными приложениями при создании FastAPI/Django-приложений;
• Экранирование параметров, которое снижает вероятность SQL-инъекций и ошибок.

Как пользоваться

Создадим минимальный пример для SQLite с таблицей пользователей:

Этот код создаёт базу example.db, таблицу users, добавляет туда одного пользователя и выводит всех пользователей в базе. При необходимости можно использовать SQLAlchemy Core для написания гибких запросов вручную, если нужно работать ближе к SQL.

Почему это меняет карьеру

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

Знание SQLAlchemy открывает дорогу в мир API, микросервисов и продуктов, где требуется качественное управление данными и гибкая логика работы с БД. Работа с SQL теперь совсем не страшная.

10. Seaborn

Seaborn — библиотека для визуализации данных на Python, построенная поверх Matplotlib и упрощающая создание информативных и стильных графиков с минимальным количеством кода.

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

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

Какие задачи решает

Визуализация безумно важна, особенно в контексте дата-аналитики. Seaborn отвечает за:

• Быстрое построение информативных графиков для анализа данных и поиска инсайтов;
• Автоматическую обработку ошибок отображения и масштабирования, что экономит время;
• Поддержку сложных визуализаций по типу ящиков с усами или тепловых карт без десятков строк кода;
• Стилизацию графиков без ручных настроек Matplotlib;
• Возможность добавлять статистические элементы (линию регрессии, KDE, распределение);
• Интеграцию с Jupyter Notebook для интерактивного анализа данных.

Как пользоваться

Допустим, у нас есть датасет с данными о чаевых:

В три строки мы получаем чистый и читаемый ящик с усами, показывающий, как счет за ужин распределяется по дням недели.

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

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

Почему это меняет карьеру

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

Использование Seaborn в Python-стеке помогает выделиться среди разработчиков, которые ограничиваются Pandas и текстовыми логами, ведь визуализация часто позволяет быстрее заметить закономерности и убедить команду или заказчика в правильности гипотезы.

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

А какими библиотеками пользуетесь вы? Делитесь в комментариях!

В этом материале вместе со Станиславом Погоржельским, технологическим евангелистом платформы VK Cloud, разберем особенности решений для хранения и работы с большими данными.

Особенности локальных хранилищ

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

Семь «грехов» локальных кластеров

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

Структура данных и хаос

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

Файловая система, не оптимизированная для работы с малыми файлами, быстро забивается inode'ами (переполнение файловых дескрипторов). Системы хранения начинают задыхаться не от общего объема, а от количества объектов, что критически влияет на производительность. Например, известны случаи, когда после миллиона объектов OpenStack Swift начинал терять метаданные, а в хранилищах висели призраки удаленных объектов.

RAID — не универсальное спасение

Настройка RAID-массивов кажется очевидным решением, но не все так однозначно:

• RAID 5 и 6 плохо переносят большие объемы из-за длительного времени восстановления.
• RAID 10 требует удвоения или утроения объема хранения ради скорости и отказоустойчивости.
• На петабайтных объемах пересборка массива после сбоя может занимать больше недели.

Поддержка архивов и ZIP-файлов

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

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

Автоматизация мониторинга и ремонта

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

Шардирование данных: неизбежность и боль

На больших объемах данных (более 250 Тб) приходится шардировать — разбивать на независимые логические части, чтобы сохранить производительность. Но с шардированием есть проблемы:

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

Более того, встроенные механизмы шардирования некоторых популярных СУБД (MongoDB, PostgreSQL с партиционированием) не рассчитаны на миллиарды записей и начинают деградировать.

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

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

Резервное копирование на практике

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

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

Облачные хранилища

С локальными хранилищами разобрались, теперь рассмотрим технические особенности альтернативного решения.

Гибкость и масштабируемость без ограничений

В облаке увеличение объемов хранения происходит мгновенно:

• без ожидания закупки нового оборудования;
• без сложного планирования миграций;
• без перебоев в обслуживании приложений.

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

Финансовая прозрачность и удобная модель оплаты

Модель Pay-As-You-Go (оплата по факту использования) дает бизнесу и разработчикам:

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

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

Надежность и отказоустойчивость «из коробки»

S3-совместимый Object Storage обеспечивает высокую доступность данных благодаря:

• автоматической репликации данных в нескольких географических регионах;
• встроенным механизмам самовосстановления данных;
• резервированию оборудования на уровне дата-центров;
• постоянному мониторингу целостности объектов.

Оптимизация работы с любыми типами данных

Хранилище позволяет одинаково эффективно работать:

• с миллионами мелких файлов (фото, документы, логи);
• с тяжелыми объектами (видео или архивами).

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

Высокий уровень безопасности данных

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

• шифрования на стороне клиента и сервера;
• гибкого управления правами доступа (ACL, IAM);
• соответствия требованиям хранения ПДН и прочих стандартов безопасности;
• автоматического обнаружения потенциальных уязвимостей.

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

Инструменты для разработчиков и автоматизации

Хранение данных в облаке ориентировано на удобство интеграции и масштабирование за счет:

• полного набора API и SDK для популярных языков программирования;
• готовых модулей для работы с данными в распределенных системах;
• продвинутых средств мониторинга, алертинга и автоскейлинга;
• поддержки DevOps практик через IaC-инструменты.

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

Опыт хранения больших данных

Когда речь идет о масштабных системах хранения — таких как S3-совместимый сервис Object Storage на платформе VK Cloud, — производительность определяется не только скоростью сети и дисков. Ключевую роль играют архитектурные особенности приложений: как именно данные распределяются, обрабатываются и индексируются.

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

Как измеряется производительность облачного хранилища

Для реальной оценки производительности облачного хранилища важно замерять:

• Количество операций в секунду (RPS): сколько запросов на чтение/запись способна обработать система.
• Среднюю и 99-ю персентиль задержек: критично для оценки качества обслуживания конечных пользователей.
• Производительность на больших объемах объектов: важно не просто тестировать один файл, а моделировать реальную работу приложений с множеством параллельных операций.
• Влияние мелких и крупных файлов: системы по-разному работают при миллионах маленьких объектов и гигабайтных видео.

Практические сценарии измерений:

• многопоточная загрузка 100 миллионов объектов размером 1–10 КБ;
• массовое чтение миллионов объектов через S3 API;
• удаление больших объемов объектов для оценки работы сборки мусора;
• сценарии с версионированием объектов, чтобы проверить нагрузку на метаданные.

Почему шардирование критически важно для облачного хранилища

Правильная организация шардирования данных — один из ключевых факторов производительности больших хранилищ.

Что происходит без правильного шардирования:

• «Горячие» бакеты (S3-бакеты) с высокой нагрузкой становятся узким местом.
• Распределение нагрузки по серверам становится неравномерным.
• Метаданные начинают тормозить операции доступа.
• Снижается общая масштабируемость системы.

Реальная практика VK Cloud:

• Метаданные объектов распределяются по кластерам через шардирование по диапазонам ключей.
• При превышении нагрузки шард автоматически расщепляется (split) для перераспределения нагрузки между нодами.
• Для хранения метаданных используется Tarantool как высокоскоростная in-memory база данных, способная выдерживать сотни тысяч операций в секунду на один шард.

Такой подход позволяет обеспечить:

• низкие задержки доступа даже при миллиардах объектов;
• линейное масштабирование — добавление новых серверов дает реальный прирост пропускной способности;
• быструю обработку как мелких, так и больших файлов без перегрузки одной ноды.

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

За что мы любим Tarantool

Принцип работы СУБД Tarantool кардинально отличается от классических SQL-баз (PostgreSQL, MySQL) в хранилищах:

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

Как правильно проектировать нагрузку на S3-совместимое облако

Если вы проектируете высоконагруженную систему, важно:

• Использовать естественное шардирование ключей (например, вставлять случайные префиксы в имена объектов).
• Ожидать миллионы объектов в бакете и строить приложения так, чтобы они не зависели от скорости листинга всех файлов.
• Минимизировать количество операций массового удаления объектов — использовать batch-удаление через S3 API.
• Понимать, что работа с метаданными так же важна, как и сама передача данных.

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

Заключение

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

Облачное хранилище обеспечивает:

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

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

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

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

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

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

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

Этот кейс хорошо иллюстрирует дух эпохи: отсутствие готовых безопасных решений заставляло программистов изобретать велосипеды. Многие подобные наработки позже легли в основу ORM-библиотек, но тогда они рождались в муках — через пробелы в безопасности и километры самописного кода.

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

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

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Выбрали путь программиста? Значит навсегда запомните, когда опубликовали первый самописный сайт. Откосить не получится: мы сразу перейдём к практике — к концу статьи у вас будет ссылка на сайт-визитку.

Мало времени? Выделите 10 минут — мы используем только HTML и CSS.

Вы узнаете:

• как подключать стили,
• как верстать блоки,
• как опубликовать сайт.

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

Шаг 1. Подготовим инструменты и папку проекта

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

Новичкам рекомендуем ставить Visual Studio Code (VS Code). Он бесплатный, не тормозит и понимает любой код. Плюс у него огромное сообщество — если нужно установить плагин или увеличить шрифт, ответ на вопрос уже есть в интернете.

Скачайте VS Code с официального сайта.

Как устроен веб-проект

Сайт — это папка с файлами для браузера.

HTML-файл содержит текст и разметку страницы, CSS-файл — правила оформления. Браузер берёт эти два файла и показывает веб-страницу.

Основной файл сайта обычно называют index.html. Стили хранятся в style.css.

Кроме файлов HTML и CSS, в нашем проекте будут папки:

• img — для картинок.
• fonts — для шрифтов.

Создайте на рабочем столе папку с названием сайта, например first-site, и соберите начальную структуру — это займёт 1 минуту.

Шаг 2. Создадим базовую HTML-страницу

В VS Code есть удобная фишка: наберите символ «!» и нажмите Tab. Редактор автоматически создаст базовую структуру HTML-документа.

Как читать структуру:

• <!DOCTYPE html> — сообщает браузеру, что это HTML-документ.
• <html> — корневой элемент, внутри которого живёт страница.
• <head> — служебная информация, которую не видно на странице.
• <body> — то, что увидят пользователи на странице.

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

Добавим контент в <body>:

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

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

Шаг 3. Подключим стили CSS

Сейчас сайт выглядит странно — чёрный текст на белом фоне. Так не пойдёт, добавим стилей в файле style.css.

CSS можно писать внутри HTML или в отдельном файле. Мы выберем второй вариант, потому что это удобнее.

Подключим CSS к HTML. В секции вашего index.html добавьте строчку:

Тег говорит браузеру: «Возьми файл style.css из той же папки и примени все стили к этой странице».

Добавьте в style.css первое правило:

Сохраните оба файла — HTML и CSS. Обновите страницу в браузере.

Фон поменял цвет? Значит, CSS подключён правильно. Можете вернуть белый фон или оставить голубой — далее мы добавим более интересные стили.

Шаг 4. Подключим шрифты

Есть три способа избавиться от дефолтного Times New Roman:

• Google Fonts — бесплатная библиотека шрифтов от Google.
• Локальные файлы — загружаете шрифт на свой сервер.
• Системные шрифты — используете то, что уже есть на компьютере пользователя.

Для первого сайта на HTML и CSS рекомендуем Google Fonts — это просто, быстро и надёжно.

Перейдите на fonts.google.com и выберите шрифт. Популярные варианты: Roboto, Open Sans, Lato, Montserrat. Нажмите на понравившийся шрифт, выберите начертания (тонкий, обычный или жирный), скопируйте код подключения и вставьте в head.

На Google Font собраны популярные шрифты. Если этого мало, нужно скачать шрифт (.woff, .woff2, .ttf) и поместить в папку fonts.

Путь к файлу указывается относительно CSS-файла. Подключаем начертания через @font-face:

Теперь используйте шрифт в CSS:

Для каждого начертания (обычный, жирный, курсив) нужно отдельное правило @font-face.

Шаг 5. Сверстаем блоки

Замените содержимое вашего style.css на этот код:

Что мы делаем:

• Убираем стандартные отступы браузера и задаём голубой фон.
• Центрируем карточку по всей странице с помощью flexbox.
• Создаём белую карточку с тенью и скруглёнными углами.
• Делаем круглый аватар с рамкой.
• Стилизуем текст и кнопку.
• Добавляем эффект при наведении на кнопку.

Шаг 6. Загрузим сайт на хостинг

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

Заходим на сайт хостинга (Beget, Hostiman, InfinityFree) и регистрируемся. После подтверждения email вы попадёте в панель управления. Система предложит выбрать домен — берите бесплатный типа название.fwh.is.

Загружаем файлы на сервер

После создания аккаунта появится доступ к файловому менеджеру. Через веб-интерфейс можно управлять файлами на сервере прямо из браузера. Перейдите в папку htdocs — это корневая директория вашего сайта, куда нужно загружать структуру.

Удалите лишние файлы по типу default.php и загрузите ваши файлы: index.html, style.css, папки img и fonts. Основной index.html должен лежать прямо в htdocs, а не во вложенной папке — иначе сайт не откроется.

Более продвинутый способ — использовать FTP-клиент FileZilla. В панели хостинга найдите FTP-данные и подключитесь через программу. Это удобнее для больших проектов, но для первого сайта веб-менеджера будет достаточно.

Проверяем результат

Через несколько минут после загрузки ваш сайт будет доступен по адресу. Откройте его в браузере — если всё сделано правильно, увидите свою страницу. Если что-то не работает, проверьте, что index.html лежит в корне htdocs, а style.css загружен в ту же папку.

Реальность бесплатного хостинга

Для изучения основ и создания первых проектов на HTML и CSS это отличный вариант. Регистрация занимает 1 минуту, никаких настроек, можно сразу экспериментировать и видеть результат.

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

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

Скрытые ограничения:

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

Когда стоит переходить на платный хостинг

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

Самый простой домен стоит 200-1000 рублей/год, а базовый хостинг — 100-300 рублей/месяц. Плюс получите доступ к технологиям (PHP, MySQL), более стабильную работу и нормальную техподдержку. Начните с минимального тарифа — его хватит на тренировочные проекты, а потом можно масштабироваться.

Куда двигаться дальше?

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

• как работает HTML,
• зачем нужен CSS,
• что такое хостинг и домен.

Следующий шаг — подробнее изучить CSS. Сайт-визитка из примера нормально отображается только на больших экранах. Однако 60% пользователей заходит с телефонов. Изучите медиазапросы, они применяются только на определённых размерах дисплея.

Подробнее про адаптив рассказал старший фронтенд-разработчик Никита Кушнарёв: Если вы умеете покрасить кнопочку, но хотите узнать больше о вёрстке веб-приложений.

Попробуйте переделать карточку так, чтобы она нормально выглядела на телефоне. Уменьшите размеры, измените отступы, сделайте кнопку на всю ширину. Потом изучите Flexbox и CSS Grid — современные способы вёрстки макетов.

Когда почувствуете уверенность в CSS, пора знакомиться с JavaScript. Это язык программирования, который делает сайты интерактивными. Сложные анимации, всплывающие окна, динамическое изменение контента — это JS. Предупреждаем, он сложнее HTML и CSS. В нём есть функции, условия, циклы — всё то, что пугает новичков.

Подробнее про JavaScript: Разработка на JavaScript с нуля: дорожная карта.

Изучайте инструменты разработчика в браузере. Нажмите F12 на любом сайте — откроется интерфейс для просмотра структуры сайта, отладки JS, тестирования адаптива. Смотрите, как устроены другие сайты, изучайте чужой код.

Самое время узнать о большем количестве инструментов программиста. Читайте в нашем тг-канале!

Как работает 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 с репликацией. В случае сбоев отвалятся только отдельные серверы с некоторыми наборами данных. Конечно, здесь тоже, в теории, можно положить весь кластер, включая реплики, но сделать это сложнее.

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

Больше новостей — в нашем тг-канале «Представляешь»

Он просто хотел заменить phpMyAdmin чем-то более безопасным и понятным для клиентов. Сегодня у его проекта — более 30 000 звезд, клиенты из списка Fortune 500 и команда из 50 человек.

10 лет в одиночку

Первые 10 лет инструмент был сугубо личным. Без сообщества, без поддержки, без амбиций. Только PHP, MySQL и Бен. Когда-то он просто поставил на стол счетчик звезд с GitHub — и каждая новая звезда ощущалась как маленькая победа.

10 000 звезд: первая волна

Где-то в 2015 году о проекте начали говорить — в Reddit, Slack, GitHub Explore. К проекту присоединился Рейк ван Зантен, будущий со-основатель.

Вместе они вычистили кучу спагетти-кода, переписали все с PHP на Node и Backbone на Vue. Тогда же их позвали в Сан-Франциско — крупная компания хотела внедрить проект, но испугалась, что за ним стоит всего два человека без юрлица.

20 000 звезд: время становиться бизнесом

Хейнс закрыл имевшееся у него агентство и оформил компанию. Поднял $1 млн, собрал команду, запустил облачный сервис.

Затем, после сотни встреч с инвесторами и обвала венчурного рынка, нашел партнера, который понял ценность OSS. Удалось закрыть $8 млн — и с этого момента встал вопрос устойчивости: как зарабатывать, не предавая open-source?

Ответ — собственная лицензия с бесплатным использованием для всех, кроме корпораций. Работали даже с Брюсом Перенсом, сооснователем OSI.

30 000 звезд: устойчивость

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

И да, недавно они тихо подняли еще $9 млн — на новый архитектурный рефакторинг.

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

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

Шаг 1. Готовимся к миграции

Посмотрите структуру проекта, чтобы выявить слабые места.

Архитектура далека от идеала, если проект вырос на хаотичных добавлениях новых функций.

Проанализируйте:

• Вид проекта. Ваша разработка — это монолит, модульная система, API, микросервис?
• Зависимости. Определите, какие библиотеки использует проект. Совместимы ли они с Laravel?
• Базу данных. Если в БД встречаются дубли, отсутствуют ограничения, это нужно исправить заранее.

В качестве теста на совместимость перепишите небольшую часть на Laravel. Возьмите один простой модуль и посмотрите, насколько это жизнеспособно.

Стратегии перехода

Выберем стратегию перехода:

• Big Bang,
• Поэтапный перенос.

Стратегия Big Bang — это полная остановка текущего проекта и создание новой версии на Ларавел с нуля.

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

Из минусов — высокие риски. Во время разработки текущая версия может растерять пользователей. К тому же сроки реализации могут затянуться.

Стратегия с постепенным переходом выглядит надежнее.

Система продолжает работать, а вы поэтапно меняете ее «под капотом».

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

Выбор подхода зависит от проекта

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

Проект напоминает спагетти-код? Плохие новости — Big Bang неизбежен.

Шаг 2. Разворачиваем новое окружение на Laravel

Чтобы установить фреймворк, выполните команду:

Прежде чем работать с кодом, настроим окружение.

В корне проекта для этого есть файл конфигурации .env:

• APP_NAME: имя приложения, чтобы оно отображалось в логах и заголовках.
• APP_URL: адрес, на котором приложение будет доступно (например, http://localhost).

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

Подключение БД

Laravel использует Eloquent ORM для взаимодействия с базой.

Настройка БД выполняется в том же разделе .env:

Для тестирования подключения запустите команду:

Настройка маршрутов

Маршруты изначально хранятся в файлах routes/web.php (для страниц) или routes/api.php (для REST API).

В качестве примера добавим базовый маршрут приветствия:

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

Шаг 3. Переносим модели данных и бизнес-логики

Eloquent ORM работает с классами, представляющими таблицы в базе данных.

Чтобы перенести существующую таблицу, нужно создать модель:

Этот класс автоматически подключается к таблице с именем products.

Когда название таблицы не соответствует модели, это можно указать явно:

Если в таблице есть нестандартные поля (например, столбцы с именами вроде created_time вместо created_at), их тоже можно легко обработать:

Переносим схему БД

Laravel использует механизм миграций для управления таблицами в базе и сиды для внесения данных.

Перенос структуры БД выполняется командой:

Миграция создается в папке database/migrations.

Переносим данные

Если текущая БД уже содержит данные, их можно перенести через сиды: файлы, которые заполняют таблицы данными.

Создаем сид:

Внутри метода run описываем данные:

Переводим бизнес-логику в сервисы и фасады

Старый проект состоит из функционала, размазанного по контроллерам? Улучшим структуру и сделаем код независимым. С этим помогут сервисы и фасады.

Сервисы — это классы, которые объединяют бизнес-логику в одном месте.

Например, если проект выполняет расчеты цен и скидок, можно создать класс:

В этом классе описана бизнес-логика:

Теперь сервис можно вызывать в контроллерах и моделях.

Фасады — это статический интерфейс к сервисам, который делает вызовы более читаемыми.

Например:

С фасадом вызов становится простым:

Шаг 4. Перенос маршрутов и контроллеров

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

Если в старом проекте использовались API-запросы для работы с внешними сервисами или мобильными приложениями, перенесем их в api.php и добавим префикс api для маршрутов:

Теперь про контроллеры. Они отвечают за логику обработки запросов и взаимодействие с моделями. В Laravel контроллеры работают по правилам MVC (Model-View-Controller).

Пример обычного метода контроллера:

Laravel определяет маршруты групповыми методами — по префиксам, middleware или зонам авторизации.

Middleware — это посредники, которые обрабатывают запросы до их поступления в приложение.

Навесим middleware на маршруты, требующие авторизации пользователя:

Политики контролируют доступ к определенным ресурсам, например, правку или удаление записей.

Пример метода политики:

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

Шаг 5. Перенос фронтенда и представлений

Если ваш старый проект использует обычные HTML-файлы, они легко преобразуются в Blade.

Blade — это встроенный механизм шаблонов. С его помощью создают пользовательские интерфейсы.

Например, перенесем главную страницу сайта:

Blade-версия:

Теперь можно динамически передавать данные из контроллера:

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

Интегрируем Vue.js или React

Vue.js/React подключают, когда нужен динамичный и интерактивный интерфейс. Например, для SPA, реалтайм-функционала, сложных форм или фильтров.

Blade и JavaScript можно комбинировать: используйте Blade для рендеринга начального интерфейса и Vue.js/React для обработки интерактива.

Динамический интерфейс без JS

Livewire — это инструмент для создания интерфейсов без необходимости обращаться к внешним библиотекам JavaScript. Преимущество в том, что весь код пишется на PHP.

Livewire пригодится для динамических форм, фильтрации таблиц, уведомлений. Он упрощает код, сохраняя гибкость.

Шаг 6. Оптимизируем и тестируем проект

Отправная точка улучшения производительности — работа с Blade-шаблонами. Laravel сам их оптимизирует, но есть практики по дополнительному ускорению:

• Минимизация логики в представлении. Злоупотребление PHP внутри Blade замедляет рендеринг страниц. Вместо описания сложной логики в шаблонах ее лучше перенести в контроллер.
• Кэширование шаблонов. Работу приложения можно ускорить за счет запуска кэширования всех шаблонов, сокращая время компиляции — «php artisan view:cache».
• Переиспользование. Если фронтенд состоит из повторяющихся фрагментов, рекомендуется использовать Blade-компоненты.

В приложениях SPA оптимизируем фрагменты JavaScript.

Laravel Mix генерирует минифицированные CSS и JS. Проверьте размер этих файлов в папке public/js. Если их вес больше 1 МБ:

• Удалите лишние пакеты.
• Используйте динамическую загрузку маршрутов или компонентов.

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

Тестирование

Убедимся, что приложение работает корректно.

Проверим, например, что страница приветствия открывается и показывает нужный текст:

Если используете Vue.js или React, для проверки компонентов применяйте Jest или Mocha.

Тест, который проверяет, что компонент отобразил нужный текст:

Если приложение работает с API:

Для проверки приложения под нагрузкой можно использовать Artillery или JMeter.

Шаг 7. Разворачиваем и запускаем проект

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

Выбор сервера зависит от предпочтений и нагрузок:

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

Фоновые задачи можно связать с Supervisor. Инструмент автоматически запускает воркеров при сбоях, обеспечивая бесперебойную обработку задач.

Автоматизация развертывания

Чтобы релиз прошел безболезненно, нужен рабочий процесс CI/CD. Например, в GitHub Actions можно настроить сценарий, который:

1. Проверит качество кода.
2. Установит зависимости.
3. Выполнит миграции.
4. Зальет проект на сервер.

Предусмотрите откат, например, через Spatie Laravel Backup. Если что-то пойдет не так, у вас должна быть возможность вернуть предыдущую версию.

Инструмент Sentry поможет отслеживать ошибки, а New Relic — оценивать производительность.

Заключение

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

Структура данных: реляционные таблицы 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 — второй, для более сложных сценариев.

В какой-то момент наши коллеги, отвечающие за качество данных, обратили внимание на Great Expectations (GX). Библиотека многообещающая: умеет валидировать, профилировать и даже составлять документацию автоматически. Однако есть одно «но»: Impala, наш основной SQL-движок для Hadoop, официально не поддерживается.

Мы решили схитрить и пустить данные через pandas DataFrame — инструмент, с которым GX ладит отлично. Тестовые прогонки показали обнадеживающие результаты, но когда дело дошло до настоящих объемов, стало ясно: DataFrame справляется с 15 000 строк за раз, а дальше — дробление, тормоза, потеря части функционала. Итог: сутки на обработку вместо минут, которые нужны Impala.

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

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

Примечание: в статье описана работа с GX версии 0.17.19. Вышли новые релизы, но общий подход и логика решений остались прежними.

Настройка проекта: подключаем Impala и кастомные проверки

Подключение к базе данных

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

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

Добавляем кастомные проверки

Теперь пришло время интегрировать собственные проверки. К сожалению, GX не предоставляет прямого механизма подключения проверок из произвольных папок — в документации указаны лишь способы через plugins или GitHub. Однако решение оказалось довольно простым:

1. Создаем папку для пользовательских проверок в директории с основным кодом GX;
2. Подключаем нужные проверки в коде, указав путь к ним:

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

Основные проблемы, с которыми мы столкнулись

Проблема №1: Регулярные выражения

Первым камнем преткновения стала попытка использовать проверки на регулярные выражения — expect_column_values_to_match_regex. При запуске на Impala они попросту не срабатывали, так как некоторые выражения Regex не поддерживались для этого диалекта.

Ошибки выглядели так:

У нас было два пути:

1. Сделать pull request с изменениями в библиотеку GX. Но это означало бы долгое ожидание и, вероятно, последующие сложности с обновлениями версии в банковской инфраструктуре.
2. Создать свою собственную проверку, игнорируя диалект и подгоняя регулярные выражения под Impala. Именно этот путь мы и выбрали.

Решение

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

В файле expect_column_values_to_match_regex_impala подключаем файл с проверкой:

Главное — заменить все названия проверок на свои.

Далее копируем еще один файл в свою директорию, меняем его название. В самом файле модифицируем переменные condition_metric_name и regex_expression. Метод SQLAlchemy использует функцию get_dialect_regex_expression, которая вызывает ошибку диалекта, так как Impala не входит в поддерживаемые базы данных. Поэтому мы отключаем вызов этой функции и формируем наше регулярное выражение (переменная regex_expression) под Impala, взяв за основу выражение из MySQL:

Теперь формируем условие регулярного выражения с помощью класса BinaryExpression из SQLAlchemy, где:

• column — проверяемая колонка
• sqlalchemy.literal(regex) — регулярное выражение
• sqlalchemy.custom_op("REGEXP") — оператор

После выполнения этого выражения получается строка вида table_nm REGEXP '%abv', в которой:

• table_nm — колонка
• REGEXP — оператор
• '%abv' — регулярное выражение

Важно! Не забудьте добавить подключение BinaryExpression. Используйте literal(regex). Именно literal — без него не отработает.

Проблема №2: Зарезервированные слова

В процессе работы GX на Impala мы столкнулись с синтаксическими ошибками. Как оказалось, причина заключалась в том, что GX, при формировании запросов к базе данных, использует зарезервированные в Impala слова. Эти слова не могут быть использованы в качестве идентификаторов в базе данных. Вот примеры ошибок:

Решение

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

В случае с типом NUMERIC достаточно просто заменить его на INTEGER, который как раз и предложен в ошибке в качестве корректного варианта.

Вот пример изменений в коде:

Было:

Стало:

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

Проблема №3: Подзапросы в Impala

Следующая трудность, с которой мы столкнулись, касалась использования подзапросов. При работе с некоторыми проверками GX (например, ExpectColumnValuesToBeUnique) мы сталкивались с ошибкой:

Дело в том, что GX использует вложенные подзапросы в разделе SELECT, которые запрещены в Impala.

Решение

Эту проблему можно обойти, если вынести не поддерживаемый Impala подзапрос в отдельный запрос и его результат подставить в основной подзапрос.

За основу мы взяли запрос из переменной unexpected_condition в файле map_condition_auxilliary_methods.py, вывели его через print и с помощью методов конструктора запросов SqlAlchemy сформировали такой же запрос в поддерживаемом Impala формате.

Вот как выглядит исходный запрос:

Из этого запроса нужно выделить подзапрос, который Impala не может обработать:

С помощью метода SqlAlchemy этот запрос будет выглядеть так:

После выполнения мы получаем результат (назовем его условно result_impala) и подставляем в окончательный запрос:

Последовательность замены файлов

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

1. Заменяем наименование проверок (чтобы они отличались от стандартных вариантов в GX) в подключении и классах: great_expectations/expectations/core/expect_column_values_to_be_unique.py
2. Меняем только подключение в следующем файле: great_expectations/expectations/metrics/column_map_metrics/column_values_unique.py
3. Выполняем изменения здесь: great_expectations/expecttions/metrics/map_metric_provider/column_map_metric_provider.py
4. Также изменяем этот файл: great_expectations/expectations/metrics/map_metric_provider/map_metric_provider.py
5. И, наконец, меняем файл, как описано в разделе «Проблема №1: Регулярные выражения»: great_expectations/expectations/metrics/map_metric_provider/ map_condition_auxilliary_methods.py

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

Это не шутка. Именно такую сумму заплатила американская сеть казино 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, чтобы защитить сервер от ошибок и предотвратить его аварийное завершение работы.

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

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

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

Frontend фреймворки

React

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

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

React обращается к DOM только для обновления изменившихся компонентов. За счет этого повышается производительность приложения.

Пример простого React компонента:

Преимущества фреймворка:

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

Недостатки фреймворка:

• Концепции JSX и управления состоянием могут быть сложны для новичков;
• Плохая кроссбраузерная поддержка;
• Требует дополнительных библиотек для маршрутизации и управления состоянием.

Vue.js

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

Преимущество Vue в его простоте и низком пороге входа. При этом фреймворк сохраняет статус мощного инструмента для разработки сложных веб-приложений.

Vue автоматически отслеживает зависимости между блоками и обновляет DOM при их изменении, как React.

Компонентная архитектура Vue позволяет разбивать UI на переиспользуемые части. Разметка, стили и логика разделяются «оболочкой», а это облегчает поддержку и масштабирование приложения.

Пример простого компонента Vue:

Экосистема Vue включает множество библиотек и плагинов, расширяющих возможности фреймворка. Например, Vuex для управления состоянием, Vue Router, Nuxt.js и другие.

Преимущества фреймворка:

• Понятный синтаксис и подробная документация;
• Может использоваться как библиотека или цельный фреймворк в зависимости от проекта;
• Есть поддержка серверного рендера;
• Автоматически обновляет интерфейс при изменении данных;
• Имеет небольшой вес файлов.

Недостатки фреймворка:

• Меньше ресурсов и сторонних библиотек по сравнению с React и Angular;
• Неполная документация на русском языке.

Angular

С помощью Angular разрабатывают клиентские части веб-приложений. Этот фреймворк сложнее Vue и React.

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

По аналогии с Vue и React, фреймворк разбивает приложение на независимые, переиспользуемые блоки кода. Компоненты: шаблон; класс, описывающий поведение; стили.

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

Пример простого Angular-компонента:

Преимущества фреймворка:

• Богатый выбор инструментов, шаблонов, которые сокращают сроки реализации сложных приложений;
• Angular CLI расширяется за счет shematics, поэтому его легко доработать под конкретные задачи;
• Есть поддержка TypeScript: статическая типизация улучшает качество кода;
• Встроенная утилита для обновления проекта при переходе на новую версию Angular.

Недостатки фреймворка:

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

Backend фреймворки

Django (Python)

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

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

Django следует архитектурному шаблону Model-View-Controller (MVC). Модели определяют структуру данных, представления обрабатывают логику и взаимодействие с моделями, а шаблоны отвечают за представление данных пользователю.

Сильная сторона Django — его ORM (Object-Relational Mapping). Интерфейс для работы с базой данных на Python используется для написания сырых SQL-запросов. Django поддерживает PostgreSQL, MySQL, SQLite, Oracle.

Если ищете универсальный фреймворк для бэкенд-разработки на Python, Django определенно заслуживает вашего внимания.

Пример модели Django:

В примере определяем модель Article с полями title, content и published_at. Метод __str__ возвращает строковое представление объекта:

Представление article_list получает объекты Article из базы данных и передает их в шаблон для отображения.

Преимущества фреймворка:

• Широкий набор инструментов: включает ORM, аутентификацию и админ-панель;
• Фреймворк задаёт структуру проекта — помогает разработчикам понимать, как и где добавлять новую функцию;
• Защищен от SQL-инъекции и подделки межсайтовых запросов;
• Подходит для высоконагруженных приложений.

Недостатки фреймворка:

• Django ORM уступает последней SQLAlchemy.

Ruby on Rails (Ruby)

Rails подходит для быстрого прототипирования и проектов, ориентированных на работу с базами данных. Его используют для SaaS-платформ, CRM-систем, CMS, маркетплейсов и многого другого.

Rails применяет архитектурный паттерн MVC (Model-View-Controller). Фреймворк хорош с точки зрения бизнес-логики и взаимодействует с базой данных с помощью ActiveRecord ORM.

Rails поставляется со встроенными инструментами и библиотеками. Например, ActiveRecord для работы с базами данных, ActiveStorage для управления файлами, ActionMailer для отправки email.

В сообществе Rails огромное количество гемов (библиотек), расширяющих функциональность фреймворка.

Пример модели Rails (с использованием ActiveRecord):

Пример контроллера Rails:

В примере определяем модель Article с валидациями и связями. Контроллер ArticlesController содержит экшены для списка статей, отображения отдельной статьи, создания новой статьи. Приватный метод article_params используется для фильтрации параметров.

Преимущества фреймворка:

• Продуманная структура, которая продвигает стандарты качества и лучшие практики веб-разработки;
• Active Record ORM упрощает взаимодействие с базой данных;
• Vue, Angular.js и React легко интегрируются с Ruby on Rails.

Недостатки фреймворка:

• Ruby on Rails js медленнее Django и Node.js.

Node.js с Express (JavaScript)

Express — фреймворк Node.js с набором функций для разработки веб-приложений и API. В нем реализован простой интерфейс для HTTP-запросов и маршрутизации.

Node.js + Express используется для сервисов, серверных приложений (например, чатов или игр).

Преимущество Node.js и Express состоит в возможности писать на JavaScript как клиентскую, так и серверную сторону. Можно вести разработку на одном языке и делиться кодом с фронтендом и бэкендом.

Пример простого приложения на Express:

Преимущества фреймворка:

• JavaScript на всем стеке — один язык для фронтенда и бэкенда;
• Имеет минимальные ограничения, можно строить архитектуру как удобно.

Недостатки фреймворка:

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

Full-Stack фреймворки

Laravel (PHP)

Laravel — фреймворк для веб-разработки на PHP. Он использует архитектуру MVC: разделяет логику приложения и улучшает организацию кода.

Laravel выбирают для разработки CMS, SaaS-платформ, электронной коммерции и др. Встроенные библиотеки ускоряют работу.

В фреймворке реализована:

• Система миграций для управления структурой базы данных;
• Eloquent ORM для работы с данными;
• Система шаблонизации Blade;
• Встроенная поддержка аутентификации и авторизации;
• Очередь заданий и планировщик для выполнения асинхронных задач.

Пример определения маршрута в Laravel:

Пример контроллера Laravel:

Пример модели Eloquent:

В примерах выше определяем маршрут, который принимает id и возвращает строку с идентификатором. Контроллер UserController методом show получает пользователя из базы данных по id и передает его в представление user.profile. Модель User представляет таблицу пользователей в базе данных и определяет заполняемые атрибуты.

Преимущества фреймворка:

• Шаблонизатор Blade упрощает создание представлений;
• ORM Eloquent облегчает работу с базами данных;
• Есть автоматизация задач с помощью встроенных инструментов и командной строки.

Недостатки:

• Сложности с долгосрочной поддержкой версий.

Spring Boot (Java)

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

Фреймворк имеет встроенный контейнер сервлетов (Tomcat, Jetty), чтобы запускать приложение как автономный JAR-файл без развертывания на внешнем сервере.

Фреймворк также предлагает:

• Автоконфигурацию библиотек (JPA, JDBC);
• Встроенные метрики мониторинга;
• Поддержку внешней конфигурации;
• Интеграцию с базами данных.

Преимущества фреймворка:

• Есть встроенные серверы Tomcat, Jetty и Undertow;
• Облегчает управление зависимостями с помощью стартовых пакетов;
• Оснащен встроенным контейнером сервлетов;
• Автоматическая конфигурация экономит время на старте проекта.

Недостатки:

• Spring Boot создает множество неиспользуемых зависимостей и увеличивает размер файла развертывания.

Meteor (JavaScript)

Особенность Meteor в том, что он синхронизирует данные в реальном времени. Фреймворк автоматически обновляет пользовательский интерфейс при изменении данных на сервере. Это возможно благодаря протоколу DDP (Distributed Data Protocol) и реактивным источникам данных, таких как MongoDB.

На JS + Meteor можно писать код, который работает как на клиенте, так и на сервере. Фреймворк также предоставляет интегрированную систему сборки, которая автоматически объединяет ресурсы приложения.

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

Преимущества фреймворка:

• Архитектура и синтаксис с понятным кодом упрощают обучение новичков и повышают производительность команды;
• Есть мгновенная синхронизация данных между клиентом и сервером;
• Возможна интеграция базы данных MongoDB.

Недостатки фреймворка:

• Не предлагает широкого функционала для масштабирования и разделения логики на модули;
• Сложности с масштабированием при увеличении числа пользователей из-за обработки данных в реальном времени.

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

Использование индексов для ускорения запросов

Индексы — это важный инструмент для оптимизации SQL-запросов, который позволяет значительно ускорить поиск данных и снизить нагрузку на базу. Они работают как указатель, который направляет СУБД к нужным строкам вместо того, чтобы сканировать всю таблицу. Оптимизация SQL-запросов с помощью индексов позволяет повысить производительность и сократить время выполнения сложных выборок.

Что такое индексы и как они работают?

Индекс — это дополнительная структура данных, созданная на основе столбцов таблицы. При добавлении индекса СУБД организует данные таким образом, чтобы ускорить операции чтения. Основной принцип работы индексов заключается в упрощении поиска с помощью упорядоченных структур, по типу B-деревьев.

1. SHOW DATABASES - "Покажи мне все свои хранилища"

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

Пример ниже (и все следующие) с сайта sqlize.online

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

2. SHOW TABLES - "Покажи, что у тебя есть"

Когда вы хотите узнать, какие таблицы существуют в определенной базе данных, просто используйте SHOW TABLES. Это похоже на просмотр содержимого папки на компьютере. Для того что бы получить список таблиц в нужной нам базе перед выполнением команды SHOW нужно выполнить USE dbname;

Таким образом мы получили список таблиц.

3. SHOW COLUMNS - "Что у тебя внутри?"

Если вам интересно, какие столбцы есть в таблице, просто воспользуйтесь SHOW COLUMNS. Так вы узнаете, какие данные вы можете там найти. Данная команда используется вместе с названием исследуемой таблицы следующим образом:

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

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

4. SHOW INDEX - "Покажи мне твои секретные индексы"

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

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

5. SHOW CREATE TABLE - "Покажи, как создать это"

Хотите узнать, как создать определенную таблицу? Просто используйте SHOW CREATE TABLE, и MySQL покажет вам SQL-запрос для создания таблицы.

Очень удобная штука! Таким образом вы видите всю структуру в компактном виде. Это удобно для сравнения структуры таблиц например на тестовом сервере и на боевом. Так же эта команда не заменив если кто-то просит вас показать DDL таблиц. Одна команда и всё готово. Кстати если вам нужно поделиться с коллегой вы можете воспользоваться сайтом sqlize.online - наберите или скопируйте свой SQL код, нажмите кнопку RUN чтобы код был выполнен системой, а затем кнопку SHARE, чтобы получить в буфер обмена короткую ссылку на ваш код. После этого любой, кто получит ссылку, сможет продолжить работать с вашим кодом!

В дополнение к SHOW CREATE TABLE вы можете использовать

то есть получить код создания любого объекта в базе данных

6. SHOW TABLE STATUS - "Сколько у тебя строк?"

Наконец, SHOW TABLE STATUS позволяет вам получить различную информацию о таблице, такую как количество строк или размер таблицы. Это полезно для оценки производительности и размера таблиц.

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

7. SHOW GRANTS - "Кто имеет доступ?"

С помощью SHOW GRANTS можно узнать привилегии, предоставленные пользователям в MySQL. Это полезно для проверки безопасности и доступа к данным.

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

8. SHOW MASTER / REPLICA STATUS - "Эй! Кто отстаёт?"

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

8. SHOW [GLOBAL] VARIABLES - "Покажи настройки"

Данная команда позволяет увидеть параметры конфигурации базы данных. Если вам нужно выбрать только нужные из большого списка - отфильтруйте их при помощи LIKE как в примере ниже:

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

• SHOW ERRORS - показывает список ошибок.
• SHOW ENGINE STATUS - статус движка базы данных - позволяет увидеть DEAD LOCKS

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

Один парень из моего чата в Telegram спросил меня: «Как я могу увидеть все внешние ключи, связанные с определенной таблицей?» Я дал ему быстрый ответ: «Посмотрите в `information_schema`». Я был полностью уверен в ответе, но всё равно решил убедиться лишний раз.

Я создал простую таблицу `test` и таблицу `ref1` с полем `test_id`, связанным с полем id:

Кажется, просто, потому что я люблю этот короткий синтаксис. После этого я посмотрел на таблицу информационной схемы `REFERENTIAL_CONSTRAINTS` и не нашел никаких записей.

Что за?! Это невероятно! Я люблю этот краткий синтаксис для создания внешних ключей и использовал его много раз!

Я создал еще одну связанную таблицу `ref2` используя стандартный синтаксис.

Снова проверил. И чудо свершилось! Я увидел запись в таблице `REFERENTIAL_CONSTRAINTS`. Как это возможно?

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

Теперь я думал, что если я попробую удалить первую строку из `test` то получу ошибку (я все еще сохраняю надежду на лучшее).

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

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

И получаю долгожданную ошибку:

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

Я поискал в Google и нашел открытую ошибку с 2004 года, которую до сих пор не исправили. Ребята, что вы делаете?

Для своего душевного спокойствия я решил запустить этот тест на других базах данных и обнаружил, что все базы данных, на которых я мог проверить на SQLize.online, позволяют использовать короткий синтаксис, и все они (MariaDB, PostgreSQL, SQL Server, Oracle) создают ограничения внешнего ключа в обоих случаях, кроме MySQL и SQLite.

Если Вам понравилась статья, Вы можете поддержать автора.

Установка Prisma ORM в новом проекте

По большей части я буду использовать официальную документацию.

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

Добавим конфигурацию для TypeScript компилятора в tsconfig.json файл.

Установим Prisma ORM

Инициализация Prisma ORM для базы данных MySQL.

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

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

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

Простые запросы к базе данных

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

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

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

Использование «сырых» запросов

Теперь давайте достанем из базы первые 10 уникальных имен аккаунтов.

Код выглядит довольно просто. Но нас ожидает сюрприз в логах. SQL запрос к базе данных выглядит следующим образом:

Как вы видите, в этом запросе не используются лимиты, прописанные в запросе. Это потому, что Prisma не использует `DISTINCT` в запросах и фильтрует данные в памяти. Это крайне сомнительное решение. Оно будет работать когда в базе есть несколько тысяч записей, но перестанет если там будет несколько миллионов. Да и вообще крайне странно доставать из базы миллион записей для того, чтобы отфильтровать первые 10 уникальных имен.

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

Полученный SQL запрос:

На первый взгляд код из этого примера выглядит как классический пример из книги «Как сделать SQL инъекцию». Но на самом деле это не так. Под капотом Prisma делает немного магии, которая позволяет избежать уязвимостей.

Результат следующего кода это не просто строка с подставленными в нее значениями переменных. Prisma генерирует объект с запросом и параметрами этого запроса.

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

«Сырые» небезопасные запросы

Представьте себе ситуацию, в которой вам нужно фильтровать данные по полям из JSON объекта `meta`. При этом, то, по каким полям производить фильтрацию тоже определяется на уровне кода.

Полученный запрос работать не будет. В этом случае эта магия, которая работает под капотом `Prisma.sql` не позволит нам просто взять и собрать запрос из нескольких строк.

Поэтому пришло время для использования `$queryRawUnsafe`. Мы все еще будем использовать параметры в запросе для значений JSON полей и лимитов

Полученный SQL:

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

Выводы

В целом Prisma ORM — это неплохой выбор для проекта. Можно подчеркнуть, что не хватает возможности на уровне построителя запросов сделать `distinct`, но при этом достаточно просто двинуться в сторону «сырых» запросов к базе данных.

Подготовка окружения

Перед работой убедитесь, что у вас установлена актуальная версия werf из стабильной ветки. В случае, если вы еще не устанавливали werf, сделайте это по официальной инструкции.

Инструкции из статьи полностью совместимы и тестировались на операционной системе Linux Ubuntu 20.04.03. Для ОС других семейств, таких как macOS или Windows, могут быть отличия. Подробнее с ними можно ознакомиться в официальной документации к werf.

Также убедитесь, что у на вашем компьютере запущен кластер minikube, в котором подготовлено пространство имён werf-first-app. Если вы уже выполняли инструкции из первой статьи, то достаточно только запустить кластер следующей командой:

А затем установить пространство имён по умолчанию:

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

Подключение базы данных

Доработка приложения

На текущий момент у нас есть stateless-приложение, то есть оно не использует БД и не хранит в ней никаких данных. В реальности такое случается нечасто, поэтому давайте доработаем его до stateful, добавив поддержку MySQL.

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

1. Добавим зависимости, необходимые для взаимодействия с MySQL.
2. Настроим конфигурацию для соединения с БД.
3. Создадим миграцию и модель схемы БД.
4. Создадим маршруты в приложении, по которым будет происходить сохранение и чтение данных.

Установим зависимости, требуемые для работы с БД:

Здесь мы добавили следующие пакеты:

• sequelize — ORM, обеспечивающий работы с БД;
• mysql2 — драйвер MySQL;
• express-async-handler — расширение контроллеров запросов, позволяющее работать с async/await;
• sequelize-cli — утилита, позволяющая генерировать миграции и модели.

Чтобы sequelize мог работать, мы создали для него конфигурационный файл .sequelizerc, в котором задали параметры подключения к БД, а также структуру файлов самого sequelize. Все директории, имеющие отношение в БД, мы определили в каталог db, а конигурацию в файл config/database.json.

Добавление endpoint’ов

Чтобы убедиться, что приложение и правда умеет обращаться к БД, добавим ему пару новых endpoint’ов — /remember и /say — первый будет записывать данные в БД, а другой извлекать и показывать. В каталоге routes добавим файл talkers.js:

Сгенерируем модель и миграцию БД с помощью команды:

Модель можно посмотреть в файле db/models/talker.js:

Также автоматически была сгенерирована миграция для новой модели, расположенная в файле db/migrations/20211101064002-create-talker.js:

Осталось создать новые маршруты в файле app.js:

Приложение подготовлено и готово к запуску!

Разворачиваем MySQL

В реальных условиях БД можно поднять как внутри кластера Kubernetes, так и за его пределами. При использовании внешней базы доступны различные варианты: от собственной базы, развернутой на своей инстраструктуре, до managed-решений наподобие Amazon RDS.

В качестве примера с нашим приложением мы развернем базу данных MySQL внутри кластера, воспользовавшись типом ресурсов StatefulSet. Для этого создадим файл .helm/templates/database.yaml со следующими параметрами:

Теперь настроим наше приложение на подключение к созданной БД. Стоит отметить, что Sequelize ожидает определения подключения для всех окружений в единственном файле — config/database.json. Пропишем в нем нужные параметры:

Инициализация БД

Развернуть MySQL — это еще половина дела. Далее следует ее правильно инициализировать, проведя нужные миграции и дождавшись ее готовности к работе.

В Kubernetes есть несколько проверенных способов для развертывания и инициализации базы данных. Один из них — использование отдельной Job’ы одновременно с разввертыванием основного приложения. В ней будут выполнять все необходимые для инициализации действия.

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

• Job’а должна убедиться, что база доступна, и только затем выполнить миграции;
• приложение ожидает перед запуском следующего, что:

1. БД доступна;,
2. БД подготовлена и готова к работе;,
3. миграции выполнены.

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

1. Поднимается БД;
2. Выполнятся миграции и инициализация с помощью Job’ы.
3. Стартанут приложения..

Приступим к реализации. Для начала добавим Job (.helm/templates/job-db-setup-and-migrate.yaml), которая будет заниматься инициализацией и миграциями БД:

Следует пояснить, почему мы ожидаем целых десять проверок БД. Если этого не сделать, то mysqladmin ping выполнится всего один раз перед тем, как StatefusSet с MySQL начнет перезапускаться при деплое. При этом база данные окажется недоступна.

Дополнительно следует обратить внимание, что при первом запуске основной процесс MySQL может перезапуститься несколько раз без перезапуска самого контейнера. Это может привести к ситуации, когда БД ушла в перезапуск, а Job’а уже начала выполнять миграции. Последние при этом само собой будут неудачными, и весь процесс разворачивания закончится ошибкой.

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

В Deployment’е также необходимо внести изменения, добавив проверку доступности БД перед тем, как стартовать приложение:

Все готово, можно запускать.

Проверка работоспособности

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

Мы должны увидеть примерно следующее:

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

Проверим, что все работает как нужно. Попробуем обратиться на /say:

Так как в базе данных пока ничего нет, мы увидим ответ:

Добавим туда данные, воспользовавшись /remember:

Если все прошло успешно, получим ответ:

Еще раз прочитаем данные из БД:

Ожидаемый результат в случае успеха:

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

Мы должны увидеть табличку с нашим текстом:

Все работает! Наше приложение стало stateful. Подобный подход к взаимодействию с базами данных аналогичен с любыми другими БД, не только с MySQL.

Заключение

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

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

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

Ждем вас в комментариях к статье, а также в Telegram-каналe werf_ru. Мы всегда рады оказать вам любое содействие на этом трудном пути. Также не забывайте про GitHub-репозиторий werf, там всегда будут рады любым issues (и звездам).

Обратите внимание, что в примерах используется MySQL, поэтому в конце каждого оператора ставится точка с запятой. Если вы только начинаете знакомство с реляционными базами данных, также рекомендуем наш материал «Основы PostgreSQL для начинающих». Эта статья — часть нашего полного путеводителя по SQL.

Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.

Настройка базы данных

Перед началом создайте БД с тестовыми данными. Для работы вам понадобится скачать два файла: DLL.sql и InsertStatements.sql. После установите MySQL, откройте терминал и войдите в консоль MySQL с помощью команды:

Затем введите пароль и выполните следующую команду. Назовём базу данных «university»:

SHOW DATABASES

SQL-команда, которая отвечает за просмотр доступных баз данных.

CREATE DATABASE

Команда для создания новой базы данных.

USE

С помощью этой SQL-команды USE <database_name> выбирается база данных, необходимая для дальнейшей работы с ней.

SOURCE

А SOURCE <file.sql> позволит выполнить сразу несколько SQL-команд, содержащихся в файле с расширением .sql.

DROP DATABASE

Стандартная SQL-команда для удаления целой базы данных.

SHOW TABLES

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

CREATE TABLE

SQL-команда для создания новой таблицы:

Ограничения целостности при использовании CREATE TABLE

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

• ячейка таблицы не может иметь значение NULL;
• первичный ключ — PRIMARY KEY(col_name1, col_name2, …);
• внешний ключ — FOREIGN KEY(col_namex1, …, col_namexn) REFERENCES table_name(col_namex1, …, col_namexn).

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

Пример

Создайте таблицу «instructor»:

DESCRIBE

С помощью DESCRIBE <table_name> можно просмотреть различные сведения (тип значений, является ключом или нет) о столбцах таблицы.

INSERT

Команда INSERT INTO <table_name> в SQL отвечает за добавление данных в таблицу:

При добавлении данных в каждый столбец таблицы не требуется указывать названия столбцов.

UPDATE

SQL-команда для обновления данных таблицы:

DELETE

SQL-команда DELETE FROM <table_name> используется для удаления данных из таблицы.

DROP TABLE

А так можно удалить всю таблицу целиком.

SELECT

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

Следующей командой можно вывести все данные из таблицы:

SELECT DISTINCT

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

WHERE

Можно использовать ключевое слово WHERE в SELECT для указания условий в запросе:

В запросе можно задавать следующие условия:

• сравнение текста;
• сравнение численных значений;
• логические операции AND (и), OR (или) и NOT (отрицание).

Пример

Попробуйте выполнить следующие команды. Обратите внимание на условия, заданные в WHERE:

GROUP BY

Оператор GROUP BY часто используется с агрегатными функциями, такими как COUNT, MAX, MIN, SUM и AVG, для группировки выходных значений. Следующий шаг после базовых команд — оконные функции.

Пример

Выведем количество курсов для каждого факультета:

HAVING

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

Пример

Выведем список факультетов, у которых более одного курса:

ORDER BY

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

Пример

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

BETWEEN

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

Пример

Выведем список инструкторов, чья зарплата больше 50 000, но меньше 100 000:

LIKE

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

Есть два свободных оператора, которые используются в LIKE:

• % (ни одного, один или несколько символов);
• _ (один символ).

Пример

Выведем список курсов, в имени которых содержится «to», и список курсов, название которых начинается с «CS-»:

IN

С помощью IN можно указать несколько значений для оператора WHERE:

Пример

Выведем список студентов с направлений Comp. Sci., Physics и Elec. Eng.:

JOIN

JOIN используется для связи двух или более таблиц с помощью общих атрибутов внутри них. На изображении ниже показаны различные способы объединения в SQL. Обратите внимание на разницу между левым внешним объединением и правым внешним объединением:

Пример

Выведем список всех обязательных курсов и детали о них:

VIEW

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

Создание

Удаление

Агрегатные функции

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

• COUNT(col_name) — возвращает количество строк;
• SUM(col_name) — возвращает сумму значений в данном столбце;
• AVG(col_name) — возвращает среднее значение данного столбца;
• MIN(col_name) — возвращает наименьшее значение данного столбца;
• MAX(col_name) — возвращает наибольшее значение данного столбца.

Вложенные подзапросы

Вложенные подзапросы — это SQL-запросы, которые включают выражения SELECT, FROM и WHERE, вложенные в другой запрос.

Пример

Найдём курсы, которые преподавались осенью 2009 и весной 2010 годов:

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

Чем отличается WHERE от HAVING в SQL?

WHERE фильтрует отдельные строки до группировки и не может работать с агрегатными функциями. HAVING применяется после GROUP BY и позволяет задавать условия для агрегированных значений, например HAVING COUNT(*) > 5. На практике WHERE отсекает ненужные данные на раннем этапе, а HAVING фильтрует уже сгруппированные результаты.

Какие SQL-команды нужно знать джуниору?

Минимальный набор для начинающего разработчика: SELECT, INSERT, UPDATE, DELETE, WHERE, JOIN, GROUP BY и ORDER BY. Этого достаточно для большинства повседневных задач. По мере роста стоит освоить подзапросы, оконные функции и индексы — дорожная карта изучения SQL до уровня middle поможет выстроить план обучения.

В чём разница между INNER JOIN и LEFT JOIN?

INNER JOIN возвращает только те строки, которые имеют совпадения в обеих таблицах. LEFT JOIN возвращает все строки из левой таблицы и совпадающие строки из правой; если совпадения нет, правая часть заполняется значениями NULL. Выбирайте LEFT JOIN, когда нужно сохранить все записи из основной таблицы, даже если связанных данных нет.

Как оптимизировать медленные SQL-запросы?

Начните с анализа плана выполнения через EXPLAIN — он покажет, какие операции занимают больше всего времени. Добавьте индексы на столбцы, используемые в WHERE, JOIN и ORDER BY — подробнее об этом в статье SQL-индексы за 10 минут. Избегайте SELECT *, выбирайте только нужные столбцы и используйте LIMIT для ограничения результатов. Готовитесь к собеседованию? 27 типовых вопросов по SQL.

Вопросы по 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-запросов. Также полезно понимать, какие навыки ожидают от разработчика на каждом грейде. Оконные функции часто спрашивают — разбор с примерами.

Инструмент за несколько минут запускает кластер баз данных на любом из трёх движков. Нужно только выбрать движок, тарифный план в зависимости от потребностей проекта и дата-центр. Если потребности изменятся, можно будет изменить и тарифный план.

Managed Databases сам ежедневно делает бэкапы, они хранятся по семь дней. Безопасность передачи данных обеспечивает оконечное шифрование. Все базы работают в пределах приватной сети. Можно даже полностью запретить запросы к ним из публичной части Интернета, а разрешить — лишь для нескольких источников из «белого списка».

Инструмент поддерживает MySQL версии 8, Redis версии 5 и PostgreSQL версий 10 и 11.

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

Не удаётся подключиться к локальному серверу

Одной из распространённых ошибок подключения клиента к серверу является «ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)».

Эта ошибка означает, что на хосте не запущен сервер MySQL (mysqld) или вы указали неправильное имя файла сокета Unix или порт TCP/IP при попытке подключения.

Убедитесь, что сервер работает. Проверьте процесс с именем mysqld на хосте сервера, используя команды ps или grep, как показано ниже.

Если эти команды не показывают выходных данных, то сервер БД не работает. Поэтому клиент не может подключиться к нему. Чтобы запустить сервер, выполните команду systemctl.

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

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

Если сервер работает (как показано) и вы по-прежнему видите эту ошибку, вам следует проверить, не заблокирован ли порт TCP/IP брандмауэром или любой другой службой блокировки портов.

Для поиска порта, который прослушивается сервером, используйте команду netstat.

Не удаётся подключиться к серверу MySQL

Ещё одна похожая и часто встречающаяся ошибка подключения — «(2003) Can’t connect to MySQL server on ‘server’ (10061)». Это означает, что в сетевом соединении было отказано.

Следует проверить, работает ли в системе сервер MySQL (смотрите выше) и на тот ли порт вы подключаетесь (как найти порт, можно посмотреть выше).

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

Ошибки запрета доступа в MySQL

В MySQL учётная запись (УЗ) определяется именем пользователя и клиентским хостом, с которого пользователь может подключиться. УЗ может также иметь данные для аутентификации (например, пароль).

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

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

Увидеть разрешённые привилегии учётной записи можно, выполнив в консоли команду SHOW GRANTS
Входим в консоль (пример для Unix, для Windows консоль можно найти в стартовом меню):

В консоли вводим команду:

Дать привилегии конкретному пользователю в БД по IP-адресу можно, используя следующие команды:

Ошибки запрещённого доступа могут также возникнуть из-за проблем с подключением к MySQL (см. выше).

Потеря соединения с сервером MySQL

С этой ошибкой можно столкнуться по одной из следующих причин:

• плохое сетевое соединение;
• истекло время ожидания соединения;
• размер BLOB  больше, чем max_allowed_packet.

В первом случае убедитесь, что у вас стабильное сетевое подключение (особенно, если подключаетесь удалённо).

Если проблема с тайм-аутом соединения (особенно при первоначальном соединении MySQL с сервером), увеличьте значение параметра connect_timeout.

В случае с размером BLOB нужно установить более высокое значение для max_allowed_packet в файле конфигурации /etc/my.cnf в разделах [mysqld] или [client] как показано ниже.

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

Слишком много подключений

Эта ошибка означает, что все доступные соединения используются клиентскими программами. Количество соединений (по умолчанию 151) контролируется системной переменной max_connections. Устранить проблему можно, увеличив значение переменной в файле конфигурации /etc/my.cnf.

Недостаточно памяти

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

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

• если клиент MySQL используется напрямую, запустите его с ключом --quick switch, чтобы отключить кешированные результаты;
• если вы используете драйвер MyODBC, пользовательский интерфейс (UI) имеет расширенную вкладку с опциями. Отметьте галочкой «Do not cache result» (не кешировать результат).

Также может помочь MySQL Tuner. Это полезный скрипт, который подключается к работающему серверу MySQL и даёт рекомендации по настройке для более высокой производительности.

MySQL продолжает «падать»

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

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

Чтобы узнать время безотказной работы сервера, запустите команду mysqladmin.

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

Или

Заключение

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

• Первый и самый важный шаг — просмотреть журналы MySQL, которые хранятся в каталоге /var/log/mysql/. Вы можете использовать утилиты командной строки вроде tail для чтения файлов журнала.
• Если служба MySQL не запускается, проверьте её состояние с помощью systemctl. Или используйте команду journalctl (с флагом -xe) в systemd.
• Вы также можете проверить файл системного журнала (например, /var/log/messages) на предмет обнаружения ошибок.
• Попробуйте использовать такие инструменты, как Mytop, glances, top, ps или htop, чтобы проверить, какая программа использует весь ресурс процессора или блокирует машину. Они также помогут определить нехватку памяти, дискового пространства, файловых дескрипторов или какого-либо другого важного ресурса.
• Если проблема в каком-либо процессе, можно попытаться его принудительно остановить, а затем запустить (при необходимости).
• Если вы уверены, что проблемы именно на стороне сервера, можете выполнить команды: mysqladmin -u root ping или mysqladmin -u root processlist, чтобы получить от него ответ.
• Если при подключении проблема не связана с сервером, проверьте, нормально ли работает клиент. Попробуйте получить какие-либо его выходные данные для устранения неполадок.

Что нового?

Система управления базами данных MySQL 8.0 оснащена:

• поддержкой Emoji;
• MySQL Document Store, упраздняющей необходимость в создании отдельной NoSQL-таблицы для смешанных приложений:

• оконными функциями SQL;
• поддержкой рекурсивных и нерекурсивных Common Table Expressions (CTE), позволяющими использовать временные именованные результирующие наборы, задаваемые при помощи оператора WITH:

• поддержкой NOWAIT и SKIP LOCKED, которые можно использовать для управления поведением при наличии блокировок в момент выполнения выражений SELECT ... FOR SHARE и SELECT ... FOR UPDATE;
• поддержкой нисходящих индексов;
• функцией GROUPING(), отделяющей полученные после агрегирования строк при GROUP BY с использованием ROLLUP значения NULL от NULL в обычных сгруппированных строках.

JSON

Особо выделяются нововведения, реализованные в рамках работы с форматом JSON:

• расширенный синтаксис для задания диапазонов (например, SELECT JSON_EXTRACT('[1, 2, 3, 4, 5]', '$[1 to 3]'); в качестве результата выдаст [2, 3, 4]);
• табличные функции JSON для манипулирования данными этого формата напрямую через SQL;
• функции агрегирования JSON_ARRAYAGG() для генерации JSON-массивов и JSON_OBJECTAGG() для генерации JSON-объектов;
• функции слияния JSON, позволяющие удалять дубликаты в пользу второго документа (например,JSON_MERGE('{"a":1,"b":2 }','{"a":3,"c":4 }'); вернёт {"a":3,"b":2,"c":4}.
• улучшенная сортировка с помощью переменных сортировочных ключей, решающая задачу до 18 раз быстрее предыдущей версии инструмента.

Отмечается, что MySQL 8.0 работает до 2 раз быстрее MySQL 5.7.

Более подробно с техническими деталями обновлённой СУБД можно ознакомиться в официальной документации. MySQL 8.0 доступна для скачивания на Windows, macOS и популярные дистрибутивы Linux.

Бессерверная Aurora

Особенность новой системы Amazon Aurora Serverless состоит в том, что хранилище данных отделено от процесса их обработки. Пользователи этого сервиса платят только за обработку данных, когда база данных реально занята какой-то работой. Разумеется, оплату за хранение данных никто не отменял, но стоит это относительно дёшево.

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

Когда можно пользоваться?

Amazon Web Services планирует перевести Aurora Serverless из демонстрационного в рабочий режим за два этапа: в первой половине 2018 года — с функциональностью MySQL, и до конца будущего года — PostgreSQL. Получить же доступ к превью-версии можно уже сегодня. Достаточно подать заявку на сайте AWS.

Другие анонсы от Amazon

Отметим также, что на re:Invent компания Amazon представила сервис для перевода в режиме реального времени Translate и сообщила о запуске инстансов i3.metal с прямым доступом к «железу». Помимо этого, было анонсировано, что компания предоставит клиентам AWS доступ к своим внутренним системам машинного обучения.

Функции, включённые в MySQL 8.0

• Поддержка Unicode 9.0 из коробки;
• Оконные функции и рекурсивный синтаксис SQL для запросов, которые ранее были невозможны или трудны для написания;
• Расширенная нативная поддержка данных из JSON-файлов и функциональности документоориентированных систем.

Поддержка Unicode 9.0

MySQL 8.0 больше не поддерживает latin1 в качестве кодировки по умолчанию. Рекомендуемым набором символов в новой версии является utf8mb4, который быстрее устаревшего utf8mb3 и поддерживает более гибкие правила сравнения символов. utf8mb4 также чувствителен к регистру.

Оконные функции

Многие другие реализации языка SQL поддерживают оконные функции — способ выполнить вычисления одновременно по нескольким строкам, сохраняя при этом доступ к каждой из строк отдельно. Похожее можно было сделать в MySQL и без оконных функций, однако более медленным и громоздким способом. MySQL 8.0 добавляет оконные функции c использованием ключевого слова OVER, которые по своей сущности похожи на уже используемые в PostgreSQL.

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

JSON-файлы и документоориентированные базы

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

Ещё одним улучшением, связанным с JSON, является появившаяся возможность MySQL хранить данные в документоориентированных базах. Чтение и запись из таких хранилищ являются транзакционно последовательными, что позволяет выполнять откаты данных JSON при необходимости. Географические данные, хранимые в формате GeoJSON, могут быть проиндексированы, что позволяет производить поиск по близости координат.

Другие ключевые функции MySQL 8.0

• Дополнительные параметры обработки заблокированных строк при помощи ключевых слов SKIP LOCKED и NOWAIT. SKIP LOCKED позволяет пропускать заблокированные строки во время операций, NOWAIT выдаст ошибку доступа при встрече заблокированной строки;
• MySQL автоматически масштабируется до объёма доступной памяти, чтобы наилучшим образом использовать виртуальные машины;
• Индексы можно вручную исключить из оптимизатора запросов при помощи функции «невидимый индекс». Индексы, отмеченные как невидимые, постоянно обновляются с изменениями в таблицах, но не используются для оптимизации запросов.

Ожидаемая дата релиза

MySQL до сих пор не анонсировала точную дату выхода общедоступной версии 8.0, но поскольку политика компании придерживается правила «новая общедоступная версия каждые 18–24 месяца», то стоит ожидать релиз в октябре 2017 года. Напомним, что версия 5.7 стала доступна в октябре 2015 года.

Установка

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

Почему Node.js и MySQL?

MySQL будет использоваться для хранения информации из Trace — инструмента Node.js для отладки и мониторинга производительности.

Выбор пал на MySQL, потому что на момент принятия решения Postgres не очень хорошо обновлял строки и обновление неизменяемых данных было бы неоправданно сложным. К сожалению, эти решения не соответствуют требованиям ACID, что затрудняет их использование.

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

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

Если имеются номинальные значения, каждое из которых имеет множество связанных данных, например, у каждого из пользователей есть множество продуктов, а пользователей довольно много — пожалуй, наиболее оптимальным будет создание отдельных таблиц с именем  <user_id>_<entity_name> для каждой из сущностей. Таким образом можно значительно уменьшить размер конкретной таблицы.

Кроме того, если не разделить пользователей по таблицам, очистка данных пользователя в случае удаления учетной записи будет являться операцией с постоянной временной сложностью алгоритма O(1), когда время выполнения не зависит от размера обрабатываемых данных. Это очень важно, потому что, если нужно удалить большое количество значений из больших таблиц, MySQL может решить использовать неверный индекс или вообще не использовать индексы. Если не создавать отдельных таблиц для каждой сущности, вы не сможете использовать подсказки для DELETE, чтобы указать MySQL, какие именно индексы нужно обрабатывать. Вы также можете захотеть использовать ALTER для таблицы, чтобы удалить данные, но это приведет к копированию каждой строки в новую таблицу, что не является рациональным при использовании одной большой таблицы для всех пользователей.

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

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

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

Секционирование таблиц с помощью MySQL

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

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

В коде нет ничего необычного до PARTITION BY RANGE.

В MySQL таблицы можно разделить на RANGE, LIST, COLUMN, HASH и KEY, о которых можно прочитать в документации. Стоит обратить внимание, что ключ секционирования должен быть частью первичного ключа или любых уникальных индексов.

Все, что начинается с <date>, должно быть понятным. Каждый раздел содержит значения, для которых столбец created_at меньше даты следующего дня. Это также означает, что from20120414 содержит все данные, которые старше 2012-04-15, так что этот раздел будет удален при выполнении очистки.

Разделы start и future нуждаются в некотором разъяснении: future содержит данные для дат, которые еще не включены в правила секционирования. Если невозможно выполнить секционирование вовремя, все данные, поступившие 2017-05-17 и позже, будут в этом разделе, и мы ничего не потеряем. Раздел start является неким защитным механизмом. Ожидается, что все строки имеют значение DATETIME created_at, однако нужно подготовиться к возможным ошибкам. Если по какой-то причине в строке в этом поле будет NULL, она окажется в разделеstart. Это укажет нам на ошибки, и, значит, нужно разбираться.

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

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

• кэш запросов не поддерживается;
• внешние ключи не поддерживаются для секционированных таблиц InnoDB;
• секционированные таблицы не поддерживают индексы или поисковые запросы FULLTEXT.

Ограничений гораздо больше, это лишь основные.

Если нужно создать новый раздел, то необходимо реорганизовать существующий и разбить его в соответствии с потребностями:

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

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

Пример секционирования при помощи Node.js и MySQL

Рассмотрим практическое решение. Для примера здесь используется knex — инструмент запросов для JavaScript. Для тех, кто знаком с SQL, понимание кода не составит труда.

Сначала создадим таблицу:

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

Первая строка:

MAX_DATA_RETENTION - 2 = 5 создает последовательность от 5 до -2 (последнее число не входит в последовательность) → [ 5, 4, 3, 2, 1, 0, -1 ], после этого вычитаются  значения из текущего времени и создается раздел today и его предел tomorrow. Порядок очень важен, поскольку MySQL выдаст ошибку, если значения для разделения находятся не в возрастающем порядке.

Пример удаления больших масштабов данных при помощи MySQL и Node.js

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

Первый метод, removeExpired, получает список текущих разделов, затем передает его в repartition.

Сначала выбираются все существующие в настоящее время разделы из таблицы information_schema.partitions, которая управляется MySQL.

Затем создаются все разделы, которые должны существовать для таблицы. Если A — это множество разделов, которые существуют, а B — множество разделов, которые должны существовать, тогда:

partitionsToBeCreated = B \ A

partitionsToBeDropped = A \ B

getPartitionsThatShouldExist creates set B.

Создание объектов разделов очень похоже на создание выражения CREATE TABLE ... PARTITION BY RANGE. Также важно проверить, является ли раздел, который будет создан, старше текущего самого старого раздела, ведь со временем может понадобиться изменить dataRetention.

Пример одного из возможных сценариев:

Пользователи могут хранить данные в течение 7 дней, но также существует возможность расширить этот диапазон до 10 дней. Сначала у пользователя есть разделы, которые охватывают дни в следующем порядке: [ start, -7, -6, -5, -4, -3, -2, -1, future ]. Вскоре пользователь решает увеличить срок хранения данных. Отсутствующие разделы в этом случае: [ -10, -9, -8, 0 ].При очистке текущий скрипт попытается реорганизовать раздел future для отсутствующих разделов, добавляя их после текущих.Создание дополнительных разделов, которые старше 7 дней, не имеет смысла, потому что эти данные будут заброшены так далеко, что это создаст список разделов, который выглядит так: [ start, -7, -6, -5, -4, -3, -2, -1, -10, -9, -8, 0, future ]. Непоследовательно возрастающий список приведет к ошибке MySQL, и вся операция завершится неудачей.

Функция MySQL TO_DAYS(date) вычисляет количество дней, прошедших с 1 января 2000 года, поэтому мы повторяем это в JavaScript.

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

Здесь просто выполняется код для создания новых разделов.

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

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

Также необходимо удалить устаревшие разделы.

Этот код создает тот же самый ALTER TABLE ... DROP PARTITION, который был показан выше.

И, наконец, все готово к реорганизации.

Заключение

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

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

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

Советуем также прочитать нашу статью о том, как избегать ошибок при работе с MySQL.

В чем заключаются действия хакеров

Суть атаки хакеров заключается в копировании данных с серверов жертв и их последующем удалении. За восстановление данных злоумышленники требуют оплату в размере 0,2 биткоина (около 13,5 тысяч рублей на момент написания статьи). Согласно исследованию компании GuardiCore, для атаки применяется брутфорс (полный перебор паролей) MySQL-серверов, к которым можно получить доступ через Сеть. Сообщается, что иногда хакеры не делают предварительный дамп данных, поэтому жертва в общем случае не имеет никаких гарантий.

Для привлечения внимания жертвы хакеры обычно создают таблицу с названием WARNING в существующей схеме на сервере или создают новую схему с названием PLEASE_READ. Используется примерно следующий код:

Считается, что атаки начались 12 февраля на территории Нидерландов (IP 109.236.88.20) и продлились 30 часов, в течение которых хакерам удалось получить доступ к БД жертв. Использование хакерами различных тактик значительно усложняет поиск связей между атаками на сервера разных СУБД, однако их общая природа наталкивает на мысль, что действует одна и та же группа.

Куда деньги на лечение скидывать?

Для вымогания средств и приема платежей хакеры используют сайт в домене .onion. На момент написания статьи сайт все еще действует.

Известно, что на указанные на этом сайте биткоин-счета уже поступило суммарно 10 платежей.

Мораль

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

Инструкция написана для следующей конфигурации: Ubuntu 16.04, Python 3.5.2, Django 1.10.4.

1. Установка сервера и консольного клиента MySQL:$ sudo apt-get install mysql-server mysql-clientВ процессе установки сервера перед вами появится окошко с предложением задать пароль для root-пользователя MySQL.
2. Создание базы данных для работы веб-приложения Django:$ mysql -u root -pВы перейдете в консольный клиент MySQL. Введите пароль root-пользователя, заданный в диалоговом окне на предыдущем шаге. В консольном клиенте введите следующую команду:mysql> CREATE DATABASE 'someapp' DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;Замените «someapp» на название вашего приложения в Django. Задание CHARACTER SET необходимо для корректной работы Django с базой данных.
3. Создание отдельного пользователя для Django в MySQL:mysql> CREATE USER 'django'@'localhost' IDENTIFIED BY 'password';mysql> GRANT ALL PRIVILEGES ON 'someapp'.* TO 'django'@'localhost';mysql> FLUSH PRIVILEGES;Укажите свой пароль вместо «password» и название своего приложения вместо «someapp». Второй и третьей командой пользователю django выдаются права на созданную ранее таблицу.
4. Нажмите Ctrl-D для выхода из консольного клиента MySQL.
5. Установка библиотек и пакетов, необходимых для работы с MySQL из Python:$ sudo apt-get install python3-dev libmysqlclient-dev build-essential$ pip install mysqlclientОбратите внимание, что mysqlclient является форком официального драйвера MySQLdb, но мы используем первый, потому что он поддерживает Python 3. На момент написания статьи MySQLdb не поддерживает третью версию языка.
6. Создание дампа данных:$ python manage.py dumpdata --indent=2 --exclude=contenttypes > datadump.jsonПри выполнении этой команды все еще используется SQLite БД — именно из нее выгружаются данные.
7. Изменение настроек проекта на использование MySQL:# инструкция с официального сайта djangoproject.com# settings.pyDATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'OPTIONS': { 'read_default_file': '/path/to/my.cnf', }, }}# my.cnf[client]database = someappuser = djangopassword = PASSWORDdefault-character-set = utf8Замените «someapp» на название созданной вами для приложения базы данных. Также обратите внимание, что вам необходимо задать корректный путь к файлу в первом фрагменте кода.
8. Проведите миграции в Django и загрузите данные:$ python manage.py makemigrations$ python manage.py migrate$ python manage.py loaddata datadump.json

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

Что за уязвимость?

Уязвимость позволяет запустить стороннюю библиотеку с root-правами, а для её эксплуатации необходим доступ к СУБД с возможностью выполнять операции SELECT и FILE. Эта уязвимость получила код CVE-2016-6662. После её исправления Давид пообещал сообщить о ещё одной уязвимости (которая должна получить код CVE-2016-6663), которая позволяет делать то же самое, но уже без прав FILE.

Самое главное — патчи уже есть?

Да, патчи уже есть: 5.5.52, 5.6.33 and 5.7.15.

Отлично. А как это работает?

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

После чего в файле /etc/my.conf появятся строки:

И при следующем запуске MySQL указанная библиотека будет запущена от имени суперпользователя. Заметим, что в целом идея атак через правку my.conf не нова. Так, например, в 2003 году в выпуске 3.23.55 уже исправлялась эксплуатация через SELECT * INFO OUTFILE '/var/lib/mysql/my.cnf'. Упоминание этого можно найти в описании обновления одного сервиса.

И что, уже даже есть готовый эксплойт?

Да, есть. Однако, он не содержит эксплуатации части обнаруженных Давидом уязвимостей, которые позволили бы проводить атаку без прав FILE, не имея доступа к записи в my.conf.

Но это же не полноценная уязвимость, а лишь возможность злоупотребить правами

Да, многие придерживаются такой же точки зрения. Тем не менее, права на выполнение запроса SELECT и на запуск исполняемого файла с root-правами — сильно разные вещи, и возможность такого «злоупотребления» должна быть устранена. Заметим, что уже сейчас есть возможность не перезаписывать существующий конфигурационный файл в директории, права на работу с которой есть только у root’а, а создать новый в папке /var/lib/mysql, права на запись в которую (естественно) есть у пользователя mysql по умолчанию.

Каким образом исправили уязвимость?

Теперь для mysql_safe аргумент --malloc-lib должен принадлежать к одной из следующих директорий: /usr/lib, /usr/lib64, /usr/lib/i386-linux-gnu или /usr/lib/x86_64-linux-gnu. Опции --mysqld и --mysqld-version могут теперь применяться только к запуску из командной строки, и не могу быть описаны в конфигурационных файлах. Кроме этого, файлы с расширениями .ini или .cnf теперь не могут быть использованы для записи функциями логирования.

Общее

• Под каждую отдельную базу данных желательно создавать отдельного пользователя.
• Кодировка базы может быть любой, если она UTF-8.
• В большинстве случаев лучше использовать движок InnoDB.
• В PHP лучше забыть про сильно устаревшее расширение MySQL и по возможности использовать PDO или MySQLi.
• Без особой нужды не стоит открывать MySQL наружу. Лучше сделать проброс портов:ssh -fNL LOCAL_PORT:localhost:3306 REMOTE_USER@REMOTE_HOST
• Используйте подсказки от PROCEDURE ANALYSE(), который анализирует структуру вашей таблицы и дает советы по оптимизации. Следует заметить, что это возможно только при наличии реальных данных в таблице, так как анализ происходит на их основе.
• Лучше перейти на MariaDB и забыть про MySQL.

Поиск и запросы

• Если при обращении к таблице вам нужна одна-единственная строка, то используйте LIMIT 1. Использование LIMIT 1 будет оптимальнее, так как база данных остановит выборку записей сразу же после нахождения строки вместо того, чтобы выбирать всю таблицу или индекс.$r = mysql_query("SELECT * FROM user WHERE state = 'Alabama' LIMIT 1");if (mysql_num_rows($r) > 0) { ... }
• Помимо обычного индекса строк, вы можете проиндексировать любые столбцы в таблице. Это даст прирост производительности при поиске.
• Не используйте ORDER BY RAND(). Если вам действительно нужен случайный порядок строк в запросе, то есть много различных способов сделать это иначе. Вам нужно будет написать дополнительный код, однако вы избавитесь от слабого места в производительности. ORDER BY RAND() экспоненциально замедляется при росте базы данных.
• Избегайте использования SELECT *. Чем больше данных считывается из таблицы, тем медленнее запрос, что, в свою очередь, увеличивает время работы с хранилищем данных. Также, если сервер БД установлен отдельно от web-сервера, то будет большая задержка при передаче данных по сети. Лучше делать следующим образом:$r = mysql_query("SELECT username FROM user WHERE user_id = 1");$d = mysql_fetch_assoc($r);echo «Welcome {$d['username']}»;

Работа с данными

• Если система 32-битная, то нет смысла ставить свойство UNSIGNED для типа INTEGER, так как такие большие числа в PHP не поддерживаются. Но если вы используете 64-битную систему, то в этом случае PHP поддерживает большие числа, вплоть до BIGINT со знаком.
• Связанные таблицы «Foreign keys» должны иметь сходство по структуре ключей.
• Для хранения булевых значений лучше всего использовать TINYINT(1).
• Денежные единицы лучше всего хранить в целых числах и работать только с целыми числами. Например, числом копеек, чтобы 100 означало один рубль.

Работа со строками

• Лучшая кодировка для большинства баз данных — UTF-8.
• Тип TEXT вмещает в себя только 64 Кб. Для того, чтобы вместить более объемные тексты, нужно использовать LONGTEXT.
• В версиях MySQL до 5.0.3 VARCHAR была ограничена 255 символами, однако в более старших версиях ограничением является 65535 символов.

Работа с датами

• При сравнении DATETIME и TIMESTAMP не забывайте делать преобразование типов:SELECT * FROM table WHERE `datetime` = DATE(`timestamp`)
• Так как TIMESTAMP хранится в виде UNIX_TIMESTAMP, есть возможность выставить автоматическое обновление колонки.
• Типы данных DATE, TIME, DATETIME выводятся в виде строк, поэтому поиск и сравнение различных дат происходит через преобразование.

Работа с перечислениями

• Для перечислений правильно использовать тип ENUM. Это очень быстрый и компактный тип поля, в котором значения хранятся как в TINYINT, но отображаются как в строковом поле.
• Как и для любой строки, для перечислений можно ставить значение по умолчанию.
• Поле с перечислением хранится как число, поэтому скорость работы довольно высокая.

Работа с бэкапами

Лучше использовать бэкап с дополнительными опциями -Q, -c, -e:

• -Q оборачивает имена обратными кавычками.
• -c делает полную вставку, включая имена колонок.
• -e делает расширенную вставку.

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

Отладка

• Если запросы работают медленно, то можно попробовать включить лог для медленных запросов в /etc/mysql/my.cnf, а потом оптимизировать запросы через EXPLAIN.
• Чтобы наблюдать как за запросами, так и в целом за работой сервера, удобно использовать программу Mytop.

Ключевые выводы:
— JDBC API позволяет подключаться к MySQL из Java через стандартную библиотеку без сторонних фреймворков
— Для подключения достаточно драйвера mysql-connector-java в CLASSPATH и строки соединения jdbc:mysql://host:port/db
— Всегда закрывайте Connection, Statement и ResultSet в finally-блоке или используйте try-with-resources
— Для чтения данных используйте executeQuery(), для записи — executeUpdate()
— В боевом коде заменяйте Statement на PreparedStatement для защиты от SQL-инъекций

Кстати, если вы ищете хорошую книгу по использованию JDBC, обратите внимание на Practical Database Programming with Java (Ying Bai). Это относительно новая книга, и в ней рассматриваются две самые популярные базы данных: Oracle и SQL Server 2008. В книге используется IDE NetBeans для примеров и описываются все инструменты, необходимые для работы с базами данных в Java. Это отличная книга для начинающих и опытных программистов.

Подключаем базу данных MySQL с помощью JDBC

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

1. Строка подключения JDBC (например:
   jdbc:mysql://localhost:3306/test).
2. Имя пользователя (root).
3. Пароль (root).
4. База данных с некоторым количеством таблиц для примера (например, база данных книг).

Строка подключения для MySQL начинается с jdbc:mysql. Это название протокола соединения, за которым следуют хост и порт подключения, на которых запущена база данных. В нашем случае это localhost с портом по умолчанию 3306 (если вы его не поменяли при установке). Следующая часть — test — имя базы данных, которая уже существует в MySQL. Мы можем создать таблицу Books:

и наполнить её хорошими книгами:

Программа на Java для работы с базой данных

Теперь давайте напишем программу на Java, которая будет подключаться к нашей базе данных, запущенной на localhost. Важно помнить о том, что необходимо закрывать соединение, запросы и результат выполнения после завершения работы с ними. Также важно закрывать их в finally-блоке, со своей try/catch оберткой, поскольку сам метод close() может кинуть исключение, что приведет к утечке ресурсов. За подробной информацией вы можете обратиться к этой статье. Кроме того, вы можете использовать обертку try-with-resource, которая появилась в Java 7. Более того, это стандартный способ работы с ресурсами в Java 1.7.

При первом запуске у вас, возможно, будет ошибка No suitable driver found for jdbc:mysql, если драйвера MySQL нет в CLASSPATH:

Добавим нужный JAR-файл в путь и снова запустим программу. Другая частая ошибка — указать таблицу в строке соединения: jdbc:mysql://localhost:3306/test/book. В этом случае вылетит следущее исключение:

Успешный запуск программы выведет на экран следующее:

Результат верный, поскольку у нас в таблице только две книги: Effective Java и Java Concurrency in Practice.

Кстати, если у вас был драйвер при компиляции, но отсутствует при запуске, вы получите исключение java.lang.ClassNotFoundException: com.mysql.jdbc.Driver. О том, как исправить эту ошибку, вы можете прочитать здесь.

Получаем данные с помощью SELECT-запроса в JDBC

Для получения данных из БД вы можете выполнить SELECT-запрос. В первом примере мы уже его использовали, но получили только количество строк. Теперь мы вернем сами строки. Большая часть программы останется без изменений, за исключением SQL-запроса и кода, возвращающего данные из объекта ResultSet:

Этот код выведет на экран следующее:

Тут есть пара моментов, на которые следует обратить внимание. Метод rs.getInt(1) используется для получения столбца с целочисленным типом, в нашем случае это столбец id. Индексы в JDBC начинаются с единицы, поэтому rs.getInt(1) вернет значение первого столбца как целое число. В случае, если вы укажете неверный индекс (многие разработчики вызывают rs.getInt(0) для получения первого столбца), выбросится исключение InvalidColumnIndexException. Доступ к столбцам по индексу чреват ошибками, поэтому лучше использовать имя столбца, например, rs.getInt("id"). Подробнее об этом вы можете прочитать в этой статье. Метод getString() используется для получения строковых значений из базы (например, VARCHAR). Цикл будет выполняться, пока rs.next() не вернет false. Это значит, что строки закончились. В нашем случае в таблице две строки, поэтому цикл выполнится два раза, выводя информацию о книгах из таблицы на экран.

Добавляем данные с помощью INSERT-запроса в JDBC

Добавление данных мало отличается от их получения: мы просто используем INSERT-запрос вместо SELECT-запроса и метод executeUpdate() вместо executeQuery(). Этот метод используется для запросов INSERT, UPDATE и DELETE, а также для SQL DDL выражений, таких как CREATE, ALTER или DROP. Эти команды не возвращают результата, поэтому мы убираем все упоминания ResultSet'а в коде и изменяем запрос соответственно:

После запуска программы вы можете проверить таблицу в СУБД. На этот раз вы увидите три записи в таблице:

Теперь вы умеете подключаться к MySQL из Java-приложения и выполнять SELECT, INSERT, DELETE и UPDATE-запросы так же, как и в MySQL GUI. Для подключения мы используем объект Connection, для чтения результатов запроса — ResultSet. Убедитесь перед подключением, что сервер MySQL запущен и mysql-connector-java-5.1.17-bin.jar находится в CLASSPATH, чтобы избежать ClassNotFoundException.

Когда разберетесь с подключением и простыми запросами, имеет смысл изучить, как использовать подготавливаемые запросы (Prepared Statement) в Java для избежания SQL-инъекции. В боевом коде всегда следует использовать подготавливаемые запросы и связывание переменных.

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

• Как подключиться к БД Oracle из Java-приложения;
• Отличия межу Connected RowSet и Disconnected RowSet в Java;
• Как использовать пул соединений в Spring;
• 5 способов улучшить производительность БД в приложениях на Java;
• Отличия между java.util.Date и java.sql.Date в Java;
• Как выполнить INSERT или UPDATE, используя пакетные запросы JDBC;
• Десять вопросов по JDBC на собеседованиях.

Полезные ссылки

• Если у вас нет базы данных MySQL, вы можете ее скачать здесь;
• Если у вас нет драйвера MySQL для JDBC, вы можете скачать его отсюда;
• Рекомендованную книгу Practical Database Programming with Java можно купить на Amazon.

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

Какой JDBC-драйвер нужен для MySQL?
Для подключения к MySQL из Java используется драйвер mysql-connector-java (MySQL Connector/J). Это драйвер Type 4, написанный на чистой Java. Скачайте JAR-файл с официального сайта MySQL и добавьте его в CLASSPATH вашего проекта. Если вы используете Maven, добавьте зависимость mysql:mysql-connector-java в pom.xml.

Как исправить ошибку No suitable driver found?
Эта ошибка означает, что JDBC-драйвер MySQL не найден в CLASSPATH. Убедитесь, что JAR-файл mysql-connector-java добавлен в путь к классам. Также проверьте строку подключения — она должна начинаться с jdbc:mysql:// и не содержать имени таблицы (только хост, порт и имя базы данных).

Чем отличается Statement от PreparedStatement?
Statement выполняет статические SQL-запросы, а PreparedStatement поддерживает параметризованные запросы с подстановкой значений через placeholder-ы (?). PreparedStatement защищает от SQL-инъекций, работает быстрее при повторных вызовах и автоматически экранирует специальные символы. В боевом коде всегда используйте PreparedStatement.

Нужно ли закрывать Connection, Statement и ResultSet?
Да, обязательно. Незакрытые ресурсы приводят к утечке соединений и памяти. Закрывайте их в finally-блоке в порядке ResultSet, Statement, Connection. В Java 7 и выше используйте try-with-resources — ресурсы закроются автоматически при выходе из блока.

Перевод статьи How to Connect to MySQL database in Java with Example