VoltDB

VoltDB 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织 www.slidestalk.com/VoltDB 编辑
编辑

VOLTDB诞生作为支持云端部署的内存数据库,并在持续增强流计算能力,原生分布式架构提供了可伸缩性,同时完全满足ACID要求,数据安全可靠。
VOLTDB采用关系型数据存储,支持严格的事务模型和标准SQL,由2014图灵奖得主Mike Stonebraker博士领导全新设计的架构。

个人动态

VoltDB 发布了文章 · 4月8日

为什么主动跨数据复制在5G时代非常重要?

01 概述

5G和IoT等新技术的融合给电信行业带来了快速而巨大的变革。这些新技术正在推动数据量、速度和多样性的空前增长。数据的增长导致传统系统发生故障,所以电信公司不得不面临一个艰难的选择:继续尝试“传统系统与现有系统一起使用”,抑或寻找新的事物,并且越快越好,因为世界上没有哪家电信公司的数据会变得越来越慢,与此同时,黑客数量变得越来越多且更具侵略性。

为了更及时地提供最新数据,跨数据中心复制(XDCR)应运而生。这种技术已经存在了数十年,但使用传统技术来运作变得昂贵,且使用5G技术来运作也很困难,无法正确执行。传统RDBMS上的主动XDCR变得很复杂且容易出错。企业也很快意识到,他们要么完全替换其数据库,要么将冒着在永久性技术和经济上处于不利地位的风险。

在本文中,我们将讨论XDCR是什么,以及为什么需要XDCR;什么是主动-主动XDCR,为什么这么多公司面临这种挑战?最后,VoltDB如何以一种主动-主动XDCR的方式避免冲突,还可以对复杂的流数据进行全面的容错,并进行10毫秒以下的智能决策,而同时不会损害数据准确性。

首先,让我们定义我们的术语。

02 什么是XDCR?

在最基本的级别上,XDCR仅意味着更改会朝多个方向进行,即,一次在多个地理位置上拥有多个实时数据库集群,以便在更新本地数据库时,更改会自动传播到所有其他副本。
您要这样做的主要原因有两个:

1.业务连续性:中断是不可避免的,但不应决定您的命运

不同位置具有多个数据库实时副本的最初动机是,如果地震、火灾或其他事件导致原始副本无法运行,企业可以继续运行。

早期的实现具有数据库的一个主副本和一个或多个远程只读副本,这些副本可能已经完全更新,也可能尚未完全更新。将此副本设为“实时”是一个手动过程,很容易需要30分钟。从业务角度来看,这带来了明显的问题。首先,数据丢失的数量可能很大。其次,主管人员对于任何需要复杂的,经过精心排序的手动事件链才能工作的系统,可能会感到不安。当切换只会在最大混乱的时刻发生时,他们会特别紧张。

最终,XDCR涉及到两个相互连接的可互换数据库,从而避免了整个切换过程。这就是所谓的“主动-主动”架构(更多内容请参见下文)。但是提供数据库行业所谓的“主动-主动解决方案”要比看起来困难得多。

在实践中,使用传统技术进行跨数据中心复制已经有十多年的历史了,但是它很容易将项目成本增加了十倍,同时又带来了足够的运营挑战和“陷阱”,从而使净可靠性成为现实。没有比单个系统更好的了。

2. 5G和延迟:您的数据需要在您的客户所在的地方

如果您是对延迟要求极其严苛的应用程序的企业,则数据中心与终端用户之间的距离将会变得很重要。

数据以约124英里/毫秒的速度通过光缆进行传输。因此,如果您的数据中心位于纽约,而您的客户位于2,900英里之外的旧金山,则任何消息往返至少须花费23毫秒至46毫秒。
如果您决定是否必须在20毫秒内接通电话,而决策过程本身又需要10毫秒,那么数据中心的距离不能超过5毫秒(约600英里)。

这意味着您将需要备份多个实时的运营数据副本,以便在不同的地理位置运营您的业务。实际上,您可能需要两个以上。

03 什么是主动-主动XDCR?

关于什么是XDCR以及“主动-主动”的含义是什么有很多困惑。如今,许多数据库架构师和管理员可能会交换使用这些术语。这是不太确切的——主动—主动和XDCR并不相同,因为“主动-主动”是一种进行XDCR的方式。但是,它的确指出了主动-主动架构的普遍性和亟需性。

因此,首先,我们将定义“主动-主动”,并将其与“主动-被动”区分开。
主动-被动意味着有多个数据库副本,但是只有一个是可更改的(即,主动的),而其他副本则被告知更改。这看起来很简单,但是将备份数据库设置为“主动”(因原始的“主动”数据库已失败,通常需要人工干预),它却无法分辨出将“主动”数据库刻录到地面的数据中心与拔下网络电缆的人的区别。而我们的目标是降低系统范围的延迟,这对我们的目标毫无帮助。

图片

Active-active意味着您有两个数据库,这两个数据库都可以实时更新,并且两个数据库都可以相互沟通同步更新。这避免了上面我们讨论过的“何时成为主动”的问题决策,并且现在我们可以解决冲突(更多内容请参见下文)。

主动-主动-主动,这意味着将另一个集群添加到您的部署中。而这种配置比您想象的更常见。如果客户对地理冗余有严格的要求(跨越多个地理位置的数据中心的物理隔离)并且还必须进行主体OS /硬件升级,那么最简单的方法通常是使用新的设备——在弃用较旧的群集之一之前,可以对其进行测试的配置。这样做的成果是,我们的大多数“主动-主动-主动”集群将在某个时候变成“主动-主动-主动-主动”。

04 为什么主动-主动XDCR如此困难?

借助足够的“血液和财富”(即以开发人员时间的形式和附加的第三方软件),我们几乎可以创建任何数据库来支持某种形式的主动-主动XDCR。这就是为什么如此众多的供应商声称他们可以这样做。因此,问题不是“‘某产品’是否符合支持主动-主动的法律要求?”而是“我能否负担得起以主动-主动模式部署X产品相关的人力、技术和财务成本?”。

许多企业在未首先了解如何在不增加运营成本的情况下实现主动-主动XDCR,或试图主动-主动XDCR,最终要么放弃,要么为妥协的解决方案而苦恼。

主动-主动XDCR的核心问题是冲突的处理。

为了说明冲突可能造成的麻烦,我们假设我们正在谈论预付费移动电话信用,并且在三个位置(位置A,位置B和位置C)中复制了相同的数据库,每个位置相距数百英里。我们假设系统跟踪大约5000万终端用户,每个终端用户拥有50-100条各种记录。

在这种情况下,避免冲突几乎是不可能的。最明显的冲突类型是,用户在位置A上连接到数据库并花费其最后的信用额度,然后以某种方式连接到位置B并再次花费相同的额度,然后此活动的消息到达位置A。

这听起来似乎不太可能,但是在多个用户共享预付费呼叫方案时常常会发生。如果用户位于流量在位置A和位置B之间不断切换的边界时,也会发生这种情况。
但是,更大的问题不是您有一个单一的冲突,您可以花点时间修复所有问题,然后停止所有冲突。您可能拥有的不止一个冲突,而当您发现这一点时,错误决策的二阶和三阶后果已经在您的整个企业中蔓延开来。

_为什么我们不能在两站点之间仅使用“两阶段提交”?
“两阶段提交”是一种过去常用于协调多个站点之间的更改的技术。对于每笔交易,其形式为站点之间的漫长对话,并最终双方认可数据项已更改。虽然它可以完成其核心任务,但由于以下原因,对于主动-主动XDCR来说并不实用:
它无法缩放。我们需要每秒能够完成数千笔交易,而两阶段提交根本无法扩展到该级别。
它假设所有事情一直在起作用。在两阶段提交体系里,我们假设所有站点始终处于打开状态并且彼此可见。这意味着在站点中断或网络问题的情况下,整个系统都将停止。_

05 如何使主动-主动XDCR更加轻松

处理冲突的难易程度取决于您使用的数据库,但是企业可以做很多事情来避免冲突。
鉴于我们无法“设计出”冲突,因此我们需要考虑减少冲突发生的频率,并在发生冲突时有效地进行处理。

您可以按照以下方法进行操作:

1.使用快速传播

您在站点之间传播与更新的速度有多快,与您将遇到多少冲突之间,存在反比关系。如果花费5秒钟而不是500毫秒,那么发生冲突的窗口将增加10倍,并且您的冲突计数也会相应增加。

XDCR的传统实现通常建立在最初设计用于填充数据仓库的更改数据捕获 (CDC) 应用程序之上。因此,它们可能是基于批处理的,但是速度会很慢。它们在设计时还考虑了单向复制,这在尝试双向或多方向时会导致问题。

2.最小化配置和自动化

传统数据中心复制产品的其他负面后果通常是数据库与 CDC 产品的差强结合。其一是基础配置的复杂性:数据库对象及其复制方式在 DDL 级别完全脱钩,这具有显著的复杂性。

且在出现问题时,也普遍缺乏自动恢复功能。即使在理想条件下,无论使用什么技术,XDCR都对人们的操作构成挑战。客户在XDCR上的操作经验向我们表明,即使自动化程度高且配置简单,最可能造成停机的原因还是人为错误。

3.程序冲突地址

鉴于冲突是不可避免的,我们需要解决它们在现实系统中造成的后果。这必须以自动化的方式完成,因为尽管每小时平均冲突数量很少,但网络中断可能导致大量冲突,从而压倒人类决策者。

这意味着对冲突消息采用标准格式,适用于自动分析和处理。这只是第一步,因为冲突将在部署中的每个站点的不同时间发生。我们还需要一种存储冲突的机制。

4.迅速解决冲突,避免造成负面影响

