Существуют ли какие-либо РЕАЛЬНЫЕ преимущества для NoSQL над РСУБД для структурированных данных на одной машине?

Итак, я очень старался выяснить, действительно ли NoSQL приносит такую значимость вне автоматического разметки и обработки данных UNSTRUCTURED.

Предполагая, что я могу поместить мои данные STRUCTURED на одной машине или иметь эффективную функцию автоматического создания шрифтов для SQL, какие преимущества предлагают любые варианты NoSQL? Я определил следующее:

Основанный на документах (MongoDB, Couchbase и т.д.). Вне его возможностей "автоматического разметки" я с трудом понимаю, в чем преимущество. Связанные объекты очень похожи на соединения SQL, в то время как объекты Embedded значительно раздувают размер документа и вызывают проблему, связанную с репликацией (комментарий может принадлежать как столбцу, так и пользователю, поэтому данные будут избыточными). Кроме того, потеря ACID и транзакций является большим недостатком.
Основанный на значении ключа (Redis, Memcached и т.д.). Служит для использования в другом случае, идеально подходит для кеширования, но не для сложных запросов.
Columnar (Cassandra, HBase и т.д.). Похоже, что большим преимуществом здесь является то, как данные хранятся на диске и в основном полезны для скоплений, а не для общего использования.
График (Neo4j, OrientDB и т.д.). Самое интригующее, использование обоих ребер и узлов делает интересное предложение ценности, но в основном полезно для очень сложных реляционных данных, чем общее использование.

Я вижу преимущества блоков Key-value, Columnar и Graph DB для конкретных случаев использования (кэширование, сопоставление взаимосвязей социальных сетей, агрегации), но не вижу никакой причины использовать что-то вроде MongoDB для данных STRUCTURED вне его "авто-осколки".

Если SQL имеет аналогичную способность "авто-осколки", будет ли SQL бесполезным для структурированных данных? Мне кажется, это было бы, но я бы хотел, чтобы мнение сообщества...

ПРИМЕЧАНИЕ. Это касается типичного приложения CRUD, такого как социальная сеть, сайт электронной коммерции, CMS и т.д.

Ответ 1

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

. Если ваши данные хорошо вписываются в несколько небольших ведер данных, тогда база данных, ориентированная на документ. Например, на сайте объявлений у нас есть пользователи, учетные записи и листинги в качестве основных данных. Основная часть операций поиска и отображения относится только к листам. С устаревшей базой данных мы должны выполнить почти 40 операций объединения, чтобы получить данные для одного листинга. С NoSQL это один запрос. С NoSQL мы также можем создавать индексы против вложенных данных, опять же с результатами, запрошенными без Joins. В этом случае мы фактически зеркалируем данные из SQL в MongoDB для целей поиска и отображения (есть и другие причины), при этом в настоящее время разрабатывается долгосрочная стратегия миграции. ElasticSearch, RethinkDB и другие - отличные базы данных. RethinkDB на самом деле берет очень консервативный подход к данным, а ElasticSearch из индексирования коробки не имеет себе равных.
Хранилище с ключевыми значениями. Кэширование - превосходный прецедент здесь, когда вы используете веб-сайт среднего и высокого уровня, где данные в основном читаются, хорошая стратегия кэширования может помочь вам В 4-5 раз больше пользователей обрабатывается одним сервером.
Columnar - Cassandra, в частности, может использоваться для распределения значительных объемов нагрузки даже для однозначных поисков. Масштабирование Cassandra очень линейно зависит от количества используемых серверов. Отлично подходит для тяжелых сценариев чтения и записи. Я считаю это менее ценным для живых поисков, но очень хорошо, когда у вас ОЧЕНЬ высокая нагрузка и нужно распространять. Это требует гораздо большего планирования и может не соответствовать вашим потребностям. Вы можете настроить настройки, чтобы удовлетворить ваши потребности в CAP, и даже обрабатывать распространение в нескольких центрах обработки данных. ПРИМЕЧАНИЕ. Большинство приложений настоятельно не требуют такого уровня использования. ElasticSearch может быть лучше подходит для большинства сценариев, которые вы бы рассматривали как HBase/Hadoop или Cassandra для.
График. Я не так хорошо знаком с графическими базами данных, поэтому здесь не могу комментировать.

Учитывая, что вы затем комментируете MongoDB специально в сравнении с SQL... даже если оба являются автоматическими. PostgreSQL, в частности, добился больших успехов с точки зрения использования нестрогообразных данных (типы JSON/JSONB), не говоря уже о мощности, которую вы можете получить от чего-то вроде PLV8, вероятно, наиболее подходит для обработки типов нагрузок, которые вы могли бы набросать на хранилище документов с преимуществами NoSQL. Там, где это происходит, это то, что репликация, ошпаривание и восстановление после сбоя запираются на решениях, которые действительно не находятся в коробке.

