Почему NoSQL быстрее, чем SQL?

48

Недавно меня спросили:

Почему NoSQL быстрее, чем SQL?

Я не согласился с предпосылкой вопроса ... это просто нонсенс для меня лично. Я не вижу никакого повышения производительности при использовании NoSQL вместо SQL. Может быть, SQL поверх NoSQL, да, но не так.

Я что-то упускаю из-за NoSQL?

performance nosql

— CND
источник

3

Если вы не видите повышения производительности, это то, что вы говорите. Факт заключается в том, что большинство решений NoSQL отказываются от одного (или нескольких) свойств ACID реляционной базы данных, поэтому они делают меньше.

— Одед

1

Существуют некоторые рабочие процессы (и структуры данных), которые не могут быть легко сопоставлены с традиционной реляционной базой данных с поддержкой ACID. Для них вы можете увидеть огромный рост производительности при использовании базы данных NoSQL. Однако, если вы просто возьмете существующую (хорошо спроектированную) базу данных SQL и поместите ее в базу данных NoSQL, то ваша производительность наверняка пострадает.

— Иоахим Зауэр

1

Ответ: это было установлено как быстрее? А быстрее в чем? Время разработки? Время Читать? Время записи? Какой тип записи? С чем мы сравниваем это? Многостоловые запросы? Присоединяется?

— Рольф

65

Вокруг существует множество решений NoSQL, каждое из которых имеет свои сильные и слабые стороны, поэтому следующее следует рассматривать с недоверием.

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

Конечно, вы можете сделать то же самое в SQL, и денормализация является обычной практикой, когда требуется производительность. Просто многие NoSQL-решения спроектированы с самого начала и всегда используются таким образом. Затем вы получаете обычные компромиссы: например, добавление комментария в приведенном выше примере будет медленнее, потому что вы должны сохранить весь документ вместе с ним. И как только вы денормализовали, вы должны позаботиться о сохранении целостности данных в вашем приложении.

Более того, во многих решениях NoSQL невозможно выполнять произвольные объединения, а следовательно, произвольные запросы. Некоторые базы данных, такие как CouchDB, требуют, чтобы вы заранее продумали запросы, которые вам понадобятся, и подготовили их внутри БД.

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

— Andrea
источник

4

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

— Морг.

Как я уже сказал в ответе, можно сделать то же самое в SQL; Просто, когда это становится правилом, а не исключением, базы данных NoSQL обычно быстрее и более естественны в использовании. Теоретически, SQL - лучшая модель, которую можно использовать, но когда данные растут до определенного размера, они просто не могут вместить некоторые модели, и дублирование данных становится быстрее и легче рассуждать.

— Андреа

3

Это бык. Реляционная модель охватывает все, что вы можете сделать в NoSQL, и многое другое. Единственное преимущество NoSQL заключается в том, что простой и непоследовательный подход к масштабированию встроен и прост в использовании. Это не имеет ничего общего с SQL, и все, что связано с не заботой о свойствах ACID. Вы можете иметь задания синхронизации между независимыми узлами SQL, которые будут иметь точно такие же (очень плохие) свойства масштабирования и согласованности, как и у хранилищ NoSQL. Разница в том, что узлы SQL ТАКЖЕ могут иметь согласованность, если вы решите.

— Морг.

1

Что делать, если у вас есть 5 000 000 миллионов строк данных, и вы хотите получить комментарий от всех из них по некоторым условиям. Не было бы быстрее, если бы у вас был индекс в поле комментариев таблицы с SQL? Полнотекстовая индексация еще больше улучшит это.

— Jwize

@morg - «Реляционная модель охватывает все, что вы можете сделать в NoSQL, и многое другое». Не на самом деле нет. Существует множество примеров типов данных, которые настолько плохо вписываются в реляционную модель, что встраивание данных в них приводит к огромной неэффективности. Пример: в онлайн-игре есть средство для хранения инвентаря игроков. У игроков есть ограниченный набор пронумерованных слотов, в каждом из которых может храниться один или несколько предметов определенного типа. Есть около 50 различных видов пункта, каждый из которых имеет 4-6 связанные атрибуты, с некоторым перекрытием, так что есть около 80 возможных атрибутов ...

— Жюль

27

Что вам не хватает в NoSQL, так это то, что NoSQl нельзя сравнивать с SQL никоим образом. NoSQL - это название всех технологий персистентности, которые не являются SQL. БД документов, БД ключей-значений, БД событий - все это NoSQL. Все они различаются практически во всех аспектах, будь то структура сохраненных данных, запросы, производительность и доступные инструменты.

Так что если кто-то задает вам такой вопрос на собеседовании, это должен быть ответ.

