Реляционные базы данных существуют уже более 40 лет. Они мало изменились за это время, и хотя они работают хорошо, они не смогли удовлетворить требования масштабируемости облачных приложений, которые мы встречаем повсюду. Именно здесь вмешался NoSQL, чтобы восполнить недостаток масштабируемости. Это тот момент, когда многие считают, что появление баз данных NoSQL означало смерть реляционных баз данных. Мэтт Йоковит, менеджер по опыту в Percona, которая владеет обоими типами баз данных в своем портфолио, пока не готов постепенно отказываться от реляционных баз данных. Во время обсуждения на европейском выпуске своей ежегодной конференции Percona Live в Амстердаме Мэтт объясняет свою точку зрения, говоря, что каждая база данных, которую он видел, хороша и плоха для других: «Когда у вас есть база данных, это хорошо для варианта использования. , это может быть чрезвычайно быстро, пока вы не захотите сделать что-то другое, кроме этого варианта использования». Он объясняет это, принимая пример с базами данных с колоночным хранилищем и тем, как они должны были революционизировать все, много-много лет назад. лет, когда они ворвались на основную сцену. данные. Хотя они хорошо разбираются в аналитике, пользователи быстро поняли, что они не очень хороши в обработке транзакций или даже в управлении обычными рабочими нагрузками. То же самое с NoSQL и реляционными базами данных: «Мы видим, что сегодня для этой цели создается гораздо больше баз данных. И это здорово. управлять ими всеми и начать управлять ими как единой единицей. Так что, я думаю, нет, мы не рассматриваем это как смерть отношений. Просто у отношений есть свой вариант использования.
Удобство использования
Мэтт считает, что популярность баз данных NoSQL в основном связана с простотой использования и знакомством с ними. Используя MongoDB в качестве примера, он говорит, что разработчики любят ее, потому что она предназначена для разработчиков: «Разработчики ненавидят SQL, давайте будем честными, они ненавидят SQL. Это SQL, он старый, и когда вы входите в MongoDB, ее интерфейс предоставляет вам данные. что «Это естественно для приложения, верно? Обмен данными происходит в формате, очень похожем на JSON. Итак, вы уже знаете это, потому что кодируете его. А теперь, вы знаете, база данных». Но у этого есть и обратная сторона. Мэтт говорит, что разработчики, как правило, предпочитают базы данных NoSQL для облачных приложений, потому что их легко масштабировать, что обычно называют «масштабированием кредитной карты». Он считает, что NoSQL предлагает более низкий барьер для входа, что всегда делали разработчики. Я искал: «Но это новое поколение, появившееся из мира разработки, вам не нужно было думать о базе данных, вы просто нажимаете кнопку, и вперед, и чем бы ни была кнопка, это проще. И это Это хорошо. По мере того, как приложения растут и растут, база данных становится узким местом и добавляет все больше и больше ресурсов базы данных, пока вы не сможете добавить больше». Это идеальное время для использования NoSQL. Мэтт, который работал с базами данных на протяжении всей своей карьеры, считает, что навыки разработчиков в области баз данных и технические знания уменьшаются по мере того, как они становятся более удобными для пользователя: «Вы не понимаете лежащие в основе технологии, такие проблемы, как неправильно настроенные приложения и утечка данных. "Реляционная эскалация
Одна из причин популярности баз данных NoSQL заключается в том, что они намного лучше адаптируются, чем реляционные базы данных. Мэтт считает, что каждая NoSQL или нереляционная база данных развивается немного по-своему. Говоря о масштабировании реляционных баз данных, он объяснил, что можно объединить больше ресурсов для создания более крупного экземпляра или использовать технологию кластеризации, такую как MySQL InnoDB Cluster. , ваш собственный кластер Percona ExtraDB или кластер MariaDB Galera. Хотя базы данных NoSQL, как правило, более эффективны с точки зрения размера, Мэтт говорит, что появляется много различных подходов, которые полагаются на реляционные базы данных, чтобы сделать их более эффективными: «Вы видите множество технологий, которые вы можете использовать для решения этих проблем, и вы можете получить технологии SQL и технологии NoSQL, чтобы иметь эквивалентные уровни масштабирования». Иногда вам нужны дополнительные компоненты». По-прежнему используя MongoDB для иллюстрации своей точки зрения, Мэтт объясняет, что большая часть функций изменения размера встроена по умолчанию и поэтому проще в использовании: «Пока вы работаете в MySQL, вам может понадобиться что-то реализовать. например, Vitess, или что-то вроде ProxySQL, или что-то еще, чтобы вывести вас на тот же уровень. Но опять же, это уровень легкости заставить его развиваться, а не способность или нет. "