集群?内存数据库:关系数据库

举报
费德勒 发表于 2017/04/14 14:44:14 2017/04/14
【摘要】 内存数据库的价值在于其强大的保护备份(容灾保护)、同时支持集群、很方便支持在线扩容、在线缩容。

​徒弟问“要内存数据库干什么? 我们设备本地不是都有内存数据缓存吗?”
答曰“内存数据库的价值在于其强大的保护备份(容灾保护)、同时支持集群、很方便支持在线扩容、在线缩容。这是我的理解。”
PS: 文中内存数据库是指分布式内存数据库

1、关系型数据库的特点
关系型数据库(RDBMS Relational Database Management System)
a、可获取持久化的数据
b、通过事物来支持并发
c、数据共享(共享同一服务器上的一份数据提供多个APP使用)
d、支持标准的SQL及模式(标准SQL使得关系数据库的通用性极强)
模式:也就是预定义结构来向数据库说明:需要哪些表格,表中有哪些列,每列存放何种类型数据。必现先定义好模式,然后才能存放数据。

2、关系型数据库的致命弱点:不能适应 云、大数据的需求
关系型数据库的设计决定了他无法支持好数据库集群,关系型数据库的不同数据分在不同的表中,某一个业务(用户)操作,可能需要访问不同的表才能完成它的操作,而此时需要访问的表可能分布在不同的数据节点上(甚至不同的数据中心),表之间有Relation,这样业务操作的时延是将问题(大数据时更明显),更重要的是跨节点、跨数据中心的表数据分布使得关系型数据库很难支持数据操作的ACID。
数据库的基本特征要求:ACID
Atomicity 原子性
Consistency 一致性
Isolation 隔离性
Durability 持久性

3、内存数据库:为集群而生,成功分一杯羹
内存数据库特征:
a、不用关系模型(无模式,即数据库本身不涉及模式,其实是把模式的定义上移到了上层APP)
b、可在集群中运行
c、可随APP一起部署
要支持集群,首先要抛弃关系模型,所以内存数据库采用了面向聚合的模型,需要聚合的信息由APP来决定,相当于把关系模式上移到APP,而不是在数据库侧。
面向聚合模型的思路是把这些聚合信息放到同有一个节点,使得APP采集数据时所需要访问的数据节点降至最低,以降低时延。
所以聚合体是作为数据分布的一个最小单元存在,支撑服务器集群横向扩展(横向扩展:通过新增数据节点来扩容,而不是在单机上不断增加内存条)。

举例说明下我对聚合的理解:
学生管理系统,学生的信息包含了其 名字、班级、年龄、性别、班主任等等信息。采用关系数据库:学生的信息被分在不同的表中存贮,表间建有Relation,当我们要查询某学生的所有信息时,通过SQL获取所有表中相关的信息。这种模式,要查询的数据是分离的,在不同的表中。
采用内存数据库:以k-v模型(key value模型)的内存数据库为例,把某学生所有的信息聚合放到v中,再给学生分一个ID作为k。 APP通过ID即可一次性获取某学生的所有信息。这种模式要查询的数据在一个表中。系统中学生的信息会分布在不同的数据节点或数据中心,当某个数据节点挂掉,只会影响一部分数据的访问,容灾性好。

​4、内存数据库不足及技术难点
a、“无模式”的灵活性仅限于聚合内部,如果改动了聚合边界,那么数据迁移工作和关系数据库一样,都非常复杂。所以,要用好内存数据库,APP要根据自身业务特征设计好聚合体,尽量避免未来聚合体在未来频繁变化。
b、集群的数据分布方案中主要涉及数据节点间的数据复制和数据分片,技术难点在如何保证主备数据的一致性 和 复制、分片的可靠性。
数据复制:是为了产生备份数据
数据分片:是把一个表的数据分布在不同的数据节点,降低因某个节点挂掉导致同一个表上所有数据不可用

作者 |莫相孟

转载请注明出处:华为云博客 https://portal.hwclouds.com/blogs

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200