这是 Redis 在 ServiceStack REST API 上的一个很好的用例吗? [英] Is this a good use-case for Redis on a ServiceStack REST API?
问题描述
我正在创建一个移动应用程序，它需要一个 API 服务后端来获取/放置每个用户的信息.我将在 ServiceStack 上开发 Web 服务，但对存储感到疑惑.我喜欢像 Redis 这样的快速内存缓存系统的想法，但我有几个问题:
我创建了我的数据存储应该是什么样子的示例架构.这似乎是使用 Redis 而不是 MySQL DB 或类似数据库的好例子?
将 Redis 存储持久化到磁盘的设置有多困难，或者当您写入存储时它是内置的吗?(我是 NoSQL 方面的新手)
我目前使用 Linux 微型实例在 AWS 上进行设置(因为它是免费的年).我知道这个答案有很多因素，但总的来说，这对我的 Web 服务和 Redis 来说是否足够?既然 Redis 在内存中，这就足够了吗?我想如果我的移动应用程序飞速发展(嘿，我们可以做梦吧?)那么我将开始触及实例的天花板.
在设计 NoSQL Redis 应用程序时要考虑什么
1) 要在 Redis 中正确开发，您应该更多地考虑如何在 C# 程序中构建关系，即使用 C# 集合类而不是用于 RDBMS 的关系模型.更好的心态是更多地考虑像文档数据库而不是 RDBMS 表这样的数据存储.基本上所有东西都通过一个键(索引)在 Redis 中被删除，所以你只需要弄清楚你的主要实体是什么(即聚合根)这将被保存在它自己的关键命名空间"中，或者它是否是非主要实体，即只是应该与其父实体一起持久化的元数据.
Redis 作为主要数据存储的示例
这是一篇很好的文章，介绍了如何使用 Redis 创建一个简单的博客应用程序:
http://www.servicestack.net/docs/redis-客户端/设计-nosql-数据库
您还可以查看RedisStackOverflow 的源代码，用于另一个使用 Redis 的真实示例.
基本上，您需要分别存储和获取每种类型的项目.
var redisUsers = redis.As();var user = redisUsers.GetById(1);var userIsWatching = redisUsers.GetRelatedEntities(user.Id); 存储实体之间关系的方式是利用 Redis 的集合，例如:您可以在概念上存储用户/观察者关系:
SET["ids:User>Watcher:{UserId}"] = [{watcherId1},{watcherId2},...]Redis 是无模式且幂等的
将 id 存储到 redis 集合中是幂等的，即您可以多次将 watcherId1 添加到同一个集合中，并且它只会出现一次.这很好，因为这意味着您永远不需要检查关系的存在，并且可以自由地继续添加相关的 id，就像它们从未存在过一样.
相关:写入或读取不存在的Redis集合(例如列表)与写入空集合相同，即当您在访问时将项目添加到列表时会即时创建列表一个不存在的列表只会返回 0 个结果.这是一个无摩擦和生产力的胜利，因为您不必预先定义您的模式来使用它们.虽然您是否需要Redis提供EXISTS操作来确定一个键是否存在或一个TYPE 操作，以便您可以确定其类型.
在你的写作中建立你的关系/索引
要记住的一件事是因为 Redis 中没有隐式索引，您通常需要设置您在写入期间读取自己所需的索引/关系.基本上，您需要预先考虑所有查询要求，并确保在写入时设置必要的关系.上面的 RedisStackOverflow 源代码就是一个很好的例子.
注意:ServiceStack.Redis C# 提供程序假定您有一个名为 Id 的唯一字段，它是其主键.您可以将其配置为使用带有 ModelConfig.Id() 配置映射的不同字段.
Redis 持久化
2) Redis 支持开箱即用的 RDB 和 Append Only File (AOF) 两种持久化模式.RDB 编写例行快照，而 Append Only File 就像一个事务日志，记录快照之间的所有更改 - 我建议添加两者，直到您对它们的功能和应用程序的需求感到满意为止.您可以在 http://redis.io/topics/persistence 阅读所有 Redis 持久性.
注意 Redis 还支持普通复制，您可以在以下位置阅读更多信息:http://redis.io/topics/replication
Redis 喜欢内存
3) 由于 Redis 主要在内存中运行，因此最重要的资源是您有足够的 RAM 来将整个数据集保存在内存中 + 用于快照到磁盘时的缓冲区.Redis 非常高效，因此即使是小型 AWS 实例也能处理大量负载 - 您需要的是拥有足够的 RAM.
使用 Redis 管理界面可视化您的数据
最后，如果您使用的是 ServiceStack C# Redis 客户端，我建议您安装 Redis Admin UI，它提供了一个很好的实体可视化视图.您可以在以下位置看到它的现场演示:http://servicestack.net/RedisAdminUI/AjaxClient/
I'm creating a mobile app and it requires a API service backend to get/put information for each user. I'll be developing the web service on ServiceStack, but was wondering about the storage. I love the idea of a fast in-memory caching system like Redis, but I have a few questions:
I created a sample schema of what my data store should look like. Does this seems like it's a good case for using Redis as opposed to a MySQL DB or something like that?
How difficult is the setup for persisting the Redis store to disk or is it kind of built-in when you do writes to the store? (I'm a newbie on this NoSQL stuff)
I currently have my setup on AWS using a Linux micro instance (because it's free for a year). I know many factors go into this answer, but in general will this be enough for my web service and Redis? Since Redis is in-memory will that be enough? I guess if my mobile app skyrockets (hey, we can dream right?) then I'll start hitting the ceiling of the instance.
What to think about when desigining a NoSQL Redis application
1) To develop correctly in Redis you should be thinking more about how you would structure the relationships in your C# program i.e. with the C# collection classes rather than a Relational Model meant for an RDBMS. The better mindset would be to think more about data storage like a Document database rather than RDBMS tables. Essentially everything gets blobbed in Redis via a key (index) so you just need to work out what your primary entities are (i.e. aggregate roots) which would get kept in its own 'key namespace' or whether it's non-primary entity, i.e. simply metadata which should just get persisted with its parent entity.
Examples of Redis as a primary Data Store
Here is a good article that walks through creating a simple blogging application using Redis:
http://www.servicestack.net/docs/redis-client/designing-nosql-database
You can also look at the source code of RedisStackOverflow for another real world example using Redis.
Basically you would need to store and fetch the items of each type separately.
var redisUsers = redis.As<User>();
var user = redisUsers.GetById(1);
var userIsWatching = redisUsers.GetRelatedEntities<Watching>(user.Id);
The way you store relationship between entities is making use of Redis's Sets, e.g: you can store the Users/Watchers relationship conceptually with:
SET["ids:User>Watcher:{UserId}"] = [{watcherId1},{watcherId2},...]
Redis is schema-less and idempotent
Storing ids into redis sets is idempotent i.e. you can add watcherId1 to the same set multiple times and it will only ever have one occurrence of it. This is nice because it means you don't ever need to check the existence of the relationship and can freely keep adding related ids like they've never existed.
Related: writing or reading to a Redis collection (e.g. List) that does not exist is the same as writing to an empty collection, i.e. A list gets created on-the-fly when you add an item to a list whilst accessing a non-existent list will simply return 0 results. This is a friction-free and productivity win since you don't have to define your schemas up front in order to use them. Although should you need to Redis provides the EXISTS operation to determine whether a key exists or a TYPE operation so you can determine its type.
Create your relationships/indexes on your writes
One thing to remember is because there are no implicit indexes in Redis, you will generally need to setup your indexes/relationships needed for reading yourself during your writes. Basically you need to think about all your query requirements up front and ensure you set up the necessary relationships at write time. The above RedisStackOverflow source code is a good example that shows this.
Note: the ServiceStack.Redis C# provider assumes you have a unique field called Id that is its primary key. You can configure it to use a different field with the ModelConfig.Id() config mapping.
Redis Persistance
2) Redis supports 2 types persistence modes out-of-the-box RDB and Append Only File (AOF). RDB writes routine snapshots whilst the Append Only File acts like a transaction journal recording all the changes in-between snapshots - I recommend adding both until your comfortable with what each does and what your application needs. You can read all Redis persistence at http://redis.io/topics/persistence.
Note Redis also supports trivial replication you can read more about at: http://redis.io/topics/replication
Redis loves RAM
3) Since Redis operates predominantly in memory the most important resource is that you have enough RAM to hold your entire dataset in memory + a buffer for when it snapshots to disk. Redis is very efficient so even a small AWS instance will be able to handle a lot of load - what you want to look for is having enough RAM.
Visualizing your data with the Redis Admin UI
Finally if you're using the ServiceStack C# Redis Client I recommend installing the Redis Admin UI which provides a nice visual view of your entities. You can see a live demo of it at: http://servicestack.net/RedisAdminUI/AjaxClient/
这篇关于这是 Redis 在 ServiceStack REST API 上的一个很好的用例吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
