关于数据切分的思考

“水平切分”和“垂直切分”这两个词经常在生活和工作中出现，对这两个东东也是一知半解的状态。现在就用写写自己的理解。

先用通俗的话说说什么是“水平切分”和“垂直切分”（其实我不知道专业的或者学术的说法是怎样的）。

假设有一个表table，它由三个字段：id，name，description，其中description是一个text类型的数据，一般都很长。不切分的做法是将所有的数据都存放在table中，但是如果将id%2==0的记录放在表结构与table相同的table1中，将id%2==1的记录放在表结构同样与table相同的table2中，这样的数据的切分存放就是水平切分。但是，如果将table表分成两个字表table1和table2，其中，他们的表结构为:table1(id,name)和table2(id,description)，这样的切分就是垂直切分。

那么水平切分和垂直切分有什么好处呢？最直观的好处就是水平切分减轻单个数据库的负担，同时增加数据的可维护性，例如备份的粒度可以细到为单个id进行备份；垂直切分则可以充分的利用数据访问的频率提高系统的性能，上面的例子中，id和name两个属性一般都是经常用到的，但是description这样的数据使用的频率就不那么大了。我们付出了冗余id的代价将description切分出去，使得description按需读取，减少了带宽需求和磁盘的IO。当然还有其他的更多的好处，比如垂直切分可以让我们对不同的字段应用不同的安全级别等等。但是需要说明的，虽然水平切分和垂直切分有这么多的好处，但是其带来的资源的消耗也是相应的。

进一步的想，实现水平切分和垂直切分的方法有哪些呢？方法应该是多种多样的，但是无论哪种方法，都需要谨记，在切分的时候请严格分析应用的场景，考虑必要和切分的好处等等，不要死搬硬套。好，先说垂直切分，实现这个更多的是系统的设计阶段，系统的耦合怎样，怎么降低耦合，怎么组合数据，怎么设计切分原则都是数据垂直切分需要考虑的问题，如果系统的耦合度过高，那么一旦系统定型了，后期要进行垂直切分困难程度就比较大了。相比垂直切分，水平切分则要简单些，水平切分不会“拆表”，它应该是“复制表”，一开始的例子说的使用id%n的方式进行的切分，还有按照一致性hash的方法切分的，还有按照数据访问频率进行拆分的。这里需要指出的，一般的我们进行数据水平拆分的时候都是使用相同的表名，其实这个不一定的，不要被这个束缚了。只有能正确的将数据路由的切分的表中就可以了，我们使用相同的表名应该是考虑实现数据路由时简单而已。这不是一定的，举个例子，在一个资源下载网站中，热门的资源的下载量非常大，而非热门的资源下载量则很小，我们就根据下载量进行水平切分，表结构统一是schema，但是表名一个是file1和file2，file1存放高下载量的数据，file2存放低下载量的数据。然后将数据更加访问频率路由到file1和file2中，这个例子就使用了不同的表名。

上面有些说的错误的或者不专业的，还请指正，愿聆听赐教。