Является ли это хорошим вариантом использования Redis для REST API ServiceStack?
Я создаю мобильное приложение, и оно требует серверной части API-службы для получения/размещения информации для каждого пользователя. Я буду разрабатывать веб-сервис на ServiceStack, но мне было интересно о хранилище. Мне нравится идея быстрой системы кэширования в памяти, такой как Redis , но у меня есть несколько вопросов:
-
Я создал примерную схему того, как должно выглядеть мое хранилище данных. Кажется ли это хорошим случаем для использования Redis в отличие отMySQL DB или что-то вроде этого?
-
Насколько сложно настроить сохранение хранилища Redis на диске или оно встроено, когда вы выполняете запись в хранилище? (Я новичок в этом NoSQL материале)
-
В настоящее время у меня есть настройка на AWS с использованием экземпляра Linux micro (потому что он бесплатный в течение года). Я знаю, что многие факторы входят в этот ответ, но в целом будет ли этого достаточно для моего веб-сервиса и Редис? Поскольку редис в памяти, будет ли этого достаточно? Я думаю, если мое мобильное приложение взлетит до небес (Эй, мы ведь можем мечтать?) тогда я начну бить по потолку экземпляра.
1 ответ:
О чем следует думать при разработке приложения NoSQL Redis
1) Чтобы правильно развиваться в Redis, вы должны больше думать о том, как вы будете структурировать отношения в вашей программе C#, то есть с классами коллекции C#, а не реляционной моделью, предназначенной для СУБД. Лучше было бы думать больше о хранении данных, таких как база данных документов, а не таблицы СУБД. По сути, в 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 является идемпотентным, т. е. вы можете добавить watcherId1 к одному и тому же набору несколько раз, и он будет иметь только одно его появление. Это хорошо, потому что это означает, что вам никогда не нужно проверять существование отношений и вы можете свободно добавлять связанные идентификаторы, как будто они никогда не существовали.
Related: запись или чтение в коллекцию Redis (например, Список), которая не существует, это то же самое, что запись в пустую коллекцию, т. е. список создается на лету, когда вы добавляете элемент в список во время доступа к списку. несуществующий список просто вернет 0 результатов. Это выигрыш без трения и производительности, так как вам не нужно заранее определять свои схемы, чтобы использовать их. Хотя в случае необходимости Redis предоставляет операциюEXISTS , чтобы определить, существует ли ключ или операцияTYPE , чтобы вы могли определить его тип.
Создайте свои отношения / индексы на ваших записях
Одна вещь, которую следует помнить, поскольку в Redis нет неявных индексов, вы будете вообще нужно настроить свои индексы / отношения, необходимые для чтения себя во время записи. В принципе, вам нужно заранее продумать все требования к запросу и убедиться, что вы настроили необходимые отношения во время записи. Приведенный выше исходный код RedisStackOverflow является хорошим примером, который показывает это.
Примечание: пакет услуг.Поставщик Redis C# предполагает, что у вас есть уникальное поле под названием Id, которое является его первичным ключом. Вы можете настроить его на использование другого поля с ModelConfig.Id () отображение конфигурации.
Redis Persistence
2) Redis поддерживает 2 типа режимов персистентности out-of-the-box RDB и Append Only File (AOF). RDB записывает рутинные снимки, в то время как файл Append Only действует как журнал транзакций, записывающий все изменения между снимками-я рекомендую добавлять оба до тех пор, пока вы не освоитесь с тем, что каждый делает и что нужно вашему приложению. Вы можете прочитать всю настойчивость редиса на http://redis.io/topics/persistence .
Рэдис внимание также поддерживает банальной репликации можно подробнее о по адресу: http://redis.io/topics/replication
Редис любит рама
3) поскольку Redis работает преимущественно в памяти, наиболее важным ресурсом является то, что у вас достаточно оперативной памяти для хранения всего набора данных в памяти + буфер для моментальных снимков на диск. Redis очень эффективен, поэтому даже небольшой экземпляр AWS сможет справиться с большой нагрузкой-что вы хотите искать, имея достаточно оперативной памяти.
Визуализация данных с помощью интерфейса администратора Redis
Наконец, если вы используетеServiceStack C# Redis Client , я рекомендую установитьRedis Admin UI , который обеспечивает хорошее визуальное представление ваших сущностей. Вы можете посмотреть его живую демонстрацию по адресу: http://servicestack.net/RedisAdminUI/AjaxClient/