我有一个web应用程序,它有正常的功能,用户设置等,这些都存储在MYSQL与用户等。
应用程序a的一个特定部分是供用户编辑的数据表。
我想使这个表实时,跨越多个用户。多个用户可以打开页面,编辑数据,查看其他用户在编辑表时所做的实时更改。
我的想法是在Redis中缓存表的数据,然后在redis中预先格式化所有的操作,比如保持所有客户端的最新信息。
一旦某个特定表的所有连接关闭,将数据保存回MYSQL以保持持久性,我知道Redis可以用作持久的NoSQL数据库,但是由于内存有限,而且我的所有其他数据都存储在mysql中,所以mysql似乎是一个更好的选择。
这是redis的正确用例吗?我的想法正确吗?
发布于 2016-05-29 08:57:36
这取决于可伸缩性。您将要处理的记录数量和用于保存它的结构。
我将讨论使用redis的优点和优点。由你来决定。
使用redis的优点:
1) It can handle heavy writes and reads in comparison with MYSQL
2) It has flexible structures (hashmap, sorted set etc) which can
localise your writes instead of blocking the whole table.
3) Read queries will be much faster as it is served from cache.使用redis的缺点:
1) Maintaining transactions. What happens if both users try to access a
particular cell at a time? Do you have a right data structure in redis to
handle this case?
2) What if the data is huge? It will exceed the memory limit.
3) What happens if there is a outage?
4) If you plan for persistence of redis. Say using RDB or AOF. Will you
handle those 5-10 seconds of downtime?需要重点关注的事情:
1)你要处理多少数据?假设一个包含10000行的表,在redis中有10列占用1GB内存(只是假设实际内存要少得多)。如果您的redis是10 10集群,那么您只能处理10个这样的表。计算一下您将要使用的rows * column * live tables数量以及它消耗的内存。
2) Redis对范围内的http://redis.io/topics/memory-optimization中的数据使用压缩。假设您决定使用hashmap保存表,您有两个选项,对于每个列可以有一个hashmap,或者对于每一行可以有一个hashmap。第二个选择将是最佳选择。因为存储1000 (散列映射->行)* 20 (每个哈希映射->列中的记录)将比以另一种方式存储的内存少10次。同样,如果更改了单元格,则可以在20个值的哈希映射中进行本地化。
3)将数据加载回MYSQL中。这种情况多久会发生一次?如果您的工作负载很高,那么MYSQL开始对其他操作执行更差的操作。
4)在通知更改时,您将如何处理多个客户端?你会加载整张桌子还是正在改变的部分?加载更改的部分将是最优的。在这种情况下,您将在哪里维护已更改的单元格列表?
用这些问题来评估你的系统,你会发现它是否可行。
https://stackoverflow.com/questions/37503544
复制相似问题