Для малой и средней нагрузки осколки действительно не лучший подход. Большинство сценариев в основном читаются, поэтому наличие набора реплик, где у вас есть дополнительные узлы чтения, обычно лучше, когда у вас есть 3-5 серверов. MongoDB отлично справляется с этим сценарием, мастер node выбирается автоматически, а переход на другой ресурс довольно быстрый. Единственная странность, которую я видел, - это когда Azure спустилась в конце 2014 года, и только один из серверов появился первым, остальные два были почти 40 минут спустя. С репликацией любой заданный запрос на чтение может обрабатываться в целом одним сервером. Ваши структуры данных становятся проще, и ваши шансы на потерю данных снижаются.

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

Дело в том, что операции SQL JOIN убивают производительность, особенно при объединении данных между этими объединениями. Для одного запроса для одного пользователя это прекрасно, даже с десятком из них. Когда вы получаете до десятков объединений с тысячами одновременных пользователей, он начинает разваливаться. На этом этапе у вас есть несколько вариантов...

Кэширование- кэширование - это всегда отличный подход, и чем реже ваши данные меняются, тем лучше подход. Это может быть что угодно из набора экземпляров memcache/redis, чтобы использовать что-то вроде MongoDB, RethinkDB или ElasticSearch для хранения составных записей. Проблема здесь сводится к обновлению или аннулированию кэшированных данных.
Миграция - перенос ваших данных в хранилище данных, который лучше отражает ваши потребности, также может быть хорошей идеей. Если вам нужно обрабатывать массивные записи или очень массивные сценарии чтения, база данных SQL не может идти в ногу. Вы никогда не сможете обращаться с подобными Facebook или Twitter на SQL.
Что-то между. Поскольку вам нужно масштабировать, это зависит от того, что вы делаете, и где ваши болевые точки относятся к тому, что будет лучшим решением для данной ситуации. Многие разработчики и администраторы опасаются, что данные разбиты на несколько мест, но это часто лучший ответ. Действительно ли ваши аналитические данные должны находиться в одном месте с вашими основными операционными данными? В этом случае ваши логины должны быть тесно связаны? Вы выполняете множество взаимосвязанных запросов? Это действительно зависит.

Личные мнения вперед

Для меня мне нравится система безопасности, предоставляемая SQL. Наличие его в качестве центрального хранилища для основных данных - это мой первый выбор. Я склонен рассматривать СУБД как немое хранилище, я не люблю привязываться к данной платформе. Я чувствую, что многие люди пытаются чрезмерно нормализовать свои данные. Часто я добавляю поле XML или JSON в таблицу, чтобы можно было хранить дополнительные фрагменты данных без раздувания схемы, особенно если это вряд ли когда-либо будет запрошено... Тогда у меня будут свойства в моих объектах в коде приложения, которые хранить в этих полях. Хорошим примером может быть оплата... если в настоящее время вы используете одну систему или несколько систем (один для CC вместе с Paypal, Google, Amazon и т.д.), То детали транзакции действительно не влияют на ваши записи, зачем создавать 5 + таблицы для хранения этих подробных данных.

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

Для данных с тяжелыми данными вы хотите, чтобы в системе играли несколько систем... В значительной степени это зависит от ваших потребностей... Вам нужна быстрая работа с горячим запросом? Пойдите с ElasticSearch. Вам нужна абсолютная массивная горизонтальная шкала, HBase или Cassandra.

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

Я действительно не понял, но чувствую, что я должен упомянуть, что есть несколько решений SaaS и других поставщиков, которые предлагают гибридные системы SQL. Вы можете работать с MySQL/MariaDB локально и развертываться в системе с SQL поверх распределенного кластера хранения. Я по-прежнему считаю, что HBase или ElasticSearch лучше подходят для ведения журналов и аналитических данных, но SQL-решения на вершине также убедительны.

Подробнее: http://www.mongodb.com/nosql-explained

Ответ 2

Без схемы без хранения (или без схемы). Возможность изменять хранилище (в основном добавлять новые поля к записям) без необходимости изменять схему "объявленного" хранилища. Для РСУБД требуется явное объявление указанных "полей" и требуется явное изменение схемы до того, как будет сохранено новое "поле". Механизм свободного доступа к схемам позволяет быстро изменять приложения, просто изменять код приложения для сохранения дополнительных полей или переименовывать поля или удалять поля и выполнять.

Традиционные пользователи РСУБД считают отсутствие схемы свободным, потому что они утверждают, что в долгосрочной перспективе нужно запросить хранилище и обработать гетерогенные записи (некоторые из них имеют некоторые поля, а некоторые - другие) затрудняют обработку. Но для запуска без схемы абсолютно заманчиво, так как быстрая итерация и время выхода на рынок - все это важно (и часто это правильно).

Ответ 3

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

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

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

Допустимо ли вашему бизнесу, если сервер A не работает, и ни один из ваших пользователей не может войти в систему?

Допустимо ли вашему бизнесу, если сервер B идет вниз, и никто не может покупать вещи?

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

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

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