数据库培训总结

数据库设计

1. 数据库分表有范围分区、哈希分区、列表分区、组合支持虚拟字段分区。
范围分区：按照时间分区，实际存储每个表为单独的表，只是逻辑上为一个大表。
哈希分区：按照哈希值分区。
列表分区：一个逻辑的分区判断。
组合分区：多个分区方法结合。

 

2. 索引：以空间换时间（物化视图）。
如果读取时候绝大部分数据都被读取，那么索引的效果没有体现，查询结果要少于30%建立索引才有意义。
数据库会为索引单独建立一个索引空间，可以到达几个G。
几千行的数据并不需要建立索引。
索引也是分区的，本地索引（强制分区表空间），全局分区索引（规定分表，但不规定分区表空间）。

 

3. 并行技术：多线程同时读取，相当耗费cpu。主要是因为需要硬解析，每个操作都是要生成执行计划。
 软解析：对于每条sql，Oracle都会记录下，当有重复的sql，Oracle会直接用以前的执行计划（一步一步如何查询出来的操作）

4. 缓冲：热表

 

5. 压缩：压缩后存储数据块少，I/O少，读取快了。但是updata效率很低，要先解压缩，更新，在压缩。
可以对新的数据压缩，也可以对所有数据压缩。

 

6. 优化：
主要是应用上（70%-80%）
写的不好的SQL
表结构设计不合理
应用设计不合理
看cpu主要看等待时间，什么也做不了等待某种资源，比较浪费。然后看交换空间是否很大，如果很大可以考虑加内存。

 

关系数据库云化：

1. 淘宝、腾讯、facebook等大互联网公司多使用关系数据库云化用1000多的mysql集群。集群到最后，往往提高性能的是缓存，大内存的缓存，淘宝双11靠的主要是缓存。

 

2. 关系数据库云化与大数据的hadoop应用场景不同，map reduce，nosql，hadoop等大数据对同步一致要求不高，大数据一般是用来分析，不适合处理关系型大数据业务处理，而对交易业务，必须使用关系数据库，大数据方法并不适用。

 

3. 改进的关系数据库一般扩展几十台，而hadoop可以扩展上千台。

 

4. Teradata、Exadata提供先进了关系云数据库，但是加个非常昂贵，存储节点加上计算节点公22台pc能报价上千万，为一个通用的产品。

 

5. 数据库如果没有索引，那么处理速度一般就1秒三四M，而且受限硬盘速度的限制，硬盘一般就10M一秒。

 

6. 关系大数据库云化的使用技术，分库、分表、读写分离。

 

7. 分库一般是垂直分库，根据不同的业务模型进行，按照商品、交易、用户等分库，这个是数据变大后第一个处理方法，可以用几个Oracle分库。

 

8. 分表可以按照hash、固定size等方法，使用hash分表再增加一个节点的时候需要对数据进行重新分配，固定大小方法没有这个问题，但是查找效率相对较低，一致性hash方法可以减少这个问题。

 

9. 读写分离并不一定能够提高性能，与读写所类似，要读的情况远多于写的情况的时候读写分离才有效（读写锁也是，否则可能性能还会降低）。读写分离有一定的前提，对一致性与实时性要求不高，如果要求实时性很高那么读写分离一点作用也不会有。

 

10. 数据库间关系是对等还是主从？对等的扩展性很好但是非常复杂，一般是主从与对等相结合。

 

11. 公共基础服务：分布服务：全局id生成，路由，查询（一个sql分多个，再合并）；协调服务，主要有分布式锁，全局配置（考虑同步），读写分离，线程池，自动恢复，负载均衡；监控与管理服务，包括新增节点，性能监视等。消息服务：主要考虑远程过程调用，多并发。公共服务非常复杂庞大，开发量巨大，非专业it公司往往不能开发完成。

 

12. 尽量避免分布式事务，基本可以放弃，性能消耗特别大，可以通过设计或者需求去避免。

 

13. 联邦摒弃了一些特性，例如关联的一致性、事务等等，这些特性可以在加载好表后去内存中完成大表与小表的关联，再分布式关联的时候，可以把常用的表拷贝到各个机器中一份。

 

14. 互联网有特殊的业务，往往很难通过开源来解决，大规模的方案往往需要自己解决，互联网公司it研发能力较强，转到传统行业中，需求往往也是定制化的，不同需求会有不同的设计，例如是否需要读写分离？但是研发成本往往很高。