随着近几年互联网 IT 的发展, 非关系型数据库 (NoSQL) 得到了极大的发展和应用和传统的关系型数据库相比, NoSQL 数据库为软件开发人员提供了高运算速度和更大的灵活性
NoSQL 数据库的数据结构一般有:
键值对(key-value), 代表数据库: Redis
列存储(Wide Column), 代表数据库: Cassandra,HBase
图(graph), 代表数据库: Neo4J
文档(document), 代表数据库: MongoDB
这些数据结构和关系型数据库表格式的数据结构都有非常大的区别, 它们都是为了适应特定的业务场景而设计的在某个业务场景下应该选择关系型数据库还是非关系数据库选择哪种类型的非关系数据库是非常重要的, 今天我们就一起来看看针对不同的业务场景应该如何选择 NoSQL 数据库
键值对 (key-value) 数据库
redis 数据库
键值数据库就像在传统语言中使用的哈希表你可以通过 key 来添加查询或者删除数据, 鉴于使用主键访问, 所以会获得不错的性能及扩展性
适用的场景:
通过键来定位查找而不是通过值来查找的业务
缓存
不适用的场景:
需要通过值来查找的业务, Key-Value 数据库中根本没有通过值查询的途径
需要储存数据之间的关系在 Key-Value 数据库中不能通过两个或以上的键来关联数据
需要事务的支持在 Key-Value 数据库中故障产生时不可以进行回滚
列存储 (Wide Column Store) 数据库
HBase 数据库
列存储数据库将数据储存在列族 (column family) 中, 一个列族存储经常被一起查询的相关数据举个例子, 如果我们有一个 Person 类, 我们通常会一起查询他们的姓名和年龄而不是薪资这种情况下, 姓名和年龄就会被放入一个列族中, 而薪资则在另一个列族中
适用的场景
日志因为我们可以将数据储存在不同的列中, 每个应用程序可以将信息写入自己的列族中
博客平台我们储存每个信息到不同的列族中举个例子, 标签可以储存在一个, 类别可以在一个, 而文章则在另一个
不适用场景
如果我们需要 ACID 事务 Cassandra 就不支持事务
原型设计如果我们分析 Cassandra 的数据结构, 我们就会发现结构是基于我们期望的数据查询方式而定在模型设计之初, 我们根本不可能去预测它的查询方式, 而一旦查询方式改变, 我们就必须重新设计列族
图 (Graph) 数据库
Neo4j 数据库
图数据库允许我们将数据以图的方式储存实体会被作为顶点, 而实体之间的关系则会被作为边
适用的场景
在一些关系性强的数据中
推荐引擎如果我们将数据以图的形式表现, 那么将会非常有益于推荐的制定
不适用场景
不适合的数据模型图数据库的适用范围很小, 因为很少有操作涉及到整个图
文档 (Document) 数据库
mongoDB 数据库
文档数据库会将数据以文档的形式储存每个文档都是自包含的数据单元, 是一系列数据项的集合每个数据项都有一个名称与对应的值, 值既可以是简单的数据类型, 如字符串数字和日期等; 也可以是复杂的类型, 如有序列表和关联对象数据存储的最小单位是文档, 同一个表中存储的文档属性可以是不同的, 数据可以使用 XMLJSON 或者 JSONB 等多种形式存储
适用的场景
日志企业环境下, 每个应用程序都有不同的日志信息 Document-Oriented 数据库并没有固定的模式, 所以我们可以使用它储存不同的信息
分析鉴于它的弱模式结构, 不改变模式下就可以储存不同的度量方法及添加新的度量
不适用场景
在不同的文档上添加事务 Document-Oriented 数据库并不支持文档间的事务, 如果对这方面有需求则不应该选用这个解决方案
来源: http://database.51cto.com/art/201803/569001.htm