(关注“数据库架构师”公众号,提升数据库技能,助力职业发展)
工作中总是遇到数据存储相关的需求工单,新需求开发设计中也多多少少会有数据模型设计和存储相关的问题。经过几次存储方案设计选型和讨论后发现需要有更全面的思考框架。
故写了这篇文章,抛出我的总结和思考,希望日后可以将一些更先进 (合适) 的技术引入业务开发中,助力业务发展。
存储选型的考虑要素
存储选型的目的还是为了我们的使用场景和用户服务,因此在选型前需要回答自己一些 业务指标 & 技术指标 方面的问题,以便于我们清楚存储选型的应用环境。
存储引擎分类及特性
数据库的分类方式非常多样,因参考维度不同而存在较大差异,下面是常见的一些分类。
数据库类型 | 常见数据库 |
关系型 | MySQL、Oracle、DB2、SQLServer 等。 |
非关系型 | Hbase、Redis、MongodDB 等。 |
行式存储 | MySQL、Oracle、DB2、SQLServer 等。 |
列式存储 | Hbase、ClickHouse 等。 |
分布式存储 | Cassandra、Hbase、MongodDB 等。 |
键值存储 | Memcached、Redis、MemcacheDB 等。 |
图形存储 | Neo4J、TigerGraph 等。 |
文档存储 | MongoDB、CouchDB 等。 |
先拿我们最熟悉的关系数据库来说,它的优点非常多,我们选用关系数据库的理由可简单概括为以下几点:
然而,在享受关系数据库带来的便利的同时,我们也不得不面临很多麻烦的问题:
如上文所分析的,关系型数据库优点明显,缺点同样不能忽视,因此通常在企业规模不断扩大的情况下,不会一味指望通过增强数据库的能力来解决数据存储问题,而是会引入其他存储,也就是我们说的 NoSql。
NoSql 的全称为 Not Only SQL,泛指非关系型数据库,是对关系型数据库的一种补充,特别注意补充这两个字,这意味着 NoSql 与关系型数据库并不是对立关系,二者各有优劣,取长补短,在合适的场景下选择合适的存储引擎才是正确的做法。下面看一下常用的 NoSql 及他们的代表产品,并对每种 NoSql 的优缺点和适用场景做一下分析,便于熟悉每种 NoSql 的特点,方便技术选型。
KV 型 NoSql(代表 —-Redis)
KV 型 NoSql 顾名思义就是以键值对形式存储的非关系型数据库,是最简单、最容易理解也是大家最熟悉的一种 NoSql。Redis、MemCache 是其中的代表,Redis 又是 KV 型 NoSql 中应用最广泛的 NoSql,KV 型数据库以 Redis 为例,最大的优点总结下来主要有两点:
因此,KV 型 NoSql 最大的优点就是高性能,利用 Redis 自带的 BenchMark 做基准测试,TPS 可达到 10 万的级别,性能非常强劲。同样的 Redis 也有所有 KV 型 NoSql 都有的比较明显的缺点:
针对那些读远多于写的数据,引入一层缓存,每次读从缓存中读取,缓存中读取不到,再去数据库中取,取完之后再写入到缓存,对数据做好失效机制通常就没有大问题了。通常来说,缓存是性能优化的第一选择也是见效最明显的方案。
搜索型 NoSql(代表 —-ElasticSearch)
传统关系型数据库主要通过索引来达到快速查询的目的,但是在全文搜索的场景下,索引是无能为力的,like 查询一来无法满足所有模糊匹配需求,二来使用限制太大且使用不当容易造成慢查询,搜索型 NoSql 的诞生正是为了解决关系型数据库全文搜索能力较弱的问题,ElasticSearch 是搜索型 NoSql 的代表产品。
全文搜索的原理是倒排索引,我们看一下什么是倒排索引。要说倒排索引我们先看下什么是正排索引,传统的正排索引是文档 –> 关键字的映射,例如”Tom is my friend” 这句话,会将其切分为”Tom”、”is”、”my”、”friend” 四个单词,在搜索的时候对文档进行扫描,符合条件的查出来。这种方式原理非常简单,但是由于其检索效率太低,基本没什么实用价值。
倒排索引则完全相反,它是关键字 –> 文档的映射,举例来说,现在这里有四个短句:
搜索引擎会根据一定的分词规则将一句话切成 N 个关键字,并以关键字的维度维护关键字在每个文本中的出现次数。这样下次搜索”Tom” 的时候,由于 Tom 这个词语在”Tom is Tom”、”Tom is my friend”、”Tom is Betty’s husband” 三句话中都有出现,因此这三条记录都会被检索出来,且由于”Tom is Tom” 这句话中”Tom” 出现了 2 次,因此这条记录对”Tom” 这个单词的匹配度最高,最先展示。这就是搜索引擎倒排索引的基本原理,假设某个关键字在某个文档中出现,那么倒排索引中有两部分内容:
可以举一反三,我们搜索”Betty Tom” 这两个词语也是一样,搜索引擎将”Betty Tom” 切分为”Tom”、”Betty” 两个单词,根据开发者指定的满足率,比如满足率 = 50%,那么只要记录中出现了两个单词之一的记录都会被检索出来,再按照匹配度进行展示。
搜索型 NoSql 以 ElasticSearch 为例,它的优点为:
同样,ElasticSearch 也有比较明显的缺点:
因此,搜索型 NoSql 最适用的场景就是有条件搜索尤其是全文搜索的场景,作为关系型数据库的一种替代方案,通常搜索型 NoSql 也会作为一层前置缓存,来对关系型数据库进行保护。
另外,搜索型数据库还有一种特别重要的应用场景。我们可以想,一旦对数据库做了分库分表后,原来可以在单表中做的聚合操作、统计操作是否统统失效?例如我把订单表分 16 个库,1024 张表,那么订单数据就散落在 1024 张表中,我想要统计昨天浙江省单笔成交金额最高的订单是哪笔如何做?我想要把昨天的所有订单按照时间排序分页展示如何做?这就是搜索型 NoSql 的另一大作用了,我们可以把分表之后的数据统一打在搜索型 NoSql 中,利用搜索型 NoSql 的搜索与聚合能力完成对全量数据的查询。
列式 NoSql(代表 —-HBase)
列式 NoSql 和关系型数据库一样都有主键的概念,区别在于关系型数据库是按照行组织的数据,数据字段即使没有值同样占空间,列式存储完全是另一种方式,它是按列进行数据组织的,好处在于:
大数据时代最具代表性的技术之一 HBase 就是列式 NoSQL 的产品实现,其优点主要是:
缺点主要表现在:
因此 HBase 比较适用于 KV 型存储且未来无法预估数据增长量的场景,另外 HBase 使用还是需要一定的经验,主要体现在 RowKey 的设计上。
文档型 NoSql(代表 —-MongoDB)
文档型 NoSql 指的是将半结构化数据存储为文档的一种 NoSql,文档型 NoSql 通常以 JSON 或者 XML 格式存储数据,因此文档型 NoSql 是没有 Schema 的,由于没有 Schema 的特性,我们可以随意地存储与读取数据,因此文档型 NoSql 的出现是解决关系型数据库表结构扩展不方便的问题的。
MongoDB 是文档型 NoSql 的代表产品,同时也是所有 NoSql 产品中的明星产品之一,它的很多概念与关系数据库类似,因此,对于 MongDB,我们只需要理解成一个 Free-Schema 的关系型数据库就好了,其优点主要是:
缺点在于:
总而言之,MongDB 的使用场景很大程度上可以对标关系型数据库,但是比较适合处理那些没有 join、没有强一致性要求且表 Schema 会常变化的数据。
通过以上讨论分析我们心中已经有了一个基本的选型框架指导,实际上在数据库选型时回答自己两个核心问题就好了:
NoSQL 数据库都是通过牺牲了 ACID 特性来获取更高性能的,假设表数据有很强的事务特性需求,那么这类数据是不适合放在非关系型数据库。此外,选用 NoSQL 数据库时也要根据公司技术栈框架、业务特性、运维成本等多方面考虑是否采纳。
总结
关系型数据库和 NoSQL 数据库的选型,往往需要考虑几个指标:
常见软件系统数据库选型参考如下:
设计实践中,要基于需求、业务驱动架构,无论选用 RDB/NoSQL, 一定是以需求为导向,最终数据存储方案必然是各种权衡的综合性设计。
说明:本文转自数据库存储选型经验总结
页面更新:2024-04-20
本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828
© CopyRight 2008-2024 All Rights Reserved. Powered By bs178.com 闽ICP备11008920号-3
闽公网安备35020302034844号