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

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

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

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

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

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

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

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

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

Когда использовать Redis?

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

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

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

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

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

  Избавление от производительности Redis практически невозможно. Представьте, что ваша база данных работает так же быстро, как ваш кеш. Это то, что похоже на использование Redis в качестве реальной базы данных.

• Если вам не так важно масштабировать.

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

Когда использовать MongoDB

• Прототипирование, запуск, Hackathons

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

• Если вам нужно быстро изменить схему.

  Потому что нет схемы! Изменение таблиц в традиционных реляционных СУБД является болезненным и медленным. MongoDB решает эту проблему, не делая много предположений относительно ваших базовых данных. Тем не менее, он пытается оптимизировать, насколько это возможно, без необходимости определять схему.

TL; DR - Используйте Redis, если производительность важна, и вы готовы тратить время на оптимизацию и организацию ваших данных. - Используйте MongoDB, если вам нужно создать прототип, не беспокоясь слишком много о своей БД.

Дальнейшее чтение:

• Интересные аспекты, которые следует учитывать при использовании Redis в качестве основного хранилища данных

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

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

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

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

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

Все ответы (на момент написания этой статьи) предполагают, что каждый из 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 или Document Stores не подходят; для некоторых крупных сложных проектов, хранящих широкое распространение данных (многие столбцы, строки не имеют значения), имеет смысл хранить некоторые данные в одной модели и другие данные в другой модели. Facebook использует как SQL, так и базу данных графа (где данные помещаются в узлы, а узлы связаны с другими узлами); Craigslist использовался для использования MySQL и MongoDB, но изучал полностью перемещение на MongoDB. Это те места, где диапазон и взаимосвязь данных сталкиваются со значительными недостатками, если поставить их под одну модель.

Redis: ключевое значение

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

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

Наиболее очевидным случаем недействительности является обновление при записи: если вы читаете user:Simon:lingots = NOTFOUND, вы можете SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon и сохранить результат 100, как SET user:Simon:lingots = 100. Затем, когда вы награждаете лингбоны Simon 5, вы читаете 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 также позволяет создавать очереди сообщений для подписчиков и подписчиков. Это еще одна тема. Пункт здесь Redis - это кеш-ключ, который отличается от реляционной базы данных или хранилища документов.

Заключение

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

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

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

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

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

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

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

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

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

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

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