— Euphoric
источник

4

Если есть одна особенность NoSQL, я бы сказал, что это масштабируемость. Вот почему Facebook и Googles используют его. Из-за гигантского объема данных. NoSQL: когда вам приходится иметь дело с огромными объемами данных.

— Питер Б

16

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

Недостающие функции зависят от конкретного продукта, как правило, полные свойства ACID или даже операции объединения не поддерживаются. Это цена за повышенную производительность.

— Карл
источник

1

Описание NoSQL как нереляционного не является более точным. Существуют другие старые нереляционные БД, которые не попадают в категорию NoSQL. NoSQL означает гораздо больше, чем просто нереляционный. Прочтите это для получения дополнительной информации: martinfowler.com/bliki/NosqlDefinition.html

— eddyP23

8

Вы правы, было бы глупо заявить об этом в общем заявлении. Что, вероятно, весь смысл; вместо одного ответа интервьюер, вероятно, ожидает, что вы ответите на вопросы, которые помогут вам выяснить, каков контекст проблемы (какие данные, сколько их, в какой операционной среде и т. д.), конкретное решение NoSQL , Они попытаются выяснить, как вы анализируете проблемы, и по пути понять, как много вы знаете о различных решениях, которые существуют.

— Eelco
источник

Да, это общее заявление, и если мы примем его за правду, то ответ на вопрос: это зависит.

— Рольф

5

Базы данных NoSQL обычно имеют смысл только в том случае, если вы создаете свои данные на их основе.

Если вы намереваетесь просто использовать их в качестве замены СУБД, вы можете получить скорее меньшую производительность, чем большую, особенно если у вас недостаточно бюджета для оплаты серверов с большим объемом оперативной памяти.

Посмотрите на эту статью, которая сравнивает использование дискового пространства MySQL с использованием MongoDB: http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage

— Клиффорд
источник

3

Какая база данных NoSQL? Какая база данных SQL? Если кто-то скажет вам, что NoSQL быстрее, чем SQL, вам следует уйти. Или еще лучше посмотреть это видео:

http://www.youtube.com/watch?v=b2F-DItXtZs

Я не скажу, что половина вещей, заявленных о NoSQL, неправильны, но я скажу, что существует множество фанатов NoSQL от людей, которые действительно не очень хорошо понимают это.

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

— Захари К
источник

-2

NoSql поддерживается базами данных, ориентированными на столбцы, где RDBMS - это база данных, ориентированная на строки ... И скажем, например, у нас есть таблица Employee с именами, возрастом, Salery, Address, EmployeeId и т. Д. ... мы помещаем одну и ту же таблицу в MySql (поддержка RDBMS) и HBase (Поддержка NoSQL). Если клиент / клиент пишет запрос, чтобы получить данные о среднем возрасте или сале из записей сотрудников 1Lakh ... что происходит?

В RDBMS она будет проходить по каждой строке и собирает значение, сумму и деление для результата. Когда дело доходит до базы данных Columnar, не нужно беспокоиться обо всех итерациях одной строки lakh. Но имейте дело только с одной строкой, которая быстрее вычисляется. Таким образом, иногда NoSQL быстрее, чем SQL. В этом случае NoSQL не волнует, жалобы ACID стоят!

— Киран Теджа Аввару
источник

2

Я немного исправил форматирование, хотя я не уверен, что вы пытаетесь получить между ними. И ACID не всегда поддерживается RDBMS.

-3

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

Например, возьмем этот пример: у вас есть модель покупателя с множеством заказов и множеством товаров, связанных с каждым заказом, тогда у них также есть много сохраненных товаров для последующих покупок ... если вы большой интернет-магазин, скажем, с 10 миллионами клиентов и 50 миллион заказов. И этот клиент входит в свою панель управления, которая отображает эти точные данные, сколько работы базы данных sql потребуется, чтобы найти клиента, объединить заказы, каждую позицию и сохраненные позиции. В базе данных sql все эти данные, вероятно, должны быть каким-то образом объединены ... или вы можете создать в своей базе данных коллекцию под названием usercache и сохранить эти данные в точности так, как вы используете их в реальной жизни. Так что это действительно может быть один запрос к одному полю [id], чтобы получить все эти данные обратно. Кроме того, база данных nosql не

Так может ли sql db запросить одно поле Id так же быстро, если не быстрее, чем nosql? Да, но может ли база данных sql вернуть все необходимые данные, запросив одну таблицу и одно поле? Нет, если вы не сделаете что-то вроде сохранения данных в Json внутри большого текстового поля. Но теперь эти данные не могут запрашивать для потенциального использования в будущем.

— Штеффан Перри
источник