您现在的位置是:首页 >市场 > 2021-04-11 12:34:25 来源:
云重新定义数据库 机器学习运行它
在预测游戏中,是我们再次进行清理的时候了。关注Big on Data兄弟安德鲁·布鲁斯(Andrew Brust)从行业高管的跨部门对人工智能相关的预测进行综述,现在轮到我们了。我们将主要关注这对数据库意味着什么,这是一种在Y2K被认为进入完成状态之后的技术。
在2019年,我们认为AI和云是最伟大的颠覆者。
让我们先描绘一下大局。在Ovum,我们一直预测,到2019年,所有新的大数据工作负载中有一半将在云中运行。根据我们的最新数据,这种情况已经出现,我们的调查显示大约45%%的受访者表示在云中至少运行了一些大数据工作负载。
云对数据库的影响在于它正在重新定义如何设计和管理数据的基本架构假设。在本地,所有这些都是关于确定足够的容量来充分利用,但没有太多的能力来触发软件审计或导致过多的许可证费用。对于大数据而言,一切都是为了将计算带入数据,因为移动所有这些太字节的网络开销并不是特别合理。
进入云,商品基础设施,低价存储,更快的网络互连,最重要的是,几乎无限的规模,对于数据库供应商,它又回到了绘图板,例如将存储与计算分离。为火灾添加一些燃料:我们相信从云数据库部署中实现价值的最佳方式是通过托管数据库即服务(DBaaS)进行补丁,升级,备份,故障转移,以及由云提供商进行配置和处理而不是DBA。这为我们的第一次预测提供了依据,顺便提一下,这恰好符合流行语。
使用ML的自动驾驶数据库将激增
云数据库提供商将应用机器学习(ML)使其DBaaS产品自行运行。就在一年多以前,甲骨文开启了大门,首先是自治数据仓库18c,大约六个月后,随着自治交易数据库18c。不要在家里尝试这个,Oracle只在其公共云中提供自治数据库,而不是DBA控制环境。
由于几个原因,将ML应用于数据库操作是不费脑子的。首先,数据库操作生成大量的日志数据以提供模型。其次,数据库操作(特别是在托管云服务中)是一个有限的问题,可以抵抗漂移或范围蔓延。最后,ML自动化的工作,例如如何为不同的负载模式配置数据库,或者如何优化查询,对于DBA而言,它不会增加价值。
毫不奇怪,自治数据库的出现给DBA带来了关于其工作安全性的重大担忧。正如我们在Oracle OpenWorld postmortem中所提到的,我们看到的任何突破的最长行是DBA与自治数据库会话。正如我们在那篇文章中所指出的那样,除非他们的雇主是愚蠢的,否则他们仍然会有工作 - 你仍然需要DBA对数据库将涵盖的内容做出战略决策,设计架构,并设置(并负责)与运行相关的策略并保护数据库。
我们预计2019年将有更多云数据库提供商遵循Oracle的领先优势。使用ML运行数据库将成为任何DBaaS产品的标准复选框项目; 我们还希望一些数据库提供商能够与Oracle区分开来,并将其中一些概念应用于内部部署。
无服务器成为复选框选项
我们还期望通过无需使用自动扩展来配置服务器,最初与AWS Lambda一起引入的无服务器计算将简化应用程序开发,并将通过云DBaaS服务变得越来越普遍。在此方案中,DBA指定上限和下限阈值,然后指定数据库自动标量。示例包括Amazon DynamoDB,其中无服务器是设计的核心,以及Amazon Aurora,其中无服务器最近作为选项用于尖峰很少或难以预测的应用程序。Google Cloud Firestore也是无服务器的; 在过去的一年中,MongoDB为其Atlas推出了Stitch无服务器产品 云服务。
无服务器不适用于所有用例; 例如,如果您的负载是可预测的或稳定的,那么保留容量将更加经济。尽管如此,开发人员的需求将使2019年所有云运营数据库成为无服务器的选择。
分布式数据库:写得到尊重
云计算的另一项创新是分布式数据库。今年,我们将看到分布式数据库使写入一等公民与读取相提并论。
我们来解释一下。分布式数据库并不是从云开始的 - 早期的例子包括关系方面的Clustrix(最近被MariaDB收购),Aerospike和NuoDB,以及像MongoDB,Couchbase和Apache Cassandra这样的NoSQL 支持者。在这些玩家中,MongoDB一直是最大突破,主要是因为它的开发者友好性使其传播病毒,尽管Cassandra已经获得了一些像Netflix这样的大型互联网名称。
但是云为分布式数据库提供了一些不公平的优势。首先,它消除了IT组织建立自己的数据中心和广域骨干的需求。其次,大部分此类数据(如日志,产品目录,物联网数据等)已经存在于云中。最后,但并非最不重要的是,云增加了一些不公平的架构优势:云提供商可以在自动复制,智能存储和自动扩展到他们的平台的本地工程。
那么,这与写入和读取性能有什么关系呢?大多数分布式数据库都使用主/从体系结构进行操作,这些体系结构具有用于提交写入或更新的集中主节点,由可以在地理上分布的只读副本包围。这使得可以在任何本地副本上执行的读取比写入快得多。
我们已经看到了新方法,例如多主机,它允许本地节点被声明为特定事务的写主机,或者一致性算法,轮询节点以指定写主机,以克服全局分布式数据库上的写入瓶颈。Amazon Aurora和DynamoDB; Google Cloud Spanner ; Microsoft Azure Cosmos DB ; 和Cockroach DB已经支持这些功能(或者提供测试版),但除了Cloud Spanner和Cosmos DB之外,这些功能仅在区域内支持,而不是在区域内支持。在2019年,我们预计多区域支持将变得更加普遍。
由GDPR等数据隐私法规和许多国家强制要求数据保留在原产国内的地方法规所带来的相关开发将是将数据库分割为本地或区域主人的角色。这种做法将变得更加普遍。
乔治·阿纳迪奥蒂斯得到了证明:星星终于与图形数据库保持一致
好吧,你可能听过的不仅仅是我的Big on Data兄弟乔治·阿纳多蒂斯(George Anadiotis),他已经履行了自己的职责,在图形数据库上教育市场。他深入研究了知识图,向我们介绍了新的图形数据库播放器,启发了图形查询语言,并冒险了解图形可以将网络表示为数据库的疯狂概念。
正如Anadiotis 大约18个月前提出的那样,“Graph技术正在从边缘领域走向成为主流。” 好吧,早在2017年初,这种说法有点为时过早。
图数据库所解决的业务问题非常简单。解读影响社交网络的模式,使领先品牌能够识别和培养意见领袖; 绘制和优化供应链运作的复杂性; 或者了解网络威胁的传播,这些只是现实世界问题的几个例子,它们都有一个共同点:它们的特点是多对多关系,不易被关系数据库所代表。挑战在于,作为数据库,图形是不熟悉的。他们缺乏构建关系模式的数十年知识,键值结构的简单性或来自JavaScript社区的JSON文档的现有知识库的优势。直到最近,
在过去一年中发生的变化是越来越多地接受事实上的标准,例如Apache TinkerPop框架和相关的Gremlin查询语言,它为开发人员提供了一个共同的目标。我们看到来自Neo4J和TigerGraph的竞争 正在引入他们自己的更像SQL的变种。我们看到云巨头进入该领域,亚马逊推出海王星,而微软的Azure Cosmos DB包括其支持的数据模型系列之一。但由于必要性是发明之母,在2019年,我们预计客户360,物联网应用和网络安全将成为图形数据库需求的驱动力,现在这些数据库比以往更容易获取。