Когда в Redis? Когда в Монгодб? [закрытый]

то, что я хочу, это не сравнение между Redis и MongoDB. Я знаю, что они разные; производительность и API совершенно разные.

Redis очень быстрый, но API очень "атомарный". MongoDB будет есть больше ресурсов, но API очень прост в использовании, и я очень доволен этим.

Они оба потрясающие, и я хочу использовать Redis в развертывании столько, сколько могу, но это трудно кодировать. Я хочу использовать MongoDB в разработке как можно больше, но это нужна дорогая машина.

Итак, что вы думаете об использовании их обоих? Когда выбрать Redis? Когда выбрать MongoDB?

10 ответов


Я бы сказал, Это зависит от вида команды разработчиков вы и ваши потребности приложения.

например, если вам требуется много запрос, это в основном означает, что для ваших разработчиков будет больше работы использовать Redis, где ваши данные могут храниться в различных специализированных структурах данных, настроенных для каждого типа объекта для эффективности. В MongoDB те же запросы могут быть проще, потому что структура более согласована между вашими данными. С другой стороны, в Рэдис скорость ответа на эти запросы является вознаграждением за дополнительную работу по работе с различными структурами, с которыми могут храниться ваши данные.

MongoDB предлагает простоту, гораздо более короткую кривую обучения для разработчиков с традиционным опытом DB и SQL. Однако нетрадиционный подход Redis требует больше усилий для обучения, но большей гибкости.

например. А кэш слой, вероятно, может быть лучше реализован в Redis. Для более схематичных данных MongoDB лучше. [Примечание: как MongoDB, так и Redis технически не имеют схем]

Если вы спросите меня, мой личный выбор-Redis для большинства требований.

наконец, я надеюсь, что вы уже видели http://antirez.com/post/MongoDB-and-Redis.html


Я только что заметил, что этот вопрос довольно старый. Тем не менее, я считаю, что стоит добавить следующие аспекты:

  • используйте MongoDB, если вы еще не знаете, как вы собираетесь запросить свои данные.

    MongoDB подходит для хакатонов, стартапов или каждый раз, когда вы не знаете, как вы будете запрашивать вставленные данные. MongoDB не делает никаких предположений о вашей базовой схеме. Хотя MongoDB является схематичным и нереляционным, это не означает, что схемы вообще нет. Это просто означает, что ваша схема должна быть определена в вашем приложении (например, с помощью Мангуста). Кроме того, MongoDB отлично подходит для прототипирования или тестирования вещей. Его производительность не так велика и не может сравниться с Redis.

  • используйте Redis для ускорения существующего приложения.

    Redis можно легко интегрировать как кэш LRU. Очень редко используется Redis в качестве автономной системы баз данных (некоторые люди предпочитают ссылаться на него как на"ключ-значение" -магазин). Такие сайты, как Craigslist use Redis рядом с их основной базой данных. Antirez (разработчик Redis) продемонстрировал с помощью Lamernews, что действительно можно использовать Redis в качестве автономной системы баз данных.

  • Redis не делает никаких предположений на основе ваших данных.

    Redis предоставляет кучу полезных структур данных (например, наборы, хэши, списки), но вы должны четко определить, как вы хотите сохранить ваши данные. Короче говоря, Redis и MongoDB можно использовать для достижения подобных вещей. Redis просто быстрее, но не подходит для прототипирования. Это один из вариантов использования, где вы обычно предпочитаете MongoDB. Кроме того, редис действительно гибкий. Базовые структуры данных, которые он предоставляет, являются строительными блоками высокопроизводительных систем БД.

