分库设计

一种以ID特征为依据的数据分片（Sharding）策略

 

http://blog.zhaojie.me/2010/03/sharding-by-id-characteristic.html

 

我觉得自己引入分片的话，太复杂了，甚至糟蹋了现有关系数据库的一些功能了。分布式的第一原则就是“尽量不使用分布式”。

数据分片是系统优化的常用设计方式之一。正如前文所说的那样，数据分片的做法很多，本文提到的方式只是其中一种方式。这种根据ID特征的分片方式比较容易遇到的问题之一，便是在数据分区数量改变时造成的规则冲突，这也正是我这篇文章所讨论的主要内容。从这个角度看来，其他一些分片方式，如创建时间也好，查找表也罢，这样的问题反而不太常见。如果您有这方面的经验或是疑惑，也欢迎与我进行交流。

现在Web 2.0网站越来越热门了，此类项目的数据量也越来越大，从近几年的讨论形式可以看出，越来越多的人在强调什么大规模、高性能、或是海量数据。然后，似乎每个人都会横向切分、纵向切分、缓存、分离。我猜，再接下来，估计又会有许多人以用关系型数据库为耻了吧？但是，想想这样的问题：博客园和JavaEye都是国内技术社区的翘楚，它们都只用了1台数据库服务器。StackOverflow是世界上最大的编程网站（它是使用ASP.NET MVC写的，兄弟们记住这个经典案例吧），似乎也只用了1台还是2台数据库服务器（可能配置比较高）及SQL Server。因此，即便是单台服务器，即便是使用关系型数据库，它在性能方面的潜力也是非常之高的。

因此，数据分片应该只在需要的时候才做，因为它带来的复杂度会比中心存储的方式高出很多。这带来的结果是，可能您的应用程序还没有用足架构的能力就已经失败了，这样各种投资也已经浪费了。假如您一开始用最简单的方式去做，可能很快会带来成长所需要空间及资源，此时再做更多投资进行架构优化也不迟——架构不是一蹴而就，而是演变得来的。当然，第一次投入多少复杂度是个需要权衡的东西，这也是考验架构师能力的地方。架构不是空中楼阁，而是各种真实资源调配的结果。

 

 

又拍网架构中的分库设计

http://www.infoq.com/cn/articles/yupoo-partition-database/

 

===========================

 

合理的业务拆发，合理的读写分离，其它使用硬件或成熟的第三方解决方案SAN、存储，mssql2005分区

横向拆分一般用得不多，合理使用接口，在写在花一定的功能。

 

自已分片，根据业务恰当的分即可，无需太过度，要充分发挥系统的系统。外键、一致性、事务，关链查询。

使用缓存来减少部分关键查询，如memcached product名称。

 

现在数据库都说要不进行关联查询了，做冗余，或者从缓存取关联数据。

 

涉及到两个库的事务，我们用文章里提到的方法，将两个事务嵌套起来。
有些地方的一致性我们是在读的时候进行修复。
另外，对于复杂的事务，我们使用任务进行一致性检查和修复。

 

评论标题，评论总数冗余。

 

自已分库后，需要解决相关问题：关联查询，事务，一致性。解决办法：冗余、应用程序事务检查解决，视图（union，中间表、查找表）、缓存

 

减少关联查询：memcahed基础数据、memcached产品名称，memcached用户名