Является ли это хорошим вариантом использования Redis в ServiceStack REST API?

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

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

    http://www.miles3.com/uploads/redis.png

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

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

Источник

1 ответ

Решение

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

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

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

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

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

Вы также можете посмотреть на исходный код RedisStackru для другого реального примера использования 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 нет неявных индексов, вам, как правило, необходимо настроить индексы / отношения, необходимые для чтения себя во время записи. По сути, вам нужно заранее продумать все требования к вашему запросу и убедиться, что вы установили необходимые отношения во время записи. Приведенный выше исходный код RedisStackru является хорошим примером, демонстрирующим это.

Примечание. Поставщик 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 любит оперативную память

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

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

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

Источник
Другие вопросы по тегам