尽管大多数产品使用“最后写赢”的某种形式来决定数据的最终外观,但我们仍然必须处理冲突发生后但在意识到之前做出的决策的下游后果。实际上,这意味着如果没有解决冲突的程序机制,在终端用户注意到这些不可避免的问题之前,您将无法解决不可避免的问题。如果你迅速解决冲突,你将能够尽量减少不准确决策的二阶和三阶效应,否则会导致混乱。

图片

5.严苛适应

一旦我们承认冲突是不可避免的,我们需要自动解决冲突,另一个要求突然变得显而易见:我们观察和试图解决的任何冲突都必须是完整和彻底的。找出大约一半的冲突是没有用的,因为我们将无法解决冲突造成的任何潜在的业务问题。
因此,我们需要一个符合严苛要求的机制来报告冲突,您可以可靠地假设,一旦您被告知冲突,您就知道这一切,而不仅仅是其中的一部分 。

6.支持自动恢复

任何花时间处理分布在局域网或地理上的数据库的人都会告诉您,当您正在说话的节点消亡时切换到可行的替换节点可能会有问题,但真正的挑战是让节点重新加入群集或在组件负载不足时向集群添加新的节点,而不会导致"失效"或完全中断。

对于许多较老的产品,重新加入过程的外观、感觉和行为都像事后诸葛亮。但是,如果节点在无计划停机和随之而来的剧情下无法重新加入,那么您将发现自己身处一个仅需保持系统正常运行就会耗费数十甚至数百小时的世界。

06 VOLTDB如何进行主动-主动XDCR

除了针对大量事务性工作负载进行了优化之外,鉴于多种原因,VoltDB还是应用主动-主动XDCR的理想平台。

尽管VoltDB已经启用了被动数据库复制功能,用以在主群集和副本群集之间提供并行二进制复制,但是VoltDB的Version 6发行版引入了XDCR和主动-主动数据库复制,也可以称为主动-主动复制。XDCR支持跨两个数据库集群的双向主动复制。借助此功能,VoltDB提供了在两个不同位置维护独立且已同步的可写数据库的功能。

图片

VoltDB将传入的请求路由到确定性队列中,这些确定性队列统称为“命令日志”,每个队列都由称为分区的单线程处理引擎使用。在每个服务器上,分区和CPU内核之间通常存在1:1的关系,因此每个内核都忙于快速处理一次事务。

在处理交易时,它们对数据库所做的二进制更改将写到所谓的“ Binlog”中。Binlog与传统RDBMS中的“重做日志”不同,后者仅限于描述对行的更改。相反,它包含在冲突发生时我们需要解决的元数据:

Binlog的一个关键方面是它具有ACID严苛语义:如果我更新两行,则Binlog要么包含两个更改,要么不包含任何更改。正如我们稍后将讨论的那样,我们认为这是任何XDCR系统的关键要求。

编写Binlog时,它会流式传输到所需的目标位置。每个分区使用一个流,这意味着我们可以扩展。如果站点之间的链接断开,更改将被缓冲直到返回。
图片

到达目的地后,它将处理多个Binlog流,并将它们所包含的更改应用于本地表(前提是它们不会引起冲突)。我们可以检测到冲突,因为在XDCR模式下,我们为每一行存储了最后修改的时间戳,因此可以查看是否存在。

VoltDB在发生冲突时会做两件事:

  • 它会使用更改的时间戳并通过比较所涉及群集的数字ID(如果时间戳相同)来自动解析它们。
  • 它向事件流报告它们的存在,该事件流通常与Kafka连接。这意味着您可以编写代码来解决冲突事件,并弄清楚如何在发生冲突的几秒钟内减轻后果。

以上两者都需要提供可信且可管理的主动-主动 XDCR 解决方案。VoltDB 不仅满足主动-主动XDCR 的必要要求,而且我们通过提供所有使主动-主动XDCR 运转良好的上述所有内容,使其既可靠又具有成本效益,包括:

1.最小配置的自动化

与其他数据库技术产品和服务不同,VoltDB的“杠杆”最少。主动-主动XDCR是VoltDB的集成功能。一旦我们的主动-主动XDCR启动并运行,它通常会保持这种状态。

2.始终如一的高性能

一般来说,更改在大约 400 毫秒内传播,外加网络时间。这 400 毫秒大致平分在确保更改记录在源环境中的本地磁盘上、拆开目的地的流以及将更改应用于目标环境之间。

3.自动恢复

如果单个 VoltDB群集中的节点出现故障,则重新加入时会自动重新同步。或者,可以手动添加新的替换节点。VoltDB 将继续为客户请求提供服务,而这种情况正在进行中。重新同步节点将从幸存的节点获取所需的数据,并将重新加入,而不会对延迟产生重大影响使用主动-主动XDCR时,恢复连接后,群集会自动重新同步。

4.支持程序解决冲突

如上所述,VoltDB在处理来自其他站点的更改流时会自动识别相互冲突的事务。冲突将被JSON化,并出现在每个站点的导出流中,使其适合快速自动化处理。

5.严苛合规

主动-主动XDCR系统ACID严苛合规性的关键功能。如果开发人员不知道他们看到的是完全冲突的交易还是部分冲突的交易,则解决程序化冲突几乎变得不可能。

07 实施主动-主动XDCR的真实应用案例

1.XDCR用于电信计费

电信服务提供商利用XDCR可近乎实时地管理帐户余额。例如,欧洲的移动运营商运行一个应用程序,该应用程序每次用户拨打电话时都会检查用户的帐户余额。根据用户所在的位置,请求将被路由到最近的数据中心,在该中心执行余额检查并迅速返回响应。XDCR负责将更改复制到远程数据库以进行异步备份。帐户余额检查必须在200毫秒内完成,因此实施所需的等待时间极短。这些均可通过依靠VoltDB得以实现。

2.XDCR用于金融服务组织

金融服务公司也转向XDCR,以确保事务一致性和低延迟。例如,银行可以在东海岸和西海岸数据中心之间实施XDCR,以支持信用卡交易。如果加利福尼亚的用户需要获得信用卡交易的批准,并且那一刻到洛杉矶数据中心的流量很高,那么银行可以通过自动将交易重新路由到其纽约数据中心来避免延迟或不必要的交易下降。同样,交易中心可以实施XDCR以确保在数据中心流量过大时在正确的时间输入订单。

VoltDB是唯一为大规模主动-主动XDCR构建,而不会增加成本或损害数据准确性的数据平台。
您看好VoltDB吗? 马上行动吧!
欢迎私信,与更多小伙伴一起探讨。

关于VoltDB
VoltDB支持强ACID和实时智能决策的应用程序,以实现互联世界。没有其它数据库产品可以像VoltDB这样,可以同时需要低延时、大规模、高并发数和准确性相结合的应用程序加油。
VoltDB由2014年图灵奖获得者Mike Stonebraker博士创建,他对关系数据库进行了重新设计,以应对当今不断增长的实时操作和机器学习挑战。Stonebraker博士对数据库技术研究已有40多年,在快速数据,流数据和内存数据库方面带来了众多创新理念。
在VoltDB的研发过程中,他意识到了利用内存事务数据库技术挖掘流数据的全部潜力,不但可以满足处理数据的延迟和并发需求,还能提供实时分析和决策。VoltDB是业界可信赖的名称,在诺基亚、金融时报、三菱电机、HPE、巴克莱、华为等领先组织合作有实际场景落地案例。

查看原文

赞 0 收藏 0 评论 0

VoltDB 发布了文章 · 4月2日

为什么拥有云原生数据平台对电信公司很重要?

VoltDB最近被添加到Linux基金会子公司——云原生计算基金会Cloud Native Computing Foundation(CNCF)中,该基金会致力于构建可持续的云生态系统。作为云原生技术的忠实拥趸,我们对这个消息感到非常兴奋。

CNCF 维护了交互式景观地图,详细介绍了构成云原生生态系统的所有技术提供商。现在,您可以在 CNCF 图表上的数据库部分找到 VoltDB -和 PostgreSQL、Couchbase和Cassandra等平台一起使用。

原生云是技术行业中最热门的流行语之一,所有垂直行业的开发人员越来越多地使用该方法构建其应用程序。为了佐证这一点, Forrester最近的一份报告发现,到2021年底,将有60%的公司使用公共云平台上的容器,而25%的开发人员将使用无服务器架构。

电信行业是云原生利用率显著上升的一个行业。考虑到这一点,我们将仔细探究为什么云原生基础架构现在已成为电信行业的重要组成部分,以及所有有竞争力的电信公司都应该掌握的东西。

云原生技术:简要入门

原生云是一种计算方法,它使用将代码和各种依赖项捆绑在一起的容器,并在云中开发软件,以便应用程序可以在任何环境中运行。

云原生应用程序被部署为微服务,并通过使用持续集成/持续开发(CI / CD)管道的DevOps工作流进行管理。它们与传统的单片应用程序(或部署在本地的单层,自包含模型)背道而驰。

简而言之,原生云改变了应用程序开发的游戏规则。而且在许多方面,电信公司都不再选择使用那些旧的规则。为了在电信领域中生存,现在需要云原生。

电信公司为何需要云原生开发

向原生云迁移是电信业的一大步,电信业长期以来一直使用旧版网络、服务器、操作系统和数据库来构建应用程序。

如今,推动更大技术生态系统的创新亟需电信行业的革新。在新兴的5G时代,越来越多的电信公司正在改变其发展方式,以更快地发展并有效竞争,在5G时代,速度和敏捷性对于成功至关重要。越来越多的应用优先考虑云本地应用,这一趋势在 2021 年正在迅速加快。

以下这些是电信公司应考虑采用云原生的一些主要原因。

1.安全性

