ORM 能不能这样

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 4072 天前的主题，其中的信息可能已经有所发展或是发生改变。

我设想，ORM 用算法判断，如果一个字段被频繁访问，就会被被判断为热点，对于热点的字段，自动的加载到内存中（比如说Redis）然后定时同步……

这种思路有意义吗？有没有成品？

12 条回复 • 1970-01-01 08:00:00 +08:00

Alex_L

2013-09-28 23:12:26 +08:00 via iPad

大部分ORM都有缓存和延迟加载一类的机制

ericls

2013-09-28 23:17:56 +08:00 via Android

好像还是只有自己写我也在寻找类似的

est

2013-09-28 23:32:37 +08:00

那也只是频繁读啊，遇到频繁写的怎么办？

shiny

2013-09-28 23:36:28 +08:00

频繁读取的，数据库本身就有 Query Cache 吧，而且可靠性很好。热点数据自己用 redis 实现也不费劲吧，关键是可靠。

tioover

2013-09-28 23:47:02 +08:00

@est 频繁写就是写在内存啊，定时写入SQL

tioover

2013-09-28 23:50:35 +08:00

好吧，那么可以讨论一下怎么判断热点数据

访问次数为y轴，时间为x轴，那么一个热点数据的曲线大致上是驼峰或者波浪型，可以通过导数来判断？

9hills

2013-09-28 23:58:21 +08:00 via Android

@tioover 写 cache 的话数据一致性怎么解决啊

Alex_L

2013-09-29 00:46:52 +08:00 via iPad

没太明白你的意思。内存的空间是有限的，不经常访问的缓存数据会过期，换而言之缓存中的数据大都是热点数据。至于利用缓存不一致写缓存要根据业务场景来，比如点赞功能就不适合每次写数据库。这种行为应该根据业务场景对数据一致性的需求，由程序员自己判断，不应该由ORM做，而且反正做起来也很简单。

davepkxxx

2013-09-29 01:27:47 +08:00

缓存框架就是干这个的。

kfll

2013-09-29 08:57:14 +08:00 via iPhone

@tioover 频繁写就没这么容易了…

tioover

2013-09-29 08:59:39 +08:00

@kfll
@Alex_L 对哦……

mengzhuo

2013-09-29 09:22:23 +08:00

一个字段……做好数据库的优化其实比应用层的优化有用得多。
先检查query cache hit rate比较好，如果是MYSQL的话，可以开始考虑proxy+主-从了。
反正一般对已上线的服务都是先加硬件，再考虑代码优化。