1.はじめに
私はあなたが頻繁に信じて、読み取りと書き込みの別々の、垂直分割、水平方向に分割し、サブライブラリーのサブテーブルこれらの用語は非常に無知な力となりました。私は時々非常に無知な力、そして今日を見つけるために、いくつかの一般的な用語データベースを置くために、だけでなく、それを記録します。
2.別の読み取りと書き込み
いくつかの比較的良好な理解は、データベース、マスタデータベース（からメインデータベースに分割されているマスターライブラリ（複数から、データを書き込むための）よだれのライブラリを介してマスタとスレーブとの間で、ポーリングデータ処理を読み取ります）データ同期のための通信機構の種類は、一般的なデータベーススキーマです。示す下図の「から1メイン二つの」上の構造：
2.1なぜ別々の読み取りと書き込み
ほとんどのインターネットデータは、書き込み操作はデータの成長と、多くの場合、小さくて読み、データベースが最初のボトルネックになる「読み」。我々はデータベースの線形読み出し性能と書き込み性能を強化したい場合は、お互いに、独自の方法に影響を与えることなく、できるだけ多くの読み取りと書き込みする必要があります。別々の読み取りと書き込みを使用する前に、我々は問題を解決できない、キャッシングの利用を検討すべきです。そして、「読み」とに応じてグループ化されたデータベースを検討「の書き込みを。」別々の読み取りと書き込み手段は、単一構造は、以下の問題を検討するために、大量のデータ、並行性の高いシナリオ中に分散されます
- 確保するためにどのようにマスターの高可用性、フェイルオーバー、電流制限ヒューズを。
- ルールは、読み取りおよび書き込み操作を区別し、コードレベルでは、読み取りおよび書き込みコマンドを処理する方法を、侵入することなく、何のビジネスを知覚しないようにしてみてください。
公差データの一貫性。データが同期されているが、しかし、これによるネットワークの不確実性に問題は無視できないまま。
サブライブラリー
データベースの縦割り、横割りのデータベースをまとめてサブライブラリー。特定の物品および寸法を指し、同一のデータは、1つのデータベース（ホスト）負荷における上記分散を達成するために、データベース（ホスト）で複数のデータベースに分割されます。私たちは、変装のパフォーマンスを改善するための時間のためのデータセット、スペースのサイズを削減します。
3.1データベースの縦割り
数据库垂直拆分 指的是按照业务对数据库中的表进行分组，同组的放到一个新的数据库（逻辑上，并非实例）中。需要从实际业务出发将大业务分割成小业务。比如商城的整个业务中的 用户相关表，订单相关表，物流相关表 各自独立分类形成 用户系统数据库，订单系统数据库，物流系统数据库 如下图：
这样带来了一些好处： （a）业务清晰，职责单一 （b）易维护，易扩展 （c）数据服务化 。 同时也有一些负面的作用：（a）提高了整个应用的复杂度，而且会形成跨库事务 （b）引发 “木桶效应”，任何一个短板有可能影响整个系统 （c）部分表关系不能 join 只能通过服务相互调用来维系。甚至由于网络问题引发数据不一致。
在需要进行分库的情况下，通常可优先考虑垂直拆分。
3.2 数据库水平拆分
在数据库垂直拆分后遇到单机数据库性能瓶颈之后，就可以考虑数据库水平拆分了。 之所以先垂直拆分才水平拆分，是因为垂直拆分后数据业务清晰而且单一，更加方便指定水平的标准。比如我们对商城业务垂直拆分后的 用户系统 进行水平拆分就比对整个商城业务进行水平拆分好找维度，我们可以根据用户注册时间的区间、用户的区域或者用户 ID 的范围、 hash 等条件，然后关联相关表的记录将数据进行拆分，如果放在整个商城业务上你是以用户为准还是以订单为准都不太好考虑。
我们按照每 100 万为区间对用户系统水平拆分如下：
这种拆分的好处在于： （a）单个库的容量可控 （b）单挑记录保证了数据完整性 （c）数据关系可以通过 join 维持 （d） 避免了跨库事务 ；缺点同样存在：（a）拆分规则对编码有一定的影响 （b）不同业务的分区交互需要统筹设计
4. 分表
分表也分为 数据表垂直拆分 和 数据表水平拆分 。
4.1 数据表垂直拆分
数据表垂直拆分就是纵向地把表中的列分成多个表，把表从 “宽” 变“窄”。一般遵循以下几个点进行拆分：
- 冷热分离，把常用的列放在一个表，不常用的放在一个表。
- 大字段列独立存放
- 关联关系的列紧密的放在一起
我们把用户表中常用的和不常用的而且大字段分离成两张表：
4.2 数据表的水平拆分
表的水平拆分感觉跟库的水平拆分思想上都是一样的，只不过粒度不同。表结构维持不变。也就是说拆分后数据集的并集等于拆分前的数据集。理解了 3.2 章节 之后这个就没有什么可说的了。
5. 总结
这里简单阐述了几个数据库优化概念，在实际操作中往往会组合使用。我们在实际操作之前要做好数据量的预估，这样能够根据预测未来数据的增量来进行选型。业务数据增长较小，常用于表的拆分。增长特别大达到上万级别则可以选择分库，比如一些资金积分流水，历史记录之类的。有些时候并不是拆分完就万事大吉了，比如我们按照地区拆分后，A 地区业务增长很快业绩很好，而 B 地区推广不力竞争激烈业绩萧条，造成了数据倾斜。也会影响分库分表的期望效果。这需要建立长效的监控预测机制来应对，甚至根据实际情况及时调整策略。数据拆分还面临分布式的很多问题，分布式事务，高可用，数据一致性，全局唯一性都是应该考虑的问题。如果你有什么问题可以通过公众号：Java知己 与我交流。
关注公众号：Java知己 获取更多资讯
[个人博客：https://blog.kotom.cn/)