容器具有固有的安全优势,其中包括:

  • a.模块化:不同的容器具有不同的安全级别,因此您可以选择在网络上处理关键信息的方式和位置。
  • b.一致性:无论应用程序使用的是哪个OS,亦或是应用程序正在生产还是测试中,容器都可以提供一致的应用程序环境。由于环境变量不变,因此应用程序在整个生产过程中都保持安全。
  • c.较小的攻击面:在虚拟服务器上托管应用程序需要保护裸机主机服务器,虚拟服务器和应用程序本身。但是,使用容器,您只需要保护主机,Docker守护进程(比虚拟操作系统小得多)和运行在容器内的应用程序,就可以使其受攻击的表面较小。
  • d.更易更新。通过容器,可以快速而又轻松地更新应用程序,而对最终用户的干扰最小,这对于任何想要有效解决安全漏洞的企业来说都是一项至关重要的功能。
  • e.连续性:如果容器化的应用程序失败,它不会清除其他部分,并且可以固定错误并重新部署错误,而不必停止其他所有操作。

2.5G速度下的创新

为了抵消传统收入模式的下降,电信公司正在寻找使利润最大化和释放新收入来源的方法。5G正在以更快的速度和更大的容量带来数据。

容器的使用使企业可以创建和部署新的应用程序,而不必重新部署整个系统(即,快速响应市场)。由于它们比传统的单片软件更快、更高效,因此云原生应用程序使电信公司能够实时预测,检测和响应不断变化的市场状况,并利用新兴机会。

3.面向未来的基础架构
过往传统的电信行业发展缓慢且资源密集,诸如敏捷性和创新之类的词不一定是流行语。但是,该领域的发展根基正在迅速转移,无法迅速转移并迅速部署新服务的电信运营商有可能被竞争对手和行业颠覆者所取代。

通过采用云原生方法进行开发,电信公司可以确保面向未来的基础架构,并为快速、经济高效地大规模推广应用奠定基础。

同时,对于大多数开发人员而言,云原生是一个巨大挑战,因为它代表了创新和设计的优势。因此,如果电信公司想要吸引顶级开发人员,那么他们需要懂得云原生技术。否则,最好的开发人员将最终进入有竞争力的公司。

4.在任何地方都可以部署应用程序
为了实现5G速度的往返数据传输,电信公司需要最大限度地减少长途传输。因此,他们不能继续依赖集中式数据中心。相反,他们需要在网络边缘部署应用程序以更接近最终用户的战略市场中。

例如,洛杉矶地区的一家电信公司不再依赖新泽西州的数据中心。距离无法实现闪电般的快速传输,当然也无法为用户提供蓬勃发展所需的顶级体验。

云原生技术实现了标准化和自动化,从而使电信公司更容易利用边缘计算。这种趋势在企业领域正在迅速发展,并进入了电信领域。为了说明这一点,Gartner预测,到2025年,将有75%的企业生成数据在传统的集中式数据中心或云外部创建和处理。

VoltDB:可用于现代电信公司的云原生数据平台

为了最大程度地提高云的速度和效率,电信公司需要关注的不仅仅是其应用程序的框架。迁移到云时要考虑的最重要的事情之一是基础数据平台。

尽管大多数数据平台都可以在云环境中运行,但是强烈建议电信公司使用可以提高速度,弹性和敏捷性的云原生数据平台。

VoltDB正是这样的数据平台之一,它提供了多种功能,使其适合于高端的云原生部署。例如,VoltDB为诸如Kubernetes和Docker之类的程序提供容器和支持。VoltDB还具有快速故障转移,无缝对接,自动修复以及灵活的可延展性,使群集可以根据需要以编程方式增长或收缩。由于其具备的强大的功能,VoltDB使电信公司能够在10毫秒内实时做出数据驱动的决策。

关于VoltDB
VoltDB支持强ACID和实时智能决策的应用程序,以实现互联世界。没有其它数据库产品可以像VoltDB这样,可以同时需要低延时、大规模、高并发数和准确性相结合的应用程序加油。
VoltDB由2014年图灵奖获得者Mike Stonebraker博士创建,他对关系数据库进行了重新设计,以应对当今不断增长的实时操作和机器学习挑战。Stonebraker博士对数据库技术研究已有40多年,在快速数据,流数据和内存数据库方面带来了众多创新理念。
在VoltDB的研发过程中,他意识到了利用内存事务数据库技术挖掘流数据的全部潜力,不但可以满足处理数据的延迟和并发需求,还能提供实时分析和决策。VoltDB是业界可信赖的名称,在诺基亚、金融时报、三菱电机、HPE、巴克莱、华为等领先组织合作有实际场景落地案例。

看好VoltDB吗? 马上行动吧!
欢迎私信,与更多小伙伴一起探讨。

查看原文

赞 0 收藏 0 评论 0

VoltDB 发布了文章 · 3月26日

HPE的通信技术集团将如何加速电信5G的普及和应用?

1、导读

2月,惠普企业(HPE)成立了新的企业通信技术集团(CTG),以帮助电信公司和企业充分把握5G带来的机遇。
这对于寄希望解锁5G 全部价值的组织意味着什么?作为 HPE 的合作伙伴,VoltDB对此感到非常兴奋。
HPE CTG 是业内最广泛的电信合作伙伴组织之一,涵盖基础设施、软件和服务。因此,HPE 现在具有独特的地位,可帮助电信公司实现基础设施和产品的现代化,从而在 5G 时代保持发展和竞争的优势。
在此声明的基础上,HPE还发布了HPE Open RAN解决方案堆栈,其中包含HPE ProLiant DL110 Gen10 Plus服务器。这款经过优化的Open RAN工作负载服务器可在全球5G网络上大规模实现Open RAN的全球商业部署。HPE Open RAN解决方案堆栈是该公司2020年3月推出的HPE 5G核心堆栈的补充。
我们服务的底线是什么?HPE正在提供领先的解决方案,利用有望成为变革性技术的技术:5G,从而使客户处于有利地位。

2.为什么很重要?

我们有很多理由让电信公司和企业对5G感到兴奋,尤其是考虑到其拥有巨大的市场潜力时。到2027年,美国5G服务市场预计将继续以每年43.9%的速度增长,届时将达到4145亿美元。在这种情况下,5G将彻底改变电信公司和企业的运营方式。
目前,5G仍处于起步阶段。当前,大多数电信公司正在从传统基础架构转向使用由不同提供商提供的模块化软件组件开放和构建的云原生平台。
可以说,这不是一件小事。成功需要电信公司打破边界,拥抱一个更大的可信赖的合作伙伴和生态系统。
有一个很明确的信息是:在5G领域,电信公司不能像孤岛一样行事。
迈向5G时代需要值得信赖的技术合作伙伴的帮助,而这正是HPE的CTG将特别有帮助的地方。

3、HPE和VoltDB:5G成功的动力二重奏

随着VoltDB持续在5G领域取得长足进步,VoltDB为能够与HPE合作而感到自豪。
VoltDB与HPE密切合作,为组织提供多项启用数据库管理服务。
例如,HPE使用VoltDB的ACID兼容数据平台为其增强的Internet使用管理器(eIUM)提供动力。HPE还使用VoltDB进行策略和计费规则功能(PCRF)优化,这是业务支持系统(BSS)的核心功能,也是电信运营商的主要收入来源。
VoltDB通过提供一个用于传输、分析实时网络策略和在线计费数据并对其采取行动的框架,来帮助HPE。该数据平台能够即时、可靠地了解用户在任何给定时间拥有多少信用,帮助 HPE 以闪电般的速度和精度对定位的有效用户进行计费、收费和货币化。通过使用VoltDB,HPE可以更快地配置和发布营销活动,并始终满足不断变化的评级和收费要求。
这些只是HPE使用VoltDB处理数据并从中获利的许多方式中的几种。新的用户案例不断涌现,两家公司正在密切合作以识别和部署支持5G的解决方案,那些最大化程度利用此机会的公司将会受益。

4、为什么电信公司选择与VoltDB合作?

最终,它取决于性能。
首先,VoltDB使用内存中的云原生NewSQL数据平台实现10毫秒以下的实时事件决策。VoltDB还提供主动-主动跨数据中心复制,并能够处理复杂的逻辑。它还得到了专业级支持团队的支持,该团队致力于帮助客户在其堆栈和部署中实现稳定性和简单性。
加起来,最终结果是一个功能强大的解决方案,可在不损害数据准确性的情况下,以超低的总体拥有成本提供大规模的卓越性能。这就是为什么越来越多的组织同意VoltDB是唯一能够将电信公司带入5G时代的数据平台的原因。
有关VoltDB如何帮助您的组织充分利用5G时代的更多信息,请查看VoltDB的功能。

_关于VoltDB
VoltDB支持强ACID和实时智能决策的应用程序,以实现互联世界。没有其它数据库产品可以像VoltDB这样,可以同时需要低延时、大规模、高并发数和准确性相结合的应用程序加油。
VoltDB由2014年图灵奖获得者Mike Stonebraker博士创建,他对关系数据库进行了重新设计,以应对当今不断增长的实时操作和机器学习挑战。Stonebraker博士对数据库技术研究已有40多年,在快速数据,流数据和内存数据库方面带来了众多创新理念。
在VoltDB的研发过程中,他意识到了利用内存事务数据库技术挖掘流数据的全部潜力,不但可以满足处理数据的延迟和并发需求,还能提供实时分析和决策。VoltDB是业界可信赖的名称,在诺基亚、金融时报、三菱电机、HPE、巴克莱、华为等领先组织合作有实际场景落地案例。_

如果您希望集成VoltDB到您的技术栈中,
可以私信或者访问VoltDB中国网站:👇
https://www.voltdb-china.cn/

查看原文

赞 0 收藏 0 评论 0

VoltDB 发布了文章 · 3月17日

您的客户管理决策是否低于10毫秒?

01 如何与客户有效互动

