NewSQL为何使传统关系数据库黯然失色

传统数据库仍旧会有一席之地，至于NewSQL的优势又是什么，简单和大家说说：

首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题，国外有篇论文pavlo-newsql-sigmodrec，如果根据该文中的分类，Spanner、TiDB、OB算是第一种新架构型，Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种（文中还有第三种云数据库，本文暂不详细介绍）。

基于中间件（包括SDK和Proxy两种形式）+传统关系数据库（分库分表）模式是不是分布式架构？我觉得是的，因为存储确实也分布式了，也能实现横向扩展。但是不是“伪”分布式数据库？从架构先进性来看，这么说也有一定道理。

“伪”主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等，这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战，本文中NewSQL数据库特指这种新架构NewSQL数据库。

NewSQL数据库相比中间件+分库分表的先进在哪儿？画一个简单的架构对比图：

传统数据库面向磁盘设计，基于内存的存储管理及并发控制，不如NewSQL数据库那般高效利用；中间件模式SQL解析、执行计划优化等在中间件与数据库中重复工作，效率相比较低；NewSQL数据库的分布式事务相比于XA进行了优化，性能更高；新架构NewSQL数据库存储设计即为基于paxos（或Raft）协议的多副本，相比于传统数据库主从模式（半同步转异步后也存在丢数问题），在实现了真正的高可用、高可靠（RTO<30s，RPO=0）；NewSQL数据库天生支持数据分片，数据的迁移、扩容都是自动化的，大大减轻了DBA的工作，同时对应用透明，无需在SQL指定分库分表键。

常见的分库方式有水平性和垂直性。一般来说，就是按照用户属性（地市或者ID的hash）进行分库，或者按照业务功能块进行分库。

水平分库方式主要根据用户属性（如地市）拆分物理数据库。一种常见的方式是将全省划分为个大区。

垂直分库方式：根据业务维度和数据的访问量等，进行数据的分离，剥离为多个数据库。例如，将一些公用的配置信息存储到一个数据库中进行单独维护。

如果有数据路由功能的中间件，分库分表后应用程序可以避免修改。

比如mysql 的proxy 、 mycat 等。

一般分库分表也都要使用这些工具，不然对开发的程序侵入性太大，也不好维护。

mysql在常规配置下，一般只能承受2000万的数据量(同时读写，且表中有大文本字段，单台服务器)。现在超过1亿，并不断增加的情况下，建议如下处理：

1分表。可以按时间，或按一定的规则拆分，做到查询某一条数据库，尽量在一个子表中即可。这是最有效的方法

2读写分离。尤其是写入，放在新表中，定期进行同步。如果其中记录不断有update，最好将写的数据放在redis中，定期同步

3表的大文本字段分离出来，成为独立的新表。大文本字段，可以使用NOSQL数据库

4优化架构，或优化SQL查询，避免联表查询，尽量不要用count(),in，递归等消耗性能的语句

5用内存缓存，或在前端读的时候，增加缓存数据库。重复读取时，直接从缓存中读取。

上面是低成本的管理方法，基本几台服务器即可搞定，但是管理起来麻烦一些。

当然，如果整体数据量特别大的话，也不在乎投入费用的话，用集群吧，用TIDB吧

以上就是关于NewSQL为何使传统关系数据库黯然失色全部的内容，包括:NewSQL为何使传统关系数据库黯然失色、数据库水平分库和垂直分库有什么区别、数据库分库分表 sql需要重写吗等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！