|
锁定老帖子 主题：一个支持数据库分布式访问的小框架(更新5)
精华帖 (0) :: 良好帖 (9) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-05-02
只是一点想法，没有真正实践过。新换了一家公司，磨合阶段没事儿干，看公司的读写分离还是硬编码在程序中，所以产生了这个念头！
|
| 返回顶楼 | |
|
发表时间：2012-05-02
aa87963014 写道 思路和我的freyja相识
http://freyja.iteye.com/blog/1412191、 不过经过封装，只需要在需要分库的用annotation标记就行了，执行sql的时候会解析表达式，然后根据annotation注解确定其所在的库、表。 annotation是我下一步的工作，以前已经做过一个框架使用annotation来标注解析器，以及轻量级的orm。当时的框架感觉不够轻。所以分出来这个halo-dal框架。目的就是要实现 使用其他框架也能解决分布式访问的问题。 |
| 返回顶楼 | |
|
发表时间：2012-05-02
xiaoZ5919 写道 我的读写分离 基于spring+mybatis，大致一样也是基于lazyconnectionProxy。
http://xiaoz5919.iteye.com/blog/1497223 兄弟，你我的思路非常像，要是支持事务就更好了。有空我们可以交流一下。。 |
| 返回顶楼 | |
|
发表时间：2012-05-02
白云飞 写道 非常不错，关注学习下
谢谢关注，多提意见 |
| 返回顶楼 | |
|
发表时间：2012-05-02
ak478288 写道 xiaoZ5919 写道 我的读写分离 基于spring+mybatis，大致一样也是基于lazyconnectionProxy。
http://xiaoz5919.iteye.com/blog/1497223 兄弟，你我的思路非常像，要是支持事务就更好了。有空我们可以交流一下。。 好的，我先研究一下仁兄的代码！私信联系 |
| 返回顶楼 | |
|
发表时间：2012-05-02
最后修改：2012-05-02
ak478288 写道 kimmking 写道 如何路由呢？
就是说对建表有什么要求，对sql有什么要求，如何路由 解析器的编写，并不会入侵到业务代码中 我觉得已经侵入到业务代码中了 ak478288 写道 和普通建表方式没有区别。 简单举例： sql: select * from user where level=1 order by xxxx; 假如需要根据level的值进行分表，那么level条件就需要在表达式中，并且有值. 如果我们需要对用户ID进行检索，需要对地区字段进行group by，需要.....这个时候可能我们需要对用户表重载N个parse方法.... 如果能够在APP和DB之间建立一层Proxy，这个Proxy的功能假设有以下几点 1） 能够跨数据库...这个功能替代了ORM框架，好处在于我们只需要链接这么一个数据源，方便维护，至于去链接mysql还是oracle、链接哪个模块的数据源，只是参数不同而已，这些都可以在Proxy上面配置。 2） 可以实现主从读写分离，之前我们如果想要实现读写分离必须得在App上面维护它们各自的IP，但现在只需要Proxy上面维护即可，好处同上 3）可以考虑用key-value结构来存储“关键”属性，这样做为了实现分库分表，不好的地方时写入的成本更高，如果前端有缓存或者不需要实时数据可以考虑异步批量写入 4）把涉及到事务、锁的问题都放这里来做吧，业务代码会变的很干净 5）.....大家补充 意淫下而已~~~ |
| 返回顶楼 | |
|
发表时间：2012-05-02
程序新手 写道 ak478288 写道 kimmking 写道 如何路由呢？
就是说对建表有什么要求，对sql有什么要求，如何路由 解析器的编写，并不会入侵到业务代码中 我觉得已经侵入到业务代码中了 ak478288 写道 和普通建表方式没有区别。 简单举例： sql: select * from user where level=1 order by xxxx; 假如需要根据level的值进行分表，那么level条件就需要在表达式中，并且有值. 如果我们需要对用户ID进行检索，需要对地区字段进行group by，需要.....这个时候可能我们需要对用户表重载N个parse方法.... 如果能够在APP和DB之间建立一层Proxy，这个Proxy的功能假设有以下几点 1） 能够跨数据库...这个功能替代了ORM框架，好处在于我们只需要链接这么一个数据源，方便维护，至于去链接mysql还是oracle、链接哪个模块的数据源，只是参数不同而已，这些都可以在Proxy上面配置。 2） 可以实现主从读写分离，之前我们如果想要实现读写分离必须得在App上面维护它们各自的IP，但现在只需要Proxy上面维护即可，好处同上 3）可以考虑用key-value结构来存储“关键”属性，这样做为了实现分库分表，不好的地方时写入的成本更高，如果前端有缓存或者不需要实时数据可以考虑异步批量写入 4）把涉及到事务、锁的问题都放这里来做吧，业务代码会变的很干净 5）.....大家补充 意淫下而已~~~ 的确存在你说的这种情况，有时候需要对数据做汇总操作。这个时候是分区条件是不起作用的。 相当于对每个分区都要进行汇总操作。这个时候，不入侵很难做到完美（也许有，但是我没有想到）。只能说需求不同，用不同的实现方式，目前这个框架能做到的就是进行分区上的查找。你说的汇总方式与业务有关，需要针对这种业务进行考虑如何使用。 框架中也提供了直接指定数据源的方案，不过文档中还没有写出来。 只能说尽量避免这种汇总操作吧，如果避免不了，只能是做一些巧妙的处理方案了。 至于你说的Proxy，目前我暂且称为 DALServer吧，我已经开始在做这个东西了，还在研究协议的问题。 感谢你提出的场景。 |
| 返回顶楼 | |
|
发表时间：2012-05-02
修改了帖子，增加了小结
|
| 返回顶楼 | |
|
发表时间：2012-05-02
我们也在做DAL，初步的想法是所有的数据关系维护在内存的二维表中，每一种数据源对应一个adapter，需要自己实现sql parse 。有一些跨表 跨库的查询比较复杂，而且涉及到数据冗余还需要数据权重配置。
|
| 返回顶楼 | |
|
发表时间：2012-05-02
chrrity 写道 我们也在做DAL，初步的想法是所有的数据关系维护在内存的二维表中，每一种数据源对应一个adapter，需要自己实现sql parse 。有一些跨表 跨库的查询比较复杂，而且涉及到数据冗余还需要数据权重配置。
尽量避免跨库 跨表查询 ，尽可能从业务上避免，不行就用其他的方式。 个人认为，只要要抓住根本问题，就是如何选择数据源，从这个点进行出发，就能解决问题。千万不要考虑跨表跨库的操作，这些问题可以通过业务上避免的。 程序设计尽量简单，然后可以接口化，随时替换为更好的方案 （目前halo-dal就能让自己写sql解析替换我的默认解析^_^） 欢迎交流思想，哈哈 |
| 返回顶楼 | |