当今的电信运营商和通信服务提供商(CSP)正在寻求新的方法,利用其产品和服务获利,尤其是在5G、物联网和工业物联网方面。为了帮助电信公司最终增加每用户平均收入(ARPU),电信软件供应商需要考虑如何构建可为5G货币化提供最佳途径和机会的应用程序。
运营商每天与客户互动的机会并不多。在这种情况下,每次接洽合作为电信公司提供了一个宝贵的机会,这可以使电信公司与客户互动并取悦客户,并在适当的时机向他们提供正确的报价。
为了充分利用他们与客户的少数互动,许多电信公司使用客户管理应用程序,使他们能够在客户最有可能接受的关键时刻显示超个性化的报价。

02 客户管理和5G:天作之合

客户管理是当今电信领域最有前途的领域之一。简而言之,它有潜力为运营商带来巨大的市场优势,尤其是随着5G的出现,它使运营商能够部署以客户管理为中心的应用程序,这些应用程序具有闪电般的速度和精度,并且不会影响数据的准确性。
研究表明,在与客户进行实时互动时,电信运营商只有250毫秒的时间提供相关报价。甚且,报价的决策部分必须在展示自己的那一刻起10毫秒内发生——这是以前4G LTE网络无法实现的任务。
简而言之,5G提供了基础框架的关键部分,使电信公司能够充分发挥客户管理的全部潜力。当然,要想从他们的解决方案中获得最大价值,5G只是其中的一部分。
为了发挥5G在客户管理应用中的全部功能,运营商还必须解决传统数据库系统结构(例如RDBMS解决方案)固有的潜在缺陷,这些缺陷使他们当前的客户管理应用程序难以跟上数据量、速度和多样性。考虑到5G和物联网的运用,运营商还需要转变为通过数据湖和仓库进行批处理,并实施支持实时流分析能力的解决方案。

03 与客户管理一起争取不到10毫秒的决策

到目前为止,您可能想知道用亚秒级决策智能替代近乎实时的分析系统的真正商业价值。
这是一个例子。
最近,一家使用VoltDB技术的公司与T1移动运营商进行了概念验证,力图弄清使用基于流分析的实时营销活动是否比近实时的营销活动能带来更大的价值。或者说,该公司希望了解实时互动能否在推动收入增长和减少客户流失方面有所作为。
在一项测试中,当用户将要使用超额服务时,测试团队会发送消息来拦截客户,并为他们提供了相关的数据包的实时报价。
在另一项测试中,该公司锁定了有价值的客户,这些客户即将用完预付费服务的信用额度,并提供了相关的实时IOU信用服务。
结果证实,使用实时分析比公司现有的近实时解决方案具有竞争优势。
实际上,得益于VoltDB,与公司现有的近实时营销活动结果相比,实时数据包销售额增长了50%以上,实时报价采用率比近实时的提高了157%。而且,订户购买的实时数据包服务比购买近实时的顾客多购买253%。
随着行业的发展进步,亚秒级延迟将很快成为行业的金标准。这样,拖延或避免进行升级的公司就有可能被竞争对手所取代。
根据最近的一份报告,有92%的电信公司正计划在2022年部署5G。到2025年,电信公司将花费超过2750亿美元建设5G网络。可以说这个领域的发展非常迅速,如果想保持竞争力,保持领先地位至关重要。

04 使用VoltDB启用下一代客户管理

VoltDB使电信公司能够提供实时创收能力,同时满足客户对于延迟升级和个性化的不断发展的期望,而不必更换他们的整个技术体系。
VoltDB 的事件驱动架构使应用程序能够在 10 毫秒内对异常数据做出智能决策,在瞬间交付目标报价,而不是在数据往返数据湖或日期仓库的漫长旅程之后,因为在此期间它就会失去价值。
所以,我们可以自豪地说,VoltDB部署的实时服务比通过传统系统提供的服务要成功1.5到2.5倍。
要了解有关改进客户管理解决方案的最简便方法的更多信息,欢迎您立即使用VoltDB进行测试。
*
关于VoltDB
VoltDB支持强ACID和实时智能决策的应用程序,以实现互联世界。没有其它数据库产品可以像VoltDB这样,可以同时需要低延时、大规模、高并发数和准确性相结合的应用程序加油。
VoltDB由2014年图灵奖获得者Mike Stonebraker博士创建,他对关系数据库进行了重新设计,以应对当今不断增长的实时操作和机器学习挑战。Stonebraker博士对数据库技术研究已有40多年,在快速数据,流数据和内存数据库方面带来了众多创新理念。
在VoltDB的研发过程中,他意识到了利用内存事务数据库技术挖掘流数据的全部潜力,不但可以满足处理数据的延迟和并发需求,还能提供实时分析和决策。VoltDB是业界可信赖的名称,在诺基亚、金融时报、三菱电机、HPE、巴克莱、华为等领先组织合作有实际场景落地案例。*

如果您希望集成VoltDB到您的技术栈中,
可以私信或者访问VoltDB中国网站

查看原文

赞 0 收藏 0 评论 0

VoltDB 发布了文章 · 3月11日

历史技术栈体系即将崩溃,我们如何应对?

01 前言

当大家都在谈论5G和边缘计算,这意味着新的技术变革即将到来,我们的技术演进迭代也将发生重大变化。简单来说:

  • 我们对延迟的需求正在逼近物理极限,并且很快就会受到光在光纤电缆传播速度的物理限制。
  • “最终用户”曾经是指数千万的人口,但在不久的将来,数百亿的物联网设备将取代人类用户,这些物联网设备的连接和数据处理是迫在眉睫的现实需求。
  • 在不造成中断的情况下,完成系统部署升级也是非常现实的问题。

当延迟的需求达到需要以光速或接近光速的速度运行时,此前可行的简单处理方式都将失效,将倒逼我们采用更先进的架构和方案。
对5G和边缘计算的巨大增长需求,使我们走到了技术发展的分水岭:一方面是旧有的面临淘汰的技术栈。另一方面是安全和广阔的新世界。
但是,您需要采用正确的技术方案才能达到目标。

02 为什么旧有的技术栈即将崩溃?

随着数据和设备的爆炸式增长,同时现实又要求这些设备之间的交互提供更低的延迟,并对各种数据做出实时决策响应。当同时涉及到大数据、低延迟、实时状态更新需求时,三个因素将迅速让现有的技术栈崩溃。

2.1物理极限

5G和边缘计算有望实现连接全球数百亿的智能设备,并实现远程控制和智能编排。5G移动网络提供1-2毫秒的延迟,这比普通的4G网络快23毫秒,但这也向现有的技术栈提出了一个非常棘手的问题:它可以打破物理极限吗?
借助5G和边缘计算,我们到达了一个新场景,当添加更多或者更快的设备并不能解决问题,并且不再可能迁移到“更快的网络”。下图说明了这一点,光在WAN网络中的传播速度每毫秒约120英里(约200公里),将4G的最低延迟时间所需的最大距离与5G的最大无延迟时间距离进行比较,比真空中的速度慢30%。
图片

_理论最大传输距离对比:5G VS. 4G
网络技术受到光速的限制,光速在真空中一毫秒内可以传播181英里,而在光纤中只能在一毫秒内传播约54英里。这意味着1毫秒的延迟,5G网络理论上最多只能在54英里以内的设备间通信。_
当下的网络技术、客户端-服务器计算所处的位置、客户端和服务器之间的距离导致了各种延迟的增加。
光在10毫秒内移动了1,810英里,这意味着任何需要在10毫秒或更短时间内发生的客户端-服务器通信,其设备的物理距离都不得超过1,810英里。实际的光纤电缆发送数据的速度,比光速还要慢30%,也就是WAN中,数据传输10毫秒大约才走500英里。
当然,可以通过新技术、例如在专用光纤电缆上追加投资等方式,可以加快网络速度,但是不可能超越光纤电缆的能力,更不用说接近光速了。
5G有望最终产生1毫秒的往返延迟,满足这么低延迟的唯一方法是双方(发送方-接收方或者客户端-服务器)彼此之间相距几英里,并进行简短的信息交换。
没有物理学上的突破,就没有技术上的突破。

2.2数字孪生的激增

数字孪生是虚拟的数字映射,通常由以下元素组成:

  1. 物理设备上的各种信号接入后,可以实现远程控制
  2. 各种在线设备系统的数字映射关系
  3. 设备间的可靠数据传输可以代表设备的当前状态

一旦这三个要素到位,不仅云计算应用将变得可行,还可以控制便宜且简单的设备,通过使用云来让大量的数字孪生设备一起协同工作,完成同一目标。
到目前为止,许多设备与互联网的交互是可选的,或者不必要,而且通常无法控制其核心功能。但是5G和边缘技术已经可以促使成百上千亿的数字孪生,每天都在满足我们赖以生存的生活需求,而这一切都取决于他们自己在网络中某个地方进行可靠的超低延迟决策。大量的设备不停的被用到,然而过往的设备操作过程是“先关闭然后再打开”,这种方式已经不能满足我们管理无数设备的期许了。
延迟还意味着设备依赖快速连接来完成预期工作,因此未能满足SLA的情况与设备中断区别不大,如果设备是根据过期的信息来决策或者执行操作,可能会带来更为糟糕的后果。
2.3计划内停机
计划内的停机时间将为5G和边缘应用带来严重后果。通常来说,5G的设备需要实时联网才能工作,停机意味着重大事故。
这有几个含义:
1.采用开源组件的复杂技术栈可能无法胜任工作。如果堆栈中的每一层都有其自己的独立补丁,当补丁达到一定复杂程度或者数量时,停机更新可能是不可避免的。但如果不打补丁,也可能会带来潜在的法律或者安全问题。当停机更新的时间每分钟需要花费数千美元时,减少技术栈组件数量或许非常必要。
2.为软件打补丁和维护相对比较容易,但为固件打补丁则非常麻烦,所以尽可能不要固件或者硬件代码来完成软件栈的功能,而是从终端设备完成固件的更新与维护。
3.敏捷开发可能并不适用于与数十亿数字孪生设备一起工作,伴随每个小版本更新可能随之带来各种错误,从而导致设备中断,甚至更严重的后果。

