На прошлой неделе мой друг переслал мне письмо от успешного предпринимателя, который утверждает, что “SQL мёртв”.
Предприниматель убеждён, что чрезвычайно популярные NoSQL базы данных, такие как MongoDB и Redis, медленно задушат базы данных на основе SQL, поэтому изучение SQL для специалиста по данным — это “интерес к наследию”.
Я был совершенно шокирован этим письмом: как он пришёл к настолько неверному выводу? Но в то же время мне стало любопытно… Возможно ли, что другие люди так же дезинформированы? Предпринимателя поддержали многие, он был весьма искренен — неужели новые специалисты по данным получают совет избегать SQL?
Поэтому я решил публично написать свой ответ этому предпринимателю в случае, если кто-то ещё верит в то, что SQL грозит вымирание .
Вам абсолютно точно стоит изучать SQL, если вы строите свою карьеру в науке о данных! NoSQL не влияет на ценность изучения SQL.
В принципе, есть две причины, гарантирующие, что SQL останется актуальным в течение многих десятилетий.
Причина №1: NoSQL базы данных не заменят аналитические, такие как Presto, Redshift или BigQuery.
Независимо от того, используют ваши приложения SQL-бэкенд (например, MySQL) или NoSQL-бэкенд (MongoDB и т.д.), данные из бэкенда в конечном счете будут загружены в специализированные аналитические базы данных, такие как Redshift, Snowflake, BigQuery или Presto.
Зачем компании перемещают свои данные в специализированные колоночные хранилища вроде Redshift? Потому что колоночные хранилища способны запускать аналитические запросы значительно быстрее, чем NoSQL или строчные базы данных вроде MySQL. Готов поспорить, что популярность колоночных хранилищ будет расти так же быстро, как популярность NoSQL баз данных.
То есть для специалистов по данным технология базы данных приложения — NoSQL или другие — как правило не имеет значения, потому что они не используют базу данных приложения (хотя есть некоторые исключения, о которых я расскажу ниже).
Причина №2: преимущества баз данных NoSQL не в том, что они не поддерживают язык SQL.
Оказывается, NoSQL хранилища могут реализовывать механизм запросов на основе SQL, если для них целесообразно их поддерживать. Аналогично базы данных SQL могут поддерживать языки запросов NoSQL, но предпочитают этого не делать.
Тогда почему колоночные хранилища намеренно выбирают SQL интерфейс?
Это происходит потому, что SQL невероятно силён в выражении инструкций манипулирования данными.
Рассмотрим простой пример запроса, который считает количество документов в наборе из NoSQL базы данных MongoDB.
Примечание: документы в MongoDB аналогичны строкам, а наборы — таблицам.
db.sales.aggregate( [
{
$group: {
_id: null,
count: { $sum: 1 }
}
}
] )Сравним с эквивалентом SQL:
select count(1) from sales
Очевидно, что язык SQL — лучший выбор для извлечения данных (NoSQL базы данных поддерживают другой язык, потому что SQL сравнительно сложно правильно построить для библиотек приложений, взаимодействующих с базой).
Выше я упоминал об исключениях из правила, говорящего, что для специалистов по данным не актуальна технология базы данных приложения. В моей первой компании, к примеру, в действительности не было аналитической базы данных, подобной Redshift, поэтому мне пришлось обращаться к базе приложения напрямую. (Точнее, я запрашивал копию для чтения этой базы).
В приложении компании также использовалась NoSQL база данных Redis, и как минимум один раз мне нужно было извлечь данные непосредственно из Redis, поэтому я изучил некоторые компоненты NoSQL API Redis.
Возможно, что в средах, где основное приложение использует исключительно базу данных NoSQL, знание любого SQL будет не актуально. Но подобные среды крайне редки, по мере роста компания почти наверняка будет инвестировать средства в аналитическую базу данных колоночного хранилища, поддерживающую SQL.
Читайте также:
Перевод статьи Tom Waterman: Is No-SQL killing SQL?
