Категории RDBMS

Вариантов разделения RDBMS на категории много. Зайду с позиции практики и выбора базы на тыщу лет вперёд.
Сначала три постулата.
Во-первых, базы данных — это давно не только лишь SQL и «сделать пару запросов». Оно как внутри теперь напоминает на картинках город (погуглите [oracle 12c architecture diagram], красиво нарисовано), так и по обилию возможностей потрясает (слово сильное, но меня именно оно). В современном мире вы можете почти всю логику приложения сделать на стороне базы, снаружи оставив лишь тонкого клиента.
Во-вторых, при выходе за рамки простых SELECT вы теряете совместимость (возможность легко сменить одну базу на другую). Так же и в инфраструктуре — едва начинаете активно использовать средства репликации, мониторинга, бекапа и т.д., вы снова привязываетесь к определённой базе. Соответственно, едва выходите в production, вам с этим жить долго и счастливо.
В-третьих, если последние два года вы не следили за прогрессом в RDBMS, вы зря. Пересмотрите changelog’и, актуализируйте информацию в голове. До сих пор живы разработчики с мантрой «PostgreSQL не умеет в репликацию», это скучные разработчики, фу.
Так вот. Категорий тоже три.

Платформы. Вы большой и толстый энтерпрайз с большой нагрузкой, десятками схем, тысячами таблиц. Вам нужна RDBMS, которая всё это потянет, а также даст определённые гарантии по SLA и по живучести данных. И чтобы система безопасности была страшнее руководителя безопасников. И чтобы админы не стрелялись, ворочая этой махиной. И чтобы можно было данными оперировать с разных направлений (корпоративные порталы, бухгалтерия, админки, импорты/экспорты и т.д. — всё это отличающиеся по трудозатратам задачи). И вообще чтобы всё. Ой, и чтобы облака. И чтобы RDBMS as a service. И документации целый шкаф. И чтобы интегрировать можно было до бесконечности! И чтобы регулирующие и дестабилизирующие органы по своим ГОСТам принимали! И вон тот кусок поля под помидоры!!!
На этом рынке рулили три монстра: Oracle (Oracle Database), IBM (IBM DB2), Microsoft (MS SQL Server). С некоторых пор их двигает PostgreSQL, который выгодно отличается стоимостью поддержки, динамичнее развивается и вообще «бесплатен» при наличии энтерпрайзных возможностей.
Если угодно, это категория RDBMS уровня предприятий, где предприятия — заводы, банки, гос.учреждения и прочие масштабные ребята. Для эффективного использования требуется специально обученный персонал. Масштаб на конкретном примере: переход Я.Почты с Oracle на PostgreSQL — обратите внимание на объём данных, на RPS, на железо.

База как база. Собственно, то, с чем работает большинство разработчиков. Если у вас сайт как сайт, продукт как продукт, а то и просто надо какие-то данные где-то хранить, но от MongoDB слегка тошнит, да и честный ACID нужен, выбираете… правильно, MySQL (вместе с InnoDB, например). Справедливости ради, MySQL из штанишек вырос давным-давно. Крайне богатый SQL, нагрузку держит отлично, скорость работы вне претензий, стабильность тоже норм.
Почему не «платформа»? Давайте сразу: Oracle не будет выращивать конкурента своему платному продукту. Не будет никакого MySQL EBS, не будет MySQL Forms, умеющих работать с PM/SQL, которого тоже не будет. Вообще много чего не будет из энтерпрайза. Вы хотите хранить охрениарды данных и быстро работать с ними? Ок, вот MySQL. Вы хотите вокруг этих данных с плотной интеграцией разных частей выстраивать орбитальную станцию и продавать в аренду марсианам? Ну, если времени много и нервы титановые, у вас это получится (и получается, да). Но следующее поколение после вас покрутит пальцем у виска и ВСЁ ПЕРЕПИШЕТ.
Важно понять следующее: нет смысла сравнивать MySQL с другими в области хранения и получения данных. Он норм для этого, по иным бенчмаркам лупит ребят сверху. Проблема как его, так и в категории (в которой у MySQL нет конкурентов) начинается при выходе за границы этих потребностей. Это вот та точка, на которой постоянно буксуют джихады MySQL vs PostgreSQL. Вроде и по скорости равны. И SQL везде клёви. И так обе могут, и эдак. Да что ж за нафиг, почему одни после research’а выбирают одно, а другие другое? Да вот ровно потому и: при выборе стратегической RDBMS рассматриваются не только скорости и диалекты. И вот ровно тут MySQL так у границы топтаться и будет.
Категория RDBMS уровня небольших предприятий, одного продукта. Или огромного продукта для хранения данных без особой логической нагрузки (иными словами, половина приложения не на стороне базы в виде процедур и функций). Для эффективного использования… Тут тяжело. Все считают, что знают MySQL, простота LAMP в наших сердцах. По факту мало кто использует именно MySQL, лишь разворачивают быстренько, слегка тюнят, потом обстреливают простыми запросами. Им хватает. А так-то MySQL — сотни страниц документации и сотни features.

Базёнки. Маленькие и/или встраиваемые RDBMS. Тут веселее: SQLite, Firebird, Derby и т.д. Типичное применение — local storage в Google Chrome, туда SQLite воткнули.
Няшные тем, что кушают очень мало ресурса, но при этом вполне толковые. Понятно, что нагрузку на них не пустишь, ожидать серьёзную репликацию и failover тоже не стоит, но для своих целей всё давно уже хорошо заточено.
Категория… ну вот какая? Если вам требуется маленькое встроить или рядом поставить, но при этом чтобы не требовалось админство-админство. Пусть будет «категория RDBMS уровня модуля приложения». Квалификация персонала — встроить и забыть.

Вот как-то так. Деление условное, простое, но достаточное, чтобы включить размышлялку и подумать о том, как правильно выбирать RDBMS, на что повлияет выбор, на какие качества базы смотреть.
PS. Любопытно ещё следующее на фоне фанатских войн… Любая RDBMS что категории «платформа», что «база как база» — сложный насыщенный продукт. Споры разработчиков о том, что лучше — зачастую споры людей, которые понятия не имеют, какой уровень SQL поддерживается, при каких условиях какие lock’и и на чём, как конкретно работают виды репликации, какие особенности шардирования и т.п. Большинство из вас не использует MySQL или PostgreSQL. Вы используете условную RDBMS, в которой вам интересно малое подмножество SQL (ну откройте спецификацию языка и скажите, действительно ли вы его знаете), ну и сверху ещё несколько шняжек, с которыми у вас получилось работать. С остальным сталкивается эксплуатация (которая тоже не всегда может выделить из своих рядов специалиста), а также бойцы, которые пытаются иногда выйти за рамки «стандартного SQL». Но и среди них редко встретишь полноценного DBA, прошедшего полноценное [само]обучение по продукту (у которого 3500+ страниц документации, например). Потому споры эти бестолковы и смысла не имеют, только бы совочками помахать.

Добавить комментарий