03 新常态的不便之处

我们面临的根本问题是,由于5G场景对于延迟的需求,很大程度上是由于技术组件栈太深,而导致了额外的延迟,从而浪费了真正的有效数据处理时间。
请记住:5G和边缘计算不会在真空中发生,也不会慢慢发生。5G和边缘计算的实施意味着设备和用户会话的数量将迅速飙升。当前5G规范,联网设备的密度约为每平方公里100万台。
其中许多设备将是运行在SLA保障较高的数字孪生场景,需要不断与远程计算能力保持联机通信,并实时做出决策。
联网设备的爆炸式增长与对延迟和连接性的期望将同时发生。
图片

_延迟预期 VS. 连接设备数
随着时间的流逝,我们使用的设备数量激增,现在已经超过了人类总量。但是设备不像人类,它期望以毫秒为单位的实时决策响应。_
在以前,“我们希望更快”就可以了。而现在,“我们在4毫秒内得到响应”很可能是SLA的需求。
如果我们认可5G和边缘计算对于低延迟需求的价值,那么我们也必须接受对当前的技术和架构的挑战。

04 如何避免技术堆叠的责任

当接近延迟要求的拐点,到达物理极限时,我们需要对管理数据和运行技术栈的方式进行革新,每项革新都会带来不同的挑战和开放式的方案。
他们是:
1.边缘处理
尽管我们仍将在数据中心计算上进行大量投资,但由于新应用程序对低延迟的要求很高,因此,在边缘端执行大量对延迟敏感的功能是很有必要的。从技术和业务角度来看,边缘处理意味着更加复杂的部署架构。
2.更简单的技术组件栈
在5G和边缘计算之前,业务问题通常通过创建包含多个组件的分层架构来解决架构间的解耦问题。但是,每一层都会增加延迟,在5G世界中,需要节省与边缘设备间的通信延迟,而不是在软件组件逻辑层之间的额外通信上浪费时间。现实是,只有推动架构向前发展,使用更少的技术组件栈,将数据流、流处理和事务状态管理合并在一起,才能从根本上解决这个问题。
3.“ 哑巴”设备
早期的IoT项目涉及向设备添加传感器,以便它们可以发送数据到服务器端,在远端完成数据分析。这些早期架构中,设备会使用有限的本地计算能力来执行部分核心功能。
而5G和边缘应用的连接无处不在,没有理由在每台终端设备上保留强大的处理能力。这样做会增加设备成本,而且也会造成无休止的设备端补丁更新噩梦。
边缘计算,逻辑上就有可能发生从设备中删除尽可能多的智能处理单元。

05 下一步:您需要评估的五个需求问题

5G不仅仅是营销术语,还是用稍好的硬件代替一般硬件的借口。但真正需要改变的是我们做事的方式。
从以下五个问题来评估您的应用场景是否适合5G:

  1. 它适用于OLTP吗?如果是,它是否可以在单位延迟时内从大规模数据中做出准确的决策?
  2. 它可以在架构上最小化数据在网络中传输的次数吗?
  3. 它是否足够简单且垂直集成,从而以高可用的方式用最少的时间来处理数据?
  4. 它是否用于IoT或流消息?如果是,它是否具与Kafka,Kinesis等消息中间件的入站和出站连接,方便集成多个数据流?
  5. 如果您的下一代5G应用依赖开源技术,您是否真正考虑过停机和故障的后果?

如果您对以上任何一个问题的回答都是“否”,那么您很可能将面临技术堆叠导致应用崩溃的境地,应该寻求有专业支持的集成解决方案来主动避免这场灾难。

06 VOLTDB如何满足5G的需求?

随着我们步入5G和边缘计算场景,您必须接受这样一个事实,现有的软件堆栈或开发技术可能很快就会过时。在技术领域,情况一直如此:昨天可以稳定工作的平台软件今天会失效,明天更可能会面临系统崩溃。
低延迟需求将大多数技术堆栈的功能扩展到其极限,许多公司都会试图找到最便宜或开发效率最快的方法。但他们不会从整体上或者根本上进行架构思考,而是从拼图和创可贴的角度开展工作,从而导致更大的后果。
没错:5G和边缘计算就在这里,并正在取代数据世界的运行方式。
如果您正在寻找可以在毫秒延迟内实现高可用性、可扩展性和实时决策的平台,请立即通过 https://www.voltdb-china.cn/contact 与我们联系,来聊聊我们如何提供帮助。

_参考:
1.https://www.quora.com/What-is-precisely-the-speed-of-light-in-fiber-optics
2.https://en.wikipedia.org/wiki/Digital_twin

  1. https://arstechnica.com/information-technology/2017/02/5g-imt-2020-specs/_

**如果您希望集成VoltDB到您的技术栈中,或者想和更多小伙伴一起交流
请私信与我们联系。**

_关于VoltDB
VoltDB支持强ACID和实时智能决策的应用程序,以实现互联世界。没有其它数据库产品可以像VoltDB这样,可以同时需要低延时、大规模、高并发数和准确性相结合的应用程序加油。
VoltDB由2014年图灵奖获得者Mike Stonebraker博士创建,他对关系数据库进行了重新设计,以应对当今不断增长的实时操作和机器学习挑战。Stonebraker博士对数据库技术研究已有40多年,在快速数据,流数据和内存数据库方面带来了众多创新理念。
在VoltDB的研发过程中,他意识到了利用内存事务数据库技术挖掘流数据的全部潜力,不但可以满足处理数据的延迟和并发需求,还能提供实时分析和决策。VoltDB是业界可信赖的名称,在诺基亚、金融时报、三菱电机、HPE、巴克莱、华为等领先组织合作有实际场景落地案例。_

查看原文

赞 0 收藏 0 评论 0

VoltDB 发布了文章 · 3月3日

5G时代,为什么NoSQL和SQL存在短板?

01 介绍

当今的通信服务提供商(CSP)需要能够在处理海量复杂的数据的同时,不会下降或者减慢网路响应速度和可靠性。5G时代,设备和用户数量呈指数级增长,这对业务支持服务(BSS)提出了新需求,也成为了一项特别艰巨的任务。
正如您目前所看到的现实情况,电信网络策略响应,个性化报价或防止欺诈交易等应用程序,必须能够在几毫秒内对数据事件做出反应,才能增加营收或防止亏损。
为了更好地满足这些日益复杂的需求,CSP需要知道如何在日益拥挤的数据库环境中进行最佳地数据管理,而且这类场景似乎每年都会出现新的类别。最新类别则是NewSQL,它为NoSQL和SQL数据库无法提供的电信公司提供了独特优势,尤其是在实时数据处理方面。当今的数据库需要遍历整个数据从获取到执行的整个生命周期,且必须在10毫秒或更短的时间完成。环顾四周,目前只有NewSQL数据平台才能实现这一目的。
本文阐述了SQL,NoSQL和NewSQL数据库之间的主要区别,并解释了为什么NewSQL数据库是电信行业顺应时代发展的关键,以及在5G时代,CSP如何充分利用各种数据库技术对其网络进行高效运维管理。

02 NewSQL缘起

NewSQL是451 Group的分析师Matt Aslett创造的一个术语,用来描述一组新的数据库特性,这些特性既继承了传统SQL关系数据库的许多功能,同时也提供NoSQL技术的某些优势。
NewSQL系统为现实提供了两全其美的方案:关系数据模型和传统数据库的ACID事务一致性;继承SQL的交互便利性以及NoSQL的可扩展性和速度。有些系统提供了比NoSQL解决方案更强的一致性保证,尽管有人认为“可调”的一致性是伪一致性,但也并不完全符合ACID。
当然,NewSQL解决方案之间也存在差异。SAP HANA可以处理少量的事务性工作负载,但是没有本地集群的优势。NuoDB是一个群集优先的SQL数据库,专注于云部署,但是吞吐量很差。MemSQL对于集群分析很有用,但是其可调整的一致性并非严格意义上的ACID事务。NuoDB和MemSQL都具有计算和存储分离的特点,因此它们可能会遇到数据传输和同步(尤其是围绕事务的同步)的问题。
ACID 原则
大多数关系数据库都遵循ACID(原子性、一致性、隔离性和持久性)原则,而大多数NoSQL数据库是BASE(基本可用、软状态、最终一致性)原则。
NewSQL数据库,如VoltDB,为联机事务处理(OLTP)工作提供了NoSQL系统的可扩展性,同时遵从了传统数据库系统的ACID保证。

03 电信业场景下的NewSQL与NoSQL

既然我们已经注意到了SQL、NoSQL和NewSQL的基本区别,以及他们各自的优缺点。接下来,就让我们深入了解下,电信业运营商和开发人员真正关心NoSQL和NewSQL的哪些特性,他们可以使用NoSQL解决哪些问题?

  • 我可以使用NoSQL解决哪些问题?
  • NoSQL在哪里使用不合适?
  • 如何利用NoSQL和NewSQL的优势?

我们不怀疑NoSQL数据库非常契合许多工作场景,但是在某些特定场景下,NoSQL技术可能并不是能选择的最佳的解决方案。
下一节会对比NewSQL和NoSQL在电信业数据管理的4个关键考量指标:可扩展性,可用性,数据一致性以及快速响应。

3.1 可扩展性

