Эта статья не является ответом на множество вопросов по базам
данных (БД) и системам управлениям базами данных (СУБД). Я как
автор выражаю своё собственное мнение о трендах, стараясь опираться
на беспристрастные показатели, статистики и т.д., но для примера
приводя собственный опыт. Я не являюсь ангажированным
представителем какой-либо компании и выражаю точку зрения опираясь
на опыт более 25 лет работы с разными СУБД, в том числе, которую
создавал своими руками. Не так много даже опытных программистов и
архитекторов, которые знают все термины, технологии, какие
подводные камни и куда идёт движение. Тема поистине огромная,
поэтому в рамках одной статьи не раскрыть даже верхний уровень
информации. Если кто-то не встретит свою любимую СУБД или её
невероятный плюс, который стоит упомянуть, то прошу в комментариях
указать и этим дополнить общую картину, что поможет другим
разобраться и понять лучше предметную область. Поехали!
Open Source DBMS vs Commercial DBMS
Для начала приведу график с сайта, db-engines.com, по моим
ощущениям, неплохо отслеживающим тренды БД. Именно этот график
добавил желания написать статью о текущем положении дел. Когда мы
говорим фразу база данных, то на самом деле чаще имеем в виду
конкретную систему управления базами данных (СУБД), поэтому если в
тексте встретится БД вместо СУБД, то это в силу такой привычки.
Open Source DBMS системы управления баз данных с открытым
исходным кодом догнали коммерческие СУБД с закрытым исходным кодом.
Open Source 49.98% против 50.02% у Commercial. Итогом 2020 года
становится момент, когда можно будет сказать, что open source не
менее популярны. Как вы видите, эта ситуация возникла не внезапно.
Подсчёт на графике не в численном соотношении, а в очках, которые
набирают те или иные системы.
Для интереса можете посмотреть на сайте где находится ваша
любимая СУБД в рейтинге. Итогом последнего года стал вылет
Microsoft Access из десятки, он вместе с языком программирования
COBOL напоминает, что жизненный цикл технологий может быть очень
длинным. Полагаю, что в следующем году IBM DB2 будет опускаться
сильнее всего в топе. Топ 10 СУБД это 75% всех набранных баллов. За
год топ 10 в очках почти не поменялся.
Open Source вырос качественно за последние годы и всё больше ИТ
специалистов, принимающих решение задаются вопросом, а стоят ли
лицензии Oracle, MS SQL, IBM DB2 и прочих коммерческих продуктов,
чтобы в них вкладываться. Не в малой степени этому способствуют
аппетиты одноимённых компаний. В последние годы стало модно в
коммерческих продуктах продавать enterprise licenses (лицензии
уровня предприятий без искусственных ограничений функционала) за
ядра процессоров. Можете по ссылке посчитать, что выходит для
сервера с 4 процессорами по 16 ядер - всего 64 ядра если вам не
подходят лицензии за пользователей.
MS SQL - 439 936$
Oracle - 1 368
000$
Мало того, запутанная система лицензирования, в которой не
всегда разбираются даже в компаниях, продающих эти лицензии
приводит к ситуации, когда к вам придут и скажут, что вы не
докупили лицензий за нечто на сумму большую чем вы уже приобрели и
заложили в бюджет. И это не редкая ситуация.
Прошлый 2019 год и текущий 2020 проходили с растущим влиянием
компании AMD и её центральных процессоров, включая серверные EPYC,
которые кардинально меняют стоимость физических ядер, а это значит,
что ядер будут покупать всё больше. Многоядерность AMD развилась с
внедрением чиплетов и теперь 64 ядра в одном процессоре - это
реальность. Готовы ли будут компании покупать платные лицензии
платных СУБД на ядра в разы больше? Не уверен. Физический сервер
будет получаться по стоимости на порядок ниже лицензий. Серверный
рынок довольно инертный и на AMD не перейдут и за несколько лет, но
Oracle, Microsoft и прочие начнут терять долю ещё быстрее если не
изменят политику. Microsoft выпускал версию SQL Server для Linux,
но опять же за деньги и не нашлось большого числа желающих её
купить. IBM DB2 теряет долю рынка уже давно.
Переход многих компаний на микросервисы (наверняка слышали на
российских конференциях и форумах мы пилим монолит на микросервисы)
зачастую приводит к отделению данных физически на разные сервера,
для коммерческих СУБД это платные лицензии, для Open Source нет.
Чтобы не выйти из бюджета выбирают бесплатные решения.
Уместно будет сказать, что бизнес коммерческих СУБД выгоден и
ими владеют богатейшие люди планеты. В топе самых богатых
людей оказываются владельцы компаний, владеющих коммерческими СУБД:
Билл Гейтс (Microsoft), Ларри Эллисон (Oracle), которые занимают
значительную долю в топе СУБД. Ещё из топ 10 списка Forbes
богатейших людей, у которых есть огромные или облачные БД
присутствуют Джефф Безос (Amazon RDS), Ларри Пейдж и Сергей Брин
(Google с их Bigtable).
В последнее время крупные ИТ компании с большими деньгами
развивают open source проекты. Можно было бы подумать, что они
прониклись идеями сообщества открытого кода, хотят сделать полезное
для общества, их наполнило человеколюбие и прочее меценатство. Но
нет, нужно понимать, что крупные акулы в бизнесе рассчитывают на
некотором этапе монетизировать эти вложения, повысить положительное
мнение о своих компаниях, занять рынки, воспользоваться бесплатным
трудом сообщества, взять выстрелившие идеи. Шутка ли тысячи светлых
голов коммитят в репозитории качественный код, тестируют на
реальных проектах и денег не просят.
Тот же MySQL несмотря на название open source был уже продан за
1 млрд.$, Sun Microsystem, а потом поглощён Oracle. Основатель
MySQL Майкл Видениус переоткрыл проект назвав его MariaDB. Я был на
его выступлении в Москве где он призывал переходить на их
продолжение оригинальной СУБД и надо сказать, что немалая часть
разработчиков так и поступило. MariaDB уже на 12 месте.
Коммерческие СУБД дороги, но есть и масса плюсов, они стабильны,
удобны, легко интегрируемы в ИТ инфраструктуру, есть система
подготовки специалистов, сторонние компании расширяют функционал.
Плюсом open source помимо бесплатности и растущей части
возможностей платных СУБД можно считать и то, что вы можете взять
код БД и поменять под свои нужды, как делал Facebook c MySQL. Для
одной СУБД open source может быть несколько движков или несколько
веток развития и вы можете выбирать любой вариант, который вам
подходит. Влетевшая в топ 10 SQLite - мультиплатформенный продукт.
Это персональная БД не использующая парадигму Сервер-Клиент, когда
вам нужно с минимальными затратами просто локально хранить данные
для приложения и пользоваться всеми плюсами СУБД.
Что в России: Нужно понимать, что когда в 70-80
годах году появились первые коммерческие продукты, например Oracle,
у нас ещё был Брежнев, Олимпиада в Москве, перестройка, отставание
в электронной промышленности и т.д. Мы пока догоняем или развиваем
существующие системы.
Первые версии СУБД в мире были коммерческие, распространялись
точечно, требовали присутствия специалистов. Покупать программное
обеспечение (ПО) за валюту в нашей стране исторически не всегда
принято (опустим обсуждение политических и экономических мотивов),
поэтому альтернатива в виде бесплатных СУБД и пиратских версий
коммерческих продуктов присутствуют. В институтах сейчас часто учат
на бесплатных движках БД, открытое ПО это стильно, модно,
молодёжно. Поэтому рынок очень быстро наполняется специалистами в
области open source. В России есть разработки СУБД в виде
ClickHouse, Tarantool, ветки PostgreSQL и т.д., коммерческих
экспортируемых БД нет. Есть реестр российских
программ где можно поинтересоваться текущим положением дел по
отечественным СУБД. Состав правда вызывает сомнение, например,
наряду с названиями, которые вы могли слышать встречаются и с
названием типа Паспортный стол общежитий ВУЗа.
Переход на open source в России ускорился и в связи с санкциями.
Помнится, выходившая новость об Oracle о возможном запрете
продавать технологии для нефтегазовой отрасли России поменяло
вектор видения будущего в умах и бюджетах некоторых наших компаний
с хорошими бюджетами на ИТ. Как выше сказал фраза мы пилим монолит
на микросервисы зачастую приводит в Open Source. В России, да как и
во всём мире, растут PostgreSQL, MySQL, SQLite, MongoDB
проекты.
Многим могло показаться, что open source давно обогнал
commercial, но это мнение может сложиться если вы относитесь к миру
online проектов, сайтов, приложений для смартфонов и т.д. Из этого
следует следующее сравнение online vs. offline.
БД online проектов против offline
Есть 2 класса проектов, которые в чём-то похожи, а в чём-то нет.
Это проекты с основным направлением онлайн продаж или оффлайн
бизнес.
Если вы берёте классический бизнес оффлайн, связанный с добычей
природных ресурсов, банковским делом, дистрибьюцией (оптовые
продажи) или ритейлом (розничные продажи), то развивался он чаще
всего из стека технологий на базе Windows решений. И переходя в
онлайн он может использовать стек технологий WISA (Windows, IIS, MS
SQL, ASP.Net). Есть и онлайн проекты изначально на WISA, для
примера, всем известный StackOverflow. На текущий момент, в чисто
онлайн проектах доминирует стек технологий типа LAMP (Linux Apache
MySQL PHP). Новые молодые команды, приходящие в существующий
бизнес, часто не работали с Windows стэком технологий и предлагают
переписывать существующие системы. В России эта тенденция очень
хорошо ощущается в последние годы.
Деньги любят счёт, и чтобы сравнить долю онлайн или оффлайн
проектов давайте посмотрим рейтинг по выручке в
мире. В топе ритейл, добыча ресурсов, автомобилестроение и т.д. В
крупнейших компаниях (не только России) обычно зоопарк из
технологий, тут будут ERP, CRM системы в виде SAP, Microsoft
Dynamics NAV или AX, 1C в России и много чего ещё. Компании с
большим оборотом используют разные системы управления предприятием,
которые в свою очередь часто используют коммерческие БД, Oracle, MS
SQL, IBM DB2.
Но капитализация компаний в мире за последние 10 лет изменилась
и мы видим, что в топе теперь ИТ гиганты и всего 2 компании из
прошлого топа Microsoft и Alphabet (Google). В динамике изменения
тут. Это значит
смещение денежного потока в онлайн. Мы все уже привыкли и платить
онлайн и переводить деньги, покупать товары с доставкой и т.д. А
текущий 2020 год принёс немало прибыли именно онлайн компаниям.
Рейтинг компаний России
по выручке. На первых местах добыча ресурсов, банки, ритейл, а не
ИТ корпорации. Яндекс на 113 месте. Правда по капитализации Яндекс
входит в топ 20. Тенденции по внедрению большего числа решений с
open source есть, причины описаны выше. Исторически многие
крупнейшие онлайн-ритейлеры (магазины) в России на платных БД, но
задумываются над переходом тестируя части функционала на open
source. Банки начали миграцию в онлайн, пример Тинькофф банка
подтверждает, что нужно развивать онлайн банкинг.
По итогам года из-за текущей ситуации с вирусом явно число и
размер online проектов выросло. Растут и облачные решения, об этом
ниже.
Реляционные СУБД против остальных
Обилие статей в том числе на Хабре про разные виды БД вводят в
заблуждение, что весь мир уже перестаёт использовать классические
реляционные СУБД. На самом деле RDBMS это подавляющее большинство
всех СУБД в мире. На другие виды приходится около части и нужно
понимать, что это чаще всего специфический функционал.
Для примера скажу, что в данный момент изо дня в день в работе
типичной крупной компании может широко использоваться одновременно
разные СУБД как платные MS SQL(Oracle) и ещё набор из MongoDB,
Redis, MySQL, ClickHouse, ElasticSearch и т.д.
Рассмотрим очень кратко основные типы:
Relational: Главный тип, который ассоциируется
с БД. Данные хранятся в виде 2-мерных таблиц с определёнными
столбцами и строками, в которых хранятся значения. Индексы
используются для ускорения поиска по указанному в создании индекса
полю или полям. Связь между 2 таблицами идёт по одинаковым полям в
них ключам (Key). Для добавления, изменения, удаления данных
используется язык SQL (Structured Query Language), о нём ниже.
Описание структуры данных хранится в самой же БД в данных системных
реляционных таблиц. Эта простая идея с 2-мерными таблицами
выдержала проверку временем и продолжает быть самой
распространённой.
Document stores:
Отличие от реляционных БД в том, что данные хранятся в виде
документов с любой структурой. То есть колонки таблицы жёстко не
определены. Но тем не менее можно создавать индексы, которые
вставляют ссылку на строку если находится указанный аттрибут
документа. Типичный представитель MongoDB хранение документов
используя синтаксис JSON (Java Script Object Notation). На самом
деле BSON (Binary JSON), который компактнее, как и любые бинарные
типы чем строковые.
Вот так выглядят строки в коллекции (это аналог таблиц)
Точно также таблицы могут ссылаться друг на друга.
Key-Value : появился этот тип NoSQL решения
из-за необходимости быстро записывать, менять и получать значения
по какому-то параметру. Не редко это используют для некритичных,
быстроменяющихся значений, которые нет смысла записывать и хранить.
Типичный представитель Redis. На старом ноутбуке вы можете получить
десятки тысяч операций в секунду по записи, изменению данных.
Достигается это тем что данные хранятся в памяти, с которой
операции быстрее. Отсюда же и минус, что если памяти недостаточно,
то скорость будет деградировать. Например, вы хотите измерять число
запросов с 1 IP за минуту. Заводится строка где ключ это IP, любое
обращение добавляет счётчику +1. Если запросов много, то троттлинг
(ограничение). Ключ может иметь TTL и обнуляться раз в X минут.
Search Engines: Поиск это важная функция в
любой системе. Если c поиском по точному совпадению в виде ID
(кода, артикула, партномера и т.д.) реляционные БД справляются
очень качественно и быстро, то поиск внутри документа по фразе,
включая использование разных форм слова, множественного числа и
прочих составляющих живого языка уже не выходит так быстро. Нужно
сканировать данные от начала до конца и выискивать походящие
документы. Поэтому поступают так как делают крупные поисковики
индексируя страницы, если представить по простому, то они проходят
по документам предварительно, составляют список слов, которые
встречаются в документе и когда нужен поиск, то ищут по
преподготовленным спискам слов с ссылками на документы, чем больше
слов совпало тем вероятнее, что этот документ и нужен. Типичный
представитель ElasticSearch его большое число инсталляций
обусловлено ещё и тем, что существует типичный стек ELK (англ.
лось) ElasticSearch+Logstash+Kibana для мониторинга событий,
например, логов веб серверов или сервисов.
Wide column stores: Лучше всего представлять
как среднее между реляционной БД и Key-Value БД. Есть таблицы,
строки и колонки. Но колонки не имеют жёсткой структуры и могут
иметь в разных строках разные названия и значения.
Представители этого типа БД Cassandra, HBase.
Graph : Тип БД, который призван обрабатывать
данные, которые представлены в виде графов. В виде графов можно
представить населённые пункты (вершины) и дороги между ними
(ребро). Типичная задача поиск нахождения кратчайшего маршрута
между пунктами путём обхода графа в ширину или более продвинутыми
алгоритмами.
Также удобно представлять графами связи между людьми (вершины),
что он знает кого-то (ребро) или их возраст и интересы. Формула
химического соединения можно представить, что вершины графаатомы
молекулы, а рёбра это связи между молекулам. Теория графов обширна
и развивается с 18 века, так что математическая база накоплена
большая. Типичный представитель графовой СУБД - Neo4j.
Columnstore
Хотя в рейтинге db-engines этот вид не идёт отдельно, а
относится к реляционным, но стоит его упомянуть. Коммерческие
реляционные СУБД включают в себя и этот вид как отдельную
особенность, но и существуют специализированные отдельные решения.
Основное отличие колоночных БД, что данные хранятся не в строках, а
в столбцах. Если у вас в столбце одни и те же значения, то они
очень сильно компрессируются и меньше места занимают на диске и в
памяти. Представители этого типа ClickHouse, Vertica. Эту картинку
с анимацией лучше смотреть на сайте ClickHouse.
В последнее время стала появляться в диаграммах СУБД ClickHouse
от Яндекса. Цифры разные, но то что её стали замечать и включать
уже хорошо для её развития.
Multi-model databases
Во многих СУБД, помимо основного исторического типа хранения
добавлялись новые с течением времени. Мир не стоит на месте,
поэтому если создатели СУБД видели необходимость поддержать другие
типы хранения данных, то они добавлялись. Поэтому у большинства
современных СУБД из топа в описании может присутствовать
multi-model. Перевод крупных реляционных СУБД в разряд multi-model
ограничила рост многих NoSQL решений в последние годы. Зачем
использовать что-то ещё, если нужный тип включен в основную СУБД
как вторичный.
SQL vs NoSQL
Сам термин NoSQL возник чуть более 10 лет назад примерно в 2009
году и как говорят сейчас пошёл хайп. Многие новые программные
продукты, которые были призваны решить некую проблему присущую
связке Реляционная БД + SQL гордо начали именоваться NoSQL, чтобы
показать, что они новые и продвигают невиданные доселе технологии
способные решить много проблем. А проблемы действительно были.
Нужна была возможность легко горизонтально масштабировать решения в
связи с ростом данных, которые могли прибывать в больших
количествах, объёмы данных стали резко увеличиваться. Причём стали
сохраняться данные, которые не были структурированы, например, с
сайта информация на что кликал, куда переходил пользователь, что
искал, какие элементы всплывали, баннер показывался и т.д. Всё это
сваливается и хранится. Сейчас вы и не удивляетесь, что вам упорно
показывают рекламу по теме, которая вас однажды заинтересовала, вас
уверенно ведут к воронке принятия решения, о покупке, подписке и
т.д.
График роста данных, он немного не свежий, но показывающий рост
данных более 10 лет назад.
По своему опыту скажу, в 0-вых годах оффлайн компании генерили
больше долларов выручки на 1 Gb данных в БД, чем сейчас онлайн
компания. И соотношение примерно раз в 100-200 меньше долларов на
Гб у онлайн.
Второй вытекающей из роста данных проблемой SQL были тяжелые
транзакционные операции по записи в БД и не могли достигать
показателя 10 или 100 тысяч в секунду на простом оборудовании. Я не
буду сейчас распространяться, что есть плюс, а что минус
транзакций, но оказалось, что можно ускорить транзакции, упростить
их или часто они не нужны. Не нужны если данных так много, что
потеряв некоторые вы восстановите всю картину запросто на
оставшихся данных. Не все данные важны настолько, что их частичная
потеря критична для бизнеса.
И появились простые, но эффективные NoSQL системы, которые
решают проблемы, не связанные накопленными ограничениями SQL,
работают быстро и чаще всего ещё и бесплатные. Но чудес не бывает,
поэтому часто NoSQL решения имеют ограниченный функционал или
работают быстро пока не кончится какой-нибудь ресурс, например,
оперативная память или число коннектов.
Часто можно встретить такого рода картинки классификаций NoSQL
БД по типам и с примерами СУБД. Выше мы их рассмотрели.
A что же SQL Structured Query Language структурированный язык
запросов? Он существует с начала 1970-х годов, был стандартизирован
и благодаря этим стандартам, которые поддерживают все создатели
реляционных БД минимизирует разницу в работе с разными реляционными
СУБД. Да, производители вставляют свои собственные фичи (features -
особенности), которые могут выходить за пределы стандартов SQL, так
как предлагают некую новые конкурентные технологии, если они будут
поддержаны массово, то эти новые технологии и их описание будут
включены со временем в стандарт SQL. Если вы пишете SQL запросы в
одной СУБД, то вам не составит большого труда перейти на другую и
продолжить работать с ней. Мало того, часто в клиентах NoSQL СУБД,
есть фишка в виде запросов на SQL. Например, для MongoDB я часто
использую Studio3T, где вы можете писать обычный SQL и он
переводится в специализированные запросы MongoDB, для самого
MongoDB есть SQL адаптер. ClickHouse и Tarantool (российские
разработки) поддерживают SQL запросы. Также во многих NoSQL СУБД
появились особенности присущие SQL, например, join-ы, схемы данных,
логика NULL для значений и т.д.
Cloud DBs vs DBs
Облачные технологии постепенно растут. Рост этот составляет
десятки и сотни процентов в год на разные облачные технологии.
Среди них есть и облачные БД. Если в любой области экономики есть
рост с такими цифрами значит всё больше усилий будут прилагать
компании, чтобы занять этот рынок и получить свой кусок пирога, а
дальше заинтересовать побольше клиентов и включить их в этот пирог
растущий дальше. Да, мы с вами это часть их пирога. На Хабре много
статей про облака, плюсы и минусы, чтобы не повторяться можно
почитать например, тут или в другой статье
по соответствующим тэгам.
По оценкам Gartner объём всего облачного рынка за 5 лет вырастет
в 2 раза.
Вот такие распределения по компаниям если брать BPaaS и IaaS. По
моим ощущениям очень похоже на правду. AWS лидер, Microsoft
понемногу догоняет в последние годы, Alibaba растёт и дешевле всего
на рынке Китая, который уже нельзя игнорировать глобальным
компаниям.
Рынок БД в облаке (DBaaS) выглядит в цифрах гораздо скромнее по
сравнению с цифрами всех облачных трат, при том, что каждая
компания имеет свои БД и не малые.
Объясняется это такими факторами:
-
Зачастую компании не используют специфичные облачные БД
провайдера, потому что нужно адаптировать приложения, есть
особенности, которые не позволяют это делать. Чаще сейчас
используется облачная инфраструктура, то есть вы получаете свои
виртуальные хосты с CPU, RAM, SSD(HDD) и используете её, чтобы там
установить экземпляры стандартных СУБД.
-
Компании не спешат переводить именно данные в облако, переводя
туда другие сервисы. Встаёт вопрос безопасности данных. Одно дело,
когда ваши данные в конкретном точном месте вашей сети, физических
хостингов, пускай и распределённых по миру, а другое когда вы
затолкали данные в чёрный ящик поставщика облачных услуг и вам
непонятно как, где оно хранится, как охраняется и т.д.
-
Кто столкнулся с облаками, тот знает, что траты могут возникнуть
откуда вы не ждёте и соответственно не просчитали стоимость.
Приведу пример, положить данные на хранение в холодное облачное
хранилище стоит не дорого, а вот скачать обратно уже в десятки или
сотни раз дороже. Поэтому если вы делаете бэкапы и храните их не
трогая, то это дешевле своих дисков, но вот когда захотите обратно
скачать, то сначала вы подождёте много часов до извлечения, а потом
заплатите значительную сумму за каждый Mb. И такая ситуация и для
AWS и для Azure и остальных. Вот недавняя история про NASA, когда
им аудиторы сказали, что будут платить гораздо больше. Случаи
перерасходов бюджетов от роста функционала сплошь и рядом.
-
Скорости перемещения информации из облака иногда удручают.
Например, вы сделали бэкап на одном хостинге в облако, а потом
решили поднять на другом хостинге. Это же облако. Но если вы и
подключили платную опцию, что у вас распределённое хранение данных
во многих регионах, то вас может неприятно удивить скорость
восстановления в соседнем штате США. Если бэкап на сотни Gb, то в
разы будет быстрее сделать бэкап на локальный диск, скопировать по
выделенному каналу бэкап и поднять его на другом хостинге.
-
Могут возникать небольшие изменения производительности, которые
трудно чем-то объяснить как работой соседних виртуальных хостов,
которые разделяют с вами физический хост провайдера. Если вы
работали с виртуальными хостами в локальной сети, то наверняка
сталкивались как могут влиять друг на друга загруженные виртуальные
сервера на одной физике. В своей сети вы можете на это повлиять или
сделать замеры вынося виртуальные сервера с физического
сервера.
-
Если вас подсадили на облака, то вы зависите от этого провайдера
облачных услуг, а это ещё одна точка отказа в вашей информационной
инфраструктуре. Например, Alibaba выключает ресурсы не глядя, как
только пробьёт 12 часов и что-то у вас превратится в тыкву по
причине того, что на вашем счете в облаке нет заранее добавленных
юаней.
-
В России к этому добавляется ситуация, что не так давно
проводилась масштабная блокировка зарубежных ресурсов, блокировали
многое включая IP адреса облачных БД. Это реальность и она может
быть во многих странах.
-
В связи с санкциями применяемых к России у отечественных
компаний возникают вопросы с хранением данных в облаках
американских компаний из топа. Нет гарантий, что завтра все ваши
данные не пропадут вместе с отключённым аккаунтом. Отключать
облачные аккаунты можно очень быстро и удобно.
В России есть Яндекс.Облако, SberCloud, честно не пользовался
ими в плане БД. Был опыт использования других сервисов Яндекса,
которые потом перевели в облако, поменяли протоколы и сделали
платными. Пока не заинтересовали платить деньги, так как есть
другие поставщики как Microsoft, Google, которые имеют бесплатные
квоты для небольших объёмов и есть ещё ряд преимуществ.
Подводя итоги: переход в облака идёт в мире чуть быстрее чем у
нас, мне известны целые компании на западе, которые перевели почти
всё в облака и это их стратегия, но доля таких ещё гораздо меньше
кто ещё это не сделал. Для иллюстрации вот такой график c указанием
совокупного среднегодового темпа роста.
Если вам нужно развернуть быстро в любой точке мира функционал,
то альтернативы облакам нет, но будьте готовы потом оплачивать
счета соразмерные потраченным ресурсам, про которые вы и не
подозревали. Нужно просчитывать заранее траты или пробовать в
реалиях. И безопасность в облаках ещё не убедительна.
В России цены на облачное хранение данных ниже чем в мире, но
иностранные компании не стремятся хранить здесь данные, поэтому
развиваются они чаще за счёт государственных заказчиков и не очень
большой доли компаний.
OLTP vs OLAP
Данные в БД могут использоваться для проведения текущих операций
бизнеса Online Transaction Processing (OLTP): найти клиента,
выписать счёт, оплатить ресурс, списать остаток со склада при
заказе товара и т.д. Почти все эти операции должны проводиться в
режиме реального времени. Если пользователь на сайте или во
внутрикорпоративной системе ожидает по несколько секунд простые
операции и это проблема с БД, то значит есть что оптимизировать.
OLTP изначально проектируются для ведения бизнеса в реальном
времени. Если компания имеет базы данных, то там есть OLTP.
Есть данные, которые используются для анализа работы компании
Online Analytical Processing (OLAP). То есть для OLAP собираются
большие массивы данных и чтобы их быстро просчитывать в любом
разрезе нужна простая магия по предрасчитыванию всего, что с
наибольшей вероятность может понадобится бизнесу. То есть если вы
хотите знать количества кликов на вашем глобальном сайте по странам
или страницам, то их нужно заранее просчитать да ещё делая эту
группировку по времени, чтобы потом смотреть динамику во времени,
сравнивать с историческими трендами. И OLAP хранилища могут быть не
реляционными да и вообще не структурированными, использовать
специализированные языки управления большими массивами данных, или
языки для статистической обработки данных. В последнее время стало
модно называть обычных специалистов по аналитике в бизнесе Data
Scientist. Это не совсем верно, но термин уже прижился. Обычно это
смесь из следующих ингредиентов SQL, Python, R, фреймворков для
работы с нейронными сетями, математическими моделями разного вида и
т.д.
Количество OLAP БД обычно меньше в количественном отношении чем
OLTP, но размеры их больше. Для OLAP БД важна поддержка
многопоточности, когда запрос распараллеливается между ядрами и
каждое ядро делает свою часть работы. Если ваша OLAP СУБД умеет
шардироваться на много серверов, хорошо работает с
многопоточностью, поддерживает все последние SIMD (single
instruction, multiple data) инструкции процессоров, когда за 1
операцию обрабатываются большие пакеты данных, то скорость
обработки данных увеличивается кратно на все эти множители.
Общая тенденция такая, что аналитику отделяют от данных
необходимы для операционной деятельности. Вынос аналитических
данных, обычно может состоять из выноса на отдельные сервера где
можно считать, что угодно не влияя на работу компании. Для
просчётов нейросетей и прочих тяжёлых математических моделей
используют облака с услугой облачных вычислений на
специализированных платах, например, NVidia Tesla.
SSD vs HDD vs Storage vs Tape vs Other
Эта часть о том на каких хранителях хранить данные для БД.
В 2020 году не остаётся сомнений в том, что SSD побеждают в
борьбе с HDD. В серверных системах с БД это понимание пришло
гораздо раньше, чем где либо. Всё дело в том, что в большинстве
типов БД, важно не последовательное чтение, а чтение в память из
разных мест с диска. И такая же случайная запись для данных. С этим
нет проблем у SSD, тогда как скорость доступа до случайного места
на диске у HDD достигается скоростью вращения шпинделя и скоростью
перемещения считывающего механизма между дорожками. Попробуйте
одновременно копировать несколько десятков файлов на HDD из разных
мест, скорость быстро деградирует до неприемлемых значений. Так и
запросы данных от 1000 пользователей, которые лежат в разных местах
диска быстро сведут на нет скорость любого HDD. Поэтому для
операционных OLTP систем нет большого смысла использовать HDD. На
картинке ниже обычные SSD c 6000 IOPS (операций считывания и записи
на диск в секунду), в серверных решениях особенно с NVME есть
гораздо больше, но стоит отделять маркетинговые цифры на коротких
замерах, попадающих в кэш от реальной работы диска в таком режиме
круглыми сутками.
HDD есть смысл использовать в OLAP системах, когда данные лежат
последовательно и их нужно читать и записывать только так или есть
смысл использовать для бэкапов данных, это крупная последовательная
запись и чтение. Также в больших архивных БД и везде где стоимость
хранения 1 Гб это решающая единица. HDD дешевле SSD по стоимости за
1 Гб.
По отказоустойчивости SSD лучше HDD если их рассматривать как
отдельные устройства. Это личный опыт на тысячах экземплярах.
Выходы из строя SSD гораздо реже HDD, но нужно понимать, что это
статистика по серверным моделям, многие из которых производились по
нормам SLC и MLC, стоящие дороже, позволяющие перезаписывать данные
гораздо больше раз чем продвигаемые сейчас TLC и QLC, которые не
рекомендуются для БД. Для серверных систем где хранятся БД
используют диски и комплектующие с повышенной отказоустойчивостью.
SSD диск в 1Tb и стоимостью 1000$ - это нормальная ситуация для БД.
В них заложены возможности работать месяцами на пределе, не только
много читая, но и много записывая, не перегреваясь или резко
сбрасывая скорость. Не нашлось картинки по сравнению
отказоустойчивости серверных SSD и HDD, но есть про обычные. SSD
выходят из строя реже.
Форм-фактор SSD это 2.5 дюйма устройства для горячей замены,
PCI-X карты, U.2 серверный аналог M.2, который в настольных
компьютерах. Современный протокол SSD NVME.
Storage Система Хранения Данных (СХД) - это
внешние хранилища данных, которые подключаются к серверам по
оптоволокну или сетевому интерфейсу. Хранилища ставятся в те же
серверные стойки, что и сервера и соединяются с ними. СХД это ещё
один огромный пласт информации, которого хватит на 10 статей.
Специализированное оборудование для хранения данных. Их основное
предназначение это высокая отказоустойчивость, повышенная скорость
обработки данных. Стоимости хранилищ данных начинаются от десятков
тысяч долларов за продвинутые версии и это с минимальным набором
дисков. Верхняя планка не ограничена, она может достигать и
миллионов долларов и больше. Современные СХД могут иметь в названии
слова типа AllFlash что подразумевает отказ в них от HDD и
внутренние алгоритмы и код оптимизированы только под SSD.
После поглощения EMC компания DELL упрочила своё положение на
рынке хранилищ уровня предприятий. Huawei растёт на глазах и
становится заметным игроком несмотря на санкции США. В России нет
своих хранилищ данных мирового уровня, все значимые игроки рынка
просто перемаркируют готовые изделия своей торговой маркой или
собирают из частей известных производителей или вендоров свой
вариант.
Intel Optane (3D Xpoint) специфичный вид
энергонезависимой памяти, самый быстрый на данный момент на
случайное чтение, но на случайную запись нет такого явного
преимущества, а в последовательном чтении и записи проигрывает
топовым SSD. Не развился из-за высокой цены на накопители и
отсутствия накопителей большого объёма. Так SSD+NVME обеспечивают
лучшие показатели цена/качество. За цену Optane можно купить
несколько SSD, которые в RAID будут давать большую скорость.
RAID Нет смысла повторяться для чего нужны
объединения дисков в массивы, для скорости и для
отказоустойчивости. Прочитать можно здесь. Смотря какую
задачу вы решаете, тот RAID и используется. Для OLTP БД чаще всего
встречается RAID10.
Tape ленточное хранение данных. Многие будут
удивлены, но в 2020 году ленты ещё живы. Выходят новые версии
картриджей с лентами, выпускаются огромные библиотеки хранения на
сотни картриджей. Всё объясняется тем, что стоимость хранения на
лентах продолжает быть самой низкой. Хранение плёнки не требует
электричества, длительность хранения выше чем на дисках, но
скорость доступа очень низкая и это последовательное чтение и
запись. Есть подозрение, что в облаках самые холодные хранилища
архивных данных могут использовать и ленты.
Возможности СУБД
Любые особенности СУБД это конкурентные преимущества, которые
играют роль при выборе для развёртывания её в своей инфраструктуре.
Я не буду рассматривать всем понятные темы как безошибочность
работы СУБД, поддержка разных наборов символов, сортировок для
любой страны и т.д., как должно быть лучше очевидно. Также про
стоимость было сказано выше. Разговор будет про важные и
востребованные технологии и части СУБД. На самом деле их
больше.
Горизонтальное масштабирование из коробки: Horizontal
scaling vs Vertical Scaling.
Это то, что в немалой степени определило появление множества
видов БД и СУБД в последние 10-15 лет. Если в начале 2000-x Oracle,
Microsoft, IBM вели обратную агитацию и призывали объединять
разрозненные данные из множества филиалов компаний в единый центр
где стоит мощный сервер с данными и все работают удалённо с этими
данными, включая появившиеся корпоративные сайты, Web API,
мобильных клиентов, то уже в конце 2000-x при взрывном росте данных
стало понятно, что вертикально масштабировать (покупать всё больший
сервер) стоит уже слишком дорого или уже невозможно. Упирались в
число CPU, дисков, сеть, соединений и т.д. для центральных узлов
инфраструктуры. Поэтому появились решения, позволяющие распределять
данные на множество серверов БД.
Большую роль в этом сыграли социальные сети и поисковые сайты,
которые очень быстро набирали число пользователей, контент их рос в
геометрической прогрессии, особенно после добавления файлов
мультимедиа или видео. Также важно географическое распределение
серверов, когда данные по клиентам хранят на серверах, которые
ближе к нему географически и значит время отклика быстрее.
Изначально распределение данных на множество небольших серверов
делалось на уровне приложений, потом такие возможности стали
включать в доделанные под себя движки СУБД, а дальше это стало
трендом.
Не стоит думать, что горизонтальное масштабирование решит все
ваши проблемы. Наоборот оно привнесёт усложнение всего и вся: кода,
инфраструктуры, поиска ошибок и много чего ещё. А это тоже всё
деньги. Но вам уже не понадобятся очень мощные и дорогие сервера,
ваш проект сможет пережить большие нагрузки. Отдельные узлы
хранящие данные часто называют шардами, а процесс распределения
данных и запросов между узлами шардированием. Если правильно
выбирать ключ шардирования, то запросы за данными идут только к той
шарде где они есть. Брать на себя распределение запросов может как
само приложение так и движок СУБД. Ниже на картинке пример, когда
используется hash функция для шардирования, чтобы определить какой
сервер использовать. И ещё у каждой шарды могут быть копии
(реплики).
В данный момент, не так просто купить новые 8 процессорные
сервера для пиковой производительности, их число очень ограничено
они не нужны рынку, вытеснены 4 процессорными, которые дешевле и не
в 2 раза, а больше. И если брать реальный пример, то 2 процессорный
современный сервер по мощности вычислений сопоставим или
превосходит 8 процессорный сервер 10 летней давности. Помимо
процессоров ускорились все компоненты серверов: память, шина и т.д.
Тот же самый запрос будет работать в 2-3 раза быстрее, если все
данные в памяти. СУБД очень хорошо умеют использовать ядра и
параллелить выполнение запросов.
У облачных провайдеров при росте числа ядер в виртуальном
сервере в 2 раза цена растёт быстрее чем в 2 раза и имеет место
ограничение на число ядер, потому, что провайдеру не выгодны
виртуалки, которым нужно выдавать большую часть физического
сервера, что с ним делать когда вы не нагружаете его, мощности
простаивают.
Итог: для реально
больших проектов вам понадобится горизонтальное
масштабирование, если вы не доросли до такого, то лучше не
усложняйте сервисы и БД разнесением на множество узлов, если только
в СУБД это не поддерживается совершенно прозрачно для приложений.
Проще проводить действия в оперативной памяти одного сервера чем
тащить разрозненные куски данных с разных узлов и объединять их,
чтобы получать результат.
Отказоустойчивость из коробки - High
Availability. Master-master, master-slave.
High Availability это термин когда ваш проект должен работать
всегда. Любой простой в минуту грозит прямыми или косвенными
убытками. В отказоустойчивых системах это достигается дублированием
узлов. Так поступают в космической промышленности, предотвращая
ситуацию, что выход из строя оборудования дорого обойдётся в
космосе и так поступают и на земле с важной системой в продакшене.
Дублируются важные узлы вашей инфраструктуры: сервера, хранилища
данных, сетевые коммутаторы, каналы интернет и т.д.
Для БД дублируются сервера, которые запускают СУБД как
программное обеспечение, дублируются данные, в самом простом случае
это RAID массивы из дублирующих дисков. В специализированных СХД
дублируются диски, блоки питания, процессоры, память, есть
батарейка, которая даст возможность сохранить данные из кэша на
диск.
Также для отказоустойчивости создаются online копии данных,
которые позволяют содержать актуальную информацию. Данные
синхронизируются в копию синхронно или асинхронно. Синхронно это
когда операция изменения подтверждается всеми узлами, что ведёт к
задержкам в сохранении или асинхронно, когда данные сохраняются и
потом распространяются в другое место отдельно.
Выглядит примерно так. Есть одна БД с данными, они расходятся на
остальные сервера, возможно в удалённом дата-центре. Slave-копии
могут использоваться для чтения, запросы за данными могут
направляться на копии. Называется Master-Slave.
Но рано или поздно начнёт возникать ситуация, что ваша БД не
успевает записывать. Хочется, чтобы данные могли записываться в
другой копии, она была бы не только для чтения. Эта схема
посложнее, так как нужно ещё разрешать конфликты если изменения
одинаковых данных происходит на разных узлах в одно время, а если у
вас master копии далеко, то вероятность конфликтов увеличивается.
Это называется Master-Master. Плюс у master могут быть slave
копии.
Дублирования данных на другие сервера могут быть как по всей БД,
так и по отдельным таблицам.
Хорошо, когда ваша СУБД поддерживает такое распространение
данных, на вас не ложится груз проблем как зафиксировав изменение
данных в одном месте добиваться, чтобы данные появились в другом. А
если сеть моргнула, а если копия не отвечает, и ещё много если на
себя берёт движок. Если master становится недоступным, то
происходит автоматическое перераспределение ролей, вчерашний slave
становится master, а все остальные копии принимают от него данные.
Приложение не замечает переключение, потому что работает через
роутер, который также переключается. У вас сломался сервер с БД, а
простоя нет, всё продолжает работать как ни в чём не бывало. Также
можно проводить работы с экземпляром БД выключая его из работы,
установить обновление СУБД и потом обратно ввести в работу.
Продвинутые хранилища СХД умеют копировать данные на другое
хранилище в фоновом режиме на уровне дисков. У вас просто копия
диска в другом месте. В ряде случаев можно использовать такие
копии, но обычно они не доступны даже для чтения до момента
прекращения синхронизации.
Online maintenance - online alter
24/7/365 означает, что ваш проект работает всегда 24 часа, 7
дней в неделю и все 365 дней. У вас нет окна для работ по
обслуживанию БД (maintenance). Значит все операции по созданию
архивных копий, перестройки индексов, созданию таблиц, удалению
колонок и много чего ещё, что должно проходить онлайн без заметной
деградации производительности. То есть пока вы перестраиваете
таблицу, например, удаляя колонку данных в реляционной БД, то
таблица будет доступна, а будет создаваться копия, которая будет
содержать все изменения пока идёт процесс перестройки. Не всегда
есть возможность иметь много копий серверов с БД, для платных СУБД
это ещё и деньги, чтобы проводить работы по очереди, поэтому
возможность изменений структур без прерывания работы очень
важно.
Мониторинг
Каждая интенсивно используемая и изменяемая БД рано или поздно
сталкивается с вопросами производительности. Но как понять, что
проблемы начались заранее не доводя до потери денег компаниями?
Нужно мониторить состояние вашей СУБД. Если вы можете делать замеры
текущего состояния, а ещё лучше смотреть статистику, которая
собирает сама же СУБД, то вы из коробки можете решить множество
проблем. В платных СУБД есть невероятно огромное количество метрик
и статистик, есть сторонние компании, создающие инструменты
мониторинга. Рынок очень конкурентный и в каждом инструменте есть
свои особенности. Бесплатные СУБД в последние годы сильно
улучшились в плане мониторинга и к ним тоже стали создавать
мониторинги, только часто они уже не бесплатные.
Инструменты управления СУБД
Какая бы прекрасная СУБД у вас не была, но управление ей должно
быть удобное. Конечно, всё можно делать из текстовых командных
строк, поставляемых с СУБД, но многие вещи удобнее и интуитивнее
делать из интерфейса, мало того вам не нужно помнить полный
синтаксис команды наизусть и вы не ошибётесь. У удобного
инструмента есть плагины от сторонних компаний, например,
расширенные подсказчики для набора текста, они очень помогают и
ускоряют написание кода, также вы можете щёлкать на всплывающих
подсказках и смотреть исходный код для таблиц, процедур. Ещё очень
важная функция это выполнение запросов на множестве БД
одновременно, у вас настроены коннекты сотен серверов и БД и вы
можете распространить на них изменение очень быстро работая в одном
окне. Ещё из интересного есть средства для помощи просмотра планов
исполнения запросов на стороне сервера с подсказками какие индексы
нужно построить, которые кардинально ускорят запрос.
Или для некоторых СУБД есть прекрасная возможность,
востребованная у работающих с крупными данными, когда виден %
исполнения запроса. Вы видите когда закончится запрос и выдаст
результат.
Ещё из интересного: скриптование данных это создание инструкций
SQL, которые создадут копию данных на другом сервере, миграция
данных, сравнение структур данных, сравнение данных, экспорт в
другие форматы, системы контроля версий и обновления product-среды
и т.д.
Есть инструменты, которые используются для управления разными
типами БД, например, DataGrip от JetBrains (те самые которые
причастны к Kotlin, ReSharper, GoLand и т.д.) очень мощный и
настраиваемый. Картинка СУБД, с которыми он работает.
Расширение функционала СУБД на другом языке
программирования
Какой бы мощной не была СУБД, но рано или поздно может не
хватить встроенных функций. Например, какой-то новый вид
хэширования или сжатия данных, который нужно поддержать на уровне
БД. Если в языках программирования вы скачиваете нужную библиотеку,
исходники и можете вставить вызов этого кода и не нужно придумывать
велосипед, тратить ресурсы компании, то такой же подход можно
реализовать и в СУБД. Вы можете расширить функционал СУБД из
коробки своими подключаемыми модулями и они будут работать так же
как просто как встроенные команды. Мало того, часто такие
расширения могут работать быстрее чем встроенный код самой СУБД.
Конечно, есть ряд ограничений, который накладывается на такого рода
расширения, но сам факт наличия возможности писать код на
распространённых языках программирования немаловажный плюс.
Логирование изменений
Важным вопросом бывает вопрос, а что было с данными или
структурами БД на некий момент назад. Логирование
изменений пригодится, когда вы поменяете структуры или данные, а
понадобится вернуть обратно сами данные, либо структуры таблиц,
индексы, либо код SQL в запросах. Вы будете знать, что на такой-то
момент было так. Также это предохраняет от уничтожения данных, чаще
всего непреднамеренного. В каждой СУБД название технологий разное,
для примера Flashback Data Archive, Temporal history, Change
Tracking, Data Audit и т.д.
Если ваша СУБД умеет, просто включать или выключать такое
логирование, то это то что обязательно пригодится. Но чудес не
бывает, поэтому если вы начинаете логировать, то привносите
нагрузку, например, загружаются диски, растёт размер логов, они
могут быть в БД или отдельно, если БД имеет копию, то сохранение в
БД расходится по копиям.
Бизнес-логика в БД или нет
Как БД хранит свою структуру в самой себе, так и код запросов
может храниться в БД. Планы запросов сохраняются при первом вызове,
чтобы потом находить данные по этим планам. Вносить изменения в код
языка БД проще, он компилируется на лету, то есть вы можете внести
изменение через несколько десятков секунд после принятия решения об
изменении, тогда как если вы соберётесь выложить обновление
сервиса, то вам его нужно скомпилировать, добиться правильного
обновления по всем инстансам этого сервиса. Это очень помогает в
критических ситуациях, когда счёт идёт на секунды и вы просто одним
изменением в БД можете прекратить поток нагрузки на другую
инфраструктуру.
Бизнес-логика - это ряд правил, которые влияют на всю
информационную структуру компании. Есть несколько подходов по
хранению бизнес-логики. Например, на уровне приложений (сервисов,
микро-сервисов) или если бизнес-логика в БД, то помимо хранения
данных ещё и решает интеллектуально как возвращать данные, как
накладывать фильтры, объединять данные из разных источников и т.д.
Это даёт ряд преимуществ по гибкости и скорости изменений, но
растёт нагрузка и в итоге упирается в производительность. Или,
например, вы решили запретить редактировать данные прошлых годов,
это правило легко реализуется на БД вместо того, чтобы отслеживать
все возможные способы сделать это из сервисов, программ, сайтов и
т.д. Чем больше способов управлять бизнес-логикой на БД тем лучше,
вы будете иметь разные способы решить бизнес-задачу.
Если БД нагружена, то выносится бизнес-логика на уровень
сервисов, кэшируются всеми способами результаты и т.д. БД
используется только для быстрого получения данных.
Не все БД позволяют хранить код запросов в БД, например, в
ClickHouse нет даже полноценного языка скриптов. Как организовывать
хранение бизнес-логики компания решает самостоятельно, здесь нет
универсальных правил.
Поддержка JSON
Самый скачиваемый NuGet-ом пакет в Micrsoft Visual Studio для
языка C# - это библиотека для работы с JSON (JavaScript Object
Notation). Этот пример показывает, что если нечто востребовано, то
оно будет пробиваться везде где сможет даже у Microsoft, который
исторически развивал XML. Хотя хранение в JSON противоречит
правилам реляционных БД, но реальность такова, что слишком много
данных в JSON в ИТ инфраструктуре и поддержку этого формата
вставляют в СУБД разного типа.
In Memory
Оперативная память RAM быстрее любых жёстких дисков. Поэтому для
максимального ускорения операций, в том числе с БД нужно по
максимуму использовать память. Скажу сразу, что во всех
СУБД память стараются использовать по полной и БД любого
типа работает быстрее если много памяти на сервере. Часто запись на
диск данных откладывается и не происходит непосредственно во время
проведения операции записи. Есть много технологий и в разных СУБД
они разные или могут называться по-разному, чтобы снизить число
обращений к дискам.
Какие-то СУБД поддерживают возможность In-Memory как вариант
работы, а некоторые объявляют эту возможность как главную,
например, Tarantool.
Сжатие данных
Немаловажный параметр, который позволит экономить на размерах
дисков и памяти серверов. Кроме этого сжатие ускоряет в разы
операции чтения данных, сохранения копий данных и т.д. Например для
OLAP хранилищ это значит более быстрое получение результатов
запросов по огромной массе данных. Нужно понимать, что сжатие не
бесплатно для ресурсов, но плюсов больше чем минусов, алгоритмы
сжатия используются быстрые, которые не сильно нагружают CPU.
Обычно сжатие задаётся на уровне СУБД и в работе программного
обеспечения никак не сказывается, то есть ничего не нужно менять в
коде.
Временные (temporary) объекты
Непростая логика получения данных может проходить несколько
этапов, когда формируются отдельные наборы, которые участвуют
дальше в последующей выборке. Не всегда нужно временные наборы
сохранять в полноценные данные, они могут сохраняться в памяти пока
существует коннект от клиента и не нужно думать об их высвобождении
после отключения. Это могут быть переменные, таблицы, временные
таблицы, которые видны другим коннектам. Временные объекты СУБД
стараются держать в памяти так как их предназначение говорит, что
ими быстро воспользуются и уничтожат, нет смысла фиксировать их
изменения на диск.
MapReduce
Под этим устоявшимся термином от Google будем обозначать класс
задач по распределённым вычислениям. Название идёт от двух шагов
Map распределяющего входные данные между распределёнными узлами и
Reduce получение результатов от распределённых узлов и формирование
итогового результата. Представители Apache Hadoop и Spark это целый
набор библиотек, файловой распределённой системы HDFS и много чего
ещё. Примером СУБД для работы с такими фреймворками является Hive,
реляционная СУБД с поддержкой SQL. Тренды.
Стоит сказать, что в операционных БД эти технологии не
используются. Используются в специализированных хранилищах данных,
когда есть смысл раскидывать данные и проводить распределённые
вычисления. Для большинства компаний без петабайт данных хватает
обычных СУБД с их распределением вычислений между хостами,
параллелизмом и т.д. По графикам и снижению рейтинга Hive можно
сказать, что интерес к этим технологиям как минимум не растёт
последние годы.
Работа с пространственными данными
Если необходимо находить объекты в реальном мире и чаще всего
это задача нахождения ближайших объектов по отношению к некой точке
в пространстве. Но как искать такие данные в реляционных данных? В
принципе ничего не мешает делать свои собственные способы как
искать в любом виде БД ближайшие точки, как подготавливать данные,
чтобы поиск был быстрым. Разработчики СУБД тоже увидев спрос на
такие поиски добавили технологии для пространственных индексов
(spatial index) в виде сеток или часто можно встретить реализацию
индексов с помощью R-tree дерева.
Graph data
Возможность работы с иерархическими или графовыми данными. Выше
было описание и примеры для чего часто используется представления в
виде графов.
Безопасность
Обычно БД находятся внутри защищённого контура сети. И напрямую
никто не открывает порты наружу. Если вы всё же каким-то образом
открыли доступ до сервера, то не сомневайтесь, что сначала будут
прощупывать порты, нет ли там БД известного типа и потом пытаться
сломать. Информация имеет ценность, поэтому открыть доступ к
серверам БД наружу это как выставить сейф с деньгами в окно -
странный вариант.
В самих БД есть ряд технологий, которые позволяют снизить риск
доступа к данным. Это шифрование бэкапов, когда даже украв диск с
копиями БД без пароля с ним ничего нельзя сделать. Файлы работающей
БД вы скорее всего не сможете просто прочитать, СУБД получает к ним
эксклюзивный доступ. В каждой СУБД есть разграничение прав
пользователей, группы в которые включаются пользователи, права на
разные операции на сервере СУБД включая чтение данных, запись,
изменение структур, настроек и т.д. Огромное число видов доступа
под любые задачи из реальной жизни. Доступы можно раздавать,
отнимать, явно запрещать доступ к неким ресурсам. Вопросы
безопасности - это огромный и очень интересный пласт информации не
для этой статьи. Не забывайте ставить обновления, так как
уязвимости находятся и закрываются производителями СУБД. Проводите
сторонний аудит безопасности ИТ инфраструктуры проверенными
компаниями. Вы будете неприятно удивлены когда до ваших данных
доберутся аудиторы безопасности (пентестеры), правда чаще это будет
не из-за проблем безопасности самой СУБД или вашей БД.
Использование GPU, NPU (Neural Processing Unit), Google TPU
(Tensor Processing Unit)
На современном этапе развития БД каких-то массовых использований
графических и специализированных процессоров в движках СУБД не
наблюдается. Да, GPU и NPU используются для математических
расчётов, обучения нейронных сетей, но размер оперативной памяти
GPU и NPU меньше чем у обычных серверов, а задача выборки или
обновления данных (наиболее частые в БД) не требуют огромной
вычислительной мощности. Данные из БД можно подавать на вход
специализированных фреймворков работающих с нейронными сетями для
дальнейших итераций. DPU (Data Processing Unit) это класс
процессоров не имеющего стандартов, обычно интегрированных в
сетевые карты. Их будущее ещё под вопросом.
Community
Большое сообщество единомышленников, использующих то же ПО
обеспечит вам ответы на вопросы, которые могут быть не так
тривиальны. Первое, что стоит смотреть при непонятной ошибке это
аналогичные вопросы с тем же текстом ошибки или описанием ситуации.
Для разных СУБД есть множество сайтов с авторитетными авторами. Тем
не менее приведу статистику с StackOverflow.com сколько вопросов
есть по топовым БД, на каждый может быть несколько ответов.
Наверняка Ваш вопрос будет уже с решением если сообщество большое.
Такая вот накопленная KnowledgeBase.
|
Tag
|
Count
|
|
MySQL
|
598,350
|
|
SQL Server
|
285,092
|
|
Mongodb
|
129,907
|
|
Oracle
|
122,385
|
|
Postgresql
|
117,427
|
|
sqlite
|
82,596
|
|
ms-access
|
46,177
|
|
elasticsearch
|
44,482
|
|
redis
|
18,290
|
|
db2
|
10,485
|
|
|
|
clickhouse
|
530
|
|
tarantool
|
103
|
Для общей картины, изображение связей БД, фреймворков, языков
программирования, платформ взятых . Не смотрим % использования -
это всегда причина для холиваров (holy war - священная война).
Здесь больше интересны связи, что с чем чаще входит в связь.
Красным отмечены СУБД. Куда делись Oracle и IBM DB2 это загадка на
совести составителей диаграммы.
Подведём итоги: Все СУБД из топа завоевали это
место в процессе естественного отбора и имеют свой кусок рынка.
OpenSource побеждает Commercial СУБД, в России процесс ускорился в
этом направлении. СУБД Online проектов растут в количестве отнимая
долю в выручке у оффлайн бизнеса. Реляционные БД в ближайшее время
не сдадут позиции и будут преобладать. Для управления БД будет
доминировать язык SQL. Для хранения данных операционных БД
используется флеш-память. Чем больше возможностей и особенностей у
СУБД и большее число людей использует, то тем проще её
интегрировать в инфраструктуру и поддерживать. Переход в облака БД
идёт фрагментарно, в ближайшие годы большая часть данных будет
храниться локально. Российские технологии по БД в мировом масштабе
не особо заметны, но есть такие и пожелаем им успеха.
12.04.2021 02:07:50 |
Автор: 
Категории: 
