Это действительно зависит от потребностей вашего приложения. Давайте рассмотрим, например, приложение чата, чтобы лучше понять, какую базу данных выбрать.
Приложение чата имеет около 50/50 операций чтения / записи. Теперь допустим, что наша база данных - это MySQL. Переходя к производству, мы создадим master / slave, потому что это топология, поддерживаемая MySQL. В какой-то момент у нас будут проблемы с производительностью, и наше узкое место окажется основным. Почему? Потому что только мастер пишет, а ведомые следуют. Каждое изменение в журнале операций базы данных передается на подчиненные устройства для репликации. Вы можете сказать ведущему только писать в него и возвращать успех и ведомые устройства для обновления асинхронного режима, но тогда ваши чтения будут несовместимы, или вы можете сказать всему кластеру, чтобы он реплицировал запись и затем возвращал ответ об успешной записи, но это дажебольше узкого места в производительности? Что я продемонстрировал? Компромиссы, которые вы должны принять в соответствии с потребностями вашего приложения. Это называется теорема CAP. В нем говорится, что вы можете выбрать в лучшем случае только 2 из 3 букв за счет оставшихся букв. CAP - согласованность, доступность, допуск на разделы.
Теперь вернемся к SQL / NoSQL.
Базы данных SQL разрешают транзакции, которые, как в контракте, говорят, либо фиксируют все, что я вам далили ничего. База данных NoSQL дает вам возможность организовать ваши данные по-другому, но они не предлагают транзакций. Вместо этого каждый из них обрабатывает чтение / запись по-своему. Например, для нашего приложения чата я бы выбрал действительно быструю запись БД, например, Cassandra (работает как журнал только для добавления). Все узлы Кассандры одинаковы, нет конфигурации главного или подчиненного, что означает, что каждый узел принимает чтение / запись. Это здорово, но у меня все еще есть проблема с непоследовательностью чтения. Что ж, эту проблему можно частично решить с помощью чего-то, что называется кворумом. По сути, это означает, что я предпочитаю более последовательное чтение в базе данных своих приложений, а не доступность, что вполне нормально и все же намного быстрее, чем MySQL. Коэффициент репликации Cassandras по умолчанию для узлов X равен X. Для 3 узлов коэффициент репликации будет равен 3, что означает, что все наши данные будут реплицированы 3 раза, а наш локальный кворум (сколько узлов должно ответить на операцию) будет равен 3. / 2 + 1 -> 2
LOCAL_QUORUM = (replication_factor/2) + 1
Таким образом, с 3 узлами каждое чтение / запись должно проходить координатор (узел, который решает, куда отправить чтение / запись) + проходить 2 узла, определенных локальнымконфигурация кворума.
Вышеприведенное было просто примером попытки с Cassandra, это очень сложная база данных, как тема о базах данных в целом.
В заключение:
ifвам нужна быстрая запись + быстрое чтение -> вы должны принять решение между согласованностью, высокой доступностью и допуском раздела + соответствующие значения базы данных.
, если вам не нужны записи и вам нужны быстрые операции чтения -> базы данных с высокой скоростьючитает + согласованность
если вам нужны транзакции -> тип SQL db
И последнее, но не менее важное, многое зависит от того, как вы моделируете свои данные иВзаимосвязь компонентов.