讨论要点
- limax对json序列化和反序列化的支持。
- json性能和存储上的损耗。
- olap在limax的用法。
- 缓存预热的支持。
- limax是否会支持PR。
content
我 21:23:26__
我最近想把项目迁移到最新的limax上，只不过我们在limax之上封装了mysql存json串，迁移的话这部分修改也比较大。所以想问下limax有意向支持mysql的json存储么，因为现在的发行商一般都会要求数据库用mysql来做，所以用limax/xdb这是个必改项。
曾攀 21:24:08
本来就可以往mysql存啊？
我 21:27:17
是的，但是存的是octets，数据类型我觉得可以扩展下，比如json，可读性较强，而且mysql5.7支持了json的数据类型。并且现在的limax对异常的处理过于粗暴，我觉得应该对一些可恢复的异常做一些容忍策略。
曾攀 21:29:06
复杂一点的应用json开销太大了。另外json可能导致精度损失，long都不能用得全了。xbean倒是支持直接marshal成json。
曾攀 21:35:20
mysql支持这个也是简单玩玩而已，仅仅当成一个数据类型而已，也不敢别的类型都不要了。
曾攀 21:36:59
我觉得跟xbean支持marshal成json差不多。
曾攀 21:42:24
浮在表面的用json交换一下数据就好，埋太深的数据还是二进制最合理，否则以后出现性能问题，后悔都晚了。
我 21:45:58
一开始想在json可以存储动态数据上做些手脚，而且存json可以直接在从库上做一些olap的分析。
曾攀 21:47:09
我看有人做的userinfo，好几K的二进制数据，各种map，要用json该有多大？如果一群用户同时上线，大量时间都耗这上面了。
我 21:48:24
是的，确实存在存储占用网络传输和解析效率的问题，目前的办法就是分小表在做，也怕线上出性能问题。
曾攀 21:50:26
分小表也解决不了大量用户同时上线带来的解析开销啊。
我 21:52:25
这个我做了个preload机制，停服的时候会把lru cache的前若干条数据的id存在本地，起服预热下缓存。
我觉得limax可以加下这个功能，比较实用。
曾攀 21:53:32
存的是二进制，还是json，如果是json，只是解决了和mysql之间的传输问题，没解决解码问题，如果是二进制，json就显得多此一举了。
我 21:55:57
缓存中是xbean，算二进制吧，这样也算取了json的优点，也避免了大量玩家同时登陆对服务器的压力问题
曾攀 21:56:53
到头来还是靠二进制啊，所以归根结底还是权衡好处和麻烦。
曾攀 21:58:30
一个正常运行起来的系统，谁会去关心数据库里存了啥？olap的分析要紧，还是用户体验要紧？
曾攀 22:00:26
limax的原则是提供分析的数据走monitor那套系统，跟运行数据脱钩。
我 22:03:02
这个我明天看下，没细读手册，如果能做到分析数据和运行数据分离那是最好的了。但是我觉得预热机制可以加下，因为这个无论是json还是二进制，在mysql中都会减少一次网络io加查询的时间。
曾攀 22:07:07
预热这个存在的一点逻辑问题就是，停机更新表结构。
我 22:09:14
这个起服预热和协议触发加载应该走一套逻辑，这个应该不存在这个逻辑问题吧。
曾攀 22:09:29
我的意思是停机备份了一下cache里的xbean，然后维护的目的是修改xbean，启动加载就对不上了。
我 22:13:16
cache只存主键，启动的时候是逐条查询的。
这个问题就可以避免了
曾攀 22:14:57
你的意思是不存数据，一次select一批回来？
我 22:15:02
是的
曾攀 22:15:10
如果表删了呢？
我 22:17:22
那其实起服的时候table都找不到，也加载不了。
曾攀 22:18:32
我的意思是，维护结构本身可能带来很多不一致，所有细节都得考虑清楚。
我 22:20:26
是的，所以我希望limax能增加相应的功能，这样我们就可以开箱即用，更可靠
曾攀 22:21:10
我也得把细节都考虑清楚啊。
我 22:21:46
辛苦曾总
曾攀 22:22:15
这个慢慢来，急不了。
我 22:24:45
嗯，limax真的很好用，未来会挂到github上接受pull request么？
曾攀 22:25:47
这个再等等，github不是卖了啊。