Ответ 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