Как выбрать базу данных

Как бизнесу выбрать базу данных под свой проект? Сравниваем on-premise и управляемую БД

Компании, которые создают ИТ-проект с нуля или ищут альтернативное решение, рано или поздно отвечают себе на вопрос: выбрать базы данных on-premise (то есть самостоятельная установка и обслуживание на своей территории) или же управляемая БД в облаке?

Дмитрий Павлов, менеджер по развитию Data Platform в Yandex.Cloud, рассказывает подробно о каждом из вариантов с цифрами и подводными камнями.

Современный бизнес в практически любой индустрии немыслим без обработки больших объёмов данных. Повысить конверсию в интернет-магазине с помощью рекомендаций, отслеживать LTV и MAU/DAU/WAU в интернет-сервисах, обрабатывать транзакции и платежи в финтехе, предсказывать простой оборудования в промышленности — для этих и других задач необходимо хранить и обрабатывать реляционные структурированные данные. Вот уже 60 лет компаниям помогают в этом реляционные системы управления базами данных (СУБД).

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

• Классический: разместить СУБД на собственном или арендованном оборудовании
• Появившийся относительно недавно: использовать управляемую СУБД в облачном провайдере

На первый взгляд кажется, что всегда лучше держать свое, что называется, под боком. По моему опыту, практически все компании изначально рассматривают вариант on-premise (то есть аренду серверов в ЦОДе или виртуальных машин) и только потом изучают возможности облака.

У обоих подходов есть плюсы и минусы, и всё же в последнее время всё больше компаний выбирают облачные PaaS-сервисы. Так, по оценке Gartner, к 2022 году более 75% СУБД в мире будут расположены в облаках. Почему? В этой статье попробуем разобраться.

Итак, нам необходимо развернуть систему управления базами данных (СУБД). Казалось бы, начинается все с установки непосредственно дистрибутива СУБД. Однако, если вы решили опираться на собственные силы, то сначала придется подготовить инфраструктуру: арендовать или разместить в ЦОДе оборудование, раскатать операционную систему, скоммутировать сеть. После развёртывания СУБД — настроить политики безопасности, резервное копирование, организовать мониторинг с алертами. С одной стороны, это разовое действие. С другой — если через месяц для нового проекта понадобится новая БД, то все придется делать заново. Немного помогают средства управления конфигурацией типа ansible или puppet, но даже при их использовании приходится делать много «тюнинга» — например, при изменении конфигурации СУБД или обновления её версии и состава компонент.

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

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

Конечно, возможен вариант, когда, например, оборудование уже есть, закупать его не требуется, только настроить. В этом случае в среднесрочной перспективе развернуть БД on-premise будет экономически обоснованно. Однако надо помнить, что эксплуатация оборудования тоже не бесплатна — его надо обслуживать.

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

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

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

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

Также нельзя забывать и про интеграции с СУБД — ни одна система не существует в вакууме. Конкретно СУБД чаще всего интегрируется с BI-системами, с ПО загрузки и трансформации данных (ETL), с шинами данных (Kafka, Rabbit), с кэшами (Redis). В случае размещения своими силами администратору придётся разрабатывать механику интеграций самостоятельно. В случае использования управляемой СУБД большинство интеграций уже имплементированы, их можно использовать без написания кода.

Таким образом, при подсчете совокупной стоимости владения (total cost of ownership, TCO) СУБД следует учитывать не только сами ресурсы, но и сопутствующие факторы.

Факторы, играющие в пользу on-premise размещения:

• Наличие большого пула ресурсов (своих серверов и ВМ) в капитальных расходах, за которые уже уплачены средства
• Наличие опытных узкоспециализированных администраторов по каждой из СУБД в нужном количестве
• Нетребовательность бизнеса к скорости запуска новых проектов (time-to-market) — если бизнес может подождать несколько месяцев, как это было лет десять назад, часто можно обойтись и своими силами

Факторы, играющие в пользу облачных управляемых СУБД:

• Требования бизнеса к скорости развёртывания новых проектов — «надо запуститься сейчас, потом будет уже поздно, так как рынок будет упущен»
• Отсутствие глубокой экспертизы в конкретных технологиях хранения данных
• Необходимость интегрировать СУБД с другими системами компании

Есть два частых вопроса к облачным СУБД, с которыми связаны опасения и заблуждения: безопасность хранения персональных данных в облаке и ширина сетевого канала, соединяющего облачную СУБД с другими системами компании. Так вот:

