从数据库角度看,大多企业关键业务的特点是:主要操作是交易型(OLTP),也要执行一些分析型(OLAP)操作。对于这样的应用,最理想的数据库架构是什么?是SQL Server/MySQL/PostgreSQL这样单机数据库?还是Oracle RAC这样的基于共享存储的集群?或者是OceanBase、TiDB这样的share nothing分布式集群?
在我看来,理想的数据库架构是:基于共享存储的集群 + 全闪分布式存储 + 算子下推。为什么?
分布式数据库的优点是:横向可扩展(scale-out)能力很强、总体聚合性能高、处理分析型负载的能力强。
缺点是:
(5)存算一体架构,存储和计算强绑定,配比是固定的,无法单独对存储扩容,也不能单独扩容计算能力。
2、为什么不是单机版数据库?
相对于基于共享存储的数据库集群,对单机版数据库定期做冷备份,故障时用冷备数据来恢复业务,故障恢复时间比较长,可用性不高。
另外,PostgreSQL 和 MySQL 的高可用方案复杂,管理成本比较高。
3、为什么是全闪分布式存储,而不是全闪阵列?
全闪阵列是专用硬件,成本比较高,也有单一厂商锁定问题。一般来说,分布式存储也是软件定义存储(SDS),标准化服务器,价格透明,也没有被单一硬件厂商锁定的问题。
全闪阵列一般分为高端、低端等不同系列,高端阵列价格很高,低端阵列可扩展性比较差,
4、为什么需要算子下推?
多数企业应用,并不是只有单纯的交易型操作,也有一些分析型操作。基于共享存储的集群数据库不擅长完成大规模分析型任务,外部存储系统与运行数据库的主机之间带宽有限,如果能够把这些分析型任务拆分之后下发到分布式存储节点上去执行,存储节点把执行结果返回给主机,在主机和存储节点之间,不再需要很高的网络带宽。这将会大大提升执行效率,缩短执行时间。
作者简介
黄岩,云和恩墨分布式存储软件总架构师,十余年存储研发经验,在NAS和备份领域有深入钻研,曾担任某NAS产品性能SE,负责产品性能调优工作,该产品在2011年打破了SPESsfs性能测试世界纪录。
「墨读时刻」特别节目黄岩人物专访即将上线,听一位存储老兵讲述摸爬滚打的这些年和对未来自研存储的洞察,敬请期待... ...
网站声明:如果转载,请联系本站管理员。否则一切后果自行承担。
添加我为好友,拉您入交流群!
请使用微信扫一扫!