NoSQL
随着5G蓬勃发展以及通信设备的迅速增长,电信业企业需要升级扩展其现有的数据管理方式。
最初NoSQL因为在互联网行业中类似Google,Facebook和Twitter广泛采用,以解决他们海量规模化数据管理时,才开始引起人们的注意。这些平台处理大量非结构化数据流入:Web搜索、移动设备、用户状态更新、信息流等。
在这些场景中,最重要的考量因素是可扩展性。数据库必须大规模快速地扩展。关系模式和扩展传统SQL数据库无法应对海量数据增长和处理,在传统SQL数据库维护海量数据和多样化查询处理请求的成本和效率是很难接受的。
NoSQL系统最重要的特性是能够在通用的硬件设备上扩展应用程序的能力。对于需要水平无限制扩展的需求场景,NoSQL可能是正确的选择,NewSQL和NoSQL在扩展性上并没有太大区别。
但是,NoSQL数据库为了扩展性而在几乎所有其它方面折衷,这对于仅依靠NoSQL的电信业公司来说有很大问题。

NewSQL
尽管NoSQL关系数据库系统提供了可扩展性选项,但通常这一成本很高。NewSQL系统也在致力于应对系统扩展性的挑战,同时它继承了传统RDBMS的事务性和SQL标准。
在典型场景中,内存中的大规模并行SQL关系数据库,该数据库在通用硬件上可以线性扩展。与NoSQL解决方案一样,NewSQL数据库对云原生友好,并且可以随意扩展以满足超大数据规模下的应用程序需求。系统应设计为使用集群内无共享数据分块的架构,来实现云端环境下低延迟的读写性能。
NewSQL数据库提供了高可用、容错性以及物理数据冗余,在电信网络之类的场景也能够平稳运行,以便电信运营商能够从容应对大量涌入的数据。借助功能强大的NewSQL数据库,用户还可以针对实时数据流处理场景,构建面向实时事务的应用程序。

3.2 可用性

NoSQL
NoSQL系统专为CAP理论的可用性而设计,这意味着即使在分布式分区的情况下,数据库也始终会响应。
但是NoSQL系统在设计上优先考虑可用性,采用最终一致性,而不是强一致性(即始终提供最新最正确的数据集快照)方案,意味着NoSQL系统为了快速响应,然而可以返回的不是最新数据。
Apache Cassandra是最终一致性理念的践行者,即快速响应比始终返回最新数据更重要,确实对于许多应用程序而言,最终的一致性是可以接受的。
但是,需要根据确切数据才可以进行交易的场景,比如电信公司需要采取措施来打击欺诈等活动,最终一致性是不可接受的。
因此,NoSQL解决方案不适用于以下情况:

  • 决定是否拨打移动用户的电话
  • 跟踪(计数)并分配有限的稀缺资源
  • 交易事务决策

NewSQL
NewSQL系统优先考虑一致性而不是可用性。NewSQL系统将向所有客户返回相同的确切答案,从而使应用程序可以在通话费用,飞机座位分配和库存等方面做出实时决策,而不会发生冲突。

3.3 一致性

NoSQL
如前所述,NoSQL系统是为实现可扩展性和可用性而设计的,但要牺牲强一致性作为代价。因此,对于需要强一致性的场景而言,NoSQL系统并不是一个好的选择,比如计费和操作支持场景,而这两个场景对于电信运营又都很常见。
同样的还有欺诈行为,电信运营商尤其是发展中国家的电信运营商,承受着巨大的压力,被滥用的SIM卡甚至可以用集装箱计,从而造成每年数十亿美元的损失。解决电信欺诈问题需要大规模准确地实时计算查询呼叫方账户,这都是NoSQL数据库无法做到的。

NewSQL
NewSQL系统具有高度一致性,它们优先考虑一致性而不是可用性,与此同时,NewSQL也支持多分区,这对于电信公司及其提供不间断服务的能力至关重要,因为这意味着即使节点到节点的通信出现故障,集群仍可以继续工作。

3.4 快速响应事务性场景

NoSQL
快速响应的场景在现代场景中非常普遍。尽管NoSQL解决方案通常可以提高数据存储速度,但无法提供大规模的强一致的事务支持。
需要快速,可扩展的交易性应用程序包括:

  1. 在验证用户余额的同时允许移动电话连接
  2. 以最优惠的价格进行交易
  3. 向潜在的数千个用户展示移动广告,而不会超出客户的广告投放预算
  4. 为电信服务商提供严格的SLA 在批准交易之前检测是否存在信用卡盗刷行为

对于这类应用程序,由于处理事件每小时每分钟都可能会发生数百万次,因此NoSQL数据库通常不是最佳选择。电信、金融服务、在线游戏、广告技术和其他行业的业务需要能够应对事件处理的并发和延迟。因此,可扩展的强一致性事务解决方案是必备的。

NewSQL
NewSQL系统为现代应用程序提供了高可扩展性和强一致性的特性,即使在海量数据处理时,多分区冗余支持也可以使得系统线性扩展,助力应用程序精确快速响应客户请求。

04 使用NewSQL构建可扩展的现代应用程序

NoSQL和NewSQL都提供了构建高度可扩展的应用程序的数据存储能力。NoSQL数据存储是高可用性应用场景的理想选择。NewSQL系统则提供强大的一致性和事务交互性能力,即便在出现故障时,一致性比可用性更受青睐的场景中,NewSQL是最佳选择。
尽管几乎所有NoSQL解决方案都提供了可扩展性,但VoltDB却提供了可扩展性并添加了强一致性的事务支持。
VoltDB具备极高的响应速度、强一致性和可扩展性。在所有NewSQL解决方案,面对集群故障的情景中,VoltDB都是最强大和最灵活的,我们针对可用性进行了独立验证,见证了许多客户在生产环境集群中稳定运行数年。
VoltDB在需要强一致性的应用场景中表现出色,包括:

  1. 处理电信BSS和网络中日益复杂的策略和计费规则问题
  2. 从呼叫后欺诈检测到防止欺诈性呼叫发生
  3. 向电信客户提供即时优惠,以改善订户体验和ARPU 应用机器学习规则来检测和防止工业物联网的入侵行为
  4. 测量、监视和检测性能下降,避免意外宕机

VoltDB是目前市场上最成熟的NewSQL系统,也是云原生数据库。它支持实时数据流中的ACID事务处理,对本地集群和Hadoop生态支持也非常完备。除此之外,它同时集成了高吞吐量,低延迟的数据处理特性,是非常优秀的数据密集型应用程序系统, 在高性能、低延迟、强一致性需求场景中表现不俗,广泛应用于策略执行,个性化推荐,欺诈或异常检测等需要实时决策响应的数据流应用程序中。

如果您希望集成VoltDB到您的技术栈中,或者想和更多小伙伴一起交流
请私信与我们联系。

关于VoltDB
_VoltDB支持强ACID和实时智能决策的应用程序,以实现互联世界。没有其它数据库产品可以像VoltDB这样,可以同时需要低延时、大规模、高并发数和准确性相结合的应用程序加油。
VoltDB由2014年图灵奖获得者Mike Stonebraker博士创建,他对关系数据库进行了重新设计,以应对当今不断增长的实时操作和机器学习挑战。Stonebraker博士对数据库技术研究已有40多年,在快速数据,流数据和内存数据库方面带来了众多创新理念。
在VoltDB的研发过程中,他意识到了利用内存事务数据库技术挖掘流数据的全部潜力,不但可以满足处理数据的延迟和并发需求,还能提供实时分析和决策。VoltDB是业界可信赖的名称,在诺基亚、金融时报、三菱电机、HPE、巴克莱、华为等领先组织合作有实际场景落地案例。_

查看原文

赞 0 收藏 0 评论 0

VoltDB 发布了文章 · 2月7日

VoltDB让Kafka支持复杂数据流驱动的实时业务决策

01 简介

VoltDB是一个高速决策引擎,为必须在数毫秒内做出响应的应用程序提供基础架构支持,适用场景包括BSS(策略和收费)、预防欺诈、客户价值管理(即个性化)和实时工业自动化等等,那些通过实时决策可以增加收入或减少损失的场景。

这些应用程序通常需要VoltDB运行在一个多样化和异构计算的软件生态里,它需要与各种技术集成对接,包括Apache Kafka。实际上,Kafka已然成为企业消息队列的首选中间件。Kafka Connectors丰富的生态系统让其它技术框架与VoltDB集成变得很简单。

虽然有很多技术可以从Kafka里提取数据来并交给下游进一步处理,但能够同时完成实时数据决策需求的技术就屈指可数了。

通过订阅Kafka Topic,VoltDB可以直接从Kafka上提取数据,并在10毫秒内完成数据决策,然后立即把结果发送回Kafka,在诈骗实施得手或者失去盈利机会前,完成相关决策执行。
图片

VoltDB让企业在Kafka技术生态的投值增值,它实现了在复杂流数据上的实时决策能力,让应用开发重心放在处理重要的业务逻辑上,在实时完成数据的分析、处理和修改。

我们的客户通过集成VoltDB和Kafka,赋能让各种应用场景,比如:让电话接线员给在90多个国家的用户提供实时的个性化服务,帮助需要大规模、高并发、实时响应的大型体育运动平台提供流畅的个性化用户体验。

在已经建立成熟的事件驱动型软件架构中,只需要加入VoltDB,您的应用程序就可以获得实时分布式事务决策的能力,可以有效应对5G时代下的物联网、机器学习的实时推理决策需求。

随着5G、机器学习和物联网的迅猛发展,VoltDB和Kafka技术的对接已经非常成熟,它使Kafka能够快速并无缝地查询复杂的流数据。Kafka建于2011年,用于处理流数据,那时5G,物联网和机器学习等实时处理的需求还并不是特别旺盛,因此,尽管Kafka在某些场景下可以正常工作,但可能不适用于当代快速查询复杂流数据的场景。

02 Kafka的强大之处