• Большинство современных облачных провайдеров имеют развитые средства защиты данных и все необходимые сертификаты для хранения любых данных — персональных, финансовых, и т.д
• В большинстве случаев трафик между облачной СУБД и ЦОДом компании идёт не через интернет, а через специальный выделенный канал до ЦОДа — интерконнект. Такой канал имеет пропускную способность около 20 Гбит/с и минимальную latency. Фактически доступ к облачной СУБД не отличается от доступа к СУБД, развёрнутой в своём ЦОДе.

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

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

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

Вот схема построения отказоустойчивого кластера:

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

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

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

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

Кроме привычных всем бекапов, в некоторых СУБД есть механизм point-in-time recovery (PITR). Эта полезная функция позволяет восстановить данные на любой момент, а не только на момент создания копии. Например, бекап создается в 00:00. Утром в БД появляются новые данные, а в обед junior-разработчик случайно удаляет одну таблицу. Если восстановить предыдущую копию — то потеряются утренние данные. Механизм PITR позволяет указать точное время, на которое нужно восстановить данные: он сам восстановит последнюю копию и применит все транзакции, которые прошли после ее создания.

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

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

Есть и другой вариант: пользователи получают полный доступ к СУБД и ВМ, на которой она работает. Это нельзя назвать полностью управляемым сервисом, это скорее ВМ с готовым шаблоном для быстрого развертывания. Такой вариант упрощает установку и настройку (то есть вычитаем из затрат первый этап). Но раз вы имеете доступ ко всем внутренним настройкам и функциям — провайдеру сложнее гарантировать стабильную работу. Если из-за вмешательства система сломается, разбираться придется самостоятельно.

Соответственно, в БД on-premise у вас (или администраторов) в руках все карты — все системы управления.

Еще одна особенность управляемых БД — соглашение об уровне сервиса (SLA). Оно гарантирует, что БД будет доступна определенное количество времени. В противном случае провайдер компенсирует стоимость сервиса. Но подобные условия предоставляются только для кластера.

При аренде БД на ВМ провайдер также гарантирует доступность по SLA. Но, как правило, в этом случае она ниже, чем для управляемой БД. Например, в Yandex.Cloud SLA для ВМ — 99,95%. Когда ВМ простаивает, это означает, что БД недоступна на чтение и на запись. А в управляемой БД эти операции разделены, и если она недоступна на запись, то вполне вероятно, что доступна хотя бы на чтение.

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

Компания MongoDB описала все действия, на которые расходуется время в различных моделях развертывания БД — на своем оборудовании, на облачной ВМ и полностью управляемой БД. На схеме видно, что в управляемых БД практически все время уходит на разработку и инновации, то есть на решение конкретных задач бизнеса, а не на настройку и обслуживание БД.

Мы рассчитали стоимость владения и управления тремя видами ресурсов — on-premise, ВМ на базе Yandex Compute Cloud и сервисом по управлению базами данных. Мы выбрали эквивалентное по мощности оборудование и сравнили, сколько это стоит в каждом из вариантов.

Расчеты приведем на горизонте трех лет, то есть амортизацию оборудования в on-premise-решении посчитаем за три года.

Это упрощенный расчет — мы не учли несколько моментов. Например, что в on-premise решении оборудование можно продать после использования, а отсутствие капитальных затрат в управляемой БД можно инвестировать в другие направления бизнеса.

Вот сравнение стоимости управления и владения различными вариантами БД:

Давайте рассмотрим расчеты более подробно.

В случае on-premise придется самостоятельно покупать оборудование и следить за ним, поддерживать бесперебойную работу и периодически менять, когда оно устареет или сломается. Если проект развивается, то со временем мощности станет недостаточно и потребуется новое оборудование. Если же сразу взять мощность с запасом — оборудование будет простаивать.Пример: сервер HP с 12 ядрами стоимостью ≈ 800 000 ₽. С учетом амортизации за три года получается ≈ 22 000 ₽ в месяц.

Согласно исследованию некоммерческой организации NRDC, утилизация on-premise оборудования от трех до четырех раз ниже, чем облачного. С учетом данной поправки стоимость владения оборудованием составит как минимум ≈ 22 000 × 3 ≈ 66 000 ₽ в месяц.

