[Перевод] Пять факторов, которые влияют на выбор базы данных
При выборе баз данных для текущего проекта (или при замене тех, которые не отвечают вашим текущим потребностям) количество возможных вариантов очень велико. Это и хорошо, и плохо, ведь нужны какие-то критерии фильтрации.
Сегодня есть гораздо больше баз данных, чем когда-либо. В декабре 2012 года, когда DB-Engines.com впервые начал ранжировать базы данных, у него получился список из 73 систем (существенный рост по сравнению с самым первым списком из 18 систем). Спустя десять лет, на декабрь 2022 года в списке было уже почти четыреста систем. За последнее десятилетие произошёл настоящий кембрийский взрыв технологий баз данных. Нужно ориентироваться в обширном пространстве вариантов: SQL, NoSQL, множество «многомодельных» баз данных, которые могут быть сочетанием SQL и NoSQL, или множественные модели данных NoSQL (сочетающие две или более опций: документы, ключи-значения, широкие столбцы, графы и так далее).
Кроме того, пользователи не должны путать популярность с применимостью для них. Хотя сетевой эффект имеет свои преимущества («Все пользуются X, поэтому не ошибусь, если выберу её»), он также может привести к групповому мышлению, торможению инноваций и конкуренции.
Мы с моим коллегой Артуром Песа недавно рассмотрели пять факторов, которые пользователи должны учитывать в первую очередь при выборе и сравнении баз данных.
Пять факторов
Сразу перейдём к списку.
- Программная архитектура — использует ли база данных самые эффективные структуры данных, гибкие модели данных и богатые языки запросов для поддержки ваших рабочих нагрузок и паттернов запросов?
- Использование оборудования — может ли она полностью использовать все возможности современных аппаратных платформ, или существенная часть ресурсов CPU будет простаивать?
- Способность к взаимодействию — насколько просто интегрировать её в вашу среду разработки? Поддерживает ли она нужные вам языки программирования, фреймворки и проекты? Была ли она спроектирована так, чтобы интегрироваться в ваши микросервисы и архитектуру потоковой передачи событий?
- RASP — обладает ли она необходимыми качествами: Reliability (надёжностью), Availability (доступностью), Scalability (масштабируемостью), Serviceability (удобством обслуживания) и, разумеется, Performance (производительностью)?
- Развёртывание — работает ли база данных только в ограниченном окружении, например, только на мощностях компании, или только в одном дата-центре, или только у одного поставщика облачных услуг? Или её можно развёртывать в любом нужном вам месте Земли?
Любые такие списки субъективны. Возможно, у вас будет собственный список из четырёх факторов, или из 12/20/100 критериев. И, разумеется, каждый из этих факторов, например, программная архитектура, разделяется на подкатегории, такие как «механизм хранения», «архитектура распределённой обработки» и даже «язык запросов». Но я разбиваю их на общие категории именно так.
▍ Программная архитектура
Самый критически важный вопрос здесь заключается в следующем: «Использует ли база данных самые эффективные структуры данных, гибкие модели данных и богатые языки запросов для поддержки ваших рабочих нагрузок и паттернов запросов?»
Рабочие нагрузки — вам нужны нагрузки транзакций с большим объёмом операций записи или смешанные переходные нагрузки с чтением и записью? Или в основном ваши нагрузки будут аналитическими и рассчитанными на чтение? Потребуются ли вам гибридные нагрузки из сочетания транзакций и аналитики? Нагрузки будут в реальном времени, пакетными или смешанными? Будет ли стабильный поток событий в секунду или на протяжении дня предстоят предсказуемые плавные регулярные рост и падение? А, возможно, вам нужно спланировать обработку стохастических всплесков трафика (например, при появлении экстренных новостей или других причин внезапной популярности записи)?
Модель данных — работаете ли вы с парами «ключ-значение»? С широкими столбцами (данными «ключ-ключ-значение»)? Со столбцами? Документами? Графами? RDBMS (с таблицами и JOIN)? А может быть, с чем-то совершенно иным? Действительно ли у вас есть время и потребность выполнять полную нормализацию данных, или БД будет поглощать большие объёмы неструктурированных данных настолько быстро, что нормализация была бы глупостью и вам лучше подойдёт модель денормализованных данных? В таких вопросах нет единого «правильного» ответа. Всегда нужно учитывать конкретные обстоятельства.
Язык запросов — в этом аспекте гораздо больше предвзятости, потому что, даже если ваша команда инжиниринга данных сможет маскировать или скрыть модель запросов бэкенда, у многих из пользователей есть свои склонности и предпочтения. Это одна из главных причин того, что SQL остаётся почти безвариантным выбором. В то же время существуют новые языки запросов. Некоторые из них схожи с SQL, например, Cassandra Query Language (CQL), который используется в Cassandra и ScyllaDB. Пользователям SQL он покажется смутно знакомым. Но не позвольте себя обмануть — в нём нет табличных JOIN! Кроме того, есть языки запросов нового поколения, например, JSON. На его основе работают запросы Amazon DynamoDB. ScyllaDB также поддерживает такую модель запросов JSON при помощи интерфейса Alternator, совместимого с DynamoDB. Но к чему бы вы ни склонялись, о языке запросов нужно думать до окончательного выбора базы данных.
Транзакции/Операции/CAP — что из них для вас важнее? Полностью согласованные ACID-транзакции? Или высокопроизводительные простые CRUD-операции с высокой степенью доступности? Теорема CAP гласит, что можно выбрать только два пункта из трёх: согласованность, доступность или устойчивость к разделению. Учитывая, что распределённые базы данных всегда должны быть устойчивы к разделению, вам придётся выбирать между так называемыми системами CP-режима (ориентированными на согласованность) или системами AP-режима (ориентированными на доступность). Кроме того, в рамках этих режимов следует учитывать подробности реализации. Например, способы достижения высокой согласованности в распределённой системе могут сильно варьироваться. Необходимо также учитывать выбор различных алгоритмов достижения консенсуса для обеспечения линеаризуемости, например, Paxos, Raft, Zookeeper (ZAB) и так далее. Наряду с различиями в алгоритмах, каждая реализация может существенно отличаться от другой.
Распределение данных — что конкретно подразумевается под «распределённой системой»? Мы говорим о локальном кластере в одном дата-центре? Или имеем в виду кластеризацию в нескольких дата-центрах? Как происходят межкластерные обновления? Считаются ли они одним логическим кластером или требуют межкластерной синхронизации? Как обрабатывается локализация данных и, например, обеспечивается соответствие требованиям GDPR?
▍ Использование оборудования
На наших глазах происходит революция в области оборудования, продолжающего расширять возможности ПО. Многие программные приложения и, в частности, многие базы данных по-прежнему привязаны к возникшим десятки лет назад корням, архитектурам и допущениям.
Эффективность/степень использования CPU — большая часть ПО начинает плохо работать, когда процент использования CPU поднимается выше, допустим, 40% или 50%. Это означает, что ПО будет работать неэффективно, приводя к постоянному простою половины ресурсов машин. По сути, вы платите за вдвое больший объём инфраструктуры. Так что вам необходимо разобраться, как ваша система справляется с распределённой обработкой.
Эффективность/степень использования ОЗУ — не упирается ли ваша база постоянно в ограничения памяти? Не слишком ли агрессивно или не слишком ли раздуто кэширование (например, нет ли нескольких слоёв кэширования), из-за чего в памяти хранятся ненужные данные? Как база данных оптимизирует пути чтения и записи?
Эффективность/степень использования хранилища — какой формат хранения использует ваша база данных? Имеет ли она компактные изменяемые таблицы, которые могут потребовать тяжеловесных механизмов блокировки файлов? Или она использует неизменяемые таблицы, способные обеспечивать быструю запись, но ценой увеличения пространства и количества операций чтения? Есть ли у неё возможность многоуровневого хранения? Как она обрабатывает concurrency? Файлы хранятся построчно (удобно для сценариев с активным использованием транзакций) или по столбцам (удобно для аналитики и данных с высокой повторяемостью)? Здесь тоже нет единого «правильного» ответа. Каждое решение оптимизирует систему под разные сценарии применения.
Эффективность/степень использования сети — здесь стоит поразмыслить об эффективности и кластерных коммуникаций «клиент-сервер», и о внутрикластерных коммуникациях. Модели «клиент-сервер» можно сделать более эффективными благодаря concurrency, пулингу соединений и так далее. Внутрикластерные коммуникации включают в себя и стандартный операционный/транзакционный обмен данными (репликацию данных в обновлении или операции записи), и административные задачи, например, потоковую передачу и балансировку данных между узлами при изменении топологии.
▍ Способность к взаимодействию
Ни одна база данных не является изолированной. Насколько легко интегрировать её в вашу среду разработки? Поддерживает ли она ваши языки программирования, фреймворки и проекты? Была ли она спроектирована так, чтобы интегрироваться в ваши микросервисы и архитектуру потоковой передачи событий?
Языки программирования/фреймворки — компании очень часто ассоциируют себя с предпочитаемым ими языком программирования или фреймворком. Если база данных не имеет обязательного клиента, SDK, библиотеки, ORM и/или других пакетов для своей интеграции в этот язык, то её с тем же успехом может и вообще не существовать. Нужно отметить, что взрывное развитие баз данных началось параллельно взрывному развитию языков программирования. Тем не менее стоит изучить вопрос поддержки языка программирования в клиенте. При этом нужно учитывать, он может не быть тем же языком программирования, на котором написана сама база данных (что может влиять на её программную архитектуру и эффективность). Вопрос здесь исключительно в том, на каком языке можно писать приложения для подключения к этой базе данных в бэкенде.
Потоковая передача событий/очередь сообщений — базы данных могут быть единственным источником истины, но это не единственные системы, работающие в вашей компании. На самом деле, могут существовать разные базы данных, выполняющие транзакции и анализ различных частей данных и пространства информации компании. Потоковая передача событий (event streaming) становится всё более популярным носителем, позволяющим избежать создания data silo; сегодня удобство базы данных определяется её интеграцией с технологиями передачи событий в реальном времени и очередей сообщений. Может ли ваша база данных быть и получателем, и источником данных? Есть ли у неё Change Data Capture (CDC)? Может ли она подключаться к технологиям потоковой передачи событий и очередей сообщений наподобие Apache Kafka, Apache Pulsar или RabbitMQ?
API — поддерживает ли база данных один или несколько API, например, интерфейс RESTful или GraphQL, чтобы упростить интеграцию базы данных в архитектуру приложений и микросервисов? Есть ли у неё административный API, чтобы ею можно было управлять программно, а не только через GUI? Использование GUI может показаться удобным только поначалу, пока вам не приходится управлять системами развёртывания и автоматизировать их.
Другие интеграции — как насчёт тулчейнов CI/CD? Платформ наблюдаемости? Как насчёт использования базы данных в качестве подключаемого механизма хранения или низкоуровневого элемента более масштабной архитектуры? Насколько хорошо она служит в качестве инфраструктуры или вписывается в уже используемую вами инфраструктуру?
▍ RASP
Эта аббревиатура придумана десятки лет назад и обычно используется в контексте оборудования. Она расшифровывается как Reliability (надёжность), Availability (доступность), Serviceability (удобство обслуживания) (или Scalability, «масштабируемость»), Performance (производительность). По сути, все эти параметры упрощают работу системы. При выборе базы данных они определяют, какой объём ручного труда вам может потребоваться для поддержания работы и стабильности системы. Они обозначают, насколько хорошо база данных может позаботиться о себе при обычных условиях эксплуатации и даже справляться с состояниями сбоев.
Типичный инженер платформы, запускающий группу новых узлов
Надёжность — показатель того, сколько усилий нужно вложить, чтобы не разрушилась система или не потерялись данные. Насколько высока её выживаемость? Какие механизмы защиты от энтропии она имеет, чтобы восстанавливать синхронизацию кластеров? Насколько хороши системы резервного копирования? И что более важно, насколько хороши системы восстановления? Существуют ли меры защиты, не позволяющие пользователям случайно уничтожить систему?
Доступность — что делает база данных при кратковременных разделениях сети и недоступности промежуточных узлов? Что происходит при полном сбое узла? Что будет, если сбой сети растянется на несколько часов?
Удобство обслуживания — сегодня популярно понятие «наблюдаемость» (observability), включающее в себя три категории: логирование, трассировки и метрики. Разумеется, в базу данных должна быть встроена наблюдаемость. Однако удобство обслуживания — это гораздо большее. Насколько просто выполнять апгрейды без даунтайма? Насколько удобны операции техобслуживания?
Масштабируемость — с некоторыми базами данных удобно начинать работу, однако со временем вы можете упереться в потолок. Масштабируемость подразумевает, что вам не нужно будет волноваться о том, что вы столкнётесь с ограничениями общего количества обрабатываемых данных, операций в секунду или географического расположения, например, при переходе от одного дата-центра к развёртыванию по всему миру. Кроме того, существует горизонтальная масштабируемость (увеличение количества узлов в кластере) и вертикальная масштабируемость (размещение базы данных на серверах, имеющих постоянно увеличивающееся количество CPU, объём ОЗУ и хранилища).
Производительность — если база данных не может удовлетворить SLA по задержкам или пропускной способности, то она просто не потянет продакшен. Кроме того, в связи с масштабируемостью стоит упомянуть, что многие базы данных, как будто соответствуют вашим требованиям к производительности в малых масштабах или на основании статического бенчмарка, использующего тестовые данные, однако столкнувшись с реальными нагрузками продакшена, они просто не справляются с возросшей частотой, вариативностью и сложностью запросов. Так что производительность требует сильной корреляции с линейным масштабом.
▍ Развёртывание
Всё из вышеперечисленного должно выполняться там, где вам нужно. Работает ли база данных только в ограниченном окружении, например, только на мощностях компании, или только в одном дата-центре, или только у одного поставщика облачных услуг? Или её можно развёртывать в любом нужном вам месте Земли? Задайтесь следующими вопросами:
Ограничения — может ли она работать на мощностях компании? Можно ли её развёртывать только на мощностях компании? Привязана ли она только к одному конкретному поставщику облачных услуг или она может работать у выбранного вами поставщика? Какие есть варианты гибридного облака или многооблачной структуры?
Управление/контроль — она может работать только как база данных с самостоятельным управлением или она может быть поглощена Database-as-a-Service (DBaas)? Первый вариант предоставляет вам полный контроль над системой, а второй снимает с ваших команд бремя администрирования. И тот и другой имеют свои плюсы и минусы. Можно ли выбрать только один вариант, или база данных позволяет пользователям переключаться между двумя этими бизнес-моделями?
Автоматизация и оснащение — есть ли у неё Kubernetes Operator для поддержки в продакшене? Скрипты Terraform и Ansible? Хотя это и последний пункт списка, его не стоит оставлять на потом при выборе системы для продакшена.
Играй в нашу новую игру прямо в Telegram!