当今的经济是建立在知识和数据的基础上的。与往日的石油经济一样,现代公司需要搭建基础设施,并快速并有效地处理这些知识和数据。

通过创建一个只为了让线性数据流动的中央管理系统,Apache Kafka在很大程度上降低了系统的复杂程度。Kafka完全是从头开始建造的吞吐量明显高于任何连接组件。最后,它是作为实时流数据平台构建的,始终可以让数据流实时传递。

Kafka不只是在信息传输上面表现出色,它还有其它优势:无限制的水平扩展性和简单的数据存储,在实时的流数据传递过程中可以无性能损耗的存储数据。

虽然Kafka加上KsqIDB可以通过类SQL语言读取实时流数据,如果需要进行储存和运算数据的话则需要多种辅助工具比如NoSQL数据库、流处理技术和规则引擎等。为了达到5G、工业物联网及它们相关的实时控制回路所需要的低延迟标准和智能化要求,我们需要将这些技术封装到一个中间件里,这就是VoltDB。

03 你的选择:集成还是替换

根据架构和事件驱动架构的发展程度,应用程序可以通过使用importer-exporter框架将VoltDB与Kafka消息队列集成,或者可以使用新的Topics功能本身将VoltDB用作Kafka消息队列。以下是这两个选项的简要概述。

3.1用importer-exporter框架来进行整合
VoltDB的importer-exporter框架提供了与其他技术(如Kafka,Kinesis,JDBC,Elastic,Hadoop等)的无代码集成。
导入程序将数据流传输到VoltDB中以按事件进行提取,同时确保消息/记录在存储后的持久性导入到VoltDB。然后,exporter可以以At-Least Once语义,将后处理消息/记录推送到下游系统。
图片

3.2 导入
Importer框架让用户程序集成VoltDB到事件驱动型架构。VoltDB的Importer框架管理如下过程:

  1. 轮询外部系统是否有新的可用数据
  2. 导入数据
  3. 逐条处理数据
  4. 在同一个存储过程中,依次传递数据给应用程序的业务逻辑,完成用户的自定义业务处理

可以在配置文件中或通过VoltDB的用户界面声明性地配置用于不同系统的Importer。这些内置的导入器在数据库启动时自动运行,在数据库停止时自动停止,使数据导入成为数据库操作过程的一部分。此外,Importer连接器还为摄取的事件提供持久性,以确保在灾难情况下不会丢失任何数据。可以在正在运行中的数据库上创建导入程序实例,而无需停机。

VoltDB Kafka Importer使用Kafka Consumer API从多个Kafka代理和多个Topic提取数据。开发人员可以使用与Kafka Consumer相同的属性配置导入程序。

3.3导出
导出会自动执行与导入相反的过程,捕获写入到导出表或流中的所有数据并将其发送到关联的外部目标,无论是文件,服务(例如Kafka)还是其它数据库。
开发者可以选择导出特定记录或迁移由于TTL过期而从表中删除的行。导出过程是事务性的,因此开发人员可以确保导出期间不会丢失任何记录。VoltDB保证每条数据记录将至少导出一次(At – Least Once)。
图片

3.4替换

VoltDB Topic特性(测试版)

在v10.1版本里,Topic特性允许应用程序使用发布和订阅语义与VoltDB连接。除了提供更好的语义以与其它系统集成外,这该功能还允许将VoltDB用作消息队列,一站式完成VoltDB实时数据流管理和实时数据处理。
通过标准的Kafka Consumer API和Producer API来集成此功能,VoltDB可以轻松替换Kafka,特别是对于需要低延迟事务处理的数据流场景。
图片
新的Topic特性带给应用程序带来的好处在于:

  • 通过缩减Kafka集群的大小来降低成本
  • 减少跨越组件带来的网络延迟,从而降低整体的端到端延迟
  • 更简单的架构设计
  • 复用Kafka Connect生态

VoltDB实现Kafka API Topic的优势之一是可以复用Kafka Connect,让VoltDB可以无缝替换Kafka,与那些已经和Kafka集成绑定的流行技术方案更容易集成VoltDB。应用系统架构中只用替换少量组件,就可以将发布者和使用者直接嵌入,充分复用丰富的Kafka Connect生态组件。

通过使用Source和Sink Kafka连接器将各种系统与VoltDB集成在一起,开发人员可以轻松地将其数据管道连接在一起,以充分利用将消息队列与复杂的决策引擎结合在一起的独特优势。
图片

04 结束语

现代的大数据和5G的场景需求,与传统的基础软件架构系统适用性有大量的冲突。传统基础设施,因为没有足够能力去应付瞬息万变的应用场景而即将成为历史。Kafka是在2011年被发明的,那是还是没有5G和物联网概念的时代,简单查询处理能力的程序还适用于那个时期。如今时代已经不一样了,Kafka虽然目前还是一个强大的流数据处理器,但是它仍需要一些场外援助,才能在复杂流数据上完成实时决策。

如果您正在使用Kafka,VoltDB与Kafka的集成也是容易的。但由于相信并了解Kafka的强大功能以及客户的需求,我们一直在寻找更多方法来与诸如Kafka的这类关键技术集成,这就是我们创建Kafka Importer和Exporter工具的原因,也是我们开发新的pub-sub功能的原因。

最重要的是:无论客户是否使用Kafka,我们都希望客户的数据库体系结构支持并加速其业务目标,而不是提供让人困扰的方案。这也是我们总是提供各种选项,以及与客户讨论数据架构需求的原因。

关于VoltDB

VoltDB支持需要实时智能决策的应用程序,以实现互联世界,同时又不影响ACID要求。没有其他数据库产品可以同时为需要低延时、大规模、高并发数和准确性相结合的应用程序加油。

VoltDB由2014年图灵奖的获得者Mike Stonebraker博士创建,他对关系数据库进行了重新设计,以应对当今不断增长的实时操作和机器学习挑战。Stonebraker博士对数据库技术研究已有40多年,在快速数据,流数据和内存数据库方面带来了众多创新理念。

在VoltDB的研发过程中,他意识到了利用内存事务数据库技术挖掘流数据的全部潜力,不但可以满足处理数据的延迟和并发需求,还能提供实时分析和决策。VoltDB是业界可信赖的名称,已经由诺基亚,金融时报,三菱电机,HPE,巴克莱,华为等领先组织合作有实际场景落地。

如果您对VoltDB感兴趣,欢迎私聊,与更多小伙伴一起探讨。

查看原文

赞 0 收藏 0 评论 0

VoltDB 发布了文章 · 1月29日

5G机遇 | 如何解决在核心场景的高并发、超低延迟需求?

01

每年春节,都意味着一场红包间的大战。
过去我们习惯拿一个写好祝福的红包,塞进钱送给我们的父母、亲人、长辈晚辈。
手机支付普及后,我们只需要掏出手机,就可以完成所有步骤。
移动支付带来方便的同时,也存在诸多问题,仪式感暂不提。从工程师的角度来看,如果发红包的并发流量太高,服务器则容易分分钟陷入宕机状态,撒钱都没辙。罗振宇在 2019 年的跨年演讲中提到:得到原本打算在春晚投放广告,但是被劝住了,因为春晚红包有一条不成文的规定——要想春晚打广告,产品日活先过亿。原因很简单,用户量过低,技术很难支撑起春晚级别的高并发流量。
那么问题来了,如何解决在核心场景的高并发、超低延迟需求呢?赶快在年前学习一波吧。

02

2.1 Dream11受《经济时报》热捧

前段时间,印度的《经济时报》热捧Dream11(体育运动平台),仅仅因为它能够管理数百万个并发用户,同时能够运行数千个实时实验来改善用户体验。
《经济时报》指出,在2020年印度板球超级联赛期间,Dream11每分钟处理6000万个请求,每秒处理多达8000次事务处理。
这正是VoltDB最擅长的工作:在大规模、高并发的场景下,为数据提取、处理、决策提供高效执行引擎。当然了,VoltDB不只是为体育界的客户提供服务,我们在电信、金融等其他垂直行业也会提供此类服务。

2.2 为什么电信领域也需要?
电信运营商和Dream11体育平台面临的数据量和复杂性类似。5G时代,物联网和机器学习之间,比以往任何时候都需要大规模高并发性能的能力。这样不但可以提供客户优质体验,在欺诈预防,动态策略和计费功能等方面也有强烈需求。电信公司对高速实时处理大量数据决策而构建的NewSQL数据平台,场景也非常明确。
和Dream11类似,电信公司场景有:

  • 数百万并发用户
  • 来自分布广泛的源的极其复杂的数据
  • 越来越复杂的政策和收费选项
  • 如果发生故障,将导致严重后果

2.3 电信公司可以做什么来应付5G应用场景?

面对新的前所未有的复杂流数据浪潮,电信公司需要重新考虑其技术堆栈,需要采取一些措施,才能取得与Dream11相同的性能指标:
简化技术栈
坦率地说,电信公司负担不起移动数据、处理数据、叠加业务规则以及通过四个不同的堆栈层存储数据这样的代价。为了能够挖掘5G应用低延迟应用的价值,需要把存储的技术栈简化成一层。
弹性扩展
这对于策略和收费问题尤其重要。数千万的音乐,视频和其他流媒体服务,为这些应用背后的用户提供不同的收费策略,极具挑战性。弹性扩展的数据库意味着运营商可以根据需求逐渐增加容量,并随着时间的推移推出更多复杂的服务。
机器学习
电信公司已经开始将机器学习应用于客户价值管理和欺诈预防。为了能够每秒接收数百万个单独事件,检查可疑行为并在设备甚至无法连接之前就阻止欺诈性呼叫,电信公司需要能够连续不断地实时更新并应用机器学习规则和算法,以便从中学习过去的错误,提高预防欺诈的成功率。
超低延迟
这可能是最重要的一个指标,它当然与所有上述维度(简化的堆栈,弹性扩展和机器学习)叠加后,还能维持超低延迟是非常重要的。内存NewSQL数据平台使超低延迟成为可能,并可以在10毫秒内完成数据的提取,处理和查询,从而使电信公司可以轻松应付客户对规模和性能的期望,但无需复杂的高度定制解决方案。