Также необходимо будет искать сотрудников, платить зарплату и социальные взносы. При этом потребуется как минимум два специалиста, чтобы они могли подменять друг друга во время отпуска и болезни. Скорее всего, кроме БД, эти сотрудники будут заниматься и другими задачами, поэтому предположим, что на администрирование БД они тратят только 50% времени.Зарплата специалиста ≈ 100 000 ₽, социальные взносы — 30 000 ₽. Потребуется два специалиста, каждый из которых администрирует БД 50% времени. В итоге получаем ≈ 130 000 ₽ в месяц.Итого ≈ 196 000 ₽ в месяц.

При выборе ВМ на базе Compute Cloud не нужно заниматься оборудованием. Так, например, стоимость развертывания ВМ в Yandex.Cloud ≈ 27 500 ₽ в месяц.

Но все еще нужно искать сотрудников, платить зарплату и социальные взносы. Затраты по этой статье будут такими же, как и при on-premise ≈ 130 000 ₽ в месяц.

Итого ≈ 157 500 ₽ в месяц.

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

Пример: управляемая БД (24 vCPU, 96 RAM, 240 ГБ SSD) стоит ≈ 42 000 ₽ в месяц.

Конечно, помимо выбора между on-premise и облачной управляемой СУБД предстоит определиться и с самой технологией СУБД. Здесь необходимо учитывать сразу несколько параметров, в том числе тип данных, характер нагрузки или необходимость в горизонтальном масштабировании. Недавно мы с командой подготовили специальный тест, который помогает учесть все параметры.

Безусловно, оба варианта размещения СУБД имеют свои плюсы и минусы.

On-premise даёт полный контроль над СУБД, возможность выжать несколько дополнительных процентов производительности за счёт более тонкой настройки «под себя», а также возможность утилизировать уже имеющееся оборудование. Также on-premise размещение часто выбирают высокочастотные финансовые сервисы: например, базы размещают в ЦОДах в центре города, чтобы быть ближе к биржам — источникам котировок, таким образом снизив латентность. Однако надо быть готовым к тому, что такое размещение будет очень дорогим.

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

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

Подписывайтесь на блог Yandex.Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.

Другие истории, которые активно читают наши подписчики:

"Приходите в Yandex.Cloud — это дешевле и надежней"
И можно было не катать такую простыню.

Аналогичная реклама у амазона. Глава отдела разработки, где я работаю, начитавшись medium дот комов и прочих хайпов, написал классную презентацию, где сказал, что обслуживающая IT компания хочет 10к USD в год за сервер on-premise, а в амазон мы впишемся за 12к ну и прочие рекламные моменты, которые имеются и в этой статье. Через два года мы платим 60-70к в год.

Если не секрет, где он ошибся, где оказались скрыты дополнительные косты?

1. Объём данных, которые гуляет между производством и облаком не был просчитан правильно (я сделал on premise архитектуру).
2. Товарищ этот из веб дизайна пришёл и задался тупой идеей "low code/no code". Вначале он решил, что может on premise перенести без проблем, но оказалось (для него), что там в этих ETL есть ещё и куча статистики, вот и пришли всякие lamda, ecs и прочее и к тому же хотелось low code/no code.
3. Далее когда cost of failure стал повышаться, естественно были готовы выделять больше денег, он заодно и DevOps повесил параллельно с Athena.
4. Он помешан амазоном, так что когда мы сенсоры начали пихать на производстве, он их хотел покупать сразу, чтобы они на амазон могли закидывать, опять-таки зачем писать код, если он написан — вот ещё и оттуда что-то прилетело.

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

В моём представлении, на облако я бы только кидал S3, DB (причём только то, что может быть и без облака), а вычисления распределять между стационарными компами внутри офиса. При таком раскладе миграция вообще безболезненно проходит.

Всё так, но, как говорится, есть нюанс 🙂 В статье постарался и on-premise уделить внимание. Всё-таки ещё остались кейсы, когда он выгоднее.

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

А что вы имеете ввиду под полноценным хостингом? У нас можно разворачивать "голые" ВМ, на которых можно хостить своё приложение. Также, как я описал в статье, можно прокинуть выделенный закрытый канал в свой ЦОД

Где об этом подробнее почитать, натыкался только на yandex cloud functions где PHP Может работать.

Правильно ли я понимаю, что загрузив один раз приложение, я смогу менять доступные ресурсы (cpu, память) как в этом калькуляторе: https://cloud.yandex.ru/prices без всяких проблем, на лету?
Есть там какой-то аналог ispmanager-а ?
Кто администрирует сервер?

Если мы говорим про "голую" ВМ, то ресурсы можно менять (CPU, RAM, ROM), однако для этого ВМ придётся перезапустить.

