Базы данных. Тенденции общемировые и в России

Эта статья не является ответом на множество вопросов по базам данных (БД) и системам управлениям базами данных (СУБД). Я как автор выражаю своё собственное мнение о  трендах, стараясь опираться на беспристрастные показатели, статистики и т.д., но для примера приводя собственный опыт. Я не являюсь ангажированным представителем какой-либо компании и выражаю точку зрения опираясь на опыт более 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) выглядит в цифрах гораздо скромнее по сравнению с цифрами всех облачных трат, при том, что каждая компания имеет свои БД и не малые.

Объясняется это такими факторами:

  1. Зачастую компании не используют специфичные облачные БД провайдера, потому что нужно адаптировать приложения, есть особенности, которые не позволяют это делать. Чаще сейчас используется облачная инфраструктура, то есть вы получаете свои виртуальные хосты с CPU, RAM, SSD(HDD) и используете её, чтобы там установить экземпляры стандартных СУБД.

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

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

  4. Скорости перемещения информации из облака иногда удручают. Например, вы сделали бэкап на одном хостинге в облако, а потом решили поднять на другом хостинге. Это же облако. Но  если вы и подключили платную опцию, что у вас распределённое хранение данных во многих регионах, то вас может неприятно удивить скорость восстановления в соседнем штате США. Если бэкап на сотни Gb, то в разы будет быстрее сделать бэкап на локальный диск, скопировать по выделенному каналу бэкап и поднять его на другом хостинге.

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

  6.   Если вас подсадили на облака, то вы зависите от этого провайдера облачных услуг, а это ещё одна точка отказа в вашей информационной инфраструктуре. Например, Alibaba выключает ресурсы не глядя, как только пробьёт 12 часов и что-то у вас превратится в тыкву по причине того, что на вашем счете в облаке нет заранее добавленных юаней.

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

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

