当今的数据处理大致可以分成两大类：
联机事务处理OLTP（On-Line Transaction Processing） 主要就是需要原始数据到达计算中心并且在很短的时间内给出处理结果
联机分析处理OLAP（On-Line Analytical Processing）主要是通过多个维度和各项指标对数据进行分析统计和报表等，最后给出一个合理的结果用于处理
OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
|
OLTP |
OLAP |
|
|
用户 |
操作人员，低层管理人员 |
决策人员，高级管理人员 |
|
功能 |
日常操作处理 |
分析决策 |
|
DB 设计 |
面向应用 |
面向主题 |
|
数据 |
最新的，细节的，二维的，分立的 |
历史的，聚集的，多维的，集成的 |
|
存取规模 |
读/写数条（甚至数百条）记录 |
读上百万（甚至上亿）条记录 |
|
操作频度 |
非常频繁（以秒计） |
比较稀松（以小时甚至以周计） |
|
工作单位 |
严格的事务 |
复杂的查询 |
|
用户数 |
数百个-数千万个 |
数个-数百个 |
|
DB 大小 |
100MB-GB |
100GB-TB |
| 关系型数据库 | NoSQL数据库 | |
| 特点 |
-数据关系模型基于关系模型，结构化存储，完整性约束。 -基于二维表及其之间的联系，需要连接、并、交、差、除等数据操作。 |
-非结构化的存储 -基于多维关系模型 -具有特有的使用场景 |
| 优点 |
-保持数据的一致性（事务处理） -可以进行join等复杂查询 -通用化，技术成熟 |
-高并发，大数据下读写能力较强 -基本支持分布式，易于扩展，可伸缩。 -简单，弱结构化存储 |
| 缺点 |
-数据读写必须经过sql解析，大量数据、高并发下读写性能不足 -对数据做读写，或修改数据结构时需要加锁，影响并发操作 -无法适应非结构化存储 -扩展困难 -昂贵、复杂 |
-join 等复杂操作能力较弱 -事物支持较弱 -通用性差 -无完整约束复杂业务场景支持较差 |
数据切分：
简单来说，就是通过某种特定的条件。将我们存在在同一个数据库中的数据分散存储到多个数据库（Master）上面，以达到分散单个确保负载的效果。
数据的切分（sharding）根据其切分规则的类型，可以分为两种切分模式，一种按照不同的表（或者schema）来切分到不同的数据库（master）之上，这种切分称之为数据的垂直（纵向）切分；另外一种则是根据表中的数据逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（Master）上，这种切分称之为水平（横向）切分
垂直切分：垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各种业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做的将不同业务模块所使用的表拆分到不同数据库中。根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。
水平切分于垂直切分相比较而言稍微复杂，因为要将同一个表中的不同数据拆分到不同的数据库中，对应用程序来说，拆分规则本身就比根据表名（业务块）更为复杂，后期的数据维护、查询、统计分析也比较复杂。
首先，对于高并发系统，我们应该需要规避的问题，或者说在库表设计的时候/代码编写的时候要注意的点：
我们面对比如订单这种高并发、实时写数据场景，我们要做的第一点就是拆分，水平去做分表，根据一些特定的规则去做路由设置
然后我们考虑路由表的结构，如何进行结构化存储，根据什么维度去做，要考虑后续的查询效率，以及业务需求点在哪里会是瓶颈。
接下来，我们如何进行设计数据源切换，多少个库表合适，按照哪种策略去切换数据源、散表等。
数据库的事物问题，如果有分布式事物，我们应该怎么去做？到底该不该使用事物？如果不启用事物，性能会有多大的提升，面临数据不一致等问题如何解决；如果使用事物，需要长事物还是短事物？如果高并发下出现事物死锁，那么我们的业务就会出现很大的问题；这些我们都要考量，压测之后我们给出结论
分库分表策略:
https://blog.csdn.net/qiansg123/article/details/80123124