Если говорить про управляемые СУБД, то там всё происходит на лету благодаря Rolling Upgrades: https://habr.com/ru/company/yandex/blog/433814/

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

Благодарю, с перезапуском устраивает, что по администрированию скажете, все как с обычным VPS надо делать, или у вы там за администрирование отвечаете?
Аналог ispmanager-а есть или только через консоль все?

Денис, давно не пользовался услугами хостинг-провайдера, не могу сейчас полноценно сравнить с "обычным" VPS, но очень условно можно IaaS Yandex Cloud описать как "голый, но очень и очень продвинутый VPS". Другими словами Облако дает вам в аренду продвинутый катастрофоустойчивый дата центр, а вы уже самостоятельно разворачиваете в нем необходимую вам инфраструктуру и занимаетесь управлением ею.
При этом, наряду с платформой облачной инфраструкты мы также активно развиваем платформу управляемых баз данных, о которой пишет Дмитрий, но пользоваться в своем веб-приложении ими или разворачивать отдельные сервера под СУБД в своем арендованном облаке решает клиент.
Запрос на системы управления веб-приложениями/панелями веб-хостинга понятен, мы стремимся решить его через размещение таких продуктов в Маркетплейсе https://cloud.yandex.ru/marketplace/. Ряд продуктов этой категории вы там уже сможете найти, но тут очень много нюансов лицензирования, короче, работаем. Но опять же продукты из Маркетплейса клиент сам разворачивает в своем арендованном облаке и сам занимается их настройкой, т.е. это не managed-решения.
Если отвечать, кому подойдет такой "хостинг", то в первую очередь е-кому, который перерос классические хостинговые услуги по требованиям к нагрузке, отказоустойчивости и масштабированию, обладает средствами для администрирования своей веб-витрины, но не готов нести серьезные единовременные затраты на покупку железа и арендовать физические стойки в ДЦ.

PS: Как же лампово, что вы не меняете аватар еще со времен заруб в комментах на Роеме )))
Всегда рад вас видеть в обсуждениях.

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

PS2 Как запущу новый проект — MasterPult.ru, так аватар придется поменять))))
Собственно в связи с ним и интересуюсь вашим продуктом, не хочется заморачиваться с выделенными серверами и переезжать с сервера на сервер по мере необходимости (так как не знаю какая будет потребность у этого SaaS сервиса), а так увеличил cpu и память и вперед, но необходимость администрирования отталкивает, сам не хочу этим заниматься, людей со стороны пускать тоже. Хочется под ключ как на reg.ru или мастерхост, чтобы заниматься только своим php приложением.

Ну в Облаке просто в другом фишка — масштабирование, отказоустойчивость, снятие пиков нагрузки, time-to-market по выгодной цене и без тяжелых долговременных инвестиций в железо. Запулили акцию, набежал траф, вы добавили машинок и всех обслужили, ничего не упало. Трафик ушел, убрали машинки. И не надо думать есть ли свободное место в стойке и как туда привезти сервак.
Но работать с этим придется самому или звать партнеров )

Так именно этих фишек и хочется, потому и смотрю в эту сторону, но еще и услугу администрирования, как это делает рег.ру или мастерхост с простыми дедиками.

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

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

Я нисколько не скрываю, что симпатизирую именно управляемым СУБД. В конце статьи постарался объяснить свою точку зрения на этот счёт.

Почему в статье так лихо синонимизируются понятия «база данных» и «субд»? Что за некорректный заголовок? Базу данных не выбирают, выбирают субд.

Выбор хранилища данных

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

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

Подходящие инструменты для каждого задания

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

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

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

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

И наконец, данные также можно разделить по масштабу, скорости передачи, а также скорости одновременного создания и потребления данных. Мы различаем транзакционные (OLTP) и аналитические (OLAP) базы данных. Базы данных OLAP – это более крупные базы данных для учета складских запасов и архивирования данных. В основном они имеют более низкие ограничения по требованиям к скорости, но высокие ожидания в отношении объема обрабатываемых данных. Как правило, на раннем этапе стартапы могут обойтись без системы OLAP, поэтому мы сосредоточимся только на системах OLTP.

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

