Для расширенной операции чтения и записи MongoDB против Cassandra

mongodb cassandra redis database nosql

879 просмотра

2 ответа

338 Репутация автора

Я использовал MongoDB, но плохо знаком с Кассандрой. Я работал над приложениями, которые используют MongoDB и не очень большие приложения. Операции чтения и записи не очень интенсивны. MongoDB работал хорошо для меня в этом сценарии. Сейчас я создаю новое приложение (с некоторыми функциями, такими как переполнение стека [голосование, общее количество просмотров, предложения, комментарии и т. Д.)) С множеством параллельных операций записи по одному и тому же элементу в базу данных (в будущем!). Таким образом, согласно информации, которую я собрал через Интернет, MongoDB - не лучший выбор (но Кассандра есть). Но проблема, которую я нахожу в Кассандре, заключается в выборе правильного режима данных.

Построить модели вокруг ваших запросов. Не вокруг отношений и предметов.

Я также посмотрел на решение использования Mongo + Redis. Эффективно ли сначала обновить базу данных Mongo, а затем обновить базу данных Redis для всех нескольких запросов записи для одного и того же элемента данных.

Я хочу проверить, какой из них будет лучшим для решения этой проблемы: Монго + аттракционы или Кассандра?

Любая помощь будет высоко ценится.

Автор: Kunal Sharma Источник Размещён: 18.07.2016 12:24

Ответы (2)


3 плюса

17608 Репутация автора

Выбор базы данных очень субъективен. Я бы сказал, что современная MongoDB 3.2+, использующая новый WiredTiger Storage Engine, хорошо справляется с параллелизмом.

При выборе распределенного хранилища данных NoSQL (или SQL) вы обычно можете выбрать только два из этих трех:

  • Согласованность (все узлы видят одни и те же данные одновременно)
  • Доступность (каждый запрос получает ответ о том, успешно он или нет)
  • Допуск раздела (система продолжает работать, несмотря на произвольное разбиение из-за сбоев сети)

Это называется теорема CAP .

MongoDB имеет C и P, Cassandra имеет A и P. Cassandra также является базой данных, ориентированной на столбцы, и будет использовать немного иной подход к хранению и извлечению данных, чем, скажем, MongoDB (которая является базой данных, ориентированной на документы) , Реальность такова, что любая база данных должна легко масштабироваться в соответствии с вашими потребностями. Я бы беспокоился о том, насколько хорошо семантика хранения и поиска данных соответствует модели данных вашего приложения и насколько полезны предоставляемые функции.

Решение, какая база данных лучше для вашего приложения, очень субъективно и граничит с «основанным на мнении вопросом» о переполнении стека.

Использование Redis в качестве LRU-кэша, безусловно, является компонентом эффективной стратегии масштабирования. Типичная модель заключается в том, чтобы при чтении кэшируемых данных сначала проверять, существуют ли данные в кэше (Redis), а если нет, запрашивать их из базы данных, сохранять результат в кэше и возвращать его. Хотя в некоторых случаях это может быть уместно, просто записать все как в Redis, так и в базу данных. Вам нужно выяснить, что кэшируется и как долго должен храниться каждый кэшированный элемент, и либо кэшировать его во время чтения, как я объяснил выше, либо во время записи.

Автор: Will Размещён: 18.07.2016 12:46

0 плюса

1 Репутация автора

Это зависит только от того, для чего ваша заявка. Для обширных приложений для записи лучше использовать Cassandra

Автор: Lotchi Dagbo Размещён: 06.08.2016 12:11
Вопросы из категории :
32x32