«SQL устарел», «Традиционные реляционные базы данных больше не могут удовлетворить потребности бизнеса», «NoSQL, большие данные — продукт новой эры». Мы много слышали об этом не только в контексте баз данных, но и за их пределами. Но действительно ли это правильно? На мой взгляд, SQL не только не устарел, его свет только начался. В этой статье давайте рассмотрим, какую роль операторы SQL играют в современном процессе разработки.
Рождение #SQL
История SQL восходит к исследовательскому центру IBM 1970 года, где родились реляционные базы данных. В то время запрос данных был очень утомительной работой, требующей множества вычислений, промежуточных результатов и переплетения различных математических формул и определений. Доктор Дональд Чемберлин и Рэймонд Бойс обнаружили узкое место запроса данных и начали давать новое определение оператора запроса. Их отправной точкой является предоставление возможности людям, не имеющим математического образования, извлекать данные из базы данных с помощью операторов запросов. В то время язык C все еще был лидером языков высокого уровня.В то время разработчики SQL полагали, что они хотят разработать оператор запроса к базе данных, подобный человеческому языку.После нескольких лет напряженной работы, наконец, родился SQL в 1974 г. После этого За десятилетия SQL быстро превратился в стандартный язык баз данных.Почти все реляционные базы данных, System R, Ingres, DB2, Oracle, SQL Server, PostgreSQL и MySQL реализовали поддержку SQL.
SQL действительно работает, и его все любят, но с изобретением Интернета в 1989 году все изменилось. Мы все видели рост Интернета, меняющий темп жизни во всех отношениях. Производство данных росло в геометрической прогрессии, и люди обнаружили ограничения реляционных баз данных, жестких моделей данных, расширения серверов баз данных и так далее. Два интернет-гиганта, Google и Amazon, последовательно выпустили продукты для нереляционных баз данных: Google выпустила MapReduce в 2004 году и Bigtable двумя годами позже, а Amazon выпустила Dynamo в 2007 году. С тех пор появились нереляционные базы данных: под влиянием Bigtable и Dynamo в 2008 году была выпущена Cassandra, а в следующем году была создана нереляционная база данных на основе документов MongoDB. Поскольку эти системы представляют собой повторно реализованные продукты, они более или менее предпочитают избегать старых способов SQL.
#NoSQL Хорошая идея, плохое название
Позвольте мне сначала пояснить различия между SQL и NoSQL:
- SQL (Structured Query Language)数据库，指关系型数据库。主要代表：SQL Server，Oracle，MySQL(开源)，PostgreSQL(开源)。
- NoSQL（Not Only SQL）泛指非关系型数据库。主要代表：MongoDB，Redis，CouchDB。
Причина, по которой NoSQL развивается так быстро, в основном связана с отсутствием ограничений структуры таблиц, простотой разработки, распределенной структурой и высокой производительностью запросов. Но это принесло много негатива, одних только NoSQL видов больше 200, и выбор стал головной болью. Во-вторых, анализ данных без помощи операторов SQL сведет с ума большинство администраторов баз данных, ведь для получения результата анализа данных часто необходимо выполнить несколько шагов расчета, затем подсчитать результаты расчета и, наконец, сделать вывод. В SQL может быть предложение Проблемы, решаемые таким образом, могут быть выполнены в несколько шагов в NoSQL.
Наиболее распространенным примером является выполнение запроса к нескольким таблицам в NoSQL. Это простая и уже не простая операция в SQL. Пока несколько реляционных таблиц объединены вместе, их данные могут быть запрошены. Однако, поскольку NoSQL не имеет концепции табличной структуры, а продукты NoSQL, такие как MongoDB, рекомендуют хранить все соответствующие данные в коллекции, когда возникает необходимость запрашивать данные между несколькими коллекциями, многие люди могут решить эту проблему только на уровне приложения. но это вызывает несколько проблем: Причина, по которой NoSQL развивается так быстро, в основном связана с отсутствием ограничений структуры таблиц, простотой разработки, распределенной структурой и высокой производительностью запросов. Но это принесло много негатива, одних только NoSQL видов больше 200, и выбор стал головной болью. Во-вторых, анализ данных без помощи операторов SQL сведет с ума большинство администраторов баз данных, ведь для получения результата анализа данных часто необходимо выполнить несколько шагов расчета, затем подсчитать результаты расчета и, наконец, сделать вывод. В SQL может быть предложение Проблемы, решаемые таким образом, могут быть выполнены в несколько шагов в NoSQL.
Наиболее распространенным примером является выполнение запроса к нескольким таблицам в NoSQL. Это простая и уже не простая операция в SQL. Пока несколько реляционных таблиц объединены вместе, их данные могут быть запрошены. Однако, поскольку NoSQL не имеет концепции табличной структуры, а продукты NoSQL, такие как MongoDB, рекомендуют хранить все соответствующие данные в коллекции, когда возникает необходимость запрашивать данные между несколькими коллекциями, многие люди могут решить эту проблему только на уровне приложения. но это вызывает несколько проблем:
- 应用程序只能由开发人员维护，DBA很难对应用程序进行开发和调试。
- 应用程序层逻辑比较复杂，将多表联合操作放到里面增加了程序的维护难度。
- 由于相关数据都加载到应用程序层，这需要更多的内存来进行数据的联合操作，如果算法写的不好有可能还会出现O(n2)的时间复杂度代码，严重影响程序性能。
- 像SQL语句那样的JOIN操作转换成程序代码可能需要多次搜索数据库，这需要多次磁盘IO操作，再次影响了性能。
Конечно, для решения этой проблемы некоторые базы данных NoSQL предоставляют поддержку совместных запросов, например, MongoDB поддерживает Aggregation Framework, что можно сделать следующими способами.
db.orders.aggregate([ { $lookup: {
from: "inventory",
localField: "item",
foreignField: "sku",
as: "inventory_docs"
} } ])
Вышеприведенный код выполняет совместный запрос к таблице заказов и таблице инвентаря.Это всего лишь простой запрос.Если задействованы три или четыре таблицы, код будет более сложным.Видно, что такой оператор операции сложен для DBA понять.По сравнению с SQL Это действительно довольно сложно. Конечно, есть некоторые инструменты, которые могут помочь вам упростить вышеуказанные операции, такие какdbKodaГрафический метод запроса предоставляется следующим образом. Но такая операция все же слишком сложна.
Это не означает, что базы данных NoSQL больше не популярны, напротив, NoSQL дает нам беспрецедентный опыт. Например, традиционные реляционные базы данных основаны на дисковом хранилище, а в базах данных NoSQL мы можем выполнять неограниченное горизонтальное расширение базы данных до нескольких пользователей, тем самым избегая узких мест, вызванных скоростью диска. Расширение данных без ограничений по структуре таблиц, апгрейд - дело приятное. Но NoSQL не может существовать как язык баз данных.В мире SQL независимо от того, какая реляционная база данных поддерживает стандартные операторы SQL. Но среди множества баз данных NoSQL нет стандартного языка, который был бы совместим со всеми операциями базы данных NoSQL. Почти все продукты NoSQL основаны на собственных характеристиках и требованиях, поэтому у них мало общего, и разработчики сталкиваются с беспрецедентными трудностями при миграции баз данных. В реляционных базах данных, если вы занимаетесь разработкой Oracle и хотите перейти в лагерь SQL Server, вам придется потратить намного меньше, а стоимость обучения относительно невелика, можно сказать, что вам не нужно начинать заново. . Можно гарантировать совместимость данных, экспортируемых из реляционных баз данных, со стандартным синтаксисом SQL, который имеет уникальные преимущества при переносе данных. В отличие от NoSQL, вам в основном нужно учиться с нуля при совмещении двух разных продуктов NoSQL, и стоимость обучения всегда беспокоит большинство разработчиков. Почему я говорю, что NoSQL — это неудачное имя?Вы можете видеть, что торговая точка NoSQL заключается в том, чтобы оторваться от SQL, но он помещает множество совершенно разных типов баз данных в одно пространство имен, таких как графовая база данных Neo4j и основанная на столбцах база данных. Cassandra — это продукт совершенно другого типа, но его нужно поместить в пространство имен под названием NoSQL, что кажется неудовлетворительным. Таким образом, с этой точки зрения, развитие NoSQL столкнулось с узким местом: как высокоинтеллектуальный вид люди обязательно найдут альтернативные методы решения текущих проблем.
#Большое количество данных
Рост данных — это не только увеличение объема, но и увеличение источников данных.Интеграция данных из нескольких источников данных неизбежно приведет к таким проблемам, как несоответствие формата данных и ограничения пространства для хранения. В результате одна за другой появились платформы для работы с большими данными, среди которых Hapoop и Apache Lucene можно рассматривать как две основные платформы данных. Тем не менее, упомянутые выше проблемы существуют и для поиска больших данных.Возьмите Hadoop в качестве примера, чтобы увидеть следующий пример.Mapreduce Hadoop используется для подсчета количества вхождений одного и того же слова в статье:
public void map(Object key, Text value, Context context
) throws IOException, InterruptedException {
StringTokenizer itr = new StringTokenizer(value.toString());
while (itr.hasMoreTokens()) {
word.set(itr.nextToken());
context.write(word, one);
}
}
}
public static class IntSumReducer
extends Reducer {
private IntWritable result = new IntWritable();
public void reduce(Text key, Iterable values,
Context context
) throws IOException, InterruptedException {
int sum = 0;
for (IntWritable val : values) {
sum += val.get();
}
result.set(sum);
context.write(key, result);
}
}
public static void main(String[] args) throws Exception {
Configuration conf = new Configuration();
Job job = Job.getInstance(conf, "word count");
job.setJarByClass(WordCount.class);
job.setMapperClass(TokenizerMapper.class);
job.setCombinerClass(IntSumReducer.class);
job.setReducerClass(IntSumReducer.class);
job.setOutputKeyClass(Text.class);
job.setOutputValueClass(IntWritable.class);
FileInputFormat.addInputPath(job, new Path(args[0]));
FileOutputFormat.setOutputPath(job, new Path(args[1]));
System.exit(job.waitForCompletion(true) ? 0 : 1);
}
}
Видно, что для реализации базового запроса я не буду объяснять функцию и функцию вышеуказанного утверждения слишком много. Список здесь является просто для объяснения существования такого громоздкого функции запроса в поле NoSQL. Mapreatuce требует, чтобы разработчики написали вышеуказанный код, который приемлемо для разработчиков Java, но для DBA необходимо потребовать их для их выполнения приведенного выше кода. С точки зрения базы данных, мы также не хотим видеть такой громоздкий язык запроса базы данных.
Поэтому все больше и больше разработчиков NoSQL начали разрабатывать операторы запросов, аналогичные языкам SQL, а некоторые даже воссоздали операторы SQL в NoSQL. Например, Hive реализует операции операторов SQL в Hadoop. Например, если приведенный выше код MapReduce вместо этого Hive может быть реализован с помощью оператора, подобного следующему:
select words,count(words) CntWords from
(select explode(words) words from temp) i group by words order by CntWords desc
В дополнение к Hive, Apache Drill реализует операции SQL с различными источниками данных. Кроме того, некоторые производители реляционных баз данных также начали разрабатывать поддержку сложных структур данных и реализовывать горизонтальное расширение с помощью операторов SQL, например: ClustrixDB, DeepSQL, MemSQL и VoltDB. Некоторые поставщики облачных баз данных Amazon Aurora и Google Cloud SQL также предоставляют расширения для поддержки операторов SQL. Именно потому, что операторы SQL могут работать с большими данными, это делает работу администратора баз данных все более простой и удобной. Администратор баз данных может выполнять запросы к большим данным между тысячами узлов данных точно так же, как работать с реляционной базой данных.
#SQL возвращает Язык SQL был широко принят всеми, поэтому мы не можем обойтись без распределенной поддержки NoSQL и свободных определений структур данных. Чтобы идеально решать проблемы, с которыми сталкиваются люди, мы обязаны в определенной степени комбинировать эти два подхода. Что касается баз данных SQL и NoSQL, NoSQL приближается к реальности языка SQL или превращает базы данных SQL во что-то такое же простое, как NoSQL? делать распределенное масштабирование? Как известно любому, кто использовал реляционные базы данных, трудно представить, сколько времени потребуется MySQL, Postgres или Oracle для поддержки распределенного развертывания на сотнях или тысячах узлов. Вместо этого было бы проще, если бы NoSQL поддерживал язык SQL. Таким образом, в сочетании SQL и NoSQL представляется относительно возможным вывести SQL в область NoSQL, как уже упоминалось ранее, некоторые компании уже начали это делать, например, Hive, Apache Drill и т. д.
В области компьютерных сетей есть такой термин:网络中的细腰(узкая талия). «Тонкая талия» — это метафора, как показано на следующем рисунке:
Мне нечего сказать о структуре сети здесь? Давайте подумаем, является ли SQL в поле базы данных «тонкой талией» сетевого уровня? См. структурную схему ниже:
#резюме
SQL вернулся, да, мы не хотим писать много кода для запроса и извлечения данных, как NoSQL, мы не боимся изучать новые языки или новые технологии, но предпочитаем сохранять высокоэффективный ритм работы . Мир полон данных, а данные повсюду, на нас и позади нас. Компьютерные программные и аппаратные технологии помогают нам обрабатывать и анализировать эти данные, они могут быть спроектированы достаточно разумно, мы можем выбрать узнавание мира вокруг нас через тысячи интерфейсов, или мы можем выбрать SQL, потому что он восстанавливает баланс данных Источник питания.
#Об авторе Чжао И занимается ИТ более 10 лет после окончания Пекинского технологического института.Он работал над самыми разными проектами, включая Интернет, мобильные устройства, медицинские устройства, социальные сети и хранилища больших данных. В настоящее время работает в Southbank Software, занимается разработкой NoSQL и MongoDB. Он работал на должностях разработчиков интерфейсов и серверов, технического директора и на других должностях в GE, ThoughtWorks и Yuanqi Rabbit.