В течение долгого времени реляционные базы данных занимали доминирующее положение, но вполне очевидно, что времена одного типа баз данных остались в прошлом. Реляционные базы данных имеют широкий спектр применения, и на сегодняшний день они все еще являются доминирующим типом баз данных. Реляционные базы данных являются самоописываемыми, поскольку позволяют разработчикам определять схему базы данных, а также отношения и ограничения между строками и таблицами в базе данных. Разработчики используют возможности реляционной базы данных (а не код приложения), чтобы реализовывать схемы и сохранять ссылочную целостность данных в БД. Как правило, реляционные базы данных используют для интернет‑приложений, мобильных приложений, корпоративных приложений и онлайн‑игр. Стартапы используют множество разновидностей и версий Amazon RDS и Amazon Aurora для создания высокопроизводительных и масштабируемых приложений на AWS. Как RDS, так и Aurora – это полностью управляемые и масштабируемые системы.

Документные данные и данные типа «ключ – значение»

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

Amazon DynamoDB – это управляемая база данных типа «ключ – значение» и документная база данных, которая обеспечивает производительность менее 10 миллисекунд при любом масштабе.

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

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

Еще бывают графовые базы данных. Графовые базы данных предназначены для упрощения разработки и запуска приложений, работающих с наборами тесно связанных данных. В числе стандартных примеров использования графовой базы данных – социальные сети, сервисы рекомендаций, системы выявления мошенничества и графы знаний. Amazon Neptune – это полностью управляемый сервис графовых баз данных. Neptune поддерживает как модель Property Graph, так и модель Resource Description Framework (RDF), поэтому пользователи могут выбрать один из двух API графов – TinkerPop или RDF/SPARQL. Стартапы используют Amazon Neptune для построения графов знаний, предоставления внутриигровых рекомендаций, а также для выявления мошенничества.

Базы данных в памяти

Кроме того, существуют базы данных в памяти. В сфере финансовых услуг, электронной коммерции, интернет‑приложений и приложений для мобильных устройств время отклика иногда не должно превышать доли миллисекунды, и нужно быть всегда готовым ко внезапным всплескам трафика. Это касается, к примеру, ведения списков лидеров, хранения данных сеансов и аналитики в режиме реального времени. Мы разработали сервис Amazon ElastiCache, совместимый с Memcached и Redis, специально для поддержки рабочих процессов с высокой пропускной способностью и низкой задержкой, для которых не подходят хранилища на дисковых носителях. Еще одним примером специально разработанного хранилища данных является Amazon DynamoDB Accelerator (DAX). Благодаря сервису DAX считывание данных в DynamoDB происходит на порядок быстрее (от миллисекунд до микросекунд) даже при миллионах запросов в секунду.

И наконец, есть поисковые базы данных. Многие приложения создают журналы, с помощью которых разработчики находят и устраняют проблемы. Сервис Amazon Elasticsearch Service (или Amazon ES) специально разработан для визуализации в режиме, близком к режиму реального времени, и анализа машинных данных посредством индексации, агрегации и поиска по слабоструктурированным журналам и метрикам. Кроме того, Amazon ES – это мощный, высокопроизводительный сервис для полнотекстового поиска. Стартапы хранят миллиарды документов для разнообразных критически важных примеров использования: от мониторинга хозяйственной деятельности и выявления в ней проблем до отслеживания стека распределенных приложений и оптимизации цен.

После рассмотрения всевозможных вариантов баз данных давайте обсудим, как минимизировать риск, связанный с выбором базы данных для стартапа. Доступность инструментария высокого уровня – самый важный фактор для разработчиков. Как известно, стек PHP-MySQL или LAMP является хорошим примером того, как единообразие и поддержка MySQL становятся залогом успешной разработки на PHP и наоборот. В целом, RDS, DynamoDB и DocumentDB являются прекрасными вариантами для начала и имеют широкую поддержку инструментов, языков и гибких шаблонов использования данных.

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

Сравнение современных СУБД

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

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

Интересуетесь максимально актуальными данными? Обратите внимание на две более свежие статьи «Анализ популярных реляционных и нереляционных систем управления базами данных» (с) 2022 г., которые опубликованы в журнале Системный администратор.

На что стоит обращать внимание

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

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

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

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

1. Oracle 12c

Неудивительно, что корпорация Oracle предлагает одноимённый продукт, с которого обычно начинается рассмотрение вариантов популярных СУБД. Первая версия Oracle была создана в конце 70-х годов. На данный момент у этого продукта блестящая репутация. Кроме того, существует несколько версий этого продукта для удовлетворения потребностей конкретной организации.

Актуальная версия Oracle на момент написания настоящей статьи — 12с — предназначена для облачных сред и может быть размещена на одном или нескольких серверах, это позволяет управлять базами данных, которые содержат миллиарды записей. Некоторые из функций новейшей версии Oracle включают в себя grid framework и использования как физических, так и логических структур.

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

