其实不论是Hadoop还是分布式数据库，技术体系上两者都已经向着计算存储层分离的方式演进。对于Hadoop来说这一趋势非常明显，HDFS存储与YARN调度计算的分离，使得计算与存储均可以按需横向扩展。而分布式数据库近年来也在遵循类似的趋势，很多数据库已经将底层存储与上层的SQL引擎进行剥离。传统的XML数据库、OO数据库、与pre-RDBMS正在消亡；新兴领域文档类数据库、图数据库、Table-Style数据库与Multi-Model数据库正在扩大自身影响；传统关系型数据库、列存储数据库、内存分析型数据库正在考虑转型。可以看到，从技术完整性与成熟度来看，Hadoop确实还处于相对早期的形态。直到今天，很多技术在很多企业应用中需要大量的手工调优才能够勉强运行。同时，Hadoop的主要应用场景一直以来面向批处理分析型业务，传统数据库在线联机处理部分不是其主要的发展方向。同时Hadoop技术由于开源生态体系过于庞大，同时参与改造的厂商太多，使得用户很难完全熟悉整个体系，这一方面大大增加了开发的复杂度，提升了用户使用的难度，另一方面则是各个厂商之间维护不同版本，使得产品的发展方向可能与开源版本差别逐渐加大。
而分布式数据库领域经历了几十年的磨练，传统RDBMS的MPP技术早已经炉火纯青，在分类众多的分布式数据库中，其主要发展方向基本可以分为“分布式联机数据库”与“分布式分析型数据库”两种。对比Hadoop与分布式数据库可以看出，Hadoop的产品发展方向定位，与分布式数据库中列存储数据库相当重叠而在高并发联机交易场景，在Hadoop中除了HBase能够勉强沾边以外，分布式数据库则占据绝对的优势。目前，从Hadoop行业的发展来看，很多厂商而是将其定位改变为数据科学与机器学习服务商。因此，从商业模式上看以Hadoop分销的商业模式基本已经宣告结束，用户已经体验到维护整个Hadoop平台的困难而不愿被强迫购买整个平台。大量用户更愿意把原来Hadoop的部件拆开灵活使用，为使用场景和结果买单，而非平台本身买单。另外一个细分市场——非结构化小文件存储，一直以来都是对象存储、块存储，与分布式文件系统的主战场。如今，一些新一代数据库也开始进入该领域，可以预见在未来的几年中，小型非结构化文件存储也可能成为具备多模数据处理能力的分布式数据库的战场之一。
我们在这篇文章中给大家介绍了很多有关大数据分布数据库的发展前景，通过这篇文章我们不难发现数据库的发展是一个极其重要的内容，只有搭建分布式数据库，大数据才能够更好地为我们服务。
作者 石默研
本文对新一代NewSQL分布式数据库发展策略中的普遍困扰进行讨论，包括云原生（Cloud Native）与本地部署(On Premise)、HTAP进展方向、分布式与单机需求等分布式数据库商业与技术发展中难以决策的问题。
1. 困扰
分布式NewSQL数据库近年来蓬勃兴起，其原因显而易见：切中了业务与数据量不断增长的用户对关系型数据库RDBMS需求，这在传统RDBMS到大数据的发展阶段中，有相当一段时间是空白。同时，随着互联网技术的不断发展与普及，用云计算模式满足IT需求似乎已经成为未来 社会 产业互联网发展的明确趋势，也就是说，有一种共识：不久的将来，绝大多数产业的IT服务是从公共的、行业的或者私有的、混合的云计算中心提供的。这一共识又带来了云原生（Cloud Native）概念与技术的兴起，而分布式NewSQL数据库自然也应该是云原生的，这决定了其相当多的产品设计决策应以符合这一趋势为原则。然而，在当今的现实中，满足业务与数据量不断增长的RDBMS需求的用户，与云原生的用户，除了互联网企业外，大多数情况下，并不重合，需要On-Premise部署的用户仍然占有很大比重，这就带来了第一个困扰：云原生（Cloud Native）与本地部署(On Premise)对产品发展要求的矛盾。
另一个困扰，是关于HTAP，即交易与分析混合负载。HTAP是当今非常火的一个概念与技术，在交易库上直接进行分析，而不再是将“数据从交易库搬下来，挪到另一个数据库中去”这样的繁琐过程。可以毫不夸张的说： 历史 上规模性企业IT复杂度的相当一部分，都来自于“搬数据”，这导致了数据采集、实时采集、全增量合并、数据传输、数据加载、数据建模、数据质量、数据标准、企业级元数据管理等繁杂多样的技术环节的产生，导致了企业数据分布、数据流向、数据模型、主数据、基础数据平台、ODS/数据仓库/数据集市、数据治理等复杂的数据架构设计优化领域，导致了由于多系统大规模数据搬迁而带来的如数据交换平台之类的复杂调度工程......。咋眼一看，感觉该企业的数据技术好厉害，相关各领域的技术产品好丰富，技术人员的相关技能也好受欢迎。但如果在交易库就能直接满足分析需求而不影响生产效能的话，这些复杂高级的技术环节不都成了“自己给自己造了一座山，还说自己爬的好辛苦”？然而，现实却是，问题并不这么简单，除了在交易库中进行分析会影响业务效能外，还有很多原因导致这一现象产生：交易库并不需要存储那么长的 历史 数据，而分析往往是需要建立在大量 历史 数据之上的；交易库的模型往往并不适合分析需求，多数情况下需要重要建模，如非常流行且价值不菲的各行业数仓主题模型；用于交易的OLTP数据库与用于分析的OLAP数据库，其技术体系完全不同；以及大型企业已固化的内部业务结构并没有留给交易/分析整合可实施的可行空间......等等。由于， 历史 积累的企业级数据体系相当复杂，HTAP的发明者迄今为止都没有系统表达完全替代数据分析需求、自顶而下重构企业数据体系的架构级策略，而是将产品重点定位在技术优化层面：在交易库上直接完成实时统计分析，满足高并发需求且不影响业务效能；或者是为实时分析统计/查询而建设的数据服务中间平台。然而，即使是暂时没有这种策略性的意向，在面向AP的产品具体研发中，又会发现明确的界限确实不好把握，随着一个个具体功能的不断完善，似乎假以时日，技术上也不是没有完全替代纯OLAP平台的可能性。那么，HTAP究竟如何定位呢？
再者就是规模化的分布式需求，与小规模的单机数据库需求（这里指逻辑上的单机）之间的矛盾：分布式数据库，自然而然是要应对规模化的数据管理需求的，长尾的小规模需求当然不应在产品设计考虑之列，同时，大炮轰苍蝇经常还打不好；然而，分布式NewSQL数据库又应该是云原生的，如果把云原生的业务含义理解为“全自助”，它应该以支持什么样的需求为主呢？现实看来，小规模长尾业务对云原生数据库的需求最起码应该是占据相当大的比重的。显而易见，如果是大规模的数据管理需求，即使是部署在云上，DBPaaS的“全自助”是其核心需求吗？这种规模化的业务，如果是云上的On-Premise又需要做出哪些方面的改变？从互联网与云计算发展的 历史 来看，“云自助”，其最核心的商业动机当然包括给用户侧的运维带来了方便，但更重要的可能是给云服务运营商应对海量长尾客户的安装与运维带来了极大的成本优势。这正如银行的小微及个人消费贷款都要走互联网线上模式，而重客、大客甚至中小企业信贷仍然是以线下为主的策略一样，本质是成本问题，而不是客户方便性问题。于是，矛盾显而易见：分布式是面向规模客户的，起码是中、大型客户，而云原生却有可能、最起码相当一段时间内是要以长尾客户为主要服务对象的。
以上困扰实质上，都涉及到了NewSQL分布式数据库的产品发展策略问题。
2. 讨论
问题是客观而又普遍的，但分析与应对策略往往包含主观因素：人们的一个决定与决策，很多情况下并不由严格推理而来，而是心中已经有一个答案，再来找理由支持它。这里的讨论或许也并不能例外。
首先，来看看Cloud Native与On Premise。云原生本应是数据库即服务，然而目前真正有规模化数据增长需求的NewSQL应用相当多的情况下却是付费On Premise与免费On Premise区别，很多互联网企业的应用也可能只是部署在云基础设施上而已，真正的云原生更多是一些实验性、尝试性的需求。但云原生数据库在公有云、行业云以及大型私有云上已经逐渐在形成一种意识上的共识，其商业前景不可限量。也就是说，未来的数字化转型进程中，产业互联网的数据库部署，会逐渐向云基础设施迁移，长在云上。它可能是公有云，也可能是行业云，也可能是私有云，它们都是被定义为云原生NewSQL数据库的市场范围。当然，肯定还会有相当一部分数据库长在云下，这也不用纠结，将其排除在云原生市场战略目标之外即可，就是说，不需要考虑这部分客户需求对产品规划的影响，因为前一部分的份额已经足够大了。这样看来，以云原生为目标进行产品规划的逻辑没有问题，不过，还是要明确一点：长在云上的数据库是不是一定符合我们对“云原生”的既有理解？这里认为，即使未来，在云上形成了产业互联网数据库市场的主体，需要“全自助”的数据库即服务可能也是以面向长尾客户最为迫切、必不可少并且是核心本质，而对中大型以上的需求，“全自助”的意义相对有限，同时比较而言商业模式的转变或者更关键些。那么，如果是以“长在云上”为市场目标，似乎可以将其定义为“广义的云原生”，同时，只要是“长在云上”，那么“云原生”概念中高d性、高可用、低成本、快速迭代、存算分离等技术优势也都能方便获得。而对“云原生”策略中“云原生”一词的理解不同，对产品规划决策的影响也应该有所不同：一是目前被认为是On Premise的客户需求，或许也就是未来“云原生”主体市场的需求；二是NewSQL数据库关于云原生服务的产品策划，对用户侧“自助”水平的决策或许可以更灵活实用。高水平自助确实可以减轻客户对IT的依赖程度，但这里认为，云原生与用户自行在云上购买资源进行On-Premise部署相比，最关键的价值在于商业模式的改变，能自助多少，不一定是最重要的，因为成为云服务商后，运营运维的工作只会更多，责任可能会更大，甚至有时连IaaS的运维也需要PaaS服务商兜底。但从一个个客户的本地服务，变成集中化云服务，就已经是本质性的模式转变了。总之，需要就事论事，回到原点，仔细分析后决策，而不是用概念教条的判断，因为概念本身的定义并不见得准确对应实际的业务需求。
再来看看HTAP，对这个问题，正如在其它文章中表达过的一样，本文的观点较为明确。一是随着计算能力与架构的升级，从技术上讲，AP与TP的界限会越来越模糊；另外特别是在云原生的新世界里，数据库的这一特性又犹为重要，因为云原生的重要作用之一就是要让客户尽量摆脱对IT运维的依赖，将越来越多的精力集中到自己的业务发展上来；同时端到端的能力提升对云原生商业模式的贯彻也至关重要（需要仔细分析下目前DBPaaS的技术要求是否完全符合这一原点的、本质性的动力），过去与纯OLAP数据库的优势比较纠结在这里也可以得到正面支持；再者，既然架构上已经走向了AP，就很难做到在产品规划上时刻厘清纯AP与混合负载的需求后，再将前者排除在外。于是，以“混合负载满足部分AP需求”应该是由于投入与阶段性市场策略导致的阶段性产品规划，而长远来讲，以一套技术架构满足大多数需求，应该是云原生NewSQL数据库的追求。
接下来，就是关于规模化分布式与小规模单机需求的矛盾了。现在看来，经过上面的讨论，这一点已经不是什么问题了：因为“长在云上”、从分散服务向集中服务的商业模式转变就是指广义的云原生，而不一定要以小微的、迫切需要全自助的长尾为主流，那么，云原生NewSQL数据库仍然应以规模化分布式为其主体的需求方向，而小规模单机则暂时可以不做为重点来考虑。
最后指出一点，希望也能引发进一步的思考：我们所批判的主机，也声称自己是分布式架构，暂且不论其是否客观，但在现实中主机需要被替代的核心问题并不是有没有分布式，而是：一、扩展不灵活带来成本问题：“我只需要扩展一个节点，你却让我再买一台主机”；二、不自主可控；三、往往是软硬件结合的设计策略，包括内存、网络、存储与IO上的软硬融合设计，而这一点，是否需要云原生数据库从广义的定义出发进行学习参考，也是需要进一步讨论的。
下一代数据库技术的发展主流
针对关系数据库技术现有的局限性，理论界如今主要有三种观点 :
面向对象的数据库技术将成为下一代数据库技术发展的主流 部分学者认为现有的关系型数据库无法描述现实世界的实体，而面向对象的数据模型由于吸收了已经成熟的面向对象程序设计方法学的核心概念和基本思想，使得它符合人类认识世界的一般方法，更适合描述现实世界。甚至有人预言，数据库的未来将是面向对象的时代。
面向对象的关系数据库技术 关系数据库几乎是当前数据库系统的标准，关系语言与常规语言一起几乎可完成任意的数据库 *** 作，但其简洁的建模能力、有限的数据类型、程序设计中数据结构的制约等却成为关系型数据库发挥作用的瓶颈。面向对象方法起源于程序设计语言，它本身就是以现实世界的实体对象为基本元素来描述复杂的客观世界，但功能不如数据库灵活。因此部分学者认为将面向对象的建模能力和关系数据库的功能进行有机结合而进行研究是数据库技术的一个发展方向。
面向对象数据库技术 面向对象数据库的优点是能够表示复杂的数据模型，但由于没有统一的数据模式和形式化理论，因此缺少严格的数据逻辑基础。而演绎数据库虽有坚强的数学逻辑基础，但只能处理平面数据类型。因此，部分学者将两者结合，提出了一种新的数据库技术——演绎面向对象数据库，并指出这一技术有可能成为下一代数据库技术发展的主流。
数据库技术发展的新方向
非结构化数据库是部分研究者针对关系数据库模型过于简单，不便表达复杂的嵌套需要以及支持数据类型有限等局限，从数据模型入手而提出的全面基于因特网应用的新型数据库理论。支持重复字段、子字段以及变长字段并实现了对变长数据和重复字段进行处理和数据项的变长存储管理，在处理连续信息（包括全文信息）和非结构信息 （重复数据和变长数据）中有着传统关系型数据库所无法比拟的优势。但研究者认为此种数据库技术并不会完全取代如今流行的关系数据库，而是它们的有益的补充。
数据库技术发展的又一趋势
有学者指出 ：数据库与学科技术的结合将会建立一系列新数据库，如分布式数据库、并行数据库、知识库、多媒体数据库等，这将是数据库技术重要的发展方向。其中，许多研究者都对多媒体数据库作为研究的重点，并认为多媒体技术和可视化技术引入多媒体数据库将是未来数据库技术发展的热点和难点。
未来数据库技术及市场发展的两大方向数据仓库电子商务 部分学者在对各个数据库厂商的发展方向和应用需求的不断扩展的现状进行分析的基础上，提出数据库技术及市场在向数据仓库和电子商务两个方向不断发展的观点。他们指出 ：从上一年开始，许多行业如电信、金融、税务等逐步认识到数据仓库技术对于企业宏观发展所带来的巨大经济效益，纷纷建立起数据仓库系统。在中国提供大型数据仓库解决方案的厂商主要有Oracle、IBM、Sybase、CA及Informix等厂商，已经建设成功并已收回投资的项目主要有招商银行系统和国信证券系统等。当前，国内外学者对数据仓库的研究正在继续深入。与此同时，一些学者将数据库技术及市场发展的视角瞄准电子商务领域，他们认为 ：如今的信息系统逐渐要求按照以客户为中心的方式建立应用框架,因此势必要求数据库应用更加广泛地接触客户，而Internet给了我们一个非常便捷的连接途径，通过Internet我们可以实现所谓的One One Marketing和One One business，进而实现E business。因此，电子商务将成为未来数据库技术发展的另一方向。
面向专门应用领域的数据库技术 许多研究者从实践的角度对数据库技术进行研究，提出了适合应用领域的数据库技术如工程数据库、统计数据库、科学数据库、空间数据库、地理数据库等。这类数据库在原理上也没有多大的变化，但是它们却与一定的应用相结合，从而加强了系统对有关应用的支撑能力，尤其表如今数据模型、语言、查询方面。部分研究者认为，随着研究工作的继续深和数据库技术在实践工作中的应用，数据库技术将会更多朝着专门应用领域发展。 数据和数据处理
数据（Data）是用于描述现实世界中各种具体事物或抽象概念的，可存储并具有明确意义的符号，包括数字，文字，图形和声音等.数据处理是指对各种形式的数据进行收集，存储，加工和传播的一系列活动的总和.其目的之一是从大量的，原始的数据中抽取，推导出对人们有价值的信息以作为行动和决策的依据；目的之二是为了借助计算机技术科学地保存和管理复杂的，大量的数据，以便人们能够方便而充分地利用这些宝贵的信息资源.
数据库
数据库（DataBase,DB）是存储在计算机辅助存储器中的，有组织的，可共享的相关数据集合.数据库具有如下特性.
⑴数据库是具有逻辑关系和确定意义的数据集合.
⑵数据库是针对明确的应用目标而设计，建立和加载的.每个数据库都具有一组用户，并为这些用户的应用需求服务.
⑶一个数据库反映了客观事物的某些方面，而且需要与客观事物的状态始终保持一致.
数据库管理系统及其基本功能
数据库管理系统（DataBase Management System,DBMS）是对数据库进行管理的系统软件，它的职能是有效地组织和存储数据，获取和管理数据，接受和完成用户提出的各种数据访问请求.能够支持关系型数据模型的数据库管理系统，称为关系型数据库管理系统（Relational DataBase Management System,RDBMS).
RDBMS的基本功能包括以下4个方面：
⑴数据定义功能：RDBMS提供了数据定义语言(Data Definition Language,DDL），利用DDL可以方便地对数据库中的相关内容进行定义.例如，对数据库，表，字段和索引进行定义，创建和修改.
⑵数据 *** 纵功能：RDBMS提供了数据 *** 纵语言(Data Manipulation Language,DML），利用DML可以实如今数据库中插入，修改和删除数据等基本 *** 作.
⑶数据查询功能：RDBMS提供了数据查询语言（Data Query Language,DQL），利用DQL可以实现对数据库的数据查询 *** 作.
⑷数据控制功能：RDBMS提供了数据控制语言(Data Control Language,DCL），利用DCL可以完成数据库运行控制功能，包括并发控制（即处理多个用户同时使用某些数据时可能产生的问题），安全性检查，完整性约束条件的检查和执行，数据库的内部维护（例如索引的自动维护）等.RDBMS的上述许多功能都可以通过结构化查询语言(Structured Query Language,SQL）来实现的，SQL是关系数据库中的一种标准语言，在不同的RDBMS产品中，SQL中的基本语法是相同的.此外，DDL,DML,DQL和DCL也都属于SQL.
⒈3.4数据库应用系统及其组成
数据库应用系统又简称为数据库系统，是指拥有数据库技术支持的计算机系统，它可以实现有组织地，动态地存储大量相关数据，提供数据处理和信息资源共享服务的功能.
各类人员主要参与数据库应用系统的需求分析，设计，开发，使用，管理和维护，他们在数据库应用系统的开发，运行及维护等阶段扮演着不同的角色，并起着不同的作用.各类人员主要包括以下几种.
⑴最终用户.
⑵系统分析员.
⑶应用程序员.
⑷数据库管理员(DataBase Administrator,DBA). 从其应用方式来看，数据库技术主要起着两方面的作用.
⑴信息系统开发作用.利用数据库技术以及互联网技术，并结合具体的编程语言，可以开发一个信息系统，从而解决业务数据的输入和管理问题.在信息系统开发中，主要利用的是RDBMS的基本功能，即数据定义功能，数据 *** 纵功能，数据查询功能以及数据控制功能.
⑵数据分析与展示作用.利用RDBMS的数据查询功能对数据库中的数据进行关联组合或逐级汇总分析，并以表格，图形或报表形式将分析结果进行展示，从而解决业务数据的综合利用问题.
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）