когда использовать Рэдис?

  • кэширование

    кэширование с помощью MongoDB просто не имеет большого смысла. Это будет слишком медленно.

  • Если у вас есть достаточно времени, чтобы подумать о своем дизайне ДБ.

    вы не можете просто бросить свои документы в Redis. Вы должны думать о том, как вы хотите хранить и организовывать свои данные. Например, хэши в Redis. Они сильно отличаются от" традиционных", вложенных объектов, что означает вам придется пересмотреть способ хранения вложенных документов. Одним из решений было бы сохранить ссылку внутри хэша на другой хэш (что-то вроде ключ: [идентификатор второго хеш]). Другой идеей было бы сохранить его как JSON, что кажется противоречащим интуиции большинству людей с *SQL-фоном.

  • Если вам нужно действительно высокая производительность.

    избиение производительности Redis обеспечивает почти невозможно. Представляю вам базу быть так же быстро, как ваш кэш. Вот что значит использовать Redis как реальные


Redis. Предположим, вы написали сайт на php; по какой-то причине он становится популярным, и он опережает свое время или имеет порно на нем. Вы понимаете, что этот php настолько чертовски медленный: "я потеряю своих поклонников, потому что они просто не будут ждать 10 секунд для страницы."Вы внезапно осознаете, что веб-страница имеет постоянный url (он никогда не меняется, вау), первичный ключ, если хотите, а затем вы вспоминаете, что память быстрая, а диск медленный, а php еще медленнее. : (Затем вы создаете хранилище механизм, использующий память и этот URL, который вы называете "ключом", в то время как содержимое веб-страницы вы решаете назвать "значением".- Это все, что у тебя есть-ключ и содержание. Вы называете это "кэш мемов".- Тебе нравится Ричард Докинз, потому что он потрясающий. Вам кэш ваш HTML как белки кэш свои орехи. Вам не нужно переписывать свой дерьмовый php-код. Вы счастливы. Затем вы видите, что это сделали другие-но вы выбираете Redis, потому что у другого есть запутанные образы кошек, некоторые с клыками.

Монго. Вы написали сайт. Черт возьми, вы написали много, и на любом языке. Вы понимаете, что большая часть вашего времени тратится на написание этих вонючих SQL-предложений. Вы не dba, но все же вы пишете глупые SQL-операторы... не один, а везде. "Выберите это, выберите то". Но в частности вы помните раздражающий пункт WHERE. Где фамилия равна "Торнтон", а фильм - "Плохой Санта"."Ух. Вы думаете: "почему бы этим dbas просто не сделать свою работу и дать мне некоторые сохраненные процедуры?"Затем вы забываете какое-то второстепенное поле, такое как middlename, а затем вы должны удалить таблицу, экспортировать все 10G больших данных и создать другое с этим новым полем и импортировать данные-и это продолжается 10 раз в течение следующих 14 дней, когда вы продолжаете помнить дерьмо, такое как приветствие, название, плюс добавление внешнего ключа с адресами. Тогда вы считаете, что фамилия должна быть фамилия. Почти одна смена в день. Тогда ты говоришь "черт". Я должен получить и написать веб-сайт / систему, не важно это модель данных БС. Итак, Вы google: "я ненавижу писать SQL, пожалуйста, не SQL, остановите его", но всплывает "nosql", а затем вы читаете некоторые вещи, и он говорит, что просто сбрасывает данные без какой-либо схемы. Вы помните фиаско на прошлой неделе, уронив больше столов, и улыбаетесь. Затем вы выбираете mongo, потому что некоторые большие ребята, как "airbud" сайт аренды квартиры использует его. Сладкий. Больше никаких изменений модели данных, потому что у вас есть модель, которую вы просто продолжаете изменять.


возможно, этот ресурс полезен, помогая решить между обоими. Он также обсуждает несколько других баз данных NoSQL и предлагает краткий список характеристик вместе с "для чего я бы его использовал" объяснение для каждого из них.

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis


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

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

с учетом сказанного, MongoDB не требует дорогостоящего оборудования. Как и любое другое решение базы данных, он будет работать лучше с большим количеством процессора и памяти, но, безусловно, не требование, особенно для целей раннего развития.


Redis - это в хранилище данных, которые могут persist это состояние на диск (для восстановления после перезагрузки). Однако, будучи хранилищем данных в памяти, размер хранилища данных (на одном узле) не может превышать общее пространство памяти в системе (физическая ОЗУ + пространство подкачки). На самом деле, это будет намного меньше, так как Redis разделяет это пространство со многими другими процессами в системе, и если он исчерпает пространство системной памяти, это, вероятно, будет убит операционной системой.

Монго-это диска хранилище данных, которое наиболее эффективно, когда оно рабочий набор подходит для физической ОЗУ (как и все программное обеспечение). Будучи дисковыми данными, нет никаких внутренних ограничений на размер базы данных Mongo, однако параметры конфигурации, доступное дисковое пространство и другие проблемы могут означать, что размеры баз данных более определенного предела могут стать непрактичными или неэффективными.

оба Redis и Mongo может быть кластеризован для обеспечения высокой доступности, резервного копирования и увеличения общего размера хранилища данных.


все ответы (на момент написания этой статьи) предполагают, что каждый из Redis, MongoDB и, возможно, реляционная база данных на основе SQL по существу являются одним и тем же инструментом: "хранить данные". Они вообще не рассматривают модели данных.

MongoDB: Сложные Данные

MongoDB-это хранилище документов. Для сравнения с реляционной базой данных, управляемой SQL: реляционные базы данных упрощаются до индексированных файлов CSV, каждый файл является таблицей; хранилища документов упрощаются до индексированных файлов JSON, каждый файл, являющийся документом, с несколькими файлами, сгруппированными вместе.

JSON-файлы похожи по структуре на XML и YAML-файлы, а также на словари, как в Python, поэтому подумайте о своих данных в такой иерархии. При индексировании структура является ключом: документ содержит именованные ключи, которые содержат дополнительные документы, массивы или скалярные значения. Рассмотрим следующий документ.

{
  _id:  0x194f38dc491a,
  Name:  "John Smith",
  PhoneNumber:
    Home: "555 999-1234",
    Work: "555 999-9876",
    Mobile: "555 634-5789"
  Accounts:
    - "379-1111"
    - "379-2574"
    - "414-6731"
}

вышеуказанный документ имеет ключ, PhoneNumber.Mobile, который имеет значение 555 634-5789. Вы можете поиск по коллекции документов, где ключ, PhoneNumber.Mobile, имеет некоторое значение; они индексируются.

он также имеет массив Accounts которые содержат несколько индексов. Можно запросить документ, где Accounts содержит ровно некоторое подмножество значений,все некоторого подмножества значений, или любой некоторого подмножества значений. Это означает, что вы можете искать Accounts = ["379-1111", "379-2574"] и не найти выше; вы можете искать Accounts includes ["379-1111"] и найти над документом; и вы можете искать Accounts includes any of ["974-3785","414-6731"] и найти выше и любой документ, включающий учетную запись "974-3785", если таковые имеются.

документы идут так глубоко, как вы хотите. PhoneNumber.Mobile может содержать массив или даже поддокумент (PhoneNumber.Mobile.Work и PhoneNumber.Mobile.Personal). Если ваши данные имеют высокую структуру, документы являются большим шагом вперед от реляционных баз данных.

если ваши данные в основном плоские, реляционные и жестко структурированные, вам лучше с реляционной базой данных. Опять же, большой знак - это то, что ваши модели данных лучше всего подходят для коллекции взаимосвязанных файлов CSV или коллекции файлов XML/JSON/YAML.

для большинства проектов вам придется идти на компромисс, принимая незначительную работу в некоторых небольших областях, где либо SQL, либо хранилища документов не подходят; для некоторых больших, сложных проектов, хранящих широкое распространение данных (многие столбцы; строки не имеют значения), будет иметь смысл хранить некоторые данные в одной модели и другие данные в другой модели. Facebook использует SQL и graph database (где данные помещаются в узлы, а узлы подключаются к другим узлам); Craigslist использовал MySQL и MongoDB, но смотрел на перемещение полностью на MongoDB. Это места, где диапазон и взаимосвязь данных сталкиваются со значительными препятствиями, если поместить их под одну модель.

Redis: Ключ-Значение

Redis-это, в основном, хранилище ключевых значений. Redis позволяет вам дать ему ключ и посмотреть одно значение. Redis сам может хранить строки, списки, хэши и некоторые другие вещи; однако он смотрит только по имени.

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

наиболее очевидным случаем недействительности является обновление на write: if you read user:Simon:lingots = NOTFOUND, возможно SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon и сохранить результат, 100, as SET user:Simon:lingots = 100. Затем, когда вы награждаете Simon 5 lingots, Вы читаете user:Simon:lingots = 100, SET user:Simon:lingots = 105 и UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon. Теперь у вас есть 105 в вашей базе данных и в Redis, и вы можете получить user:Simon:lingots без запроса базы данных.

второй случай-обновление зависимой информации. Предположим, вы генерируете куски страницы и кэшируете их вывод. Заголовок показывает опыт, уровень и количество денег игрока; страница профиля игрока имеет блок, который показывает их статистику; и так далее. Игрок получает некоторые опыт. Ну, теперь у вас есть несколько templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simon и т. д. Поля, в которых вы кэшировали выходные данные полудюжины запросов базы данных, выполняемых через механизм шаблонов. Обычно, когда вы показываете эти страницы, вы говорите:

$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
  $t = BuildTemplate("StatsBox.tmpl",
                     GetStatsFromDatabase($playerName));
  SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;

потому что вы только что обновили результаты GetStatsFromDatabase("Simon"), вы должны отбросить templates:*:Simon из кэша значений ключей. При попытке отрисовки любого из этих шаблонов приложение будет отрабатывать извлечение данных из базы данных (PostgreSQL, MongoDB) и вставив его в свой шаблон; затем он сохранит результат в Redis и, надеюсь, не будет беспокоиться о создании запросов к базе данных и шаблонов рендеринга при следующем отображении этого блока вывода.

Redis также позволяет делать очереди сообщений publisher-subscribe и тому подобное. Это совсем другая тема. Точка здесь Redis-это кэш значений ключей, который отличается от реляционной базы данных или хранилища документов.

вывод

выбрать ваши инструменты, основанные на ваших потребностях. Самой большой потребностью обычно является модель данных, поскольку она определяет, насколько сложен и подвержен ошибкам ваш код. Специализированные приложения будут опираться на производительность, места, где вы пишете все в смеси C и сборки; большинство приложений будут просто обрабатывать обобщенный случай и использовать систему кэширования, такую как Redis или Memcached, что намного быстрее, чем высокопроизводительная база данных SQL или хранилище документов.


и вы не должны использовать ни один, если у вас много ОЗУ. Redis и MongoDB приходят к цене инструмента общего назначения. Это вводит много накладных расходов.

была поговорка, что редис в 10 раз быстрее, чем Монго. Возможно, это уже не так. MongoDB (если я правильно помню) утверждал, что избил memcache для хранения и кэширования документов, пока конфигурации памяти одинаковы.

абы. Рэдис хорошо, MongoDB-это хорошо. Если вы заботитесь о подструктуры и агрегация потребности идут для MongoDB. Если хранение ключей и значений является вашей главной заботой, это все о Redis. (или любое другое хранилище ключевых значений).


Redis и MongoDB являются нереляционными базами данных, но они имеют разные категории.

Redis-это база данных ключей / значений, и она использует память в памяти, что делает ее очень быстрой. Это хороший кандидат для кэширования материала и временного хранения данных(в памяти), и поскольку большинство облачных платформ (таких как Azure, AWS) поддерживают его, его использование памяти масштабируется.Но если вы собираетесь использовать его на своих машинах с ограниченными ресурсами, подумайте об использовании памяти.

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


Если ваш проект сдвинулся позволяет иметь достаточно оперативной памяти в вашей среде-ответ Redis. Особенно учитывая новый Redis 3.2 с кластерной функциональностью.