【数据库技术的特点】在分布式数据库技术选型前,我们都考虑些什么?

2019-02-23 16:36:15 其他数据库 97 views 其他数据库
[导读]:本文(《在分布式数据库技术选型前,我们都考虑些什么?》)由来自江西的用户投稿,并经由本站(数据库吧)结合主题:数据库技术的特点,收集整理了众多资料而成。主要记述了分布式数据库,mysql,大数据,数据库技术,mysql读写分离,mysql中间件,mysql数据库等方面的信息。相信从本文您一定可以获得自己所需要的!

题图: from Zoommy

对于许多金融企业(含互金)来说,在系统初始阶段,使用 ‘IOE’ 技术选型进行核心系统的搭建,似乎是种标配,但随着系统拆分的演进,从年初起,我们开始讨论数据库中长期规划的相关话题。

跟大多数金融行业的数据库选型一样,我们的核心系统运行在商业关系型数据库之上,而将大部分QPS交给分布式缓存来进行处理。

- 01. 为什么选择MySQL作为选型 -

在这一点上,通过大量的调研与大咖交流后,我们最初除MySQL外,还尝试了解过例如PostgreSQL,TiDB等其他不同种类的DB,但最终选择了MySQL,不是说MySQL最优秀,也不是其它DB不优秀,更重要的原因是MySQL可以对他们的业务模型在支撑上更方便一点,更重要的原因是其他数据库的人才难招、难管、难养活。

除此之外,其他数据库在国内社区没发展起来,用户及业务场景覆盖度不够广等原因,也是产生顾虑的主要来源,而反观MySQL,无论社区还是产品成熟度,相对更加稳定、更加活跃。

大胆设想下,除非业务规模已处于 “扛不住了,不干就死了” 的地步,又有哪家强业务驱动型的金融企业,愿意建立 “一个看似华丽,投入又大的数据库团队” 呢?疯了吧?

以上这些原因,促使我们选择了MySQL。

- 02. 为什么要开搞分布式数据库 -

简明扼要,列出思考的起始点(如与Oracle数据库相比):

  • 钱往哪花?购买商业数据库授权?还是用开源数据库+自主研发?

  • 服务越来越多怎么办?搞过Oracle的人都知道,面对越来越多的服务数量,及越来越小的服务颗粒,光存储设备的投入,就可以让你眼睛一辣。

  • 怎么上云?虽说现在Oracle 12C号称能够上云,但并不是所有的云厂商都能支持,就算能支持,也会开出个天价。

  • 数据越来越大怎么办?这点上,Oracle有着完美的解决方案,但又不能光看这一项而忽略以上几项,可MySQL(单/群)又无法满足,只能通过对数据的水平拆分,或者垂直拆分来进行加持。

  • 数据库管理的成本怎么投?这点上,Oracle也属于完胜,但是该把这部分钱投在买商业管理软件上呢?还是投在自主研发上呢?如果选择商业路线,后期的维护可以跟上吗?

其实,以上五点未必都是“不用分布式数据库就会死”的核心理由,有些也只不过是借助这件事的推动,而期望获得的辅助收益罢了。

图片

不管怎么说,数据库,一个系统(或者一家企业)的命脉,在业务发展进入稳定期之后,结合自身特点、技术价值观及中长期技术投入考虑,选定一个关系型数据持久化的技术选型进行长久的规划与孵化,是非常有必要的。

- 03. 分布式数据库有哪几种玩法 -

根据思考的起始点,我们整理出两种玩法,下面我以笔记的形式进行下罗列:

| 第一种:重量级中间层

大体上可以分为两类形态:

  • 商业形态:如腾讯云DCDB、阿里云DRDS。

  • 开源形态:如MyCat、Cobar。

商业形态

把大部分关于数据库的操作通过数据库的中间价层来去实现,例如支持各种规则的分库和分表,支持分布式事物,支持各种分片节点的聚合等操作。

优点

  • 使用中间价来分担后端的数据库的压力。

  • 使用中间价来完成数据聚合,减少开发的代码逻辑。

缺点

  • 会产生一定购买中间价的费用。

  • 对于中间价和中间件厂商的依赖过大。如果中间件厂商不靠谱,毕竟代码不开源,那时候我们该应对?

开源形态

目前主流的开源MyCAT和dble等产品。dble主要是针对MyCAT进行bug的修复和一些新功能的完善。目前社需活跃,修复bug还算及时。

