Некоторая важная информация отсутствует для ответа на вопрос: какие случаи использования должна быть в состоянии охватить базу данных? Нужно ли выполнять комплексный анализ на основе существующих данных ( OLAP ) или приложение должно обрабатывать много транзакций ( OLTP )? Какова структура данных? Это далеко от времени окончания вопроса.
На мой взгляд, неправильно принимать технологические решения на основе смелых модных слов, не зная точно, что стоит за ними. NoSQL часто хвалят за его масштабируемость. Но вы также должны знать, что горизонтальное масштабирование (по нескольким узлам) также имеет свою цену и не является бесплатным. Затем вам нужно разобраться с такими проблемами, как возможная согласованность и определить, как разрешать конфликты данных, если они не могут быть разрешены на уровне базы данных. Однако это относится ко всем системам распределенных баз данных.
Радость разработчиков со словом «меньше схемы» в NoSQL в начале тоже очень велика. Это умное слово быстро разочаровывается после технического анализа, потому что оно правильно не требует схемы при записи, но вступает в игру при чтении. Вот почему это должно быть правильно "схема на чтение". Может быть заманчиво иметь возможность писать данные по своему усмотрению. Но как мне справиться с ситуацией, если есть существующие данные, но новая версия приложения ожидает другую схему?
Модель документа (как, например, в MongoDB): не подходит для моделей данных, в которых существует много взаимосвязей между данными. Объединения должны выполняться на уровне приложения, что является дополнительным усилием и требует, чтобы я программировал то, что должна делать база данных.
Если вы утверждаете, что Google и Amazon разработали свои собственные базы данных, потому что обычные СУБД больше не могут обрабатывать поток данных, вы можете только сказать: вы не Google и Amazon. Эти компании являются лидерами, примерно в 0,01% случаев, когда традиционные базы данных больше не подходят, но для остального мира они есть.
Что немаловажно: SQL существует уже более 40 лет, и миллионы часов разработки ушли на большие системы, такие как Oracle или Microsoft SQL. Это должно быть достигнуто с помощью некоторых новых баз данных. Иногда также легче найти администратора SQL, чем кого-то для MongoDB. Что подводит нас к вопросу обслуживания и управления. Предмет, который не совсем сексуален, но является частью технологического решения.