精华内容
下载资源
问答
  • 云原生数据库设计新思路

    千次阅读 2021-01-14 12:32:30
    本文作者为 PingCAP 联合创始人兼 CTO 黄东旭,将分享分布式数据库的发展趋势以及云原生数据库设计的新思路。 在讲新的思路之前,先为过去没有关注过数据库技术的朋友们做一个简单的历史回顾,接下来会谈谈未来的...

    本文作者为 PingCAP 联合创始人兼 CTO 黄东旭,将分享分布式数据库的发展趋势以及云原生数据库设计的新思路。

    在讲新的思路之前,先为过去没有关注过数据库技术的朋友们做一个简单的历史回顾,接下来会谈谈未来的数据库领域,在云原生数据库设计方面的新趋势和前沿思考。首先来看看一些主流数据库的设计模式。

    常见的分布式数据库流派

    分布式数据库的发展历程,我按照年代进行了分类,到目前为止分成了四代。第一代是基于简单的分库分表或者中间件来做 Data Sharding 和 水平扩展。第二代系统是以 Cassandra、HBase 或者 MongoDB 为代表的 NoSQL 数据库,一般多为互联网公司在使用,拥有很好的水平扩展能力。

    第三代系统我个人认为是以 Google Spanner 和 AWS Aurora 为代表的新一代云数据库,他们的特点是融合了 SQL 和 NoSQL 的扩展能力,对业务层暴露了 SQL 的接口,在使用上可以做到水平的扩展。

    第四代系统是以现在 TiDB 的设计为例,开始进入到混合业务负载的时代,一套系统拥有既能做交易也能处理高并发事务的特性,同时又能结合一些数据仓库或者分析型数据库的能力,所以叫 HTAP,就是融合型的数据库产品。

    未来是什么样子,后面的分享我会介绍关于未来的一些展望。从整个时间线看,从 1970 年代发展到现在,database 也算是个古老的行业了,具体每个阶段的发展情况,我就不过多展开。

    数据库中间件

    对于数据库中间件来说,第一代系统是中间件的系统,基本上整个主流模式有两种,一种是在业务层做手动的分库分表,比如数据库的使用者在业务层里告诉你;北京的数据放在一个数据库里,而上海的数据放在另一个数据库或者写到不同的表上,这种就是业务层手动的最简单的分库分表,相信大家操作过数据库的朋友都很熟悉。

    第二种通过一个数据库中间件指定 Sharding 的规则。比如像用户的城市、用户的 ID、时间来做为分片的规则,通过中间件来自动的分配,就不用业务层去做。

    这种方式的优点就是简单。如果业务在特别简单的情况下,比如说写入或者读取基本能退化成在一个分片上完成,在应用层做充分适配以后,延迟还是比较低的,而整体上,如果 workload 是随机的,业务的 TPS 也能做到线性扩展。

    但是缺点也比较明显。对于一些比较复杂的业务,特别是一些跨分片的操作,比如说查询或者写入要保持跨分片之间的数据强一致性的时候就比较麻烦。另外一个比较明显的缺点是它对于大型集群的运维是比较困难的,特别是去做一些类似的表结构变更之类的操作。想象一下如果有一百个分片,要去加一列或者删一列,相当于要在一百台机器上都执行操作,其实很麻烦。

    NoSQL - Not Only SQL

    在 2010 年前后,好多互联网公司都发现了这个大的痛点,仔细思考了业务后,他们发现业务很简单,也不需要 SQL 特别复杂的功能,于是就发展出了一个流派就是 NoSQL 数据库。NoSQL 的特点就是放弃到了高级的 SQL 能力,但是有得必有失,或者说放弃掉了东西总能换来一些东西,NoSQL 换来的是一个对业务透明的、强的水平扩展能力,但反过来就意味着你的业务原来是基于 SQL 去写的话,可能会带来比较大的改造成本,代表的系统有刚才我说到的 MongoDB、Cassandra、HBase 等。

    最有名的系统就是 MongoDB,MongoDB 虽然也是分布式,但仍然还是像分库分表的方案一样,要选择分片的 key,他的优点大家都比较熟悉,就是没有表结构信息,想写什么就写什么,对于文档型的数据比较友好,但缺点也比较明显,既然选择了 Sharding Key,可能是按照一个固定的规则在做分片,所以当有一些跨分片的聚合需求的时候会比较麻烦,第二是在跨分片的 ACID 事务上没有很好的支持。

    HBase 是 Hadoop 生态下的比较有名的分布式 NoSQL 数据库,它是构建在 HDFS 之上的一个 NoSQL 数据库。Cassandra 是一个分布式的 KV 数据库,其特点是在 KV 操作上提供多种一致性模型,缺点与很多 NoSQL 的问题一样,包括运维的复杂性, KV 的接口对于原有业务改造的要求等。

    第三代分布式数据库 NewSQL

    刚才说过 Sharding 或者分库分表,NoSQL 也好,都面临着一个业务的侵入性问题,如果你的业务是重度依赖 SQL,那么用这两种方案都是很不舒适的。于是一些技术比较前沿的公司就在思考,能不能结合传统数据库的优点,比如 SQL 表达力,事务一致性等特性,但是又跟 NoSQL 时代好的特性,比如扩展性能够相结合发展出一种新的、可扩展的,但是用起来又像单机数据库一样方便的系统。在这个思路下就诞生出了两个流派,一个是 Spanner,一个是 Aurora,两个都是顶级的互联网公司在面临到这种问题时做出的一个选择。

    Shared Nothing 流派

    Shared Nothing 这个流派是以 Google Spanner 为代表,好处是在于可以做到几乎无限的水平扩展,整个系统没有端点,不管是 1 个 T、10 个 T 或者 100 个 T,业务层基本上不用担心扩展能力。第二个好处是他的设计目标是提供强 SQL 的支持,不需要指定分片规则、分片策略,系统会自动的帮你做扩展。第三是支持像单机数据库一样的强一致的事务,可以用来支持金融级别的业务。

    代表产品就是 Spanner 与 TiDB,这类系统也有一些缺点,从本质上来说一个纯分布式数据库,很多行为没有办法跟单机行为一模一样。举个例子,比如说延迟,单机数据库在做交易事务的时候,可能在单机上就完成了,但是在分布式数据库上,如果要去实现同样的一个语义,这个事务需要操作的行可能分布在不同的机器上,需要涉及到多次网络的通信和交互,响应速度和性能肯定不如在单机上一次操作完成,所以在一些兼容性和行为上与单机数据库还是有一些区别的。即使是这样,对于很多业务来说,与分库分表相比,分布式数据库还是具备很多优势,比如在易用性方面还是比分库分表的侵入性小很多。

    Shared Everything 流派

    第二种流派就是 Shared Everything 流派,代表有 AWS Aurora、阿里云的 PolarDB,很多数据库都定义自己是 Cloud-Native Database,但我觉得这里的 Cloud-Native 更多是在于通常这些方案都是由公有云服务商来提供的,至于本身的技术是不是云原生,并没有一个统一的标准。从纯技术的角度来去说一个核心的要点,这类系统的计算与存储是彻底分离的,计算节点与存储节点跑在不同机器上,存储相当于把一个 MySQL 跑在云盘上的感觉,我个人认为类似 Aurora 或者 PolarDB 的这种架构并不是一个纯粹的分布式架构。

    原来 MySQL 的主从复制都走 Binlog,Aurora 作为一种在云上 Share Everything Database 的代表,Aurora 的设计思路是把整个 IO 的 flow 只通过 redo log 的形式来做复制,而不是通过整个 IO 链路打到最后 Binlog,再发到另外一台机器上,然后再 apply 这个 Binlog,所以 Aurora 的 IO 链路减少很多,这是一个很大的创新。

    日志复制的单位变小,意味着我发过去的只有 Physical log,不是 Binlog,也不是直接发语句过去,直接发物理的日志能代表着更小的 IO 的路径以及更小的网络包,所以整个数据库系统的吞吐效率会比传统的 MySQL 的部署方案好很多。

    Aurora 的优势是 100% 兼容 MySQL,业务兼容性好,业务基本上不用改就可以用,而且对于一些互联网的场景,对一致性要求不高的话,数据库的读也可以做到水平扩展,不管是 Aurora 也好,PolarDB 也好,读性能是有上限的。

    Aurora 的短板大家也能看得出来,本质上这还是一个单机数据库,因为所有数据量都是存储在一起的,Aurora 的计算层其实就是一个 MySQL 实例,不关心底下这些数据的分布,如果有大的写入量或者有大的跨分片查询的需求,如果要支持大数据量,还是需要分库分表,所以 Aurora 是一款更好的云上单机数据库。

    第四代系统:分布式 HTAP 数据库

    第四代系统就是新形态的 HTAP 数据库,英文名称是 Hybrid Transactional and Analytical Processing,通过名字也很好理解,既可以做事务,又可以在同一套系统里面做实时分析。HTAP 数据库的优势是可以像 NoSQL 一样具备无限水平扩展能力,像 NewSQL 一样能够去做 SQL 的查询与事务的支持,更重要的是在混合业务等复杂的场景下,OLAP 不会影响到 OLTP 业务,同时省去了在同一个系统里面把数据搬来搬去的烦恼。目前,我看到在工业界基本只有 TiDB 4.0 加上 TiFlash 这个架构能够符合上述要求。

    分布式 HTAP 数据库:TiDB (with TiFlash)

    为什么 TiDB 能够实现 OLAP 和 OLTP 的彻底隔离,互不影响?因为 TiDB 是计算和存储分离的架构,底层的存储是多副本机制,可以把其中一些副本转换成列式存储的副本。OLAP 的请求可以直接打到列式的副本上,也就是 TiFlash 的副本来提供高性能列式的分析服务,做到了同一份数据既可以做实时的交易又做实时的分析,这是 TiDB 在架构层面的巨大创新和突破。

    下图是 TiDB 的测试结果,与 MemSQL 进行了对比,根据用户场景构造了一种 workload,横轴是并发数,纵轴是 OLTP 的性能,蓝色、黄色、绿色这些是 OLAP 的并发数。这个实验的目的就是在一套系统上既跑 OLTP 又跑 OLAP,同时不断提升 OLTP 和 OLAP 的并发压力,从而查看这两种 workload 是否会互相影响。可以看到在 TiDB 这边,同时加大 OLTP 和 OLAP 的并发压力,这两种 workload 的性能表现没有什么明显变化,几乎是差不多的。但是,同样的实验发生在 MemSQL 上,大家可以看到 MemSQL 的性能大幅衰减,随着 OLAP 的并发数变大,OLTP 的性能下降比较明显。

    接下来是 TiDB 在一个用户实际业务场景的例子,在进行 OLAP 业务的查询的时候,OLTP 业务仍然可以实现平滑的写入操作,延迟一直维持在较低的水平。

    未来在哪里

    Snowflake

    Snowflake 是一个 100% 构建在云上的数据仓库系统,底层的存储依赖 S3,基本上每个公有云都会提供类似 S3 这样的对象存储服务,Snowflake 也是一个纯粹的计算与存储分离的架构,在系统里面定义的计算节点叫 Virtual Warehouse,可以认为就是一个个 EC2 单元,本地的缓存有日志盘,Snowflake 的主要数据存在 S3 上,本地的计算节点是在公有云的虚机上。

    这是 Snowflake 在 S3 里面存储的数据格式的特点,每一个 S3 的对象是 10 兆一个文件,只追加,每一个文件里面包含源信息,通过列式的存储落到磁盘上。

    Snowflake 这个系统最重要的一个闪光点就是对于同一份数据可以分配不同的计算资源进行计算,比如某个 query 可能只需要两台机器,另外一个 query 需要更多的计算资源,但是没关系,实际上这些数据都在 S3 上面,简单来说两台机器可以挂载同一块磁盘分别去处理不同的工作负载,这就是一个计算与存储解耦的重要例子。

    Google BigQuery

    第二个系统是 BigQuery,BigQuery 是 Google Cloud 上提供的大数据分析服务,架构设计上跟 Snowflake 有点类似。BigQuery 的数据存储在谷歌内部的分布式文件系统 Colossus 上面,Jupiter 是内部的一个高性能网络,上面这个是谷歌的计算节点。

    BigQuery 的处理性能比较出色,每秒在数据中心内的一个双向的带宽可以达到 1 PB,如果使用 2000 个专属的计算节点单元,大概一个月的费用是四万美金。BigQuery 是一个按需付费的模式,一个 query 可能就用两个 slot,就收取这两个 slot 的费用,BigQuery 的存储成本相对较低,1 TB 的存储大概 20 美金一个月。

    RockSet

    第三个系统是 RockSet,大家知道 RocksDB 是一个比较有名的单机 KV 数据库,其存储引擎的数据结构叫 LSM-Tree,LSM-Tree 的核心思想进行分层设计,更冷的数据会在越下层。RockSet 把后面的层放在了 S3 的存储上面,上面的层其实是用 local disk 或者本地的内存来做引擎,天然是一个分层的结构,你的应用感知不到下面是一个云盘还是本地磁盘,通过很好的本地缓存让你感知不到下面云存储的存在。

    所以刚才看了这三个系统,我觉得有几个特点,一个是首先都是天然分布式的,第二个是构建在云的标准服务上面的,尤其是 S3 和 EBS,第三是 pay as you go,在架构里面充分利用了云的弹性能力。我觉得这三点最重要的一点是存储,存储系统决定了云上数据库的设计方向。

    为什么 S3 是关键?

    在存储里边我觉得更关键的可能是 S3。EBS 其实我们也有研究过,TiDB 第一阶段其实已经正在跟 EBS 块存储做融合,但从更长远的角度来看,我觉得更有意思的方向是在 S3 这边。

    首先第一点 S3 非常划算,价格远低于 EBS,第二 S3 提供了 9 个 9 很高的可靠性,第三是具备线性扩展的吞吐能力,第四是天然跨云,每一个云上都有 S3 API 的对象存储服务。但是 S3 的问题就是随机写入的延迟非常高,但是吞吐性能不错,所以我们要去利用这个吞吐性能不错的这个特点,规避延迟高的风险。这是 S3 benchmark 的一个测试,可以看到随着机型的提升,吞吐能力也是持续的提升。

    如何解决 Latency 的问题?

    如果要解决 S3 的 Latency 问题,这里提供一些思路,比如像 RockSet 那样用 SSD 或者本地磁盘来做 cache,或者通过 kinesis 写入日志,来降低整个写入的延迟。还有数据的复制或者你要去做一些并发处理等,其实可以去做 Zero-copy data cloning,也是降低延迟的一些方式。

    上述例子有一些共同点都是数据仓库,不知道大家有没有发现,为什么都是数据仓库?数据仓库对于吞吐的要求其实是更高的,对于延迟并不是那么在意,一个 query 可能跑五秒出结果就行了,不用要求五毫秒之内给出结果,特别是对于一些 Point Lookup 这种场景来说,Shared Nothing 的 database 可能只需要从客户端的一次 rpc,但是对于计算与存储分离的架构,中间无论如何要走两次网络,这是一个核心的问题。

    你可能会说没有关系,反正计算和存储已经分离了,大力出奇迹,可以加计算节点。但是我觉得新思路没必要这么极端,Aurora 是一个计算存储分离架构,但它是一个单机数据库,Spanner 是一个纯分布式的数据库,纯 Shared Nothing 的架构并没有利用到云基础设施提供的一些优势。

    比如说未来我们的数据库可以做这样的设计,在计算层其实带着一点点状态,因为每台 EC2 都会带一个本地磁盘,现在主流的 EC2 都是 SSD,比较热的数据可以在这一层做 Shared Nothing,在这一层去做高可用,在这一层去做随机的读取与写入。热数据一旦 cache miss,才会落到 S3 上面,可以在 S3 只做后面几层的数据存储,这种做法可能会带来问题,一旦穿透了本地 cache,Latency 会有一些抖动。

    这种架构设计的好处:首先,拥有对实时业务的数据计算亲和力,在 local disk 上会有很多数据,在这点上很多传统数据库的一些性能优化技巧可以用起来;第二,数据迁移其实会变得很简单,实际上底下的存储是共享的,都在 S3 上面,比如说 A 机器到 B 机器的数据迁移其实不用真的做迁移,只要在 B 机器上读取数据就行了。

    这个架构的缺点是:第一,缓存穿透了以后,Latency 会变高;第二,计算节点现在有了状态,如果计算节点挂掉了以后,Failover 要去处理日志回放的问题,这可能会增加一点实现的复杂度。

    还有很多值得研究的课题

    上面的架构只是一个设想,TiDB 其实还不是这样的架构,但未来可能会在这方向去做一些尝试或者研究,在这个领域里面其实还有很多 open question 我们还没有答案,包括云厂商、包括我们,包括学术界都没有答案。

    现在有一些研究的课题,第一,如果我们要利用本地磁盘,应该缓存多少数据,LRU 的策略是什么样子,跟 performance 到底有什么关系,跟 workload 有什么关系。第二,对于网络,刚才我们看到 S3 的网络吞吐做的很好,什么样的性能要配上什么样的吞吐,要配多少个计算节点,特别是对于一些比较复杂查询的 Reshuffle;第三,计算复杂度和计算节点、机型的关系是什么?这些问题其实都是比较复杂的问题,特别是怎么用数学来表达,因为需要自动化地去做这些事情。

    即使这些问题都解决了,我觉得也只是云上数据库时代的一个开始。未来在 Serverless,包括 AI-Driven 几大方向上,怎么设计出更好的 database,这是我们努力的方向。最后引用屈原的一句话,就是路漫漫其修远兮,我们还有很多事情需要去做,谢谢大家。

    展开全文
  • 云原生数据库STAC specification is getting closer to the ver 1.0 milestone, and as such the first virtual Cloud Native Geospatial Sprint is being organized next week. An outreach day is planned on Sep ...

    云原生数据库

    STAC specification is getting closer to the ver 1.0 milestone, and as such the first virtual Cloud Native Geospatial Sprint is being organized next week. An outreach day is planned on Sep 8th with a series of talks and tutorials for everyone. Read more about the sprint in this blog post by our Technology Fellow Chris Holmes. A new addition to the sprint is a data labeling contest!

    STAC规范越来越接近1.0版本的里程碑,因此,下周将组织第一个虚拟Cloud Native Geospatial Sprint 。 计划在9月8日举办外展日,并为每个人提供一系列讲座和教程。 在我们的技术研究员克里斯·霍姆斯(Chris Holmes)的博客中阅读有关冲刺的更多信息。 sprint的新成员是数据标签竞赛!

    If you have followed our blogs, we have written many times on the importance of open-access and high-quality labels on satellite imagery for building geospatial machine learning models. A scalable solution to generate labels for a large number of imagery is to run crowdsourcing campaigns and encourage the community to contribute to open-access training data catalogs.

    如果您关注我们的博客 ,我们已经多次撰写了关于卫星图像上开放获取和高质量标签对于构建地理空间机器学习模型的重要性的文章。 为大量图像生成标签的可扩展解决方案是运行众包活动并鼓励社区为开放获取培训数据目录做出贡献。

    我们在贴什么标签? (What are we labeling?)

    While multispectral satellite imagery provide valuable and timely observations globally, the presence of clouds in the imagery makes them unusable for monitoring land surface. Indeed, some regions around the world are covered by clouds almost daily. So, it’s essential to be able to detect clouds in the imagery and mask them before running any analysis.

    尽管多光谱卫星影像可在全球范围内提供有价值且及时的观测结果,但影像中云的存在使它们无法用于监视地面。 实际上,世界上某些地区几乎每天都被乌云遮盖。 因此,在执行任何分析之前,必须能够检测出图像中的云并对其进行遮罩,这一点至关重要。

    We have decided to run a data labeling contest for identifying cloud (and background) pixels in Sentinel-2 scenes to enable the development of an accurate cloud detection model from multispectral data. Several scenes from Digital Earth Africa’s (DEA) Sentinel-2 catalog have been selected. DEA’s team has converted all of the Sentinel-2 imagery across Africa to COG and hosted them on AWS (check it out here).

    我们已决定举办一次数据标签竞赛,以识别Sentinel-2场景中的云(和背景)像素,从而能够从多光谱数据中开发出准确的云检测模型。 从非洲数字地球(DEA)的Sentinel-2目录中选择了几个场景。 DEA的团队已将整个非洲的所有Sentinel-2图像转换为COG,并将其托管在AWS上( 在此处查看 )。

    After the completion of the contest, the resulting training dataset will be hosted on Radiant MLHub with a CC BY 4.0 license for public access.

    竞赛结束后,最终的训练数据集将以CC BY 4.0许可证托管在Radiant MLHub上 ,以供公众访问。

    我们如何标记图像? (How are we going to label imagery?)

    Azavea’s GroundWork platform is being used for the contest. Their team has already ingested a set of Sentinel-2 scenes from DEA’s catalog and created several projects that will be shared with participants. Each scene will be divided into 512 x 512 pixel tasks on GroundWork, and participants can choose to label any of them or automatically get assigned to a task.

    Azavea的GroundWork平台正在用于比赛。 他们的团队已经从DEA的目录中提取了一组Sentinel-2场景,并创建了几个项目,这些项目将与参与者共享。 每个场景将在GroundWork上划分为512 x 512像素的任务,参与者可以选择标记其中的任何一个或自动分配给任务。

    In each task, you should label cloud and background pixels and ensure that all pixels are assigned to either of the two classes before submitting them. You will receive detailed instructions from GroundWork’s team on how to use the tool and identify cloudy pixels.

    在每个任务中,应标记云像素和背景像素,并确保在提交所有像素之前将其分配给两个类中的任何一个。 您将收到GroundWork团队的详细说明,以了解如何使用该工具和识别模糊像素。

    计分 (Scoring)

    We have defined a score to rank your contribution in the contest based on a combination of the number of tasks you finish and their complexity. For example, tasks that have no cloudy pixels are much easier to label compared to tasks that have many small patches of altocumulus cloud.

    我们已经定义了一个分数,可以根据您完成的任务数量及其复杂程度来对您在比赛中的贡献进行排名。 例如,与具有许多小积云的任务相比,没有浑浊像素的任务更容易标记。

    Image for post

    S: Your score

    S:你的分数

    N_tasks: Number of tasks completed (completed is defined as all pixels labeled)

    N_tasks:已完成的任务数(已完成的定义为所有标有像素的像素)

    N_polygons: Number of polygons completed overall (polygons of both cloud and background classes will be counted)

    N_polygons:整体完成的多边形数量(将同时计算云类和背景类的多边形)

    f_cloud: fraction of cloud-labeled pixels in a completed task

    f_cloud:已完成任务中云标记像素的比例

    f_background: fraction of background-labeled pixels in a completed task

    f_background:完成的任务中带有背景标签的像素的比例

    For example, if you finish two tasks, one of them with a single cloudy polygon covering 30% of the task, and another one with two cloudy polygons covering 40% of the task, your score will be:

    例如,如果您完成了两个任务,其中一个任务覆盖了任务的30%,一个多云多边形,而另一个任务覆盖了任务的40%,两个多云多边形,您的得分将是:

    Image for post

    获奖情况 (Awards)

    A number of awards will be presented to top contributors of the contest:

    竞赛的主要贡献者将获得许多奖项:

    • Top Labeler — $2000 plus an open 50cm SkySat Image, tasked by the winner.

      顶级贴标机-2000美元,外加50厘米的开放式SkySat图像 ,由获胜者负责。

    • 2nd and 3rd place labelers — Jacket or $200

      第二和第三名贴标机—夹克或$ 200
    • Top Labeler from an African Country (who is not in the top 3 prizes) — Jacket or $200

      非洲国家/地区的最佳贴标机(不是前三名)–夹克或$ 200
    • Top Woman Labeler (who is not in the top 3 prizes) — Jacket or $200

      顶级女性贴标机(不在前三名中)-夹克或$ 200
    • Next 5 top labelers — Hoodie or $60

      接下来的5个顶级贴标商-连帽衫或$ 60
    • Anyone with a minimum score of 10 on the leaderboard — t-shirt or $20

      排行榜上最低分数为10的任何人-T恤或$ 20

    Read more about all the awards of the Cloud Native Geospatial Sprint here.

    在此处阅读有关Cloud Native Geospatial Sprint的所有奖项的更多信息。

    如何参加? (How to participate?)

    Fill out this form, and you will receive an email from GroundWork on Sep 8th at 10am PDT (5pm UTC) notifying you about the projects that are ready to be labeled. Depending on the completion rate of projects, we will add more projects throughout the contest.

    填写表格,您将在9月8日美国太平洋夏令时间上午10点(世界标准时间下午5点)收到GroundWork发出的电子邮件,通知您有关已准备好贴标签的项目。 根据项目的完成率,我们将在比赛中添加更多项目。

    You will have until 11:59pm PDT on Sep 15th (6:59am UTC on Sep 16th) to participate and label imagery. After that the leaderboard will be closed and awardees will be selected.

    您将在美国夏令时(PDT)9月15日晚上11:59(UTC时间9月16日上午6:59)之前参与并标记图像。 之后,排行榜将被关闭,获奖者将被选中。

    松弛通道 (Slack Channel)

    We have created a new channel on Radiant MLHub’s slack named, #stac-6-labeling-contest, for participants to share their experience with each other. If you are already on our slack workspace, search for the channel and join. If not you can join the workspace using this link, and then join the channel.

    我们在Radiant MLHub的闲暇处创建了一个名为#stac-6-labeling-contest的新频道供参与者彼此分享经验。 如果您已经在我们的闲置工作空间中,请搜索频道并加入。 如果不是,您可以使用此链接加入工作区,然后加入频道。

    Finally, this wouldn’t have been possible without the support of our sponsors. Thanks to Planet, Microsoft, Azavea, and Radiant Earth Foundation for sponsoring this event.

    最后,没有我们的赞助商的支持,这是不可能的。 感谢Planet,Microsoft,Azavea和Radiant Earth Foundation赞助了此活动。

    Looking forward to seeing many of you in the contest!

    期待在比赛中与大家见面!

    Image for post
    Sample image from GroundWork showing cloud and background labels overlaid on Sentinel-2 scene (credit: Azavea)
    来自GroundWork的示例图像显示了覆盖在Sentinel-2场景上的云和背景标签(来源:Azavea)

    翻译自: https://medium.com/radiant-earth-insights/data-labeling-contest-cloud-native-geospatial-sprint-5d5f0ffdc609

    云原生数据库

    展开全文
  • 目录 1、简介 2、阿里巴巴数据库系统架构 3、阿里巴巴数据库系统的其他关键功能 4、阿里云本机数据库 5、应用和操作 ...Cloud-Native Database Systems at Alibaba:...这些来自云应用程序的挑战为云原生数据库带来...

    目录

            1、简介

            2、阿里巴巴数据库系统架构

            3、阿里巴巴数据库系统的其他关键功能

            4、阿里云本机数据库

            5、应用和操作

            6、结论


    Cloud-Native Database Systems at Alibaba: Opportunities and Challenges

    阿里云原生数据库系统:机遇与挑战

     

    摘要

    由于各种应用程序对 弹性和按需(elasticity and on-demand)使用 的需求,云原生数据库在云计算时代变得越来越重要。这些来自云应用程序的挑战为云原生数据库带来了新的机遇,传统的企业内部数据库系统无法完全解决这些问题。云原生数据库利用软硬件协同设计来探索新硬件(如 RDMA、NVM)和 DPDK 等内核绕过协议提供的加速(A cloud-native database leverages software-hardware co-design to explore accelerations offered by new hardware such as RDMA, NVM, kernel bypassing protocols such as DPDK)。同时,新的设计架构,如共享存储,使云原生数据库能够将计算与存储分离,并提供出色的弹性特性对于需要水平伸缩性的高度并发工作负载,云原生数据库可以利用一个无共享层来提供分布式查询和事务处理。应用程序还需要云原生数据库通过分布式共识协议提供高可用性。

    在阿里巴巴,我们探索了一套设计云原生数据库系统的技术。我们的存储引擎 X-Engine 和 PolarFS 通过使用 LSM 树设计和自适应的冷热数据记录分离来提高写入和读取吞吐量。在此基础上,我们设计并实现了 POLARDB 及其分布式版本 POLARDB-X,成功支持了 2018  11  11 日全球购物节期间极端交易负载,并在阿里云上取得了商业成功。我们还设计了一个名为 AnalyticDB(简称 ADB )的 OLAP 系统,用于实现大数据的实时交互式数据分析。我们开发了一个自动驱动(self-driving)的数据库平台,实现了数据库的弹性伸缩和智能化管理。我们将分享关键技术和经验教训,强调阿里巴巴云计算数据库系统面临的技术挑战和机遇。

     

     

    1简介

    随着越来越多的应用程序和系统向云端迁移,云原生数据库系统开始获得广泛的支持和普及。云服务供应商提供的云数据库服务,如 AWS、Microsoft Azure、阿里云、Google 云等,为云原生数据库的开发做出了贡献。因此,近年来,云数据库的市场份额迅速增长。越来越多的企业和组织已经将其业务从内部数据中心迁移到云端。云平台提供了高弹性、严格的服务级别协议(SLAService-level Agreement),以确保可靠性和易管理性,同时降低运营成本。云数据库在支持基于云的业务方面起着关键作用。它成为连接底层资源(IaaS)和各种应用程序(SaaS)的中心枢纽,使其成为云计算的关键系统。

    在阿里巴巴集团,数据库系统需要支持一个丰富而复杂的商业生态系统,涵盖娱乐和数字媒体、电子商务和电子支付,以及各种新的零售和 o2o(offline to online)业务运营。在 2018  "光棍节" 全球购物节(2018年11月11日)期间,阿里巴巴的数据库每秒处理多达 49.1 万笔销售交易,相当于每秒处理超过 7000 万笔交易。由于对灵活性、可伸缩性和可管理性的需求,传统的数据库内部部署已经不能满足这种复杂的业务操作。

    例如,如 图1 所示(2018 年阿里巴巴光棍节期间,TPS 增长超过 100 倍,响应时间稳定。),在光棍节购物节的第一秒,TPS 突然增加,大约是前一秒的 122 倍。当我们简单地将 MySQL  PostgreSQL 部署在本地SSD和高I/O虚拟机的云实例(cloud instance)上时,得到的数据库实例容量有限,不适合提供可伸缩的数据库服务。它无法在潜在的磁盘驱动器故障中生存;数据库实例必须管理数据复制以提高可靠性。此外,该实例使用通用文件系统,如 ext4  XFS。当使用低 I/O 延迟硬件(如 RDM A或 PCIe SSD)时,内核空间和用户空间之间的消息传递成本可能会迅速地使吞吐量达到饱和状态。相比之下,采用云本地设计的数据库(如计算和存储的解耦、自动缩放)更具吸引力,能够提供更多的计算和存储容量,并提供更快的恢复能力和更低的成本[30,7]。

    对于云原生数据库来说,还有其他至关重要的能力:支持异构数据源和多样化查询接口的多模型;自动管理和调整数据库实例的自治性和智能性,以降低手动操作的成本;软硬件协同设计,利用高性能硬件的优势;高可用性,满足严格的 SLA 需求(例如,RPO = 0,RTO 非常小)。考虑到这些设计,云原生数据库在基于云的部署方面获得了快速增长。

    在本文中,我们发表了在阿里云上建立企业云原生数据库的最新进展[1],该数据库还支持阿里巴巴集团内各个业务部门(从娱乐、电子商务到物流)的整个业务运营。为了满足各种各样的应用程序需求,我们提供了广泛的数据库系统和工具,如图3所示。我们为每个节点开发了 100TB 的数据库处理容量。为了进一步扩展容量,我们已经开发了 POLARDB-X,一个集成了共享内容和共享存储设计的分布式 OLTP 数据库。我们还开发了 AnalyticDB,这是一个 OLAP 数据库,作为下一代数据仓库,用于 PB 级的高并发、低延迟和实时分析查询。为了管理云端承载的大量数据库实例,我们构建了 SDDP,这是一个自治的数据库操作平台,它可以自动管理实例并调整性能,只需很少的 DBA 参与。在阿里云上运行的数据库实例有近 50 万个(来自客户和阿里集团内的各个业务部门)。 POLARDB  AnalyticDB 在电子商务、金融、媒体和娱乐、教育、新零售等广泛的商业领域都获得了快速增长。这些云数据库系统和技术成功地服务于阿里巴巴集团内部复杂的商业生态系统和许多外部企业客户。

     

     

    2阿里巴巴数据库系统架构

    根据共享的内容,我们在阿里巴巴探索了三种流行构建数据库系统的架构,如 图2 所示。第一类是单实例,这是主流数据库最常用的架构。在这个模型中,数据库中的所有进程共享处理器内核、主内存空间和本地磁盘(即在一台机器上)。这样的体系结构促进并简化了系统内部的通信和协调。

    随着 Google、Amazon、Microsoft、Alibaba 等大型互联网企业在数据量和工作负荷上的快速增长,人们发现单实例架构有其局限性。单台机器的无法满足日益增长的业务需求。因此,提出了共享存储架构,以 AWS Aurora  Alibaba POLARDB为代表。在该模型中,底层存储层(通常由多个节点组成)被解耦,存储的每个数据记录都可以被运行在任意节点上的任何上层数据库内核访问。通过利用 RDMA 等快速网络,数据库可以与共享分布式存储层进行交互,就像与单个(共享)本地磁盘进行交互一样。在这个共享存储之上,我们可以轻松地启动多个计算节点来创建单个数据库的副本,在同一数据上具有相同的视图。因此,可以将请求分发到不同的(只读)节点进行并行处理。但是,为了避免写冲突,避免处理分布式事务和分布式提交的复杂性,通常只有一个节点处理数据库的所有写请求(例如,插入、更新、删除)。这种体系结构通过改变只读节点的数量,可以根据需要动态调整查询容量。允许对多个节点(即多主节点)的写入以扩展写容量也是可行的,但通常需要复杂的并发控制机制和一致协议[6,12,16,17,23,34]。

    共享存储体系结构也有其自身的局限性。首先,计算节点和存储节点之间的低延迟数据传输不能总是得到保证。对于跨交换机、数据中心甚至区域传输的消息,传输时间将大大增加,特别是当使用本地 RDMA 网络时。其次,单个数据库支持的只读节点数量是有限的。当节点数量达到一定的规模时,大量的请求将被阻塞,使得访问远程存储的成本高得令人望而却步。因此,一个实际的限制是大约有十几个只读节点。为了解决这个问题,我们需要一个无共享的架构(shared nothing architecture)。在共享存储体系结构中,逻辑数据库被分成多个分片,每个分片分配给一个节点。这些节点可以放置和复制到不同的数据中心和区域。这种架构的一个典型实现是 Google Spanner[7],它使用 GPS 和原子钟来实现跨区域的副本一致性和事务一致性。在阿里云上,我们构建了 POLARDB-X,它扩展了 POLARDB。我们探讨了在多个数据库之上构建一个无共享系统的好处,而每个数据库都有一个共享的分布式存储。(we build POLARDB-X that extends POLARDB and explores the benefits of building a shared-nothing system on top of multiple databases each with a shared distributed storage)

    请注意,这种共享和共享存储体系结构(shared-nothing and share-storage architectures)的混合体带来了一些特殊的好处。我们可以在顶层应用分表,但是将多个节点分配给一个分片(而不是每个分片一个节点)。在这个分片下面,这些节点可以访问共享存储。这种混合架构的好处是它减轻了小碎片过多的缺点。特别是,它有助于简化分片重新平衡的过程,降低跨分片事务的概率(并减少昂贵的分布式提交量)。同时,它还支持出色的水平扩展性这种混合架构同时利用了无共享和共享存储的优点,是我们在 POLARDB-X 数据库设计中探索的一个很有前途的方向。

     

     

    3、阿里巴巴数据库系统的其他关键功能

    除了探索不同的系统架构外,在阿里巴巴复杂的业务应用程序的驱动下,阿里巴巴数据库系统的设计还考虑了一些其他关键特性。

     

    3.1 多模型分析

    阿里巴巴的一个重要应用场景是支持多模型分析,它包括两个方面:southbound 和northbound 的多模型访问。Southbound 多模型访问表明底层存储支持不同的数据格式和数据源。存储的数据可以是结构化的,也可以是非结构化的,例如图形、矢量和文档存储。然后,数据库提供一个统一的查询接口,如 SQL 或类似 SQL 的接口,用于查询和访问各种类型的数据源和格式,形成数据湖服务。Northbound 多模型访问表明,单个数据模型和格式(例如,在大多数情况下,键值模型)用于将所有结构化、半结构化和非结构化数据存储在单个数据库中。在这个单一存储模型的基础上,数据库支持多个查询接口,如 SQL、SPARQL  GQL,这取决于应用程序的需要。微软 CosmosDB[9]就是这类系统的代表。

    除了满足我们内部的业务运营需求外,能够支持多模型分析也是云数据库服务的基本要求。许多云应用程序需要从异构数据源收集大量数据,并进行联合分析,以链接不同的数据源并揭示业务洞察力(即 southbound 多模型访问)。另一方面,云数据库(例如,大型 KV 存储,如HBase)通常是一个中央数据存储库,由具有不同应用需求的多个应用程序访问。由于可用性和效率的原因,他们可能更喜欢使用不同的查询接口,在这种情况下需要进行 northbound 多模型分析。

     

    3.2 性和智能性

    鉴于阿里巴巴数据库系统需要管理的数据库实例数量庞大,工作负载复杂,因此,提高数据库操作平台的自(autonomous)和智能性是必不可少的要求。在我们的平台上运行着数十万个实时数据库实例,以每个实例的方式来响应传统的基于 DBA 的手动操作、调优和维护是不可行的。从数据库内核和底层操作平台的角度来看,支持自主操作的机会很多[8、18、19、21、24、26、29]。基于此,我们致力于建设一个具有自我检测、自我决策、自我恢复和自我优化能力的自驱动数据库平台(SDDP)。以自优化为例,数据库内核中的各个模块(如索引、查询优化器和缓冲池管理)将通过采用机器学习技术进行增强,以便这些模块能够针对动态工作负载进行自适应优化。然而,由于机器学习模型的训练和推理成本很高,使得它们在数据库内核中既有效又高效是一项具有挑战性的任务。另一方面,自我检测、自我决策和自我恢复的目标是提高数据库操作平台的效率和有效性。如何自动检测实例状态和检测异常行为,以及一旦检测到错误,如何在较短的反应时间内做出正确的修复决策,是一个关键的挑战。

     

    3.3 软硬件协同设计

    阿里巴巴数据库系统创新的另一个关键课题是在硬件领域探索和利用快速发展和创新硬件。与任何其他系统一样,我们的目标是设计和实现我们的数据库系统,这些系统能够以安全和高效的方式使用有限的系统硬件资源。这一目标意味着系统必须关注硬件性能的不断变化和改进,以便能够利用创新的新硬件特性的优势。作为一个性能为主的系统,数据库系统需要充分利用可用的资源,稳健高效地执行查询和事务。随着新的硬件性能不断提高,简单地遵循现有的数据库设计并期望它们在新硬件上的性能最大化是不明智的。例如,直接运行在支持 RDMA 的分布式存储上的复杂数据库(如 MySQL)的性能明显低于具有相同 CPU 和内存配置的本地 PCIe SSD 上的性能,这需要仔细重新设计[5]。因此,新硬件带来的机遇是设计阿里巴巴数据库系统的重要考虑因素。例如,我们广泛探索和集成了新的硬件技术,如 RDMA、NVM、GPU/FPGA  NVMe SSD。

     

    3.4 高可用性

    高可用性是阿里巴巴数据库系统的基本要求之一,以确保我们的业务运营和云客户零停机,因为大多数企业客户无法容忍业务中断。高可用性的一个标准解决方案是复制,它可以在数据库实例、表或表碎片的粒度上完成。广泛使用的主备份三向复制(primary-backup and three-way replications)在大多数情况下都能胜任。对于需要更高可用性的银行和金融部门,可以强制执行四个或更多副本,这些副本通常放置在不同的数据中心(可用区域)和区域,以便在大区域故障(如网络故障和数据中心停机)中生存。

    在采用复制时,必须仔细处理副本之间的数据一致性。CAP 定理的结论是,在一致性、可用性和分区容差之间,只有三个属性中的两个可以满足。在阿里巴巴,我们在设计和实现我们的数据库系统时考虑到了"C"(一致性)和"P"(分区容差),并通过定制的 Parallel Paxos 协议(称为 X-Paxos)来确保高可用性,从而确保我们仍然可以提供高达99.999%的极高可用性。X-Paxos 实现并优化了复杂的复制技术和一致性协议,并通过日志确保数据的一致性和可用性。

     

     

    4阿里云本机数据库

    在本节中,将分享我们在阿里巴巴构建云原生数据库系统方面的最新进展。图3 总结了阿里巴巴和阿里云上的数据库系统和产品的完整概述。重点讨论了 POLARDB(共享存储 OLTP 数据库)及其分布式版本 POLARDB-X(一个基于 POLARDB 之上的共享 OLTP 数据库)、AnalyticDB(一个实时交互式OLAP数据库)和 SDDP(一个自主的数据库操作平台)。

     

    4.1 POLARDB:云原生 OLTP 数据库

    POLARDB 是基于 AliSQL(MySQL/InnoDB 的一个分支)[2]构建的关系型数据库系统,在阿里云上作为数据库服务提供。POLARDB 遵循云本地架构,提供高弹性、高容量和高并发性。另外,POLARDB  MySQL  PostgreSQL 完全兼容,帮助客户进行透明、流畅的业务应用迁移。

     

    4.1.1 系统设计

    POLARDB 遵循共享存储架构,如 图4 所示。它由三层组成:PolarProxy 作为统一的访问门户、多节点数据库集群和分布式共享文件系统 PolarFS。PolarProxy 是一个具有自适应能力的分布式无状态代理集群。

    它集成了多个计算节点的资源,为应用程序提供了一个统一的访问门户。它的动态扩展能力支持灵活地增加/减少节点。POLARDB 中的数据库节点分为 主节点  多个只读节点 两种类型。主节点可以同时处理读和写查询,而 RO 节点只处理读查询。主节点和 RO 节点共享 Redo 日志文件和数据文件,这些文件由 PolarFS(第4.1.2节)管理,PolarFS 是一种具有超低延迟、高吞吐量和高可用性的分布式文件系统。

    这种体系结构有几个独特的优点。首先,计算和存储资源被解耦。计算和存储节点可以使用不同类型的服务器硬件,并且可以单独定制。例如,计算节点不再需要考虑内存大小与磁盘容量的比率,这高度依赖于应用场景,并且很难预测。其次,它突破了单节点数据库(如 MySQL、PostgreSQL)的局限性。存储节点上的磁盘形成一个存储池,这降低了碎片化、使用不平衡和空间浪费的风险。存储群集的容量和吞吐量可以透明地横向扩展。POLARDB 能够提供 100TB 的存储容量,每个节点实现 100万 QPS。第三,由于数据都存储在存储集群上,计算节点上没有本地持久状态,这使得执行数据库迁移更容易、更快。由于 PolarFS 提供的数据复制和其他高可用特性,数据可靠性也可以得到提高。

    除了 POLARDB,其他云数据库服务也可以从这个架构中获益。首先,数据库可以基于虚拟化技术(如 Xen[3]、KVM[13]  Docker[20]构建一个更安全、更易于扩展的环境。其次,由于后端存储集群提供了快速 I/O、数据共享和快照功能,因此可以轻松实现数据库的一些关键功能,如多个只读实例和检查点。

     

    4.1.2 PolarFS  PolarStore

    数据存储技术持续地快速变化,当前的云平台很难充分利用 RDMA  NVMe SSD 等新兴硬件标准。例如,一些广泛使用的开源分布式文件系统,如 HDFS[4]  Ceph[31],被发现比本地磁盘有更高的延迟。当使用最新的 PCIe SSD 时,性能差距甚至可能达到数量级。与具有相同 CPU 和内存配置的本地 PCIe SSD 相比,直接在这些分布式存储上运行的 MySQL 之类的关系数据库的性能要差得多。

    为此,我们构建 PolarFS[5] 作为 POLARDB 的共享存储层。它是建立在 PolarStore(基于RDMA 网络的共享分布式存储)之上的分布式文件系统,通过以下机制提供超低延迟、高吞吐量和高可用性。首先,PolarFS 充分利用了 RDMA  NVMe-SSD 等新兴硬件,在用户空间实现了一个轻量级的网络栈和 I/O 栈,以避免陷入内核和处理内核锁。第二,PolarFS 提供了一个类似 POSIX 的文件系统 API,目的是编译到数据库进程中,替换操作系统提供的文件系统接口,使整个 I/O 路径都能保存在用户空间中。第三,PolarFS 数据平面的 I/O 模型也被设计用来消除锁和避免关键数据路径上的上下文切换。所有不必要的内存拷贝都被消除了,而 RDMA 被大量用于在主内存和 RDMA NIC/NVMe 磁盘之间传输数据。所有的本地到文件端的系统延迟都大大降低了。

    由于大型 POLARDB 集群中的节点故障很常见,因此需要一个共识协议来确保所有提交的修改不会丢失。按位复制应该总是一致的。在 PolarFS 中,我们首先使用 Raft[23],这是 Paxos 家族[17,16]的一种变体,它更易于实现,并且广泛应用于许多分布式系统。然而, Raft 被应用时,我们发现它严重地阻碍了 PolarFS  I/O 可扩展性,在 PolarFS 中使用低延迟 NVMe SSD  RDMA(其延迟约为几十微秒)。因此,我们开发了基于 Raft 的一致性协议 ParallelRaft,它允许无序的日志确认、提交和应用,同时允许 PolarFS 遵循传统的 I/O 语义。使用该协议,并行 I/O 并发性得到了显著的提高。

    综上所述,PolarFS 支持 POLARDB,其特点是:(1)PolarFS 可以将文件元数据的修改(如文件的截断或扩展、文件的创建或删除)从主节点同步到 RO 节点,这样 RO 节点的所有更改都是可见的。(2)PolarFS 确保对文件元数据的并发修改是序列化的,这样文件系统本身在所有数据库节点上都是一致的。(3)在网络分区的情况下,两个或多个节点可以作为主节点并发地写入共享文件。PolarFS 可以确保只有真正的主节点成功服务,防止数据损坏。更多技术细节见[5]。

     

     

    4.2 POLARDB-X:分布式 OLTP 数据库

    POLARDB 可以很好地扩展到多达数十个节点(由于底层 RDMA 网络的限制),但这不足以支持大量数据和事务的高度并发工作负载,例如在单日购物节上发现的数据和事务。因此,我们扩展了 POLARDB 并构建了 POLARDB-X,这是一个分布式的无共享 OLTP 数据库,以支持水平扩展POLARDB-X 结合了共享存储和无共享架构。与在每个分片上使用单个节点实例的标准无共享体系结构相比,这种设计的好处是,由于共享存储体系结构引入的扩展能力,每个分片现在可以存储和处理更多的数据和事务。因此,对于相同数量的数据和/或事务处理需求,与标准的共享系统相比,混合体系结构需要的碎片数量要少得多;这反过来又减少了处理复杂且昂贵的分布式事务处理和分布式提交的机会。因此,它支持海量数据上的高并发事务,并通过 Parallel Paxos 协议 X-Paxos 确保 cross-AZ 和跨区域事务的一致性。

     

    4.2.1 系统设计

    图5 显示了 POLARDB-X 的体系结构,其中关系数据被划分为多个 POLARDB 实例,并由分布式关系数据库服务(DRDS)管理。DRDS 接受 SQL 查询或事务,解析并优化它们的计划,最后将它们路由到相应的 POLARDB 实例以供执行。如前所述,每个 POLARDB 实例由一个主节点和多个只读节点组成。每个读节点都作为主节点的一个副本,共享 PolarFS 上的相同存储,PolarFS 又位于 PolarStore(阿里巴巴的块存储系统)上。 POLARDB 节点中,有一个用于从 DRDS 推送的查询计划的计划执行器(用于事务处理的事务服务)和一个 X-Engine(阿里巴巴基于 LSM 树的 OLTP 存储引擎)。

     

    4.2.2 X-Engine

    我们发现,在阿里巴巴和我们的大企业客户处理此类交易时,必须解决三个关键挑战:(1)海啸问题——随着大型销售和促销活动的启动,交易量急剧增加(例如,阿里巴巴光棍节全球购物节出现了 122 次高峰),这给底层数据库带来了巨大的压力。(2)泄洪问题——大量的热记录很容易淹没系统缓冲区,如果缓冲区无法快速刷新,则会阻碍后续事务处理。(3)活动时快速移动问题——由于持续时间短的大量促销事件,记录的 "热度"(即热、、冷)频繁发生快速变化,这大大降低了缓存命中率。

    我们构建 X-Engine[10]是为了应对阿里巴巴电子商务平台所面临的上述挑战,因为交易处理性能的一个重要部分归结数据的持久性和从存储中检索的效率。X-Engine 利用多核处理器中的线程级并行性(TLP)来处理主存中的大多数请求,将写入与事务分离以使其异步,并将长写入路径分解为管道中的多个阶段,以提高总体吞吐量(decomposes a long write path into multiple stages in a pipeline in order to increase the overall throughput)为了解决泄洪问题,X-Engine 利用一种分层存储方法在不同层之间移动记录,利用了改进的 LSM 树结构[22,25]和优化的压缩算法。我们还将 FPGA 卸载应用于压缩。最后,为了解决当前快速移动的问题,我们引入了一个多版本的元数据索引,该索引以写时拷贝的方式更新,以加速分层存储中的点查找,而不考虑数据热度

    图6 显示了 X-Engine 的体系结构。X-Engine将每个表划分为多个子表,并维护LSM树、关联的元快照和每个子表的索引。X-Engine 为每个数据库实例包含一个重做日志。每个 LSM 树由驻留在主内存中的热数据层和驻留在 NVM、SSD、HDD 中的暖/冷数据层(进一步划分为不同的级别)组成,其中术语 Hot、Warm  Cold 指的是数据热度,表示应该放在相应层中的数据的理想访问频率。热数据层包含 一个活跃 Memtable  多个不可变的 Memtable,它们是存储最近插入的记录的跳板,以及缓冲热记录的缓存/冷数据层以树状结构组织数据,树的每一级都存储一个经过排序的区段序列。数据块打包记录块及其关联的筛选器和索引。

    X-Engine 利用 Redo 日志元快照索引支持事务处理的多版本并发控制(MVCC)。每个元快照都有一个元数据索引,用于跟踪快照中树的所有级别的所有内存表和扩展数据块。在相邻的一层或多个层次上存储一个或多个层次的硬盘驱动器。X-Engine 中的每个子表都有自己的热、和冷数据层(即 LSM 树),以面向行的格式存储记录。我们设计了一个多版本 Memtables 来存储不同版本的记录,以支持 MVCC。在磁盘上,元数据索引跟踪存储在扩展数据块中的所有记录版本。更多技术细节见[10]。

     

     

    4.3 AnalyticDB:实时 OLAP 数据仓库

    AnalyticDB 是一个实时的 OLAP 数据库系统,设计用于 PB 级的高并发、低延迟和实时分析查询。它从 3 个节点运行到 2000 多台物理机,并作为一个数据库服务在阿里云上提供相应的服务。它服务于电子商务、金融科技、物流、公共交通、气象分析、娱乐等多个业务领域的企业客户,以及阿里巴巴集团内部的业务运营。

    最近的著作[28,14,15,32,11]总结了设计 OLAP 系统的主要挑战:实现低查询延迟、数据新鲜度、灵活性、低成本、高可扩展性和可用性。与这些工作相比,来自我们应用场景的大规模分析工作负载将 AnalyticDB 提升到更大的规模:10PB+ 数据、数十万个表和数万亿行,这对 AnalyticDB 的设计和实现提出了重大挑战:1)今天的用户面临比以往任何时候都更复杂的分析场景,但仍然对低查询延迟抱有很高的期望。尽管来自不同应用程序的查询是多样和复杂的,但它们通常不能容忍花费很长时间的查询。2)新兴的复杂分析倾向于结合不同类型的查询和数据。超过一半的用户数据具有复杂的数据类型,例如文本、JSON 字符串或 vector。一个实用的数据库应该能够有效地支持对具有复杂类型的异构数据的查询。3)在以低延迟处理实时查询的同时,系统还需要每秒处理数千万个在线写入请求。在同一进程路径中读写数据的传统设计不再适合这种情况。应该考虑在查询延迟、写入吞吐量和数据可见性之间进行仔细的设计。

    为了解决这些挑战,我们用几种新颖的设计构建了 AnalyticDB。首先,AnalyticDB 嵌入了一个高效的索引引擎。在这个引擎中,索引建立在每个表中的所有列上,以显著提高复杂查询的性能。我们进一步提出了一种基于运行时过滤器比率的索引路径选择机制,以避免索引滥用导致的性能下降。由于在关键路径中更新大型索引的成本过高,因此索引是在非高峰时段异步构建的。我们还维护了一个轻量级的排序索引,以最小化异步索引构建对涉及增量数据(即,在当前一轮索引构建开始之后写入的数据)的影响。

    其次,我们设计了底层存储布局,以支持结构化数据和其他复杂类型数据的行列混合存储。特别是,我们使用快速顺序磁盘 I/O,因此无论是 OLAP 样式还是点查找工作负载(OLAP-style or point-lookup workloads),其开销都是可以接受的。我们进一步在存储中加入了复杂的数据类型(包括索引),以提供与结构化数据一起搜索资源(即JSON、vector、text)的能力。

    第三,为了支持高吞吐量写和低延迟查询,我们的系统遵循一种将读写解耦的体系结构,即分别由写入节点和读取节点提供服务。这两种类型的节点彼此隔离,因此可以独立伸缩扩展。特别是,写节点会持久地向盘古(阿里云上的一个可靠分布式存储)发送写入请求。为了确保服务查询时数据的新鲜,在读取节点上应用版本验证机制,这样就可以看到以前在写节点上处理的写操作。

    第四,为了进一步提高查询延迟和并发性,我们在 AnalyticDB 中增强了优化器和执行引擎,以充分利用我们存储和索引的优势。具体来说,我们提出了一种基于存储的 SQL 优化机制,根据存储特性生成最优的执行计划,并在基于成本的优化器(estimation in cost based optimizer)中提出了一种有效的基数估计实时采样技术。此外,我们还设计了一个高性能的用于混合存储的矢量化执行引擎,可提高计算密集型分析查询的效率。

    系统架构如 图7 所示。AnalyticDB 中主要有三种类型的节点,即协调器、写入节点和读取节点Coordinator, Write Node and Read Node)。协调器从客户机连接收集请求(包括写入和查询),并将它们分派到相应的写入和读取节点。写入节点负责处理写入(如INSERT、DELETE、UPDATE)以及将 SQL 语句刷新到盘古中以实现持久性。读取节点负责处理查询(例如SELECT)。通过这种方式,写和读节点彼此解耦。伏羲(阿里云上的资源管理器和作业调度器)利用所有这些节点上的可用资源为异步任务执行提供计算工作。此外,AnalyticDB 还提供了一个在计算工作上运行的通用管道模式执行引擎。以列块为单位的数据通过系统从存储器流向客户机。所有的数据处理都在内存中,并且在网络的不同阶段之间通过管道传输。这种流水线工作流使 AnalyticDB 能够以高吞吐量和低延迟服务于用户的复杂查询。更多技术细节见[33]。

     

     

    4.4 SDDP:自驱动数据库平台

    为了管理阿里云上众多的数据库实例,我们搭建了一个自的数据库管理平台 SDDP(Self-Driving database platform)。该平台收集所有运行数据库实例的实时统计信息,并使用机器学习和统计方法来优化实例和提供资源。

     

    4.4.1 系统设计

    图8 显示了 SDDP 的体系结构。混合云数据库管理(HDM)层从数据库实例收集 SQL 和度量,并将它们存储在时间序列数据库(TSDB)中。同时,HDM 检测数据库状态并将这些信息与控制器同步。数据库状态通常由 DDL 操作更改。例如,我们可以使用 ALTER TABLE t1 HOTCOLD='SMART' 将表设置为智能模式并自动分离热/冷数据(第4.4.3节)。HDM 还分配控制器来驱动机器学习任务,例如参数调整(第4.4.2节)、资源调度和异常检测。控制器将这些任务调度到模型训练平台(MTP,Model Training Platform)。MTP  TSDB 检索数据,包括 SQL 和衡量指标,并使用不同的模块来完成相应的作业。结果将由控制器传回 HDM 并应用于数据库实例。

     

    4.4.2 缓冲区大小调整

    缓冲池是 OLTP 数据库的一个关键资源,它作为一个数据缓存空间来保证理想的系统性能。对阿里巴巴超过 10000 个实例的 OLTP 数据库集群的实证研究表明,缓冲池平均消耗每个实例 98% 的内存空间。数据库管理员(通常基于固定的数据库配置和经验)一致推荐。这种手动过程既不高效也不有效,甚至不适用于大型云集群,尤其是当工作负载可能在单个数据库实例上动态变化时。

    为此,我们构建了 iBTune[27],个性化的缓冲区优化,以自动减少任何单个数据库实例的缓冲区大小,同时仍保持其响应时间的服务质量,而不依赖 DBA 来设置预定义的级别。我们利用未命中率和缓冲池大小之间的关系来优化内存分配。我们的模型利用类似实例中的信息。同时,我们设计了一个新的双深度神经网络,利用实例对的测量值来预测响应时间的上界。到目前为止,iBTune 已经部署在 SDDP 上,并应用于 10000 多个数据库实例。我们成功地将内存消耗减少了 17%(≥ 27TB),同时仍然满足我们多样化业务应用所需的服务质量。

    图9 显示了 iBTune 的体系结构和工作流的概述。有四个关键组件:数据收集、数据处理、决策和执行。iBTune 工作流形成了一个封闭的循环,因为数据首先从 DBMS 内核收集、处理并用于训练,然后生成的模型再次应用于 DBMS。在数据收集中,我们使用定制的代理从 DBMS 收集各种数据库衡量指标和日志。收集了 1000 多个指标。代理位于 DBMS 外部,以避免 DBMS 内核不必要的性能开销。所有的衡量指标和日志都以一秒的粒度收集并输入到消息队列中。在数据处理中,流处理系统从消息队列中读取数据,并执行某些数据操作/标准化操作,如规范化、聚合和日志转换。然后,处理后的衡量指标和日志存储在分布式数据存储系统中,用于分析和模型训练。在决策中,我们提出了一种新的预测 RT 和计算新的 BP(缓冲池)大小的方法。如果预测的 RT 满足要求,计算出的新 BP 大小将被发送到执行组件(execution component),该组件包含一个计划器和一个调度程序(planner and a scheduler)。为了处理大量的数据库实例,Action Planner 的目标是为成千上万个操作制定一个全局高效、无冲突的执行计划。它包括不同操作类别之间的优先级设置、同一实例的操作合并、操作冲突的检测与解决、canary 执行策略等。它最终将多个操作序列输出到 Action Scheduler。更多技术细节见[27]。

     

    4.4.3 其他场景

    除了缓冲区大小调整外,我们还探索了其他自治设计,如慢 SQL 优化、空间缩减、冷热分离、ML 优化器、故障检测和恢复。以热/冷分离为例,通过数据的热度(范围)来区分 X-Engine(第4.2.2节)中的水平。一个区段的热度是通过它在最近的窗口中的访问频率来计算的。当执行压缩时,X-Engine 使用阈值指定的数量选择最冷的数据块,例如 500 个数据块,并将这些数据块推到更深的级别进行压缩。通过这样做,X-Engine 保持了上层的热数据块(warm extents)和深层的冷数据块(cold extents)。但是这种方法不能很好地处理动态工作负载。例如,当前块的存取频率较低时,此算法会将来可能会变热的块视为冷数据。为此,我们研究了基于机器学习的算法来识别合适的热度范围。直觉是,除了范围之外,我们还使用行级别(record)作为粒度来推断热度(warm/cold)。如果在最近的窗口中从未访问过某个记录,则该记录被标识为处于 cold。否则,它被认为是 warm。因此,热度辨识转化为二元分类问题,并可使用分类模型(例如使用随机森林或基于神经网络的方法)来解决。

     

     

    5应用和操作

    在阿里云上运行的数据库实例已近 50 万个,既支持阿里集团内部业务运营,也支持外部客户业务应用。通过利用我们的云原生数据库系统,我们成功地为大量复杂的应用程序场景提供服务。

    POLARDB。POLARDB 在阿里云上的人数增长迅速。它为金融科技、游戏和娱乐、教育和多媒体等不同行业的领先公司提供服务。许多应用程序选择迁移到 POLARDB,因为它们的自部署数据库支持的事务处理速率有限。例如,一个应用程序在 MySQL 实例中,在高峰时间会增加 5 倍的延迟和频繁的事务失败。POLARDB 有助于将所有事务延迟保持在 1 秒之内,并将峰值吞吐量提高 3 倍。另外,一个 POLARDB 实例能够在 5 节点复制的 MySQL 集群上保持相同的查询性能,并减少经验丰富的 DBA 所需的工作。在大多数情况下,它可以将数据库的总体拥有成本(TCO)降低50-80%。

    POLARDB-XPOLARDB-X 已应用于阿里巴巴的许多性能为主和成本敏感的商业领域中。例如,2018年光棍节全球购物节开始时,我们处理的交易量增加了 122 倍,每秒处理多达 49.1 万笔销售交易,相当于每秒超过 7000 万笔数据库交易。为此,已经在线部署了 2000 多个 POLARDB-X 节点。随着 GMV(总商品量)的快速增长,管理 OLTP 数据库和维护底层服务器的成本迅速上升,这是阿里巴巴面临的一大挑战。为了降低成本,我们在阿里巴巴的许多业务中用 POLARDB-X 替换了 MySQL,这些业务利用了降级的硬件(例如,CPU 核数和存储量更少),同时保持了相同的 QPS/TPS 级别。在许多情况下,我们设法将数据库的总体拥有成本降低了50%。

    AnalyticDB。AnalyticDB 已经在阿里云 2000 多个节点上运行。它服务于广泛的商业领域,如电子商务、金融科技、物流、公共交通和娱乐。基于 AnalyticDB,我们扩展了一个端到端的解决方案,涵盖了从数据采集到数据可视化的整个分析途径。与其他解决方案相比,我们的客户能够无缝构建在线分析服务,同时降低总成本。AnalyticDB 帮助应用程序更好地利用其数据:对万亿级数据的即时多维分析和业务探索可以在毫秒内完成;用户可以通过调用内置函数和模块来定义和启动其分析任务;在许多情况下,可视化新获取的数据的端到端延迟减少到小于一分钟;并且不需要客户手动操作来维护服务。

    SDDP。SDDP 已经被用于管理阿里巴巴的数万个数据库实例。我们通过使用多个自主智能模块,成功地节省了大量集群资源:SQL 优化模块检测并优化了 2740万 条低效 SQL 请求;空间优化模块释放了 2.26PB 的存储空间(如通过去碎片化和删除无用的索引/表);iBTune 模块在保证服务质量的同时,节省了 27TB 的内存空间;全局工作负载调度模块将磁盘利用率从 46% 提高到 63%。

     

     

    6、结论

    云原生数据库系统是一个日益重要的研究和开发课题。它为数据库社区和行业带来了许多新的技术挑战和新的机遇。在阿里云内部,我们分享了阿里云在本地和本地数据库建设方面的丰富经验和教训。考虑到云技术的快速发展,云原生数据库系统在未来的道路上将变得更加关键,并为支持下一代云应用开辟新的令人兴奋的研究方向和工程挑战。

     

    原论文中的声明:

    本作品根据 Creative Commons AttributionNoDerivatives 4.0 国际许可证授权。要查看此许可证的副本,请访问http://creativecommons.org/licenses/by-nc-nd/4.0/。对于本许可证涵盖范围以外的任何用途,请通过电子邮件获得许可info@vldb.org。版权归所有人/作者所有。授权 VLDB 基金会出版权。

    展开全文
  • 云原生数据库可以说是当下最火的产品技术形态之一。火到什么程度?很多为了云而云的数据库产品也号称自己是云原生的。 概念大火的同时也让许多门外人打出了一串问号: 云原生数据库到底是怎么一回事儿? 它怎么就...

    微信图片_20200915094148.gif

    微信图片_20200921091138.png

    云原生数据库可以说是当下最火的产品技术形态之一。火到什么程度?很多为了云而云的数据库产品也号称自己是云原生的。

    概念大火的同时也让许多门外人打出了一串问号:

    云原生数据库到底是怎么一回事儿?
    它怎么就云了、怎么就原生了?
    什么是云原生?
    云原生数据库又有什么用?

    所有的疑惑汇成一句:“你说的这个云原生数据库……它厉害么?”

    先说小偶的结论:**云原生数据库厉害,而且很厉害。**那么它究竟厉害在哪儿呢,咱们还得先从云原生说起。
     

    到底什么是云原生?

    微信图片_20200921091149.png

    直到今天,关于云原生的定义仍然没有一个确切和统一的说法。

    云原生这一概念的提出者** Matt Stine 于2017年将云原生归纳为模块化、可观察、可部署、可测试、可替换、可处理**6特质。

    而云原生领域影响力最大最有话语权的组织CNCF,他们给出的定义则是这样的:

    云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API

    这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

    CNCF,全称为Cloud Native Computing Foundation,中文译为“云原生计算基金会”


    CNCF,全称为Cloud Native Computing Foundation,中文译为“云原生计算基金会”

    概念众说纷纭,而且又都使用了大量的技术名词去描述,难免让人看的一头雾水,不得要领。我们可以试着从字面意思来解读,以此揭开一些云原生的面纱。

    云原生中的“云”表示存在于云中,而不是传统的部署于本地。比如云盘中的文件就在云中,而不是存储在用户电脑的硬盘中。“原生”则代表着应用从设计环节便考虑到云环境的因素,为云而设计,在云上运行。

    也就是说云原生是生在云上,长在云上,也应用于云上,这么一个足以称之为“根正苗红”的技术。

    微信图片_20200921091200.jpg

    了解了云原生,接下来让我们看看云原生数据库拥有怎样的神通,它因何而火?

     

    云原生数据库应该长什么样?

    云原生技术对于数据库产品的意义之一,便是它有利于构建和运行可弹性扩展的应用。也就是说,云原生数据库具备更好的弹性扩展能力。因为云原生数据库拥有以下这些特征。

    首先是普遍可访问高可用性。因为云原生数据库是完全存在于云上的,所以它可以随时随地的从多前端访问,提供云服务的计算节点。因其集群部署在云上,所以单点失败对服务的影响特别小。而且当需要升级或更换服务的时候,可以对节点进行不中断服务的逐渐升级。

    微信图片_20200921091208.jpg

    其次是高扩展性可迁移性。云原生数据库会与底层的云计算基础设施分离,所以能够灵活及时的调动资源进行扩容和缩容,以从容应对流量激增可能带来的压力,以及流量低谷期因资源过剩造成的浪费。也正是因为能够灵活扩缩容,云原生数据库也具备很强的可迁移性,我们甚至可以粗暴的理解为在新的位置扩容100%又在旧的位置缩容全部的50%。

    此外,基于高扩展性、高可用性以及可迁移性等特征,云原生数据库还具备可监控性安全性的特征。

    微信图片_20200921091212.jpg

    一方面黑箱状态下无法保证及时处理扩容、节点故障等需求和问题;另一方面全盘部署在云上且各服务之间相互独立,可以对应用或服务提供更多层的安全防护和实现许多新的容错服务。

    最后是演进式设计快速迭代。云原生数据库中的各项服务之间是相互独立的,个别服务的更新并不会对其他部分产生不利影响,而不是一旦出了问题就只能全场熄火。此外,云原生的研发测试和运维工具是高度自动化的,这使得应用的更新会更加快速频繁。

    将网络资源和云更好的融合在一起,处处独立而又自然联系着,才能更充分的发挥数据库上云的优势,得到更高的效率。

     

    怎样才算一个好的云原生数据库?

    如果一款数据库产品具备了存储和计算的完全分离以及执行引擎的完全弹性这两点,那么它就能称得上真正发挥了上云的优势,就可以将数据和云更好地融合在一起,就可以说自己做好了云原生。

    微信图片_20200921091217.png

    拿小偶家的核心产品OushuDB来说,作为可以原生运行在云平台中的并行数据仓库引擎,它就做到了存储和计算的完全分离

    存储和计算的完全分离真正实现了不把所有的鸡蛋放在一个篮子里,而不是像一些仅仅声称自己是云原生的数据库产品,实质上是把两个篮子绑在一块或者在篮子中插了一块隔板而已。

    实现存储和计算的完全分离,不仅能使数据库产品在安全性上有巨大提升,而且还是实现产品执行引擎完全弹性的重要基础之一

    由于OushuDB的执行引擎具备完全弹性,所以它可以很容易很方便的做动态的缩容和扩容,无论是存储节点还是计算节点需要增加就可以马上增加需要减少就可以马上减少,可以动态的把计算派遣到数据所在的位置。

    这就让产品的性能和功效真正成为了完美的革命一块砖,哪里需要哪里搬。而且是需要多少就可以搬多少,不需要那么多的时候还可以把多余的砖头收回去,不需要找个地儿堆着。避免了小马拉大车或者高射炮打蚊子这种尴尬情况的发生。

    也正是因为具备了这两个特点,OushuDB才算得上是原生运行在容器云平台里的一个分布式数据库

    微信图片_20200921091224.jpg

    真正的云原生数据库就应该像城市自来水系统那样,无论你在哪里,只要拧开水龙头,就可以随意取水使用,只需要事后按用量交水费就可以了。

    不然的话,如同那些为了上云而上云的产品,本质上是自来水龙头接在了楼旁的水塔上,水用完了要等着水塔下次补水。水不够用,想换个大水箱,还得考虑水塔能不能承受得住?要不要连水塔主体一块盖个新的?这样的自来水又和挑水回家存在缸里又有什么差别呢?

    云原生在数据库上的应用并不会改变云和数据库本身的状态,但它的应用让云变成了更理想的云,也让数据库上云有了货真价实的意义。

    聊了这么多,那升华了数据库的云原生究竟有多厉害呢?用一个套娃行为来说就是:

    2011年,Netscape公司的创始人马克·安德森说:“软件正在吞噬事件”;
    而后在2016年,OpenStack基金会创始人Jonathan·Bryce 补充说:“世界的一切源于开源”;
    近几年来,云计算又用极快的速度扛起了指引未来方向的大旗;
    而在云计算概念日趋清晰且细化的今天,只有云原生才是那个能号令天下的宝刀屠龙。
     


               

                                                偶 数 科 技


    ⌈偶数科技⌋是一家领先的AI和大数据产品、解决方案提供商,致力于赋能全球各行业客户。公司的愿景和使命是 “让人类只为兴趣而工作”。偶数科技的产品已在金融、电信、制造、公安、能源和互联网等行业得到广泛的部署和应用。目前⌈偶数科技⌋已经获得多轮国际顶级VC的投资,是微软加速器成员企业,并入选美国著名商业杂志《快公司》“中国最佳创新公司50”榜单。
     

    drawing

    展开全文
  • 数据库技术的发展与变革方兴未艾,NewSQL的出现,只是将各种所需技术组合在一起,而这些技术组合在一起所实现的核心功能,推动着云原生数据库的发展。在上一篇文章《关系型数据库尚能饭否?NoSQL、NewSQL谁能接棒?...
  • 简介:11月18日,阿里云宣布推出云原生数据库备份DBS。DBS是阿里云提供的低成本、高可靠的云原生数据库备份平台。DBS提供无限容量的备份存储、秒级应急恢复和恢复演练,并借助秒级沙箱实例和备份数据查询激活冷数据...
  • 云原生数据库 云—风靡一时,各地的企业都采用新策略将其应用程序和系统迁移到云中。 但是,仅将云视为天空中具有成本效益的数据服务器的公司就失去了其真正的优势:作为快速创新的平台。 为什么这个这么重要? ...
  • 9月21日,2018杭州·云栖大会上,阿里云向数据库研发人员发起首届POLARDB数据库性能大赛,希望能够促进国内数据库领域的交流,一起推动云原生数据库的发展。 POLARDB是阿里云自主研发的云原生数据库,是阿里云面向...
  • 云原生数据库Redis 6 技术概述技术创新变革未来目录产品形态新品特点CONTENT产品能力基于k8s的管控产品形态规格家族独享型共享性专属集群引擎版本社区版企业版部署架构基础版高可用集群版Redis 6.0新特性安全能力SSL...
  • 活动详情作为第一个进入Gartner全球数据库领导者象限的中国数据库,阿里云数据库在数据管理及数据分析领域都拥有深厚的技术积累。云原生数据库PolarDB既解决了传统数据库容量有限、扩缩...
  • 11月18日,阿里云宣布推出云原生数据库备份DBS。DBS是阿里云提供的低成本、高可靠的云原生数据库备份平台。DBS提供无限容量的备份存储、秒级应急恢复和恢复演练,并借助秒级沙箱实例和备份数据查询激活冷数据。DBS...
  • 4月17日(巴黎时间)阿里云POLARDB走出国门,亮相ICDE2018,并同步...以下为阿里云资深技术专家蔡松露演讲实录:现在我给大家介绍一下我们的云原生数据库-POLARDB。大家可能要问到底什么是“云原生数据库”,云原...
  • 云原生TP(事务型)数据库我准备重点分析2款典型的云原生数据,AWS的Aurora和阿里的polardb,我把以aurora为代表的称之为redo log复制流,把polardb为代表的称之为文件复制流。之所以这么区分的原因在于他们实现...
  • 阿里云原生数据库POLARDB压力测试报告 POLARDB介绍 POLARDB是阿里云ApsaraDB数据库团队研发的基于云计算架构的下一代关系型数据库,其最大的特色是计算节点(主要做SQL解析以及存储引擎计算的服务器)与存储节点...
  • 11月22日消息,腾讯云宣布新一代自研云原生数据库CynosDB正式发布。作为腾讯云在产品矩阵上的重要布局,CynosDB融合了传统数据库、云计算和新硬件的优势,支持无限量存储、百万级查询和秒级的故障恢复,与高性能形成...
  • Oracle的云原生数据库,可帮助金融、医疗、制造等大型企业在数小时内完成业务迁移,10TB数据备份只需10分钟。 企业业务迁移上云已成趋势,但不少大企业的核心业务依旧存放在传统商业数据库中,这些数据一般达数百TB...
  • 前言多年以来,各云数据库厂商基于传统的单体数据库为客户提供了云上的数据库服务,满足了客户...云原生数据库的主要特点是: 更好的弹性:占用空间随数据大小自动扩缩容,甚至可以做到计算资源随工作负载自动扩缩容...
  • 《创新、进化、竞合、开放——阿里云自主研发云原生数据库POLARDB的开拓之路》 阿里云ApsaraDB数据库 高级产品专家 贺军 前言 数据库作为信息时代平台科技(CPU/芯片、PC/手机操作系统、数据库)最复杂最核心的...
  • 【前言】Taurus是华为对标AWS Aurora的一款重磅云原生数据库。其设计思想是Log-as-database以最小化网络IO,采用计算存储分离的架构。Taurus的市场定位是OLTP的企业级市场以及高端MySQL客户,但兼顾中小客户。技术...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,904
精华内容 1,161
关键字:

云原生数据库