В России есть Яндекс.Облако, 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. Для хранения данных операционных БД используется флеш-память. Чем больше возможностей и особенностей у СУБД и большее число людей использует, то тем проще её интегрировать в инфраструктуру и поддерживать. Переход в облака БД идёт фрагментарно, в ближайшие годы большая часть данных будет храниться локально.  Российские технологии по БД в мировом масштабе не особо заметны, но есть такие и пожелаем им успеха.

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 106

    –14
    после перевода на атомарные пайплайны в монго даже не знаю зачем теперь реляционные нужны. А какой у монго под это дело sqd для строготипизированных языков — вау
      +10
      Полагаю, что специалисты, например, использующие PostgreSQL (тоже OpenSource) могут с Вами поспорить насчёт реляционных. И реляционные БД живей всех живых, об этом было в статье.) Я использую MongoDB и знаком с ней с 2010 когда её с трудом можно было пользовать, чтобы прям вау не сказал бы, но улучшается с каждым годом и растёт не просто так, есть нужные особенности.
        +10

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

          0
          Атомарные они наверное в той же степени как и все остальные фичи, которые монга обзывает атомарными и надежными. Достаточно погонять в jepsen и вскроется туча багов с потерей и порчей данных.
            0

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

              +2
              Проблема в том, что они сначала должны быть идеальными, а потом должен подниматься вопрос производительности. Иначе это не транзакции и не атомарность, а ерунда. Монга делает заявления, что все надежно и круто, прям лидеры индустрии. Это не так, по крайней мере с теми настройками, которые идут из коробки.

              Пусть они были бы не идеальными, но меня и авторов jepsen вполне бы это устроило, если бы в документации об этом прямо писали — «транзакции» есть, но не ожидайте от них надежности реальных транзакций реляционных баз данных, где действительно есть железные гарантии.
                +1

                Если даже отбросить необходимость транзакций. Предположим они совсем не нужны. У монги не нахожу преимуществ совсем. Элемпнтаные действия как то join которые все же там есть хоть и своеобразные или под чет количество строк это квест и не все его проходят. Мангус же этого не реализует. Уже не говорю об элементарном поиске по строке аналоге like. Поддерживаю несколько проектов на столе чужих. Одни траблы. А расхлябанность схеме данных совершает картину. Единственное что у монги на пять с плюсом это пиар. MEAN стек.

                  +1
                  У меня примерно тоже самое. Я каждый раз смотрю на эту монгу и думаю, чего же она так популярна. Может я чего-то теряю, что не освоил и не применил нигде ее до сих пор. Но как-то не вижу надобности работать с джисонами без схемы. Да и масштабируемость там всегда была какая-то ущербная. В итоге получается, что как-то не нахожу ей места до сих пор. Для надежности есть постгре или вот сейчас смотрим на cockroach, для жутких нагрузок какая-нить касандра, для индексации текста эластик, для кэша и оптимизаций редис. Куда тут впихнуть монгу непонятно.
                    0

                    Пример из воздуха, надо было проверить гипотезы и "пощупать данные":


                    1. на "кластер" монги из 3 машин(дев. ттх) 280 gb данных, 3 млрд записей — записывались данные и по 4 ключам-полям строился индекс 12 часов с небольшим.
                    2. Те же данные почти тем же кодом записывались в кластер эластика из большего количества серверов и сервера были условно с прода — 29 часов.
                      +1

                      Совсем не корректное сравнение. В еластике при этом строились индексы для поиска слов по всяким хитрым лингвистическим расстояниям слов (пропуски букв перестановки слов и т.п.) а в монге аж ничего. В том смысле что индексы которые строили многа это на дав-три порядка в десятичном исчислении более простые индексы чем строила эластика. А время различается в два раза всего

                        0

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

                          0
                          Эластику надо было просто сказать, чего вы от него хотите. Сказать, какие поля ему нужно индексировать и как. Из коробки он принимает все подряд и все подряд индексирует. При чем по своему желанию определяет тип индекса, обычно так, что поддерживается поиск и по полному совпадению, и подстроке, и частичному вхождению, и с учетом лингвистического анализа. Естественно это намного дольше и больше ресурсов требует.
                      +1
                      Но как-то не вижу надобности работать с джисонами без схемы

                      очевидно, что для тех случаев, когда схема меняется.
                      у меня, например, в одном проекте в json хранится лог: действие и атрибуты, список которых зависит от действия.
                      (речь не про монгу конкретно, а про «зачем может потребоваться schemaless»)

                      0

                      Не совсем понял, что не так с поиском по строке аналоге like? В монге это работает, и regexp работает. Отсутствие схемы — очень удобно, когда может прийти любой структуры документ. Индексы работают нормально, геоиндекс из коробки — отлично работает. Монга до определенных размеров очень быстро работает и на запись и на чтение. С монгой очень удобно работать, когда надо проанализировать данные, в отношении которых — не всегда очевидна структура документов, база занимает место — при определенных обстоятельствах, меньше других.

                        0

                        Работает полным перебором строк. В то же время в Postgresql bson поля индексируются и поиск идет в примеро с той же скоростью что и по простому текстовому полю

                          0

                          Не полным, постройте индекс по полю и сравните, также доступны text-search.

              0

              Каждая модель СУБД имеет свои плюшки, позволяющие наиболее эффективно решать определенные задачи.


              Реляционные СУБД по моему опыту хороши как минимум тремя вещами:


              1. SQL — это фактически стандарт. И в реляционных СУБД его поддержка завсегда лучше, чем в альтернативных, особенно когда дело касается хранения действительно больших объемов данных.
              2. Многие представления предметных областей при хранении лучше таки ложатся на реляционную модель.
              3. Реляционное представление простое и понятное во всех отношениях.

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

                +1

                Не согласен что SQL фактически стандарт — это реально стандарт

                  0

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

                    0

                    "в альтернативных СУБД часто есть механизмы доступа к данным без всякого SQL, позволяющие существенно увеличить скорость доступа на специфических задачах"
                    Но ведь prepared запрос это по сути и есть та самая альтернатива, и вы можете "переписать драйвер" и получать сырые строчки, не думаю что там прямо большие накладные расходы. Честно говоря не очень представляю чем именно sql может реально замедлить обработку, единственное чего не будет это map reduce на роды хотя и для sql как языка это работает (exadata/impala/teradata)...

                      0
                      Честно говоря не очень представляю чем именно sql может реально замедлить обработку,

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

                        0

                        Вы как-то, на мой взгляд, неправильно понимаете что такое sql, условно вы можете писать напрямую в бацткоде jvm или например на java и использовать jit оверхед по сути будет только на компиляцию (другой вариант c++ и машкоды) в принципе в теории на машкодах(ассемблере) можно быстрее на практике не всегда из них можно выжать лучший результат, потому большинство используют то что удобней. При этом не стоит забывать что часто сам overhead от подготовки плана выполнения и его исполнения по сравнению с операцтями ввода/вывода и поиска незначительный.
                        p.s. с появлением серверов с большим объёмом RAM и SSD во многих бд провели оптимизацию в связи с тем что соотношение накладных расходов поменялось и приоритеты немного сместились, причём т.к. движки больших рсубд штука не простая этот процесс шёл не быстро что позволило появится на свет многим узкоспециализированным (в т.ч. nosql ) решениям и занять нишу, за счёт лучшего использования новых возможностей оборудования. Однако сейчас если посмотреть на то что рассказывает к примеру оракл на своих конференциях, выходит что они постепенно поглощают этот функционал, а в след за ними пойдут и open source системы...

                          0
                          Вы как-то, на мой взгляд, неправильно понимаете что такое sql,

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


                          При этом не стоит забывать что часто сам overhead от подготовки плана выполнения и его исполнения по сравнению с операцтями ввода/вывода и поиска незначительный.

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


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

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

              0

              хмм… захотелось подробнее прочитать о ClickHouse от Яндекса, эта СУБД вроде вообще относительно недавняя

                +2
                Лучше сразу сказать, что это не OLTP СУБД, текущие операции бизнеса ей не поддержать, она для анализа накопленных больших данных и быстрого поиска в них. Когда интегрировали её в инфраструктуру на одном из проектов, то несколько багов открыл мой коллега, завёл в github-е issues. Нужно будет проверить всё ли пофиксили.)
                  +2
                  Если в качеству РСУБД используется PG то можно посмотреть в сторону TimescaleDB
                0

                Спасибо за статью, подчеркнул много нового для себя.

                  0
                  Я что-то пропустил: что насчёт Snowflake и ему подобных?
                    +1
                    Snowflake как представитель облачного хранения и анализа данных имеет место быть и есть кто использует, но он не топ. Amazon RDS c ядрами известных СУБД MySQL, PostgreSQL, MariaDB плюс там же Oracle и MS SQL, а также MS Azure, Azure Cosmos DB, и множество типов специфичных AWS СУБД (https://aws.amazon.com/ru/products/databases/) — это то, куда чаще смотрят если хотят облачных БД.
                      0
                      Snowflake действительно доступен только в виде облачного варианта. Но как вы правильно выделили Snowflake хорошо подходит (в силу своей природы) для анализа данных. И я бы его отнес не столько в группу облачных хранилищ, сколько в Columnstore. И в плане популярности тогда сравнивать с реляционными базами не совсем честно. Наиболее похожим хранилищем к Snowflake будет AWS Redshift. Наверно и ClickHouse тоже можно туда отнести. И среди них Snowflakе достаточно популярен и продолжает быстро расти.
                      Спасибо за статью, однозначно в избранное.
                    +1

                    Очень содержательная статья. Я только начинаю работать с бд, но мне очень понравился sql. Всегда интеесовал вопрос, а в чем различие MariaDB и MySQL, где-то я читал, что это разные базы, но кто-то говорит, что это одно и то же.

                      0
                      Да, можно считать, что на текущий момент MariaDB и MySQL примерно одинаковы по функционалу. MariaDB ветка того же проекта MySQL после поглощения его компанией Oracle. Заподозрив в попытке слить его детище Oracle основатель Майкл Видениус создал открытую MariaDB. Протоколы MariaDB полностью совместимы с MySQL, значит приложения работают также.
                      0
                      спасибо, статья очень интересная. узнал много нового о СУБД. как вы думаете, способны ли в будущем российские облачные БД вытеснить зарубежные как минимум на территории России? очевидно, в этом есть плюсы.
                        0
                        Мы не являемся законодателями мод в плане БД и облачных тоже, поэтому путь к преобладанию облачных БД из России у нас будет долгим и тернистым. Но так как в России могут принудительно крупные госкорпорации туда отправить, то этот сегмент перейдёт быстро. Если хранить данные будет дешевле и проще без существенных доработок уже существующего функционала, то бизнес сам решит посчитав деньги.
                          +2
                          Ну вот AWS и не надо вытеснять — найдите хоть один кружочек в России на этой карте: aws.amazon.com/about-aws/global-infrastructure

                          Понятно, что пользователи в России есть, но, полагаю, в основном это компании, ориентированные на западные рынки (особенно в свете недавних ковровых блокировок Роскомнадзором огромных подсетей c миллионами адресов AWS)

                          Плюсы для пользователей — это когда все ведущие компании представлены на рынке и жестко конкурируют. Тогда растет качество и падают цены. У всех облаков цены падают непрерывно — только последнее изменение биллинга лямбд в AWS до миллисекунд уменьшило у некоторых компаний счета за этот сервис в разы. Законы рынка еще никто не обманул.
                            –5

                            Не до конца могу понять комментарий. Зачем компаниям из России использовать AWS? Завтра-послезавтра могут ввести новые санкции, и тогда — мгновенно прощай данные и бизнес. Совершенно правильно делают, что не идут в AWS.

                              0
                              Затем — что это лучшее облако на рынке.
                                +1

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


                                Кстати, то же самое касается и Oracle, про который речь идёт ниже.

                              +1
                              Законы рынка еще никто не обманул.

                              Такая же бессмысленная фраза как «от судьбы еще никто не ушел»
                              +1
                              Просто оставлю это тут
                              «При сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети “Интернет”, оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации, за исключением случаев, указанных в пунктах 2, 3, 4, 8 части 1 статьи 6 настоящего Федерального закона»

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

                              И не знаю о каких плюсах вы говорите, постгрей все вышло относительно без проблем, т.к. у нее лицензия «similar to the BSD or MIT licenses», т.е. ее можно в коммерческий продукт засунуть без угрызений совести. Вот сейчас и приедет к нам весь BSD like софт, добавят к нему приставку pro и начнут натурально продавать.
                                +1

                                Сейчас бы бесплатный постгрес покупать, ага. Купить за деньги можно Postgresql pro, но, откровенно говоря, я знаю буквально единицы случаев когда поддержка и/или дополнительные плюшки pro версии перевешивали бесплатность community версии.

                                  +1

                                  Откаты никто не отменял.

                                    0

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

                                      0

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

                                        0

                                        А вы не пробовали посмотреть список основных коммитеров и кто где работает? не в таких «паразитирующих» компаниях ли подавляющее большинство? )


                                        Тут есть два факта:


                                        • разработчику postgres надо кушать;
                                        • проект большой, уделять ему пару воскресений в месяц не выйдет.

                                        По сути выход один: работодатель должен оплачивать работу над postgres'ом.

                                          0

                                          Сразу видно того, кто не особенно разбирался в данном вопросе.
                                          Community версия регулярно получает всякие плюшки из pro, просто это происходит на пару версий позже. И такой подход весьма часто встречается в различном софте. Разработчики этих самых плюшек тоже, знаете ли, хотят кушать, а работа над ними часто занимает очень много времен. Буквально на уровне несовместимости с "поковырять в свободное время".

                                        0

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

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

                                      Не туда написал.

                                      +2

                                      Ещё бы интересно было бы почитать про технические отличия разных БД (максимальные размеры БД, поддерживаемые размеры ячеек и т.д.)

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

                                          О каких именно "много ограничений" SQLite вы пишите? Желательно в сравнении с аналогичными величинами другой СУБД

                                            0

                                            Одно ограничение, которое сильно отравляет жизнь мне лично — это то, что SQLite не поддерживает Unicode. Точнее, не поддерживает, например, регистронезависимое сравнение Unicode-строк:
                                            https://sqlite.org/faq.html#q18


                                            Да, можно скомпилировать с поддержкой, но в 99% приходится работать с SQLite, скомпилированной кем-то другим (дистрибутивной), и в 99% случаев эта поддержка выключена.


                                            По-моему, были ещё какие-то неприятные нюансы с поддержкой Unicode в SQLite, но детали уже не помню.


                                            Вообще, я серьёзно SQLite не использовал, только в составе других продуктов, она много где под капотом работает. Просто один раз столкнулся с необходимостью поправить что-то в проекте, где используется SQLite, и нужен именно case-insensitive matching, и сразу же такие грабли.

                                              0
                                              Первое ограничение SQLite, которое описано в статье, что это персональная СУБД, не поддерживающая схему клиент-сервер. Обычно СУБД поддерживает тысячи коннектов от пользователей, сервисов. Это вообще библиотека, с которой программа компилируется и работает как часть приложения. Это главное, что отличает её от остальных, она для небольших БД отдельных приложений. Когда пишу код для SQLite, то иногда забываю закрывать DB Browser, где менял или смотрел структуры и запущенная программа ждёт пока не освободится БД. Данные хранятся в 1 файле. Нет процедур, которые хранятся в самой СУБД, нет настроек, прав доступа так как персональная… Много чего ещё, чем отличается от MySQL / MariaDB, PostgreSQL. Она просто другая. SQLite небольшого размера, легко используемая с базовым набором функционала работы с данными используя SQL.
                                          +1
                                          Все здорово, молодцы, было любопытно почитать. Но, граждане, столь вольное обращение с запятыми, перегруженные несогласованные предложения — где независимая вычитка? Пожалейте свою аудиторию. Спасибо!
                                            0
                                            Спасибо, Вам, за позитивный ответ! Если чем-то расстроил, то извиняюсь. Получился такой лонгрид, который быстро не прочитать. Текст честно загонял в Word на предмет глупых опечаток и прочего, модерацию пост на сайте проходил.
                                            +2

                                            ИМХО статья очень разнонаправленная и по верхам. Очень много вольностей в трактовках. Особо опечалило описание rdbms. RDBMS в отличии от всех новомодностей основны на мат модели, и выполняют требования ACID. Что делает допустимым применение только ее, например, в транзакциях денег.Все эти супер новые технологии были реализованы в том или ином виде. Как расширения.
                                            Но никто не хочет вникать. Основной тренд последних лет — не изучать, а хайповать "новые технологии". Зачем изучать теорию и методики нормализации, принципы хранения данных, проводить семантическое моделирование, изучать аналитику в sql. 99% современных тн дата саентистов, думаю, кроме простейшего селекта с группировками и не знают.
                                            Была попытка сделать объектно редакционную субд… Lotus Notes.
                                            Но, не взлетело. Тогда тоже… Трубили фанфары про конец ркляционных бд… Лет 20 назад.
                                            Так будет со всеми этими поделками.
                                            Любая мяу атака и все эти ваши тараниулы с редисками… пишут письма мелким почерком.

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

                                              Но никто не хочет вникать. Основной тренд последних лет

                                              Больше похоже, что вам не хочется вникать, если вас причина хайпа и популярности основана на нежелании что-то изучать.

                                              Любая мяу атака и все эти ваши тараниулы с редисками… пишут письма мелким почерком.

                                              При чем тут мяу атака? Она точно так же положит любой постгре и мускл, торчащий в интернет с паролей postgres:postgres. Без кэша из тарантулов и редисок все эти ваши RDBMS непригодны хоть для какого-то хайлоада. А скейлить их приходится все теми же самыми техниками из «новомодностей». Либо вообще выкидывать на помойку, чтобы не обкладывать костылями то, что не работает.
                                                +3
                                                Без кэша из тарантулов и редисок все эти ваши RDBMS непригодны хоть для какого-то хайлоада.

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

                                                Еще отдельно хотел бы упомянуть, что реальный хайлоад — штука довольно редкая и закладывать все и вся под него не стоит.
                                                  0
                                                  Согласен. Тот же Facebook как основную БД использует MySQL. Есть там и другие БД, но они вторичны. И далеко не всем реально нужны хайлоады. По своему опыту скажу, что миллиарды вызовов в день за мелкими порциями данных, сотню тысяч IOPS-ов ( особенно на SSD+NVME) переваривает RDBMS даже на 1 хосте, а ещё можно и шардировать. Но кэши нужны, и они вполне могут быть не на RDBMS.
                                                    0
                                                    Если почитать про фейсбук, то сложно назвать mysql основной базой. Всю нагрузку переваривают совсем другие компоненты (TAO), а mysql используется тупо для хранения этого всего на диске. И эти компоненты естественно все кэшируют (слоев кэширования там аж два) в памяти и в итоге работает это все как распределенная база с eventual consistency.

                                                    сотню тысяч IOPS-ов

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

                                                        uber тоже испольует mysql но это не совсем тот mysql к которому мы привыкли см. https://habr.com/ru/post/354050/

                                                        0

                                                        Специалистов по настройке Postgres/Mysql котрые могли бы оптимизировать железо/софт чтобы работало не так уж много. Для фейсбука наверное полюбому не подошло. Но ОК/ВК модно было бы скорее всего и оптимизщировать. Плюс сейчас есть направление к протоколам MySQL/Postgresql создавать кластерные БД. Уже есть как минимум три очень популярные. Они и реляционные и кластерные одновременно.

                                                          0

                                                          На мой взгляд, привлекая внимание к вк/фб и т.п. нужно не забывать о контексте в котором совершался выбор того или другого продукта для старта, начиная от даты(сервера меняются и то для чего в 2000м нужен был большой шкаф сейчас может работать в коробочке с пассивным охлаждением) и заканчивая финансовыми возможностями (может у фб с текущими доходами всё получилось бы проще на oracle и железе от ibm, только тогда это было очень дорого для них).

                                                      0

                                                      Ну вот про Tarantool вы зря так. Там, ЕМНИП, ACID by design заложен, по крайней мере в пределах одного инстанса приложения. Оно попросту однопоточное, это даже преподносилось как плюшка и одна из главных причин высокой производительности: никаких затратных межядерных синхронизаций и блокировок.


                                                      Ну и как замену "взрослым" RDBMS никто tarantool серьёзно и не позиционировал. У него другая область применения и в ней он на самом деле хорош.

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

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


                                                        Эта же ситуация приводит к тому, что Open Source лучше всего взаимодействует с Open Source. Скажем, Django может использовать возможности PostgreSQL на 100%, а возможности Oracle вряд ли хотя бы на 80% (разве что используя raw sql, да и то не факт).


                                                        Плюс, например, если кто-то решит использовать Django и Oracle, и столкнётся с какой-либо проблемой, можно предположить, сколько ответов будет при поиске вопроса: «При выполнении запроса к кластеру Oracle возвращается ошибка ORA-nnnnnn, несмотря на полную корректность запроса» — приблизительно около нуля.

                                                          +1
                                                          не понимаю за что оракулы заминусовали тебя) Действительно же все так) Разве что ошибка ORA-nnnnnn становится головной болью Оракла — они ведь поддерживают свой продукт, насколько я понимаю
                                                            0

                                                            eumorozov Всё же обычно ora-xxxx ищется сразу и часто это ресурс оракл и если это не ora-00600 то ответ очень легко получить и это очень маловероятно "корректный запрос", всё же оракл очень удачно выбрал формат нумерации ошибок…
                                                            x67 Про поддержку ну это такое если вы не человек в очень крупной компании с доступом к поддержке, проще интернет, а вот закрытый metalink это проблема (некоторые проблемы могут иметь уникальное решение которое может не входить в общие патчи, насколько я знаю).

                                                              +1

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


                                                              Но т.к. Open Source пользуются сотни миллионов, шансы найти ответ в Google, что именно означает какая-то ошибка, или как решать проблемы в какой-то конфигурации, намного выше, чем искать ответы у Oracle, пользователей которого, наверное много, но всё же на порядки меньше, а блоггеров и просто энтузиастов, делящихся в сети, и того меньше.


                                                              Подкрепить это высказывание какими-либо данными затрудняюсь. Ну вот например на StackOverflow по тегам: PostgreSQL + Django — 6,000 вопросов. По тегам Oracle + Django — 226 — меньше в 26.5 раз.


                                                              Я не знаю, как работает поддержка Oracle, ни разу не сталкивался. Но я не думаю, что невозможна эффективная разработка продукта, когда регулярно требуется куда-то звонить, кому-то что-то объяснять. И да, я так и представил, что в Oracle есть специалисты по любым конфигурациям и комбинациям продуктов. Типа, звонишь им: "У меня в node.js на ОС Fuchsia виснет коннект во время первой четверти луны". А они сразу: "Высылаем к вам нашего сотрудника, эксперта по Fuchsia, node.js и Oracle. Прибудет через 15 минут, разберется в вашей кодовой базе за 30 минут, и решит проблему за час". Это фантастика, так не бывает. Значит, в случае любой проблемы (а проблемы неизбежны, это знает каждый разработчик чего-либо), будет какое-то неэффективное и долгое взаимодействие.


                                                              К тому же, я однажды в жизни сталкивался с поддержкой SAP. Выслали специалиста за $$$$$ на место. Этот специалист продиктовал мне всё то, что я уже успел найти на их сайте до его приезда, и что и так не помогло. Чрезвычайно эффективно. Для него, у него аж по глазам было видно, как он счастлив, что его вызвали, и ему там накапало за каждый потраченный час по $$$$.

                                                                0

                                                                Проблемы на стыке, наверное у меня уже глаз замылился, но бд при использовании стандартных драйверов и sql эта не та штука которая настолько тесно интегрируется с другими продуктами что нужно искать сочетание django + bd… Тем и силён sql что он прост как… Ну по крайней мере в основном...

                                                                  +1

                                                                  Тогда я зайду с другой стороны. Опять же, повторюсь, я нигде в своей жизни не видел Oracle в production, вообще нигде, хотя работал и в маленьких, и в больших компаниях.


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


                                                                  1. Надо сразу заплатить огромные деньги, от сотен тысяч $$$ до миллионов (где-то здесь уже была шокирующая цифра), и потом продолжать платить $$$ ежегодно. Даже для больших компаний это серьёзный повод задуматься: а что мы получим за эти деньги, когда все вокруг используют PostgreSQL, MySQL, и т.д.?
                                                                  2. Надо где-то найти специалистов, выбор которых однозначно на порядок меньше. И платить этим спецам минимум в 1.5 раза больше (подозреваю, что больше, вплоть до 5 раз, на самом деле, но некогда в рабочее время искать статистику на сайтах по найму и зарплатам), т.к. они вложили во всякие курсы кучу денег и времени, кроме того, они отлично знают, что можно сыграть на sunken cost fallacy работодателя: он уже вложил миллион $$$ в лицензию на Oracle, значит можно выкручивать ему руки с зарплатой — выбросить миллион на ветер даже самая богатая компания себе не позволит, значит аргументов для торга больше.

                                                                  И для российских реалий:


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

                                                                  Так что вот ни капли не удивлён, что Oracle никто не использует.

                                                                    +1

                                                                    Про заплатить — теперь есть облака (90 т.р. в мес и у вас 4 быстрых ядра при загрузке 100% 24/7 терабайт хранения и куча плюшек(как и минусов)).
                                                                    Про специалистов, а чем оракл сложнее postgre? Настраивается элементарно, инструментов вагон и тележка, гайдов полно… Думаю высшего технического без ИТ за глаза хватит как и для большинства современных продуктов.
                                                                    p.s. и как бы я не любил opensource приходится признавать что то что в оракл часто просто работает (и даже если очень криво писать запросы) в opensource базах иногда не хочет. Мне очень нравился в своё время Firebird но по возможностям написания для внутреннего софта он сильно отставал, ведь если мы говорим не об ит компании то часто в такой компании пара специалистов и знать всё очень сложно, не говоря уже о вечном беге за отправляющимся паровозом новых технологий.

                                                                      0

                                                                      Я дальше не могу продолжать, потому что не пользовался Oracle, и все мои рассуждения только теоретические. Если раньше было время, и можно было бы попробовать какой-нибудь триал (хотя попробовать на игрушечном проекте и реальном рабочем — две большие разницы), то сейчас на это времени совсем нет, и когда оно появляется, то есть более приоритетные вещи для изучения лично для меня.


                                                                      Но в общем, у меня тот же опыт и с OpenSource. Что с PostgreSQL, что с MySQL проблем особых не было. Ну, MySQL (которая тоже Oracle теперь), недолюбливаю, потому что с ней возникали мелкие проблемки (за ut8mb3 убил бы), и она бывала туповата. С PostgreSQL вообще никогда проблем не было.


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

                                                                      +1
                                                                      Много работал с Оракл, проблем с документацией и решением кейсов не было, всё гуглилось довольно просто, топ по объяснению концепций и фичей/багов, конечно Том Кайт. Специфические критичные баги есть, многие из них, находились в металинке (багтрекере Оракла) и исправлялись очередными не установленными патчами.
                                                                      Видел использование и в больших, и в маленьких проектах. В маленьких бесплатных, как правило, не возникало обычно никаких проблем, т.к. весь базовый функционал который требуется в маленьком проекте вылизан у Оракла до идеала, проблемы могут возникать в специфике, да и то легко обходились небольшими костылями
                                                                    0

                                                                    p.s. ошибки для оракл вообще не частая вещь, за 10 лет было две, одна очень плохая — view со сложным запросом с with recursive выдавал 0 строк всегда и молча (запрос не во всю работал версия 11.2.0.х), вторая менее страшная, после обновления с 11.2.0.4 на 12.2.0.1 один сложный запрос начал падать (много with с многократным ступенчатым использованием подзапросов, не мой...) просто пришлось переписать по другому...

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

                                                                    Если покупают за чужие деньги (тонкий намек на систему откатов)

                                                                      +2

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


                                                                      И вот совершенно точно припоминаю, что когда читаешь про известные компании, у которых сервера обслуживают пользователей со всего мира, то там никогда не упоминается оракле. Тот же любимый вами AWS, Uber, Google, Facebook, Netflix, и так далее — все они почему-то Oracle не используют, насколько я знаю.


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

                                                                        0
                                                                        от же любимый вами AWS, Uber, Google, Facebook, Netflix, и так далее — все они почему-то Oracle не используют, насколько я знаю.
                                                                        Все верно. Эти компании (заметим, профильные в ИТ) с массой, сравнимой с Ораклом, могут себе позволить собственные разработки с собственной поддержкой.

                                                                        При этом платить на сторону невыгодно.
                                                                          0
                                                                          Не используют — тк он не подходит для их объемов.

                                                                          Амазон, кстати, активно использовал Оракл до последнего времени и только последние несколько лет как перешел на другие СУБД. Можно за многое ругать Ларри и его компанию, но продукт для своего времени (конец 90х-начало 2000х) был отличный.
                                                                            0
                                                                            И вот совершенно точно припоминаю, что когда читаешь про известные компании, у которых сервера обслуживают пользователей со всего мира, то там никогда не упоминается оракле. Тот же любимый вами AWS, Uber, Google, Facebook, Netflix, и так далее — все они почему-то Oracle не используют, насколько я знаю.

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


                                                                            остаётся всякий крупный не-IT бизнес, те же банки

                                                                      +2
                                                                      Про «движки» поговорили. А что насчет проектирования, есть что-то стоящее, в чем можно бесплатно рисовать базы данных?
                                                                        0
                                                                        Можно проектировать онлайн, например, в dbdiagram.io, сами создатели СУБД имеют инструменты типа Oracle SQL Developer Data Modeler, у MS есть в Management Studio, в MySQL в workbench, PostgreSQL имеет кучу бесплатных и кросс-платформенных. Специализированные инструменты умеют строить по текущей структуре схемы и деплоить после изменений. Если бесплатные чем-то не устраивают, то платных для всех топовых СУБД достаточно где есть free тариф с ограничением числа диаграмм и объектов на них.
                                                                          0
                                                                          Спасибо.

                                                                          Посмотрел dbdiagram.io, там редактор с русскими буквами не дружит (и это в 21 веке) — курсор убегает непонятно куда.
                                                                          0
                                                                          Бесплатно ничего толкового не видел. А если за деньги и для работы — то Sparx EA, PowerDesigner, ERwin (не к ночи будет помянут)
                                                                            0
                                                                            Я, когда искал программу для проектирования БД нашел pgModeler.
                                                                            Остальное бесплатное, что нашел, не понравилось.
                                                                          0
                                                                          Большое спасибо за статью, много полезной информации
                                                                            –3
                                                                            Лицензия на опернсорс БД конечно 0, зато ценник за сопровождение достигает головокружительных высот.

                                                                            Просто об этом предпочитают молчать. И на сайтах не указывать.

                                                                            Про сыр в мышеловке напоминает это
                                                                              –1
                                                                              Просто это очевидно должно быть — что если продукт бесплатен, то продукт — вы ;)
                                                                              +1
                                                                              Мне кажется что картинка с графиками объемов разных субд уже лет 10 как публикуется в одном и том же виде, только в легенде указываются разные года )
                                                                                0
                                                                                Пользуясь случаем, хочу спросить — пользовались ли вы neo4j и/или другими графовыми СУБД? Есть ли ли от них польза, и если да, то где лучше всего применять?
                                                                                  0

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

                                                                                    0
                                                                                    спасибо!
                                                                                    0
                                                                                    Очевидно, когда у вас данные — граф по природе: с кучей нодов и сложных связей между ними и вам нужно производить над ними операции, специфичные для графов (типа поиска кратчайшего пути или циклов)
                                                                                      +1
                                                                                      Ну вот конкретный пример: у меня была задача — реализовать бота в вк, который имеет многоуровневую структуру (глубину. т.е. тыкаем по кнопке — переходим в другое меню, оттуда тыкаем ещё кнопку — открывается еще одно меню и тд). Я сделал структуру дерева, и я умею хранить дерево в РСУБД, но вдруг наткнулся на neo4j и решил попробовать. Но спустя пару часов положил болт и вернулся на PostgreSQL. Оттолкнул синтаксис и медленная выборка (было что-то ещё, но уже не помню). Возможно, я рукожоп, а может, просто использовал не по назначению. Поэтому и стало интересно. Если вы использовали — можете, пожалуйста, показать конкретный пример, где neo4j (и др.) действительно показывает себя лучше? Буду сильно благодарен.
                                                                                    +1
                                                                                    Но рано или поздно начнёт возникать ситуация, что ваша БД не успевает записывать.… Это называется Master-Master.

                                                                                    Ммм, а почему вы так говорите, будто мастер1 станет писать меньше данных? С чего бы? Объём записи от появления мастер-мастер репликации не уменьшится никак. Мастер1 будет писать то что ему приложения сказали писать, плюс весь поток изменений от мастер2. Аналогично дела у мастер2. Каждая реплика будет писать совокупный объём данных, записанных на оба мастера.
                                                                                    Мастер-мастер — это совсем не про масштабирование записи. Про масштабирование записи шардинг.

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

                                                                                    Упоминание тысяч участвующих вызывает лишь улыбку. Вот PostgreSQL большой и известный проект? Как думаете, сколько человек участвует в разработке? Много наверное, со всего мира люди трудятся. Но просто посмотрим в release notes:
                                                                                    The following individuals (in alphabetical order) have contributed to this release as patch authors, committers, reviewers, testers, or reporters of issues.

                                                                                    И вот это вот всё суммарно 380 имён для 13 версии. Тысячи?

                                                                                    Тысячи разработчиков — это как раз про коммерческие СУБД. Сколько там у оракла? «38,000 developers and engineers». Даже если всего 1% из них занимается кодом базы — это по-прежнему больше в несколько раз, чем работает над кодом postgresql. А потом учесть сколько людей занимаются кодом fulltime, а кто в свободное время напишет пару patch review на интересные лично для него штуки (и уже попадёт в список контрибьюторов).
                                                                                      +1

                                                                                      1% от 38 000 человек — это как раз 380 человек

                                                                                        0
                                                                                        Вот я и сомневался, выделить ли в цитате «or reporters of issues». Если вы только сообщили о баге, но кто-то другой его исправил — вам тоже спасибо, вы тоже контрибьютор в этом году. То есть для аналогии понадобится посчитать не только сотрудников, но и всех клиентов оракла, по чьим сообщениям в саппорт что-то исправляли.

                                                                                        Возможно, конечно, что это дополнение не настолько сильно увеличит число 38000 по сравнению с уменьшением списка контрибьюторов postgresql после исключения багрепортов. Но вот предположение, что действительно только 1% работает над базой — весьма сомнительно.
                                                                                          0

                                                                                          Тут ведь как считать, есть поддержка по регионам, есть обеспечение (логистика/доставка) есть разработка оборудования (хexadata вплоть до собственных чипов) есть java есть датацентры и их сотрудники куча продуктов вокруг (аналитика и т.п.) и даже бухгалтер есть Так что ИМХО 1% это хороший процент для работы над ядром и багфиксами...

                                                                                        0
                                                                                        Ммм, а почему вы так говорите, будто мастер1 станет писать меньше данных?

                                                                                        Чтобы не возникало недопонимания дополнил текст "… ваша БД не успевает записывать из-за общей нагрузки.". Обычно помимо нагрузки на запись есть ещё нагрузка на чтение.

                                                                                        Пример с прошлой недели, проект распределен по датацентрам (и шардинг там тоже есть) начинаются очереди сообщений на RabbitMQ, мониторинг Zabbix фиксирует повышение нагрузки на разных хостах одного датацентра. Часть сайтов через переключатель CDN переводится на другой хостинг, часть остаётся и уравновешивается нагрузка. Запись идёт в оба master, они синхронизируют изменения, которых не стало меньше, но проблем стало меньше, сайты не 500-ят.

                                                                                        Упоминание тысяч участвующих вызывает лишь улыбку. Вот PostgreSQL...

                                                                                        Фраза про open source проекты в целом, никакие конкретные СУБД не упоминаются. Если вспоминать про PostgreSQL, до 13 версии тоже наверняка был кто-то.
                                                                                        0
                                                                                        Статья хорошая, хотя я не со всеми утверждениям согласен. Возможно я ошибаюсь, но БД NOSQL появились несколько раньше, чем SQL. Да это были несовершенные программы, но сделать NOSQL базу данных проще. Особенно если взять dbm/ndbm как хранилище.
                                                                                        Также несогласен в том, что хранение JSON/XML это великое благо принесённое в реляционные СУБД. Но, к сожалению вместо развития сложных типов вроде координат и геометрии реляционные СУБД пошли на хранение структурированных (JSON/XML) и типизированных данных в столбцах таблиц.
                                                                                        Впрочем, моё мнение, несмотря на всё неприятие разрушения реляционной модели не является единственно верным.
                                                                                        Также могу отметить, что мне встречались ситуации, когда реляционная СУДБ не до конца отвечала требованиям решения и приходилось создавать некий гибрид из быстрого хранилища для поглощения входящих данных, реляционной СУБД для обработки и OLAP для архива и мономерных отчётов.
                                                                                          0
                                                                                          Спасибо за Ваши комментарии.
                                                                                          … но БД NOSQL появились несколько раньше, чем SQL

                                                                                          В статье написано про термин NoSQL. Он появился уже позже. en.wikipedia.org/wiki/NoSQL
                                                                                          Также несогласен в том, что хранение JSON/XML это великое благо…

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

                                                                                        Only users with full accounts can post comments. Log in, please.