|
精华帖 (7) :: 良好帖 (12) :: 新手帖 (0) :: 隐藏帖 (8)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-28
这样架构的前提大多针对特定的互联网应用，如SNS系统，有较强的针对性，而不去考虑多表的join和分页这种问题
|
| 返回顶楼 | |
|
发表时间：2010-09-29
J-catTeam 写道 数据库的水平切分 使用局限性还是有的。比如sql中的分组，排序，或者其他一些情况。
另外 兄弟 你的测试方法应该不是很可靠吧。 水平切分是会带来一些问题，但是既然我们已经做了水平切分，那么肯定是要牺牲一些东西的，比如数据库表的设计可能会反范式设计，简单的多表关联查询可能就没办法用了，诸如此类的问题，都会有。但是为了达到能容纳更多数据的目的，我觉得这样的牺牲是必要的。水平切分之后，我的理解就是其实RDBMS已经没有了关系，DB仅仅充当了Table的容器而已。如果还要使用关系的话，那么必然会给今后的扩展留下隐患。像时下流行的Key-Value系统，实现了什么？对外暴露出来的功能简单的就如同一个Map，但是确实是能解决一些问题的。是吧！ |
| 返回顶楼 | |
|
发表时间：2010-09-29
最后修改：2010-09-29
lishuaibt 写道 J-catTeam 写道 数据库的水平切分 使用局限性还是有的。比如sql中的分组，排序，或者其他一些情况。
另外 兄弟 你的测试方法应该不是很可靠吧。 水平切分是会带来一些问题，但是既然我们已经做了水平切分，那么肯定是要牺牲一些东西的，比如数据库表的设计可能会反范式设计，简单的多表关联查询可能就没办法用了，诸如此类的问题，都会有。但是为了达到能容纳更多数据的目的，我觉得这样的牺牲是必要的。水平切分之后，我的理解就是其实RDBMS已经没有了关系，DB仅仅充当了Table的容器而已。如果还要使用关系的话，那么必然会给今后的扩展留下隐患。像时下流行的Key-Value系统，实现了什么？对外暴露出来的功能简单的就如同一个Map，但是确实是能解决一些问题的。是吧！ 是的，我也是认为水平切分是有特定的应用场景的。如果要和其他表做关联或者做分页查询那是用水平切分就不是最好的解决方案了 |
| 返回顶楼 | |