Достоинства

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

Недостатки

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

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

2. MySQL

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

Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems, которая ранее приобрела шведскую компанию MySQL AB. Продукт распространяется как под GNU General Public License, так и под собственной коммерческой лицензией. Помимо этого, разработчики создают функциональность по заказу лицензионных пользователей. Именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

Эта СУБД позволяет выбирать различные движки для системы хранения, которые позволяют менять функционал инструмента и выполнять обработку данных, хранящихся в различных типах таблиц. Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц. Она также имеет простой в использовании интерфейс, и пакетные команды, которые позволяют удобно обрабатывать огромные объемы данных. Система невероятно надежна и не стремится подчинить себе все доступные аппаратные ресурсы.

Достоинства

• Распространяется бесплатно
• Прекрасно документирована
• Предлагает много функций, даже в бесплатной версии
• Пакет MySQL включен в стандартные репозитории наиболее распространённых дистрибутивов операционной системы Linux, что позволяет устанавливать её элементарно просто
• Поддерживает набор пользовательских интерфейсов
• Может работать с другими базами данных, включая DB2 и Oracle.

Недостатки

• Придётся потратить много времени и усилий, чтобы заставить MySQL выполнять несложные задачи, хотя другие системы делают это автоматически, например: создавать инкрементные резервные копии.
• Отсутствует встроенная поддержка XML или OLAP.
• Для бесплатной версии доступна только платная поддержка.

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

3. Microsoft SQL сервер

Ещё одной из популярных СУБД является программный продукт Microsoft SQL-сервер. Это система управления базами данных, движок которой работает на облачных серверах, а также локальных серверах, причем можно комбинировать типы применяемых серверов одновременно. Вскоре после выпуска Microsoft SQL Server 2016, Microsoft адаптировала продукт для операционной системы Linux, а на платформе Windows он работал изначально.

Одной из уникальных особенностей версии 2016 года является temporal data support (временная поддержка данных), которая позволяет отслеживать изменения данных с течением времени. Последняя версия Microsoft SQL-сервер поддерживает dynamic data masking (динамическую маскировку данных), которая гарантирует, что только авторизованные пользователи будут видеть конфиденциальные данные.

Достоинства

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

Недостатки

• Цена для юридических лиц оказывается неприемлемой для большей части организаций
• Даже при тщательной настройке производительности SQL Server способен задействовать все доступные ресурсы
• Сообщается о проблемах с использованием службы интеграции для импорта файлов
• Есть смысл покупать лицензию на этот продукт, если уже внедрена (читай «куплена») экосистема Microsoft.

Идеально подходит для: крупных организаций, которые уже используют ряд продуктов Microsoft.

4. PostgreSQL

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

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

Достоинства

• Является масштабируемым решением и позволяет обрабатывать терабайты данных.
• Поддерживает формат json.
• Существует множество предопределенных функций.
• Доступен ряд интерфейсов.

Недостатки

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

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

5. MongoDB

Еще одна бесплатная система, которая имеет коммерческую версию — MongoDB. Считается одним из классических примеров NoSQL-систем, использует JSON-подобные документы и схему базы данных. Написана на языке C++. Она предназначена для приложений, которые используют как структурированные, так и неструктурированные данные. Ядро является очень гибким и работает при подключении базы данных к приложениям через драйверы MongoDB. Существует широкий выбор доступных драйверов, поэтому легко найти драйвер, который будет работать с требуемым языком программирования.

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

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

Достоинства

• Скорость и простота в использовании
• Движок поддерживает json и другие традиционные документы NoSQL.
• Данные любой структуры могут быть сохранены/прочитаны быстро и легко.

Недостатки

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

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

6. MariaDB

Эта СУБД является бесплатной, но как и многие другие бесплатные приложения, предлагает платные версии. Есть множество доступных плагинов расширений, пожалуй, это самая быстро-развивающаяся СУБД на данный момент.

MariaDB фактически — это ответвление от СУБД MySQL, разрабатываемое сообществом под лицензией GNU GPL. Разработку и поддержку MariaDB осуществляет компания MariaDB Corporation Ab и фонд MariaDB Foundation. Толчком к созданию стала необходимость обеспечения свободного статуса СУБД, в противовес политике лицензирования MySQL компанией Oracle. Система лицензирования MariaDB обязывает участников, желающих добавить свой код в основную ветку СУБД, обмениваться своими авторскими правами с MariaDB Foundation для охраны лицензии и возможности создавать критические исправления для MySQL.

