
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
数据库架构开发是大多数软件编程开发程序员都应该熟练掌握的一个编程技术,而本文我们就通过案例分析来简单了解一下,关系数据库应用发展分析。
高性能NoSQL
关系数据库经过几十年的发展后已经非常成熟,强大的SQL功能和ACID的属性,使得关系数据库广泛应用于各式各样的系统中,但这并不意味着关系数据库是完美的,关系数据库存在如下缺点。
关系数据库存储的是行记录,无法存储数据结构
以微博的关注关系为例,“我关注的人”是一个用户ID列表,使用关系数据库存储只能将列表拆成多行,然后再查询出来组装,无法直接存储一个列表。
关系数据库的schema扩展很不方便
关系数据库的表结构schema是强约束,操作不存在的列会报错,业务变化时扩充列也比较麻烦,需要执行DDL(datadefinitionlanguage,如CREATE、ALTER、DROP等)语句修改,而且修改时可能会长时间锁表(例如,MySQL可能将表锁住1个小时)。
关系数据库在大数据场景下I/O较高
如果对一些大量数据的表进行统计之类的运算,关系数据库的I/O会很高,因为即使只针对其中某一列进行运算,关系数据库也会将整行数据从存储设备读入内存。
关系数据库的全文搜索功能比较弱
关系数据库的全文搜索只能使用like进行整表扫描匹配,性能非常低,在互联网这种搜索复杂的场景下无法满足业务要求。
针对上述问题,分别诞生了不同的NoSQL解决方案,这些方案与关系数据库相比,在某些应用场景下表现更好。但世上没有免费的午餐,NoSQL方案带来的优势,本质上是牺牲ACID中的某个或者某几个特性,因此我们不能盲目地迷信NoSQL是银弹,而应该将NoSQL作为SQL的一个有力补充,NoSQL!=NoSQL,而是NoSQL=NotOnlySQL。
常见的NoSQL方案分为4类。
K-V存储:解决关系数据库无法存储数据结构的问题,以Redis为代表。
文档数据库:解决关系数据库强schema约束的问题,以MongoDB为代表。
列式数据库:解决关系数据库大数据场景下的I/O问题,以HBase为代表。
全文搜索引擎:解决关系数据库的全文搜索性能问题,以Elasticsearch为代表。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。