Когда использовать / использовать случаи NoSQL?

Question

В настоящее время у нас огромное количество опций NoSQL и NoSQL в целом. И сегодня модно отказываться от RDBMS и игнорировать ее и "слепо" использовать NoSQL, учитывая, что большинство стартапов / проектов могут довольно хорошо справляться с традиционными RDBMS.

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

ОПРЕДЕЛЕНИЕ NoSQL: базы данных следующего поколения, в основном затрагивающие некоторые аспекты: нереляционные, распределенные, с открытым исходным кодом и горизонтально масштабируемые. (+ без схемы (фактически неявная схема, которая намного хуже, чем явная) и возможная согласованность).

NoSQL (по крайней мере, концепции обработки больших данных) был создан такими компаниями, как Google (BigTable), Amazon (Dynamo), Twitter и Facebook. Кассандра и Риак родились оттуда. Кажется, только MongoDB был разработан самостоятельно, без влияния на статьи, опубликованные Google и Amazon.

Но большинство компаний не работают в таких масштабах. И СУБД может быть хорошей подгонкой. Я не смог найти точный объем данных, которые MySQL или PostgreSQL могут обрабатывать с разумной производительностью (по крайней мере, PostgreSQL говорит, что в базе данных FAQ по PostgreSQL есть 32 ТБ БД).

И мы все еще можем масштабировать с помощью RDBMS. Мы можем сделать шардинг довольно легко (на уровне приложения) (хотя ребалансировка шардов является более сложной задачей, и может быть проблемой). Мы даже можем выполнять репликацию и масштабировать "чтения" таким образом (учитывая, что мы пишем только в "master"). Но в этом случае нам приходится иметь дело с распределенными проблемами: задержка репликации и возможная согласованность. Мы могли бы сделать это только для набора данных (например, только для нескольких таблиц), где задержка репликации не является проблемой / большой проблемой.

Для еще лучшей производительности может быть введено кэширование (redis или memcached).

И вы должны планировать свои запросы заранее, если это возможно, чтобы получить максимально возможную производительность от RDBMS и построить свой API поверх него, а не наоборот.

И, конечно же, в мире NoSQL нет замены ACID, и когда вам это нужно, гораздо проще использовать RDBMS, чем пытаться изобрести ACID поверх NoSQL (что из-за теоремы CAP невозможно). Хорошая сводка использования и масштабирования PostgreSQL от Braintree: Масштабирование PostgreSQL

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

Итак, каковы варианты использования NoSQL в пользу RDBMS и каков предел RDBMS, когда NoSQL будет более подходящим решением проблемы. Какие вопросы должны задать системные архитекторы, прежде чем выбрать NoSQL.

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

Answer 1

Довольно сложно ответить на этот вопрос, потому что NoSQL, в отличие от RDBMS, ничего не значит - использование NoSQL ничего не значит, не говоря, какой продукт вы собираетесь использовать. Представьте, что вам нужно разработать свою реализацию SVN для NoSQL SVN, и вы выбрали Cassandra - теперь вам нужно реализовать собственные версии файлов, обрабатывая при каждом коммите тот факт, что в прошлом может быть (возможно, много) столбец (столбцы).) удерживая предыдущую версию файла, и вы сможете легко показать историю файлов. Через некоторое время, изучая мир NoSQL, вы обнаруживаете HBase, который "похож" на Cassandra, но предлагает бесплатное управление версиями столбцов. D'о!

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

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

• производительность по согласованности

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

• нет единой точки отказа

Комментарии и пользователи после интеграции появлялись на любой странице сайта, от домашней страницы до страницы с подробностями компании. Я не смог закрыть весь сайт из-за проблем с БД. Я не работаю на Datastax, так что верьте, хотите нет, за более чем 4 года у нас не было никакого пуха (касаясь дерева) - продукт был выбран, потому что он не обнаружил "единой точки отказа" (к счастью, это правда!)

• управляемый запросом дизайн ( O(1) "сложные" запросы)

До начала моделирования данных я уже знал точные запросы, которые мне нужно было сделать.
- так запросы вроде

SELECT * FROM comments where city='ROME' and vote=3 and userid='abc' ORDER BY timestamp DESC LIMIT 100

выполняет очень быстро, потому что данные хранятся только для извлечения по конкретному запросу (вот почему в мире NoSQL вы часто слышите 1 таблица = 1 запрос)

Ура, Карло