В настоящее время нас подавляет множество вариантов NoSQL и NoSQL в целом. И сегодня модно отказываться от СУБД / игнорировать их и принимать «вслепую» NoSQL, учитывая, что большинство стартапов / проектов могут неплохо справляться с традиционными СУБД.
Начнем с определения NoSQL:
NoSQL ОПРЕДЕЛЕНИЕ: Базы данных следующего поколения в основном обращаются к некоторым пунктам: быть нереляционными, распределенными, открытыми и масштабируемыми по горизонтали. (+ схема без схемы (фактически неявная схема, которая намного хуже явной) и возможная согласованность).
NoSQL (по крайней мере, концепции обработки больших данных) был создан такими компаниями, как Google (BigTable), Amazon (Dynamo), Twitter и Facebook. Оттуда родились Кассандра и Риак. Кажется, только MongoDB была разработана самостоятельно, без влияния на статьи, опубликованные Google и Amazon.
Но большинство компаний не работают в таких масштабах. И РСУБД может подойти. Мне не удалось найти точный объем данных, который MySQL или PostgreSQL может обрабатывать с разумной производительностью (по крайней мере, PostgreSQL утверждает, что доступно 32 ТБ БД PostgreSQL FAQ).
И мы все еще можем масштабироваться с помощью РСУБД. Мы можем довольно легко выполнить сегментирование (на уровне приложения) (хотя перебалансировка сегментов более сложна и, возможно, может быть проблемой). Мы даже можем делать репликацию и масштабировать «чтение» таким образом (учитывая, что мы пишем только «мастеру»). Но в этом случае нам приходится иметь дело с распределенными проблемами: задержкой репликации и конечной согласованностью. Мы могли бы сделать это только для набора данных (например, всего нескольких таблиц), где задержка репликации не является проблемой / большой проблемой.
Для еще большей производительности можно ввести кеширование (redis или memcached).
И вы должны планировать свои запросы заранее, если это возможно, чтобы получить максимальную производительность от РСУБД и строить свой API поверх нее, а не наоборот.
И, конечно же, в мире NoSQL нет замены ACID, и когда вам это нужно, гораздо проще использовать СУБД, чем пытаться изобрести ACID поверх NoSQL (что из-за теоремы CAP невозможно). Хороший обзор использования и масштабирования PostgreSQL в Braintree: Масштабирование PostgreSQL
Еще один вариант использования СУБД - обычно вы разделяете таблицы «реального времени» на таблицы отчетов, которые могут иметь другую (более плоскую структуру), выполнять более эффективные запросы, или вы можете создавать отдельные таблицы / представления, предназначенные для быстрого чтения (но согласны, это добавляет сложности, но, по крайней мере, есть варианты).
Итак, каковы варианты использования NoSQL в пользу СУБД и каковы пределы СУБД, когда NoSQL будет более подходящим решением проблемы. Какие вопросы следует задать системным архитекторам перед тем, как выбрать NoSQL?
Я верю в простоту (хотя простота непроста), и NoSQL не так прост, как может показаться (бесплатного обеда нет) (плюс учитывая, что разработчики уже имеют долгую историю опыта работы с СУБД, и они являются более зрелыми продуктами в общие), и у вас будет свой собственный набор распределенных задач с NoSQL, не говоря уже о дополнительной оперативной работе по правильной настройке и мониторингу кластера.