图1. MyCat的系统拓扑图

图1. MyCat的系统拓扑图

优点

  • 相对商业化的产品,可能不需要依赖云平台,可以节约一定成本。

  • 代码开源,可以根据实际情况进行修改。

缺点

  • 部分功能的不支持,不如商业产品的完善 可靠。

  • 虽然代码开源,如要针对进行功能的添加和二次的修改,要么依赖社区或者厂商,要么自己招聘相关的工程师。

| 第二种:轻量级中间层

轻量级的中间价的开源产品主要有proxysql,由国外工程师开发,目前社区活跃,修复bug和更新代码能力的频率还是挺好的。

中间价主要的工作就是,按照规则连接的转发。把前端的SQL解析,按照一定的路由规则,发配到后端数据库,然后数据库返回结果,并吐给前端应用。可以做到读写分离 或者分库等。

图2. 自研ProxySet模式的系统拓扑图

图2. 自研ProxySet模式的系统拓扑图

优点

  • 相对商业化的产品,可能不需要依赖云平台,可以节约一定成本。

  • 代码开源,可以根据实际情况进行修改。

缺点

  • 不一定能满足我们的业务的场景,可能需要开发同学大力的配合。

  • 虽然不在过渡依赖中间价产品,但对后端的数据压力确增大了,这就意外后端的数据库需要更好的机器 更好的配置。

此外,也可以直接裸用MySQL,简单粗暴的雇佣20个DBA,1人只管理一个MySQL实例,并配置最牛逼的机器,来解决目前的现状,想想也挺好的。

根据上述方案我们看到,对于体量较小的业务层,理论上采用第二种方案更经济实惠,而对于体量较大,并发性、稳定行要求较高的,理论上采用第一种方案更为稳妥。

- 小   结 -

数据库,从商业数据库切换至MySQL,无论是否分布式,都无法采取像中间件SDK那样的平滑适配方案(可参考 这篇文章)。

光改SQL这一项,就不得不让你付出与重构相对等的成本与代价。

截止当下,我们正处于探索与方案尝试的阶段,所以本文也无法给出确切的方案,只是通过一些思考与整理,尽量让探索之路显得更明确、更贴身。

数据库技术的特点视频

AEC_BIM及数据库技术在结构工程的应用

相关问答

问:数据库技术在人工管理阶段的特点是哪些

答:一、人工管理阶段:特点
数据的管理者:人
数据面向的对象:某一应用程序
数据的共享程度:无共享,冗余度极大
数据的独立性:不独立,完全依赖于程序
数据的结构化:无结构
数据控制能力:应用程序自己控制
二、文件系统阶段:特点
数据的管理者:文件系统
数据面向的对象:某一应用程序
数据的共享程度:共享性差,冗余度大
数据的独立性:独立性差
数据的结构化:记录内有结构,整体无结构
数据控制能力:应用程序自己控制
三、数据库系统阶段:特点
数据的管理者:数据库管理系统
数据面向的对象:整个应用系统
数据的共享程度:共享性高,冗余度小
数据的独立性:具有高度的物理独立性和逻辑独立性
数据的结构化:整体结构化,用数据模型描述
数据控制能力:由数据库管理系统提供数据安全性、完整性、并发控制和恢复能力


问:数据库技术在数据库系统阶段的特点有哪些

答:答:从数据管理的角度看,数据库技术到目前共经历了人工管理阶段、文件系统阶段和数据库系统阶段。
人工管理阶段数据管理特点:数据不保存,没有对数据进行管理的软件系统,没有文件的概念,数据不具有独立性。
文件系统阶段数据管理特点:数据可以长期保存,由文件系统管理数据,文件的形式已经多样化,数据具有一定的独立性。
数据库系统阶段数据管理特点:采用复杂的结构化的数据模型,较高的数据独立性,最低的冗余度,数据控制功能


问:数据库技术有哪些特点为?

答:1,以数据为中心,通过组织数据形成综合性的数据库,为各应用共享
2,数据冗余少,易修改,易扩充。
3,采用一定的数据模型。
4,程序和数据有较高的独立性
5,具有良好的用户接口,用户可以方便的开发和使用数据库
6,对数据进行统一管理和控制,提供了数据的安全性,完整性


发表评论

发表评论:

PHONE