在数据库的应用中，数据库能承受的性能是我们选择使用数据库时要参考的非常重要的因素。过高或过低的评估都将直接影响业务系统对外能提供的吞吐量，以及后期业务发展所带来的扩容问题。
在关系型数据库中，单表存储的极限在亿级别。特别是MySQL，单表存储过亿时，数据查询会异常缓慢。而Redis、MongoDB、HBase等非关系型数据库，都支持Sharding分区功能，数据存储基本不受限制。在QPS方面，关系型数据库的极限在万级别，而非关系型数据库，根据集群规模不同，能轻松应对10万级别以上的高并发读写需求。
进行一个数据库的选型，主要需要考虑如下两点：
一是业务侧的背景需求，比如是游戏行业、电商行业还是金融行业，存储的是游戏装备/充值记录，还是电商用户订单/商品信息，又或者是金融交易数据等。业务侧对数据的结构、未来规划及扩展的需求，决定了我们是选择关系型数据库还是非关系型数据库这一大类别方向。
对数据结构、数据表及集合的规划设计，选择适合业务需求的关系型数据库或者非关系型数据库，满足业务对数据增删查改的需求。
需要考虑一些热点数据查询需不需要借助Key-Value内存数据库做缓存，从架构上减少数据库压力，提升业务系统的性能效率及稳定性。
在代码连接池方面，设计合理的连接池，连接数不宜过大或过小，以免导致后端数据库连接数不释放等性能问题。
在一些对数据库高并发的场景加入队列的控制，也是有效减轻对数据库直接压力冲击的一种方式。
- 二是运维侧的架构需求，主要表现在数据库的性能及数据库架构扩展能不能满足对业务侧快速发展迭代在数据库存储、性能、扩展方面的需求。即选择对应数据库技术能不能支撑业务的迭代和快速发展。1.存储的数据规模及后期扩展，采用主从还是副本集，又或者是Sharding的数据库架构？2.出现异常怎么进行快速切换，是需要代码层主动切换IP，还是数据库结合通过DNS+LB（负载均衡）+HA（高可用）的技术完成无缝切换？
云数据库的运维架构层考量及规划：云数据库底层已经通过DNS+LB（负载均衡）+HA（高可用）的技术保障数据库高可用，增加主从节点、增加Sharding都可以在控制台界面一键式操作。
云数据库的硬件及基础环境部署：云数据库已经封装成产品服务，不需要考虑选择什么服务器配置来部署数据库，只需要开通对应规格型号的云数据库即可使用。
云数据库的安装配置及优化：云数据库在参数方面已经优化成最优，不需要手动再去调优对应的数据库配置参数。
云数据库的SQL语句优化：云数据库在控制台直接给出慢查询的明细及优化建议。
云数据库的日常备份及恢复：云数据库自带热备及冷备，只需要手动在控制台设置对应的备份策略即可。
而我们更多的是要从业务角度出发选择需要什么样类型的数据库。
需要存储什么类型的业务数据：比如用户数据、交易数据，对数据一致性上要求较高，需要优先考虑关系型数据库。
需要存储什么量级的数据：比如TB级别数据，关系型数据库的存储已经很慢了。
需要提供什么访问量级的访问：比如上万的并发请求，关系型数据库性能已经快到极限。
