Является ли это хорошим вариантом использования Redis в ServiceStack REST API? - PullRequest
10 голосов
/ 01 декабря 2011

Я создаю мобильное приложение, и для получения / размещения информации о каждом пользователе требуется бэкэнд службы API.Я буду разрабатывать веб-сервис на ServiceStack , но мне было интересно узнать о хранилище.Мне нравится идея быстрой системы кэширования в памяти, такой как Redis , но у меня есть несколько вопросов:

  1. Я создал пример схемы того, что мое хранилище данныхдолжен выглядеть так.Похоже ли это, что это хороший случай для использования Redis, в отличие от MySQL DB или чего-то подобного?

    схема http://www.miles3.com/uploads/redis.png

  2. Насколько сложнонастройки для сохранения хранилища Redis на диске или это встроенная функция при записи в хранилище?(Я новичок в этом материале NoSQL)

  3. В настоящее время у меня есть настройки на AWS с использованием микро-экземпляра Linux (потому что это бесплатно в течение года).Я знаю, что на этот ответ влияют многие факторы, но в целом этого будет достаточно для моего веб-сервиса и Redis?С Redis в памяти этого будет достаточно?Я предполагаю, что если мое мобильное приложение взлетит до небес (эй, мы можем мечтать, верно?), Тогда я начну поражать потолок экземпляра.

1 Ответ

29 голосов
/ 01 декабря 2011

О чем следует помнить при разработке приложения NoSQL Redis

1) Чтобы правильно развиваться в Redis, вы должны больше думать о том, как бы вы структурировали отношения в вашей программе на C #, т. Е. С классами коллекции C #, а не с реляционной моделью, предназначенной для RDBMS. Лучше было бы больше думать о хранении данных, таких как база данных документов, а не о таблицах RDBMS. По сути, в Redis все получает блоб с помощью ключа (индекса), поэтому вам просто нужно выяснить, каковы ваши основные сущности (то есть совокупные корни) который будет храниться в его собственном «ключевом пространстве имен» или в том, что это не первичная сущность, то есть просто метаданные, которые должны просто сохраняться вместе с родительской сущностью.

Примеры Redis как основного хранилища данных

Вот хорошая статья, в которой рассказывается о создании простого блогового приложения с использованием Redis:

http://www.servicestack.net/docs/redis-client/designing-nosql-database

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

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

var redisUsers = redis.As<User>();
var user = redisUsers.GetById(1);
var userIsWatching = redisUsers.GetRelatedEntities<Watching>(user.Id);

В способе хранения отношений между сущностями используются наборы Redis, например, вы можете концептуально хранить отношения Пользователи / Наблюдатели с помощью:

SET["ids:User>Watcher:{UserId}"] = [{watcherId1},{watcherId2},...]

Redis не содержит схем и идемпотентов

Хранение идентификаторов в наборах redis идемпотентно, т. Е. Вы можете добавить watcherId1 к одному и тому же набору несколько раз, и он будет иметь только одно вхождение. Это хорошо, потому что это означает, что вам не нужно проверять наличие отношений и вы можете свободно добавлять связанные идентификаторы, как будто их никогда не было.

Связанный: запись или чтение в несуществующую коллекцию Redis (например, List) - это то же самое, что запись в пустую коллекцию, т. Е. Список создается на лету, когда вы добавляете элемент в список во время доступа несуществующий список просто вернет 0 результатов. Это выигрыш без трения и производительности, так как вам не нужно заранее определять свои схемы, чтобы использовать их. Хотя в случае необходимости Redis предоставляет операцию EXISTS , чтобы определить, существует ли ключ, или операцию TYPE , чтобы вы могли определить ее тип.

Создайте свои отношения / индексы для ваших записей

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

Примечание. Поставщик ServiceStack.Redis C # предполагает, что у вас есть уникальное поле с именем Id , которое является его первичным ключом. Вы можете настроить его для использования другого поля с отображением конфигурации ModelConfig.Id () .

Redis Persistance

2) Redis поддерживает 2 типа постоянных режимов: встроенный RDB и файл только для добавления (AOF). RDB записывает обычные моментальные снимки, в то время как файл «Только для добавления» действует как журнал транзакций, в котором записываются все изменения между моментальными снимками - я рекомендую добавлять оба, пока вы не освоитесь с тем, что делает каждый, и с тем, что нужно вашему приложению. Вы можете прочитать всю настойчивость Redis на http://redis.io/topics/persistence.

Примечание. Redis также поддерживает тривиальную репликацию, о которой вы можете прочитать в: http://redis.io/topics/replication

Redis любит RAM

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

Визуализация ваших данных с помощью интерфейса администратора Redis

Наконец, если вы используете ServiceStack C # Redis Client Я рекомендую установить Redis Admin UI , который обеспечивает хороший визуальный обзор ваших объектов. Вы можете увидеть живую демонстрацию этого на: http://servicestack.net/RedisAdminUI/AjaxClient/

...