databases.md

Базы данных

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

Грубо можно разбить все базы данных на следующие классы:

• OLTP
• OLAP
• key-value
• nosql/documented
• TimeSeries
• graph

Я написал "грубо" потому, что некоторые базы вполне могут попадать в несколько классов, как, например postgresql.

OLTP расшифровывается как "online transaction processing". В этот класс входят СУБД, которые главным образом предназначены для гарантии целостности и согласованности данных. Данные в таких СУБД обычно организованы в виде таблиц. С помощью баз данных из этого класса можно решать такие задачи как: документооборот, учет финансовых операций, форумы, CMS-системы, ERP, ... (здесь есть небольшое противоречие микросервисной архитектуре). Главное требование к СУБД этого класса - поддержка ACID, транзакций, высокий показатель транзакций в секунду. Обычно (в идельном мире) данные в OLTP-подходе должны быть нормализованы. Примеры СУБД: mysql, mariadb, postgre, Oracle

OLAP расшифровывается как online analytical processing. По большому счету, OLAP - это целый подход к обработке и хранению данных для построения аналитики. И у этого подхода есть набор СУБД, которые справляются с этой задачей наилучшим образом. Для того, чтобы иметь возможность обрабатывать большие массивы данных, а именно это необходимо чаще всего для построения аналитики, приходится прибегать к денормализации данных и создавать OLAP-кубы данных. Такие кубы еще называют агрегатами и строятся они обычно заранее по расписанию, собирая все данные, которые могут быть необходимы в дальнейшем для построения запросов. В целом, это очень обширная тема. Примеры: ClickHouse, Oracle

Key-value-СУЬД имеют своей главной целью производительность. Обычно их используют в качестве кэшей. Это очень удобно, поскольку можно быстро положить значение по ключу и быстро достать его. Иногда у этого ключа бывает срок жизни по истечении которого запись в СУБД будет уничтожена. Также из-за требования к высокой производительности некоторые СУБД не хранят данные на диске, а только в оперативной памяти. Примеры: Redis, Memcached.

Nosql-СУБД также еще называют документоориентированными или schemaless СУБД. В отличие от OLTP-подохода, здесь данные хранятся не в виде таблиц, а в виде документов (например, json- или jsonb-документов). Получать значения в таких СУБД можно не только по ключу, но также можно делать различные выборки и агрегации. Преимуществом СУБД данного класса является отсутствие необходимости поддержания схемы данных, а, следовательно, необходимости выполнения миграций данных. Данные могут храниться внутри одного документа, при этом, структура документов можно различаться и нет необходимости производить join-ы данных, что очень хорошо сказывается на производительности. Однако, если возникает необходимости в объединении документов (join), производительность таких СУБД резко проседает. Некоторые поддерживают концепцию map-reduce, но все равно это не их главное преимущество. Примеры: MongoDB, CouchDB, Riac

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

Graph - графовые СУБД. Обычно используются для хранения и извлечения информации о связях между сущностями. Могут использоваться в социальных сетях для хранения связей пользователей. Примеры: Neo4j.

Здесь будет краткий экскурс к наиболее популярным и полезным СУБД

elasticsearch

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

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

debezium

позволяет настроить потоковую передачу данных из одной базы в другую или куда угодно еще. Для передачи данных используется Kafka, debezium имеет коннкеторы к многим популярным базам данных (mongodb, postgres, mysql, ...). С помощью него можно, например, настроить отправку и обновление индексов в поисковом движке (sphinx, elastic) или же отправлять информацию об изменениях в аналитическую систему.

Cassandra

Особенности

• является, по сути, key-value хранилищем
• Модель данных:
  • keySpace - база данных
  • columnFamily - таблица
  • column - колонки
• шардинг из коробки
• автоматическая перебалансировка в процессе работы и при добавлении новых нод
• высокая отказоустойчивость
• репликация данных асинхронная
• master-master, master-slave репликация
• нет транзакций
• любая нода кластера может выступать в роли точки доступа (координатора)
• при вставке данных можно определить количество подтвердений записи (one, n, all, кворум)
• те же механизмы можно использовать при извлечении данных
• шардирование по ключам можно сделать:
  • по заданным ключам
  • по случайным ключам
• периодически запускается процесс уплотнения, который объединяет таблицы на диске
• при удалении данных по ключу происходит запись метки об удалении. Иначе при дальнейшем считывании наличие записи на одном из узлов будет означать, что запись есть
• у маркеров об удалении есть время жизни, после чего они тоже должны удаляться
• есть операция repair, которая приводит базу в консистентное состояние
• если вовремя не запустить repair и успеют удалиться метки об удалении, то появится масса zombie-меток
• периодически надо делать repair на кластере
• период удаления меток об удалении > период repair
• нужно избегать large partition-реплик
• нужно много мониторинга, чтобы уметь понять почему выросла скорость ответа координатора

Clickhouse

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

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

Greenplum

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