Ведущий разработчик — Майкл Видениус, автор оригинальной версии MySQL и основатель компании Monty Program AB.

Ядро базы данных позволяет выбирать из нескольких систем хранения, и это делает использование ресурсов более оптимизированным, что повышает производительность запросов и обработки. В состав MariaDB включена подсистемы хранения данных XtraDB для возможности замены InnoDB, как основной подсистемы хранения. Также включены подсистемы Aria, PBXT и FederateX. Она полностью совместима с MySQL, и вполне подходит в качестве замены, т.к. полностью клонирован как набор команд, так и API. Многие разработчики MySQL были вовлечены в процесс разработки, а сейчас принимают участие в развитии.

Достоинства

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

Недостатки

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

Идеальна как альтернатива MySQL, если MySQL не устраивает по каким-то причинам.

7. DB2

Созданная компанией IBM, DB2 представляет собой СУБД, которая имеет возможности NoSQL, и может читать JSON и XML-файлы. Ввиду того, что система разрабатывалась для серверов компании IBM модельного ряда iSeries, логично, что система работает на Windows, Linux и Unix.

Диалект языка SQL, используемый в DB2 за редкими исключениями строго декларативен, система снабжена многофазовым оптимизатором, строящим по этим декларативным конструкциям план выполнения запроса. В диалекте SQL DB2 отсутствуют подсказки оптимизатору, мало развит (а долгое время вообще отсутствовал) язык хранимых процедур, и, таким образом, всё направлено на поддержание декларативного стиля написания запросов. Язык SQL DB2 при этом является вычислительно полным, то есть потенциально позволяет в декларативной форме определять любые вычислимые соответствия между исходными данными и результатом. Это достигается в том числе за счёт использования табличных выражений, рекурсии и других развитых механизмов манипулирования данными.

Оптимизатор DB2 широко использует статистику распределения данных в таблицах (если процесс её сбора был выполнен администратором базы данных), поэтому один и тот же запрос на языке SQL может быть оттранслирован в совершенно различные планы выполнения в зависимости от статистических характеристик данных, которые он обрабатывает.

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

DB2 является единственной реляционной СУБД общего назначения, имеющей реализации на аппаратно-программном уровне (система IBM i; также в оборудовании мэйнфреймов IBM System z реализуются средства поддержки DB2).

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

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

Достоинства

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

Недостатки

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

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

8. SAP HANA

Разработанная компанией SAP SE, SAP HANA — это СУБД, с движком ориентированным на работу со столбцами, работающая с родными данными SAP и чужими данными. Ядро ориентировано на сохранение и извлечение данных из приложений и других источников на нескольких уровнях хранения. Система может быть размещена на физических серверах или в облаке.

Достоинства

• Она поддерживает SQL, OLTP и OLAP.
• Ядро снижает требования к ресурсам за счет использования сжатия.
• Данные хранятся в памяти, сокращая время доступа, в некоторых случаях, значительно.
• Отчеты формируются в реальном времени.
• Может взаимодействовать с рядом других приложений.

Недостатки

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

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

9. ЛИНТЕР

«Линтер» — российская СУБД, реализующая стандарт SQL:2003 (за исключением нескалярных типов данных и объектно-ориентированных возможностей) и поддерживающая большинство операционных систем, в том числе семейство Windows, различные версии UNIX, ОС реального времени (включая QNX).

К особенностям можно отнести защиту данных: 2 класс защиты данных от несанкционированного доступа и 2 уровень контроля отсутствия недекларированных возможностей. Мандатный контроль доступа к данным на уровне таблиц, столбцов записей и отдельных полей записей. Управление доступом к рабочим станциям и устройствам хранения информации. Контроль доступа к СУБД по расписанию. Управление протоколированием операций над БД (аудит). Аутентификация пользователей через LDAP, Kerberos, средствами операционной системы. Хеширование паролей по алгоритму FIPS 180-2 SHA-224.

18 марта 2016 года по решению Экспертного совета по российскому программному обеспечению при Минкомсвязи России СУБД ЛИНТЕР включена в единый реестр российских программ для электронных вычислительных машин и баз данных (реестр российского ПО).

Репликация асинхронная (в том числе и двунаправленная), возможна репликация с другими БД через ODBC.

Имеет утилиты конвертации, работающие через ODBC и ADO.NET. Конвертер из DBF-формата. Конвертер модели данных (из ERwin в ЛИНТЕР).