03

我们知道Dream11的成绩仅仅是开始,越来越多的行业和公司也在慢慢使用VoltDB技术。只要基于VoltDB的数据平台准备就绪,电信公司就有理由对5G和物联网的复杂场景的应对保持乐观。

如果您对VoltDB的工业物联网大数据低延迟方案、全生命周期的实时数据平台管理等感兴趣,欢迎私聊,与更多小伙伴一起探讨。

查看原文

赞 0 收藏 0 评论 0

VoltDB 发布了文章 · 1月22日

2020 总结 | VoltDB的亮点,你了解多少?

2020年,VoltDB变得更易于维护,更易于二次开发,更易于集成到业务的数据流管道中。
最新的长期支持版本(LTS)V9.3,让生产环境中使用VoltDB也更加放心。

公共云和私有云中更易于维护

VoltDB V10引入了VoltDB Kubernetes Operator模块、Helm图表和Prometheus代理。部署和运行VoltDB集群,并依靠Kubernetes编排技术,让实例的部署、运行、维护比以往更加简单。

跨数据中心复制(XDCR)也好,单个集群或多集群部署维护也都支持不错。
此外,VoltDB今年还引入了对IPv6的支持。

可以加快开发和集成效率的新特性

在2020年,我们添加了几个功能,这些功能让编写VoltDB的应用程序变得轻松简单。其中一个新的强大功能——Topics ,方便用户可以轻松地将VoltDB集成到实时流数据管道中:

  • 自定义任务和调度。去年,当VoltDB在表上引入TTL时,我们认识到就自动执行数据库操作而言,自动删除数据这种任务调度功能需求很普遍。在V9.3中,我们添加了自定义任务和调度计划,通过API就可以完成相关操作,开发者可以完全自定义任务逻辑。自定义的任务调度,可以使用上次运行的结果来影响将来的决策,从而允许创建复杂的工作流程,比如:“IF… THEN … ELSE…”类型的任务调度计划。
  • Topics -V10.1引入了Topics这个概念,可以轻松地将VoltDB集成到数据管道中,并利用VoltDB将复杂的有状态逻辑应用于数据流。Topics易于使用,并且可以使用行业标准协议。与简单的流系统不同,VoltDB主题为低延迟,复杂的应用程序提供了丰富的语义支持,可以通过SQL和Java语言来实现执行相关逻辑,并提供了对数据库状态的完全访问权限和实时决策。Topics还允许多个并发的Topics订阅者,每个订阅者都可以按照节奏工作。

稳定性改进和新的LTS版本

许多客户已经升级到V8.4 LTS,这个版本在2019年推出。我们承诺会支持该版本三年,并通过关键缺陷和安全修复程序进行主动更新。我们还添加了对软件依赖项的支持。例如,在2020年,V8.4LTS中支持了Java 11。

2020年中,我们发布了V9.3 LTS,它对V9的所有新功能都提供更长的支持期限,并为VoltDB的稳定性和正常运行提供了两项重大改进。

1. 当事务导致副本之间的差异时,改进了正常运行时间

在V9.3中,当VoltDB检测到数据不一致时,系统不再关闭,而之前的版本,为了确保数据一致性,会自动停止数据库服务。

新版本中,VoltDB会检查所有在分区副本上运行的事务、SQL查询、输入和结果。当检测到差异时,只会关闭额外的数据副本,通过在单副本状态下运行来保持数据库完全一致,从而在不影响耐用性、性能或一致性的前提下保持可用性,让应用研发团队能够尽快修复问题代码。

2. 改善数据导出时的可扩展性和资源利用率

在V9.3中,我们重新设计了流式导出子系统以提高可靠性和性能。

V9中引入的各种新的流式数据特性(TTL迁移、导出表、Alter Stream和可配置的刷新间隔),也得以获得取快速决策和处理的能力。我们还大大减少了线程数并提高了吞吐量。在V10(Topics)中,我们也将流式导出子系统用于Topics功能。

我们对2021年的期待

2021年,VoltDB会有一系列改进计划。

首先,我们将继续支持Kubernetes。
寻找对三数据中心的XDCR支持,对Helm图表更新的增强,对较新的Kubernetes版本的支持以及安全更新。
我们还计划在合并测试版的反馈意见,完成稳定性测试并进行一些调整以提高流式传输速度的同时,Topics普遍可用。

年中,我们将发布V10 LTS产品,其中所有Kubernetes和Topics的特性都将稳定,可用于生产环境。

最后,使用V11,我们将对VoltDB内存管理进行全面的优化重写。这种重写(我们称为“确定性存储”)将在所有副本上以相同顺序排列数据,并且对VoltDB应用有三大好处:
SQL查询将在所有副本上获得确定性结果,而无需添加额外的“ ORDER BY”子句和它们所需的额外索引。大大简化应用程序开发过程,并节省许多内存。

生产中的数据一致性问题将更少。在V9.3 LTS中,一致性问题不再导致致命错误,但将导致VoltDB以单副本模式运行。SQL语句上缺少ORDER BY子句会让生产环境更加简单。

作为此重写的模块,我们还将消除了内存GC造成的停顿,这个对于实时处理应用而言,是非常致命的长尾延迟问题。

在2020年VoltDB有很多的改进,2021年我们也将持续优化。随着我们不断改进产品,我们一直在倾听客户的声音,使VoltDB能够很好地满足相关应用场景的需求。

如果您对VoltDB的工业物联网大数据低延迟方案、全生命周期的实时数据平台管理等感兴趣,欢迎私聊,与更多小伙伴一起探讨。

查看原文

赞 0 收藏 0 评论 0

VoltDB 发布了文章 · 1月19日

使用内存NewSQL数据平台来处理实时数据流的三个好处

从Apache Kafka的传统发布订阅系统,到相关的流处理框架,例如Apache Samza,Apache Storm,Apache Flink,都适用于大多数工作在基本决策能力、运行效率、支撑的数据规模和稳定性方面的需求。

然而,Apache这类开源项目,并不能够满足于大多数的行业需求,比如在金融、广告技术、医疗物联、电信等行业。

那使用内存NewSQL数据平台来处理实时数据流有哪些好处呢?

1、复杂的机器学习运算

对于现代程序来说,拥有一个具备实时决策能力的引擎至关重要。虽然传统的流数据处理平台拥有一些基本的机器学习和模式识别能力,但还是缺乏一些重要的场景特性:

  • 以毫秒为单位来实时决策复杂的、有大量参数变量和上下文状态的场景
  • 从历史数据和实时数据流中,动态训练和更新机器学习模型的场景

基于内存的NewSQL关系数据库管理系统,简称(RDBMS),是为了快速处理复杂的数据而建立。

RDBMS的核心功能,比如:用户自定义函数和存储过程等,可用来用作自定义的机器学习模型,方便嵌入到数据库系统中,进行数据流的实时决策。PMML模型会被自动转化成UDF并运用于生产。

只有基于内存的NewSQL RDBMS可以为现代大规模应用提供可执行的复杂决策+低延迟+高效率等一系列组合需求。

2、目前SQL还是王道
SQL是一个具有悠久历史并被公认的数据查询标准,所有尝试替代SQL的工具最后都以失败告终,其中也包括了像是Apache Hadoop框架下的MapReduce和其他多数NoSQL工具。

带有讽刺的是目前多数NoSQL把重心放在添加SQL或是SQL类似的查询语言。就连Apache Kafka也在顺应SQL的时代,并为了流处理而加入KSQL。

然而,目前KSQL标准离SQL还是相差甚远。

在另一方面,作为一个参照与NewSQL RDBMS而创立的系统,VoltDB在流数据上提供了全面的ANSI适用型SQL,实现更广的查询和操作复杂的事件处理。

此外,ANSI适用型SQL也能给开发者们提供对于快速流处理所需要的熟悉度,灵活度和标准化。NewSQL在给HTAP提供相同的NoSQL可扩展性平台的同时,也不会影响到ACID语义保障。

3、ACID保障很重要
一个优秀的NewSQL RDBMS不仅仅是一个快速、可扩展、容易部署的系统,在简化开发和部署的同时,它还需要提供ACID保障。

从开发者的角度,ACID可理解为:

  1. 简化的查询过程。把复杂的单个数据表查询语句简化成多个查询语句,通过引入事务的概念确保他们有相同的执行结果,严格的ACID要求确保了这些查询语句是可以独立执行的。
  2. 更容易的数据测试。对于数据库的数据变更,都可以通过事务操作来完成,在完成数据测试之前回滚事务状态即可。隔离性确保了多个数据测试可以并行执行,不会导致数据在不确定状态下被修改。
  3. 更快的并发。ACID保障每个事务的隔离性前提下,并发的程序可以运行地更加快,也不需要开发者们在自己应用逻辑中考虑不同事务操作的并发时序。

简单来说,传统的流处理技术已经不能够像NewSQL RDBMS一样符合ACID保障。它们最多只能包含能提供最终一致性的NoSQL数据库。

对于企业来说,数据的准确性和一致性是至关重要的。不完整的资料不仅仅会让企业损失惨重,还会严重影响到企业品牌形象。更多关于NewSQL流处理信息,请参考以下文件:

图片
或复制下方链接下载👇

https://www.slidestalk.com/VoltDB/Whitepaper_VoltDBt_Streaming_Processing_ArchitectureF74054

查看原文

赞 0 收藏 0 评论 0

认证与成就

  • 获得 1 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2020-10-29
个人主页被 1.2k 人浏览