Достоинства

• Российская разработка
• Она поддерживает SQL:2003.
• Облегчается конвертация при переходе с других СБУД
• Рекомендована «Единым реестром российских программ».

Недостатки

• Падение эффективности в случае высокой динамики изменений.

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

9. РЕД База Данных

«РЕД База Данных» — российская СУБД, работает на всех основных платформах и ОС (Windows, Linux, BSD Unix, IBM AIX, HP-UX, Sun Solaris и т.д.). Система модульная. Имеет открытый исходный код.

Возможность «горячего» резервного копирования и инкрементного резервного копирования. Сертифицирована ФСТЭК России. Соответствует отечественным требованиям по защите информации.
Может использоваться при создании информационных систем до класса защищенности 1Г включительно и при создании информационных систем персональных данных до 1 класса включительно. Полное соответствие принципам атомарности, непротиворечивости, изоляции, долговечности (ACID).

Имеются модули сопряжения практически для всех используемых сред разработки (драйверы ODBC, JDBC, C/C++, C#, Java, Delphi, PHP, Python, Perl, VB, и т.д.), результатов тестов этих модулей и гарантия стабильной работы.

Возможность работы во «встроенном» в ПО (embedded) локальном режиме в виде библиотеки DLL без отдельной установки и настройки СУБД, в т.ч. поддержка встраивания в виртуальную машину Java.

Достоинства

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

Недостатки

• Низкая распространённость.

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

Обсуждение

Если сравнивать популярность современных СУБД с точки зрения их распространенности, то можно увидеть следующую картину по состоянию на 2013 год (рис. 1).

Рис. 1. Распространенность современных СУБД по состоянию на 2013 г.

C течением времени картина распространенности СУБД изменилась и в 2017 году приняла следующий вид (рис. 2).

Рис. 2. Распространенность современных СУБД по состоянию на 2017 г.

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

7 типов современных баз данных: предназначение, достоинства и недостатки

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

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

1. Нужен ли нам аналитический доступ к базе данных?
2. Нужно ли нам писать или читать в реальном времени?
3. Сколько таблиц / записей мы хотим сохранить?
4. Какая доступность нам нужна?
5. Нужны ли нам столбцы?
6. Сможем ли мы получить доступ к таблицам, отфильтрованным по столбцам или по строкам?

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

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

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

Достоинства:

• Поддержка SQL
• ACID-транзакции (атомарность, согласованность, изоляция и долговечность)
• Поддержка индексации и разделения

Недостатки:

• Плохая поддержка неструктурированных данных / сложных типов
• Плохая оптимизация обработки событий
• Сложное / дорогое масштабирование

Примеры: Oracle DB, MySQL, PostgreSQL.

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

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

Достоинства:

• Нет привязки к схеме
• Нет необходимости всегда писать все поля в каждой записи
• Хорошая поддержка сложных типов
• Подходит для OLTP

Недостатки:

• Плохая поддержка транзакций
• Слабая аналитическая поддержка
• Сложное / дорогое масштабирование

Примеры: MongoDB.

Базы данных в оперативной памяти

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

Достоинства:

• Быстрое написание
• Быстрое чтение

Недостатки:

• Труднодостижимая надёжность
• Дорогое масштабирование

Примеры: Redis, Tarantool, Apache Ignite.

Базы данных с широкими столбцами

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

Достоинства:

• Быстрая запись построчно
• Быстрое чтение по ключу
• Хорошая масштабируемость
• Высокая доступность

Недостатки:

• Формат «ключ-значение»
• Нет поддержки аналитики

Примеры: Cassandra, HBase.

Столбчатые базы данных

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

Достоинства:

• Быстрое чтение столбец за столбцом
• Хорошая аналитическая поддержка
• Хорошая масштабируемость

Недостатки:

• Подходит только для пакетных вставок

Примеры: Vertica, Clickhouse.

Поисковая система

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

Достоинства:

• Быстрый доступ по любому слову
• Хорошая масштабируемость

Недостатки:

• Подходит только для пакетных вставок
• Плохая аналитическая поддержка

Примеры: Elastic.

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

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

Достоинства:

• Структура данных графа
• Управляемые отношения между сущностями
• Гибкие конструкции

Недостатки:

• Специальный язык запросов
• Трудно масштабировать

Выводы

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

Если вы готовитесь к собеседованию, посмотрите также статью, в которой собраны 27 распространённых вопросов по SQL и ответы на них.