5月10日，弗若斯特沙利文（Frost & Sullivan，简称“沙利文”）联合头豹研究院发布《2021年中国分布式数据库市场报告》。报告显示，在中国市场，分布式数据库发展正处于“爆发期”。从专利申请的数据角度出发，中国的分布式数据库相关专利申请量从2012年的全球占比22%爬升至2021年的76%，中国已经成为了全球分布式数据库的技术创新中心。通过对2021年数据库市场进行持续跟踪和调研，沙利文指出，数据库作为大多数信息系统的基础设施，向下发挥硬件算力，向上承接上层应用，各式各样的数据库产品分别满足不同的业务需求。数据库的速度、易用性、稳定性、扩展性、成本都对企业的基础业务与增长弹性至关重要。对于数据库行业的发展趋势，沙利文认为，在云上建设数据库服务，设计出以基础云先行，全线适应云特点的云原生数据库尤为重要。腾讯云自主研发了新一代高性能、高可用数据库TDSQL-C，100%兼容MySQL和PostgreSQL，实现超百万级QPS的吞吐能力。展望未来，数据库的发展动力依然来自数据存储规模和性能要求，以及硬件的发展，未来的数据库技术还将满足AI对数据管理的需求。《2021年中国分布式数据库市场报告》 下载  https://www.modb.pro/doc/60894文章来源：https://baijiahao.baidu.com/s?id=1732412452502027034&wfr=spider&for=pc

日前，百易存储研究院、中国计算机学会信息存储专委会、中国计算机行业协会信息存储与安全专委会、DOIT 正式发布《2022分布式存储市场调研报告》。报告指出，中国分布式存储市场规模虽然无法准确回答，但市场发展的趋势是明确和清晰的，未来市场潜力巨大。 事实上，分布式存储发展至今，市场上并没有一个能够被广泛接受并引用的定义。百易存储研究院认为用传统存储、传统阵列或者传统磁盘阵列的表述更为便于理解。对于中国分布式存储市场规模有多大？报告指出，这其实也是一个很难准确回答的问题。“一来分布式存储市场参与的厂商很多，其中很多厂商不是上市企业，没有办法获得销售数据；二来分布式存储没有一个市场可以普遍接纳的定义和分类，会导致数据统计口径混乱，例如分布式存储是否包括去中心化存储、是否包括超融合、是否包括云存储、内涵与界定的不同，市场规模自然也不一样。”IDC 给出的统计数据表明：2021年中国存储市场规模为42.9亿美元，其中，软件定义存储14亿美元，占比 26.1%；超融合为12亿美元，占比 20.3%。本报告中的分布式存储包括 SDS、HCI 两个部分，总体市场规模26亿美元，占比46.3%。配合本次调查报告的调查问卷中，受访者也对市场进行了估算，结果从10亿美元～ 1000亿人民币不等；超融合市场规模从30亿美元～300亿人民币不等；云存储市场的规模50亿（美元）～ 1800亿（人民币）规模不等。差距和出入非常大，体现了不同消费者的不同理解。目前百易存储研究院没有官方的渠道和数据对存储市场规模进行统计，但是可以肯定，随着数据量的快速增长，数据存储市场会呈现一种快速增长的趋势，IDC 给出的预计，市场增长速率为 54.2%，未来发展不会低于这个增速。在目前的情况下，分布式市场的规模也是仁者见仁、智者见智，但是无论如何，市场发展的趋势是明确和清晰的，未来市场潜力巨大。《2022分布式存储市场调研报告》下载 :https://www.modb.pro/doc/60979文章来源：C114通信网 https://g.pconline.com.cn/x/1500/15002204.html

电脑可以没日没夜地运行，但早先的网站却做不到24*7小时的运营。现在看来我们都不可思议。然而，在互联网出现之前，24*7的高可用性这个提法并不存在。那时我们对可用性是有期待，但我们却压根不会认为这是我们有权要求获得的东西。我们只在需要时使用计算机；更多的时候我们其实本来就不太有机会使用它，自然也很少会让计算机一直开着以便它可以随时响应我们。随着互联网的发展，那些以前在当地时间凌晨 3 点不常见的请求变得越来越多，也让这个时间段在全球各地都变成了黄金营业时间，因此确保计算机能够服务这些请求变得非常重要。然而，许多系统仅依靠一台计算机来处理这些请求——单点故障——我们都知道这是个很糟糕的事实。为了保持正常运行，我们需要在多台可以满足我们需求的计算机之间分配负载。然而，分布式计算有着非常明显的优势：特别是同步和容忍系统内的部分故障（容错）。每一代工程师都在迭代这些解决方案，以满足这个时代的需求。数据库领域是如何引入分布式的，这件事很多人并不清楚前因后果，因为这本身就是一个比其他领域发展缓慢得多的难题。当然，软件在本地数据库中会记录一些分布式计算的结果，但数据库本身的状态只能保存在单台机器上。为什么？因为跨机器的状态复制是非常困难的。在这篇文章中，我们来看看分布式数据库在历史上是如何处理容错的，以及高可用性是什么样子的。另外，我们还会介绍高可用性系统的几种不同类型。高可用性数据库有哪些类型?高可用性数据库一般情况下可分为两类，目前出现了第三类，而且变得越来越普遍：主-从数据库：数据库有一个主节点处理请求，另外一个是热备节点（即从节点），一旦主节点故障后就会投入使用主-主数据库：数据库具有多个主节点，这些节点将数据分片后分别对数据库进行写操作多主数据库：数据库具有至少三个主节点，这些节点都可以对集群中的任何数据执行读写操作而不会产生冲突。什么是主从可用性?主从可用性意味着数据库有一个主节点处理请求，另外一个是热备节点（即从节点），一旦主节点故障后就会投入使用。主从可用性模型基于两节点概念，即一个节点接收所有请求，然后再将数据复制到其追随者。在过去，数据库在单台机器上运行。它只有一个节点，处理所有的读写操作。没有所谓的“部分失败”；数据库不是成功启动就是失败停服。对互联网来说，单节点数据库的完全不可用是一个双重问题；首先，计算机全天候被访问，因此停机更有可能直接影响用户；其次，通过将计算机置于持续的访问请求之下，它们更有可能出现故障。很明显，这个问题的解决方案是使用多台计算机来共同处理请求，这也是分布式数据库起步的契机所在。生活在单节点世界中，最自然的解决方案是继续让单个节点提供读写服务，并将其状态简单地同步到辅助的备份机器上——因此，主从复制诞生了。主从模式是通过即时备份实现高可用性的早期步骤。在主节点发生故障的情况下，您可以简单地将流量引导到从节点，从而将其提升为主节点。只要有可能，您就会用一台新的备份机器替换停机的服务器（并希望主节点在此期间不会出现故障）。首先，从主节点到从节点的复制是一个同步过程，即在从节点确认之前，数据转换并不会被提交。但是，目前还不清楚如果从节点出现故障该怎么办。如果备份系统不可用，整个系统宕机当然没有意义——但是只要使用同步复制，就会发生这种情况。为了进一步提高可用性，可以改为异步复制数据。虽然它的架构看起来是一样的，但它能够处理主节点或从节点的宕机，而不会影响数据库的可用性。虽然异步主从模式是向前迈出的又一步，但仍然存在明显的缺点：当主节点宕机时，任何尚未复制到从节点的数据都可能丢失——即使客户端已经确认了数据完全提交。依靠单台机器来处理流量，仍然受限于单台机器的最大可用资源。对五个 9 的高可用性追求扩展到多台机器随着互联网的普及，业务需求的规模和复杂性都在增长。对于数据库来说，这意味着它们需要能够处理比任何单个节点都多的流量，并且提供“始终在线”的高可用性成为一项任务。鉴于现在大量工程师拥有从事其他分布式技术的经验，很显然，数据库可以超越单节点的主从模式，将数据库分布在多台机器上。分片同样，我们可以从调整现有的系统起步，我们的工程师通过开发分片将主动复制调整为更具可扩展性的架构。在此方案中，您按某个值（例如行数或主键中的唯一值）拆分集群的数据，并将这些段分布在多个实例，每个实例都有一套主从节点。然后，您在由这些实例组成的集群前添加某种路由技术，以将客户端请求引导到正确的实例来处理。分片允许您在将工作负载分配到多台机器上，从而提高吞吐量，并通过容忍更多的部分故障和消除单点故障来创建更大的弹性。尽管有这些好处，但对系统进行分片是复杂的，并且给团队带来了巨大的运维负担。特意对碎片进行的统计可能会变得非常繁琐，以至于路由最终会渗入应用程序的业务逻辑。更糟糕的是，如果您需要修改系统分片的方式（例如模式更改），通常需要明显的（甚至是巨大的）工程量来实现。单节点主从系统也提供了事务支持（即使不是强一致性）。然而，跨分片协调交易的难度是如此的琐碎和复杂，许多分片系统是决定彻底放弃它们的。什么是主主可用性?主主可用性意味着数据库至少有两个主节点，它们对数据进行分片并执行对数据库的写入。主主可用性代表了从主从的演变，通过让集群中的节点提供读写服务，使数据库能够扩展到单台机器之外。考虑到分片数据库难以管理且功能不全，工程师们开始开发至少可以解决其中一个问题的系统。这时候出现的是仍然不支持事务的系统，但管理起来已经非常容易。随着对应用程序正常运行时间的需求不断增加，帮助团队满足其 SLA 的决定是很明智的。这些系统背后的动机是每个实例节点都可以包含集群的部分（或全部）数据，并为其提供读取和写入服务。每当一个节点收到写入请求时，它都会将更改传播到所有其他需要它的副本的节点。为了处理两个节点对同一个键值写入的情况，任何一个节点的转换在提交之前都会被送入冲突解决算法。鉴于每个站点都是“活跃的”，因此被称为主主。因为每台服务器都可以对其所有数据进行读写，所以分片更容易在算法上实现，并使部署更易于管理。在可用性方面，主主非常出色。如果一个节点发生故障，客户端只需重定向到另一个确实包含数据的节点。只要数据的单个副本处于活动状态，就可以为其提供读取和写入服务。虽然这种方案在高可用性方面非常出色，但其设计在一致性和数据正确性方面存在根本性的问题。因为每个实例节点都可以处理键值的写入（在故障转移场景中也是如此），所以它在处理数据时保持数据完全同步是非常困难的。该方案通常是通过冲突解决算法来调解实例之间的冲突，而该算法对如何“消除”不一致性的决策是粗粒度的。由于该解决方案是事后完成的，是在客户端已经收到有关程序的响应之后——并且理论上已经根据该响应执行了其他业务逻辑——主主复制很容易在数据中生成异常。然而，考虑到正常运行时间的溢价，停机成本被认为大于潜在异常的成本，因此主主成为主要的复制类型。大规模正确性共识和多活可用性主主似乎解决了基础设施面临的主要问题——提供高可用性。但它只是通过放弃事务来做到这一点，这使得系统在强一致性需求的满足上并不那么可信。例如，谷歌在其广告业务中使用了一个庞大而复杂的 MySQL 分片系统，该系统严重依赖 SQL 的表达能力来任意查询数据库。因为这些查询通常依赖二级索引来提高性能，所以它们必须与它们所派生的数据保持完全一致。最终，这个系统变得足够大，开始导致分片 MySQL 出现问题，工程师开始设想如何解决这样的问题：既要有大规模可伸缩的系统，又要提供业务所需的强一致性。主主缺乏事务支持意味着它不应该是一个可选项，因此他们不得不设计一些新东西。最终，他们用这样的一个系统解决了问题，这是一个基于共识复制的系统，既能保证一致性，又能提供高可用性。使用共识复制，写入被提议到一个节点，然后被复制到一些其他节点。一旦大多数节点确认写入，就可以提交。共识和高可用性这里的关键概念是，共识复制是介于同步和异步复制之间的一种机制：您可以指定任意数量的节点来进行同步，但这些节点是哪些并不重要。这意味着集群可以容忍少数节点宕机，而不会影响系统的可用性。（处理被关机服务器流量等的注意事项）然而，共识的代价是它需要节点与其他节点进行通信以执行写入。虽然您可以采取一些措施来减少节点之间产生的延迟，例如将它们放在同一个可用区中，但这需要和高可用性一起权衡考虑。例如，如果所有节点都在同一个数据中心，它们之间的通信速度很快，但如果整个数据中心离线，你的服务也不会独活。将您的节点分散到多个数据中心可能会增加写入所需的延迟，但却可以提高你的可用性，就算整个数据中心都离线了，你的应用也仍然在线。什么是多主可用性？多主可用性要求数据库至少具有三个活动节点，每个活动节点都可以对集群中的任何数据进行读写而不产生冲突。CockroachDB 实现了Google Spanner 论文中的大部分内容（但值得注意的是，它不需要原子钟），包括那些超越共识复制之外的特性，这些特性使可用性变得更简单。为了描述其工作原理并将其与主主区分开来，我们创造了术语多主可用性。主主 vs. 多主主主通过允许集群中的任何节点为其键值提供读写服务来实现可用性，但只有在提交写之后才将其接受的更改传播给其他节点。另一方面，多主可用性允许任何节点提供读写服务，但确保大多数副本在写入时保持同步，并且仅提供来自最新版本副本的读取服务。在高可用性方面，主主只需要一个副本即可同时用于读写，而多主则需要大多数副本在线才能达成共识（这仍然允许系统内部出现部分故障）。显然这些数据库在可用性方面的不同表现源于系统在对一致性方面处理的差异。主主数据库在大多数情况下都会努力工作写入数据，但是不能保证客户端现在或将来能够读取到该数据。而多主数据库仅在可以保证以后可以以一致的方式读取数据时才接受写入。回顾与展望在过去的 30 年中，数据库复制和可用性取得了长足的进步，现在已经支持全球范围内部署，感觉就像它们永远不会不受欢迎。该领域的首次尝试通过主从复制奠定了重要的基础，但最终，我们需要更好的可用性和更大的规模。在这个领域，业界发展出了两种主要的数据库类型：其中主从用于满足那些主要关注快速写入的应用程序，而多主则服务于那些对一致性有需要的应用程序。我们都期待有一天，我们可以利用量子纠缠并转向下一代数据库类型：可管理的分布式数据库。原文链接：​​https://www.cockroachlabs.com/blog/brief-history-high-availability/​

根据DB-Engines官网消息，4月，DB-Engines图数据库类目数量新增1个至37个，新入选者为国产数据库品牌星环科技StellarDB，至此共5家国产图数据库上榜DB-Engines，分别为Nebula Graph、HugeGraph、GraphBase、 Galaxybase和StellarDB。1、Nebula Graph：简介：Nebula Graph 一款开源、分布式图数据库，擅长处理超大规模数据集。 Nebula Graph 采用存储计算分离架构，支持水平扩展，利用 RAFT 分布式 concensus 协议来实现金融级的高可用，类 SQL 查询语言降低了 SQL 程序员迁移成本。Nebula Graph 是一款开源的分布式图数据库，擅长处理千亿个顶点和万亿条边的超大规模数据集。提供高吞吐量、低延时的读写能力，内置 ACL 机制和用户鉴权，为用户提供安全的数据库访问方式。作为一款高性能高可靠的图数据库，Nebula Graph 提供了线性扩容的能力，支持快照方式实现数据恢复功能。在查询语言方面，开发团队完全自研开发查询语言——nGQL，并且后续会兼容 OpenCypher 接口，让 Neo4j 的用户可无缝衔接使用 Nebula Graph。2、HugeGraph简介：HugeGraph 是一款易用、高效、通用的开源图数据库系统（Graph Database）HugeGraph 是一款易用、高效、通用的开源图数据库系统（Graph Database）， 实现了 Apache TinkerPop3 框架及完全兼容 Gremlin 查询语言， 具备完善的工具链组件，助力用户轻松构建基于图数据库之上的应用和产品。HugeGraph 支持百亿以上的顶点和边快速导入，并提供毫秒级的关联关系查询能力（OLTP）， 并可与 Hadoop、Spark 等大数据平台集成以进行离线分析（OLAP）。HugeGraph 典型应用场景包括深度关系探索、关联分析、路径搜索、特征抽取、数据聚类、社区检测、 知识图谱等，适用业务领域有如网络安全、电信诈骗、金融风控、广告推荐、社交网络和智能机器人等。本系统的主要应用场景是解决百度安全事业部所面对的反欺诈、威胁情报、黑产打击等业务的图数据存储和建模分析需求，在此基础上逐步扩展及支持了更多的通用图应用。3、GraphBaseGraphBase是一个图形数据库管理系统 (Graph DBMS)，旨在简化复杂数据图的创建和维护。复杂且高度连接的结构是关系数据库管理系统 (RDBMS) 面临的挑战。图数据库提供了更好的建模实用程序、性能和可扩展性。借助GraphBase，我们的目标是简化复杂数据结构的管理，让您的数据变得更加丰富。它可以成为内识。我们通过重新定义应如何管理图形数据来实现这一点。在GraphBase中。您将获得与“行和表”范式等效的图形，它使关系数据库如此易于使用。图是一个事务单元。可以通过多种方式切割、组合和操作大型或小型整图。4、Galaxybase简介：Galaxybase是中国自主知识产权的通用商业化分布式图数据库，目前世界最快、延展性最好，性能超美国同类竞品百倍。Galaxybase改变了传统数据存储的方式，以一种更为灵活的基于“对象”和其间“关系”的图数据结构，将分散的不同种类的原始数据连接在一起形成一个关系网络，打通数据孤岛，通过自然语言处理、机器学习、图挖掘等人工智能算法，提供用户从关系角度分析问题的能力，帮助其完成实时决策。Galaxybase作为第三代图数据库技术的代表产品，是国内首个成熟、通用、全自主知识产权的商业化图数据库。得益于底层自研数据存储和分布式并行处理架构，解决了大规模关联数据高效存储、查询、计算的难题，较现存同类技术有百倍性能提升，为企业打通数据孤岛、建立以推理为基础的人工智能，提供了从数据迁移、数据建模、数据存储、数据查询、数据运算到数据分析的一站式解决方案。5、StellarDB简介：Transwarp StellarDB是星环科技推出的一款为企业级图应用而打造的分布式图数据库，用于快速查找数据间的关联关系，并提供强大的算法分析能力。StellarDB克服了海量关联图数据存储的难题，通过自定义图存储格式和集群化存储，实现了传统数据库无法提供的低延时多层关系查询，在社交网络、公安、金融领域都有巨大应用潜力。Transwarp StellarDB是星环科技推出的一款为企业级图应用而打造的分布式图数据库，用于快速查找数据间的关联关系，并提供强大的算法分析能力。StellarDB克服了万亿级关联图数据存储的难题，通过自定义图存储格式和集群化存储，实现了传统数据库无法提供的低延时多层关系查询，在社交网络、金融领域都有巨大应用潜力。

FastDFS是一个开源的轻量级分布式文件系统，纯C实现，目前提供了C、Java和PHP API。功能包括：文件存储，文件同步，文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以中小文件（建议范围：4KB < file_size <500MB）为载体的在线服务。Fast DFS系统有三个角色：跟踪服务器(Tracker Server)、存储服务器(Storage Server)和客户端(Client)。client请求Tracker server 进行文件上传、下载，通过Tracker server调度最终由Storage server完成文件上传和下载，在底层存储上通过逻辑的分组概念，使得通过在同组内配置多个Storage，从而实现软RAID10。Tracker server：跟踪服务器，主要做调度工作，起到均衡的作用；负责管理所有的Storage server和group，每个storage在启动后会连接Tracker，告知自己所属group等信息，并保持周期性心跳。tracker上的元信息都是由storage汇报的信息生成的，本身不需要持久化任何数据，这样使得tracker非常容易扩展，直接增加tracker机器即可扩展为tracker cluster来服务，cluster里每个tracker之间是完全对等的，所有的tracker都接受stroage的心跳信息，生成元数据信息来提供读写服务，tracker根据storage的心跳信息，建立group==>[storage server list]的映射表。Storage server：存储服务器，主要提供容量和备份服务；以group为单位，每个group内部可以有多台storage server，数据互为备份。客户端上传的文件最终存储在storage服务器上，Storage server没有实现自己的文件系统，而是利用操作系统的文件系统来管理文件，可以将storage称为存储服务器。storage可配置多个数据存储目录，比如有10块磁盘，分别挂载在/data/disk1-/data/disk10，则可将这10个目录都配置为storage的数据存储目录。Client：客户端，上传下载数据的服务器，也就是我们自己的项目所部署在的服务器。FastDFS向使用者提供基本文件访问接口，比如upload、download、append、delete等，以客户端库的方式提供给用户使用跟踪服务器和存储节点都可以由一台或多台服务器构成，跟踪服务器和存储节点均可以随时增加或者下线不会影响线上服务，其中跟踪服务器中所有服务器是对 等，可以根据服务器压力情况随时增加或减少文件的上传Storage server会连接集群中所有的Tracker server，定时向他们报告自己的状态，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。上传的内部机制如下：选择tracker server当集群中不止一个tracker server时，由于tracker之间是完全对等无状态的关系，当集群中不止一个tracker server时，由于tracker之间是完全对等的关系，客户端在upload文件时可以任意选择一个trakcer。 选择存储的group 当tracker接收到upload file的请求时，会为该文件分配一个可以存储该文件的group，支持如下选择group的规则：Round robin，所有的group间轮询Specified group，指定某一个确定的groupLoad balance，剩余存储空间多多group优先选择storage server当选定group后，tracker会在group内选择一个storage server给客户端，支持如下选择storage的规则：Round robin，在group内的所有storage间轮询First server ordered by ip，按ip排序First server ordered by priority，按优先级排序（优先级在storage上配置）选择storage path当分配好storage server后，客户端将向storage发送写文件请求，storage将会为文件分配一个数据存储目录，支持如下规则：Round robin，多个存储目录间轮询剩余存储空间最多的优先生成Fileid选定存储目录之后，storage会为文件生一个Fileid，由storage server ip、文件创建时间、文件大小、文件crc32和一个随机数拼接而成，然后将这个二进制串进行base64编码，转换为可打印的字符串。 选择两级目录 当选定存储目录之后，storage会为文件分配一个fileid，每个存储目录下有两级256*256的子目录，storage会按文件fileid进行两次hash（猜测），路由到其中一个子目录，然后将文件以fileid为文件名存储到该子目录下生成文件名当文件存储到某个子目录后，即认为该文件存储成功，接下来会为该文件生成一个文件名，文件名由group、存储目录、两级子目录、fileid、文件后缀名（由客户端指定，主要用于区分文件类型）拼接而成文件的下载跟upload file一样，在download file时客户端可以选择任意tracker server。tracker发送download请求给某个tracker，必须带上文件名信息，tracke从文件名中解析出文件的group、大小、创建时间等信息，然后为该请求选择一个storage用来服务读请求。定位文件：客户端上传文件后存储服务器将文件ID返回给客户端，此文件ID用于以后访问该文件的索引信息。文件索引信息包括：组名，虚拟磁盘路径，数据两级目录，文件名。组名：文件上传后所在的storage组名称，在文件上传成功后有storage服务器返回，需要客户端自行保存。虚拟磁盘路径：storage配置的虚拟路径，与磁盘选项store_path*对应。如果配置了store_path0则是M00，如果配置了store_path1则是M01，以此类推。数据两级目录：storage服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件。文件名：与文件上传时不同。是由存储服务器根据特定信息生成，文件名包含：源存储服务器IP地址、文件创建时间戳、文件大小、随机数和文件拓展名等信息。知道FastDFS FID的组成后，我们来看看FastDFS是如何通过这个精巧的FID定位到需要访问的文件：通过组名tracker能够很快的定位到客户端需要访问的存储服务器组，并将选择合适的存储服务器提供客户端访问存储服务器根据“文件存储虚拟磁盘路径”和“数据文件两级目录”可以很快定位到文件所在目录，并根据文件名找到客户端需要访问的文件同步时间管理当一个文件上传成功后，客户端马上发起对该文件下载请求（或删除请求）时，tracker是如何选定一个适用的存储服务器呢？ 其实每个存储服务器都需要定时将自身的信息上报给tracker，这些信息就包括了本地同步时间（即，同步到的最新文件的时间戳）。而tracker根据各个存储服务器的上报情况，就能够知道刚刚上传的文件，在该存储组中是否已完成了同步。同步信息上报如下图：写文件时，客户端将文件写至group内一个storage server即认为写文件成功，storage server写完文件后，会由后台线程将文件同步至同group内其他的storage server。每个storage写文件后，同时会写一份binlog，binlog里不包含文件数据，只包含文件名等元信息，这份binlog用于后台同步，storage会记录向group内其他storage同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，所以最好能保证集群内所有server的时钟保持同步。storage的同步进度会作为元数据的一部分汇报到tracker上，tracke在选择读storage的时候会以同步进度作为参考。 比如一个group内有A、B、C三个storage server，A向C同步到进度为T1 (T1以前写的文件都已经同步到B上了），B向C同步到时间戳为T2（T2 > T1)，tracker接收到这些同步进度信息时，就会进行整理，将最小的那个做为C的同步时间戳，本例中T1即为C的同步时间戳为T1（即所有T1以前写的数据都已经同步到C上了）；同理，根据上述规则，tracker会为A、B生成一个同步时间戳。集成NginxFastDFS通过Tracker服务器,将文件放在Storage服务器存储，但是同组存储服务器之间需要进入文件复制，有同步延迟的问题。假设Tracker服务器将文件上传到了192.168.4.125，上传成功后文件ID已经返回给客户端。此时FastDFS存储集群机制会将这个文件同步到同组存储192.168.4.126，在文件还没有复制完成的情况下，客户端如果用这个文件ID在192.168.4.126上取文件,就会出现文件无法访问的错误。而fastdfs-nginx-module可以重定向文件连接到文件上传时的源服务器取文件,避免客户端由于复制延迟导致的文件无法访问错误。另外，使用nginx反向代理后，后端可以以HTTP请求的方式来访问文件资源。访问nginx反向代理+上传文件时的IDMooseFS原理MooseFS 是一款具有冗余容错功能的分布式文件系统。它把数据分散在多台服务器上，确保一份数据多个备份副本，对外提供统一的结构。对于标准的文件操作，MooseFS 表现与其他类Unix文件系统一致。 支持的通过文件系统特性：层次结构（目录树）兼容 POSIX 文件属性支持特殊文件符号链接和硬链接基于 IP 地址和密码的访问控制高可靠性(数据的多个副本存储在不同服务器)容量动态扩展（添加新硬盘或者服务器）可以回收在制定时间内删除的文件，类似回收站功能可以对整个文件甚至是正在被写入的文件创建文件快照MooseFS架构中的四种角色管理服务器（Master Server）：也称为元数据服务器，负责管理各个数据存储服务器，调度文件读写，回收文件空间以及恢复多节点拷贝。目前MFS只支持一个元数据服务器master，这是一个单点故障，需要一个性能稳定的服务器来充当元数据日志服务器（Metalogger Server）：负责备份管理服务器的变化日志文件，文件类型为changelog_ml.*.mfs，以便于在管理服务器出问题时接替其进行工作。元数据日志服务器是mfs 1.6以后版本新增的服务，可以把元数据日志保留在管理服务器中，也可以单独存储在一台服务器中。为保证数据的安全性和可靠性，建议单独用一台服务器来存放元数据日志。需要注意的是，元数据日志守护进程跟管理服务器在同一个服务器上，备份元数据日志服务器作为它的客户端，从管理服务器取得日志文件进行备份数据存储服务器（Chunk Server）：数据存储服务器是真正存储用户数据的服务器，负责连接管理服务器，听从管理服务器调度，提供存储空间，并为客户提供数据传输。在存储文件时，首先把文件分成块，然后将这些块在数据存储服务器之间互相复制客户端（Client）：通过FUSE内核接口挂载远程管理服务器上所管理的数据存储服务器，使共享的文件系统和使用本地文件系统的效果看起来是一样的首先客户端（Client）访问主服务器（Master），获取文件实体的位置等相关信息主服务器（Master）查询缓存记录，把文件实体的位置等相关信息发给客户端（Client）客户端（Client）根据拿到的信息去访问对应的存储实体数据的服务器（Chunk Server）存储实体数据的服务器（Chunk Server）把对应的数据返回给客户端（Client）客户端（Client）访问主服务器（Master），请求写入数据主服务器（Master）查询缓存记录，如果是新文件，则联系后面的数据服务器（Chunk Server）创建对应的chunk对象准备存放文件数据服务器（Chunk Server）返回创建chunk对象成功的消息给主服务器（Master）主服务器（Master）把文件实体的位置等相关信息发给客户端（Client）客户端（Client）访问对应的数据服务器（Chunk Server）写数据数据服务器（Chunk Server）之间进行数据同步，互相确认成功数据服务器（Chunk Server）返回成功写入信息给客户端（Client）客户端（Client）回报给主服务器（Master）写入结束MooseFS VS FastDFS对比说明 / 文件系统FastDFSMooseFS开发语言Cperl性能很高相对较差易用性安装简单，社区相对活跃，不需要二次开发即可直接使用安装简单，官方文档多，且提供Web界面的方式进行管理与监控适用场景单集群的中小文件单集群的大中文件在线扩容支持支持冗余备份支持支持单点故障不存在存在跨集群同步部分支持不支持数据存储方式文件/块块FUSE挂载不支持支持访问接口不支持POSIX支持POSIXFUSE挂载：fuse解决了文件系统必须在内核态的的难题。实现了一个对文件系统访问的回调，它使无特权的用户能够无需编辑内核代码而创建自己的文件系统POSIX：表示可移植操作系统接口（Portable Operating System Interface of UNIX，缩写为 POSIX ），也就是Unix下应用程序共同遵循的一种规范。支持POSIX的应用程序意味着在各个Unix系统间提供了跨平台运行的支持。例如：#include <pthread.h> //在Linux下编写多线程程序需要包含的头文件POSIX线程（POSIX threads），简称Pthreads，是线程的POSIX标准。该标准定义了创建和操纵线程的一整套API。在类Unix操作系统（Unix、Linux、Mac OS X等）中，都使用Pthreads作为操作系统的线程。Windows操作系统也有其移植版pthreads-win32。作者：Minority链接：https://www.jianshu.com/p/1103971ffef8来源：简书

智慧渔业时代的深远海养殖平台控制系统张建波1,2, 王宇1,2, 聂雪军1,2, 吴国庆1,2, 刘久军2, 严俊11 南方海洋科学与工程广东省实验室（湛江），广东 湛江 5240132 湖北海洋工程装备研究院有限公司，湖北 武汉 430223摘要分析了深远海养殖平台控制系统，在云计算的开放架构下引入边缘智能的协同控制技术，建立起深远海养殖平台的分布式智能控制模式，探索性地提出“云-网-边-端-智”可灵活部署的深远海养殖平台云边协同控制系统总体框架体系和智能养殖云平台开放式架构体系，提出了深远海养殖平台控制系统的开发思路、云中心控制和边缘智能的实现方案。试图建立云边协同控制的理论框架和思想体系，构建深远海渔场的全过程智能化养殖方式和陆海联动的运营管理模式，以期最终实现智慧渔业产业生态和绿色可持续发展目标。关键词： 深远海养殖 ; 云边协同控制系统 ; 云平台开放式架构体系 ; 边缘智能 ; 智慧渔业1 引言随着社会经济的发展和人民生活水平的提高，人们越来越追求高品质、高营养的优质蛋白质的摄取，对渔业养殖的产量和品质需求越来越高。受近海或湾内环境条件的限制，养殖鱼类的品质和产量逐渐受到影响，为扩大养殖容量、降低环境风险、提升鱼类品质，海洋渔业养殖由近海走向深远海已势所必然。为摆脱近海和湾内的地域限制，使养殖区域由封闭海域向开放海域扩展，提高深远海养殖的常态化生存和海洋环境适应能力、提高深远海养殖的远程监控和运营管理能力，亟须开发成熟的深远海养殖装备[1]。近年来，国家提出智慧水产养殖和深水网箱智能化发展的要求。发展适合中国海域养殖特点的深远海智能化养殖装备将是今后科技攻关的重点领域，要在网箱设计、养殖方法、投饲系统、收捕系统、网衣清洗、智能决策等方面实现自主创新和成熟应用，逐步缩小与挪威等深远海养殖发达国家的差距。本文基于深远海智慧渔业养殖的发展背景和需求，综合利用互联网、物联网、人工智能、大数据、云计算与边缘计算等新一代信息通信与计算机技术，在云计算的开放架构下引入边缘智能的协同控制技术，构建基于云边协同的深远海养殖平台控制系统，汇聚深远海养殖装备感知、计算、通信、控制、决策的技术体系与能力，旨在提高深远海智能养殖装备的国产化水平和自主可控能力，提高养殖生产效率、降低人工养殖成本，改变传统的个体渔业养殖模式，建立集约化、规模化、工业化的渔业养殖模式，最终实现渔业养殖“高效、优质、生态、健康、安全”的绿色可持续发展战略目标[2]。2 结束语随着深远海养殖装备的发展，逐渐实现了自动化的养殖设备控制与信息化的养殖过程管控，并正在向养殖装备和养殖过程全生命周期的智能控制与智慧管理迈进，逐渐摆脱了“农耕经济”的思想束缚，使深远海养殖产业展现出可持续工业化集约发展的美好图景。本文以“国家海洋强国战略”驱动下的智慧渔业发展为背景，研究基于云边协同的深远海养殖平台控制系统，构建深远海养殖控制模式和平台体系，以建立深远海渔场的全过程智能化养殖方式和陆海联动的运营管理模式。本文针对深远海养殖装备的发展需求，分析了深远海养殖平台控制系统，基于两级管理三层控制的分层结构模型建立深远海养殖平台的分布式智能控制模式，有针对性地将模型驱动、数据驱动、事件驱动的控制方法应用于深远海养殖平台不同的被控对象和场景。以分布式智能控制为核心理念，在云计算的开放架构下引入边缘智能的协同控制技术，探索性地提出“云-网-边-端-智”可灵活部署的深远海养殖平台云边协同控制系统总体框架体系，并衍生出覆盖全产业链的智能养殖云平台开放式架构体系，提出深远海养殖平台控制系统的开发思路、云中心控制和边缘智能的实现方案。试图建立云边协同控制的理论框架和思想体系，以指导深远海养殖装备的生产管控实践，以期最终实现智慧渔业产业生态和绿色可持续发展目标。深远海养殖平台云边协同控制系统采用面向服务的分布式开放架构体系，融合感知、计算、通信、控制、决策的5层架构体系，便于建立统一的基准、支持设备的模块化插件化、便于统一资源调度与管理，为设备的“即插即用”提供了一个开放、通用、标准的软/硬件环境体系，提高了任务系统的可扩展性、自适应性和高可用性。但作为深远海养殖领域的分布式智能控制系统，需深化人工智能与深远海养殖场景的融合、加强云平台与边缘智能的协同演化、增强边缘智能的自适应性，可以进一步研究和探讨的专题领域具体包括以下方面。1) 深远海智能养殖知识服务：扩大深远海养殖领域的专题数据库、智能算法库、模型训练集，开展融合边缘智能的养殖数据处理技术研究，构建深远海养殖场景下的水质、水文、气象、鱼类生物等要素相互耦合的知识图谱，构建深远海养殖多源跨领域的知识反演模型，强化人工智能在深远海养殖场景中的应用。2) 人工智能云边协同进化：开发兼容云平台和边缘智能控制系统的模型与算法，模型与算法的加载、迁移与卸载方法。3) 新一代融合感知、通信、计算、控制、决策的边缘智能自适应控制系统：开放通用高端的边缘智能控制器，以网络为核心的自适应操作系统，提供开放式软/硬件环境，兼容现有主流网络协议与硬件模组。3 原文链接http://www.infocomm-journal.com/wlw/article/2021/2096-3750/2096-3750-5-4-00120.shtml

ZooKeeper 是 Apache 软件基金会的一个软件项目，它为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。ZooKeeper 的架构通过冗余服务实现高可用性。Zookeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。谁适合阅读本教程？本教程是为专业的程序开发人员，通过本教程你可以一步一步了解 zookeeper 的应用。zookeeper 数据结构zookeeper 提供的名称空间非常类似于标准文件系统，key-value 的形式存储。名称 key 由斜线 / 分割的一系列路径元素，zookeeper 名称空间中的每个节点都是由一个路径标识。相关 CAP 理论CAP 理论指出对于一个分布式计算系统来说，不可能同时满足以下三点：一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。可用性：每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据。分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。在这三个基本需求中，最多只能同时满足其中的两项，P 是必须的，因此只能在 CP 和 AP 中选择，zookeeper 保证的是 CP，对比 spring cloud 系统中的注册中心 eruka 实现的是 AP。BASE 理论BASE 是 Basically Available(基本可用)、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。基本可用：在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级）。软状态：允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的 data replication（数据备份节点）之间的数据更新可以出现延时的最终一致性。最终一致性：data replications 经过一段时间达到一致性。BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。相关资源zookeeper 官网：https://zookeeper.apache.org/

AI模型开发的过程，称之为Modeling，一般包含两个阶段：开发阶段：准备并配置环境，调试代码，使代码能够开始进行深度学习训练，推荐在ModelArts开发环境中调试。实验阶段：调整数据集、调整超参等，通过多轮实验，训练出理想的模型，推荐在ModelArts训练中进行实验。两个过程可以相互转换。如开发阶段代码稳定后，则会进入实验阶段，通过不断尝试调整超参来迭代模型；或在实验阶段，有一个可以优化训练的性能的想法，则会回到开发阶段，重新优化代码其部分过程可参考下图：ModelArts提供了如下能力：丰富的官方预置镜像，满足用户的需求。支持基于预置镜像自定义制作专属开发环境，并保存使用。丰富的教程，帮助用户快速适配分布式训练，使用分布式训练极大减少训练时间。分布式训练调测的能力，可在PyCharm/VSCode/JupyterLab等开发工具中调试分布式训练。约束限制开发环境指的是ModelArts提供的新版Notebook，不包括旧版Notebook。总览页面打开的CodeLab不支持此项功能，但是如果用户在AI Gallery中打开了可用的案例，会自动跳转到CodeLab中，此时是可以使用这项功能的。如果切换了Notebook的规格，那么只能在Notebook进行单机调测，不能进行分布式调测，也不能提交远程训练任务。当前仅支持Pytorch和MindSpore AI框架，如果MindSpore要进行多机分布式训练调试，则每台机器上都必须有8张卡。本文档提供的调测代码中涉及到的OBS路径，请用户替换为自己的实际OBS路径。本文档提供的调测代码是以Pytorch为例编写的，不同的AI框架之间，整体流程是完全相同的，只需要修改个别的参数即可。

随着各领域数字化转型的推进，数据系统的应用范围不断扩大，承载业务愈发关键，用户的高频访问成为常态，系统复杂性呈指数上升，这些因素显著增加了稳定性风险，传统系统稳定性保障方法论难以适应数字化发展需要，导致近年来全球范围内数据系统故障事件频发。 2022年4月27日，首届“全球数据系统稳定性峰会”以线上线下结合的形式召开。峰会由中国信息通信研究院和中国通信标准化协会指导，中国通信标准化协会大数据技术标准推进委员会（CCSA TC601）主办，会议得到了中国IDC圈、dbaplus社群的大力支持。大会旨在助力我国数字经济发展“又快又稳”，推动全球数据系统稳定性迈上新台阶。 中国工程院院士廖湘科、中央网信办信息化发展局副局长张望、中国通信标准化协会副理事长兼常务副秘书长代晓慧、中国信息通信研究院副院长魏亮等专家领导参会并致辞。廖湘科院士在致辞中指出，数据系统已经成为数字经济时代不可或缺的基础设施，大量关乎国计民生的关键数据系统已成为托举我国社会平稳运行、经济持续增长的重要底盘。廖院士强调，在系统稳定性方面，要坚持自主创新，强化服务支撑，加强稳定性保障相关人才培养力度。成果发布 中国信通院云计算与大数据研究所所长何宝宏对中国信通院数据系统稳定性工作体系进行了介绍。中国信通院于2021年启动稳定性相关工作，依托分布式系统稳定性实验室，面向供给侧机构、监管机构及应用侧机构，形成面向产品、工具、服务商、系统、灾备和保障体系等对象的“STAR”评估体系，助力我国各领域系统稳定性保障工作。 中国信通院云计算与大数据研究所副所长魏凯介绍了本批数据系统稳定性评估评测的总体情况，从保障能力、应用行业等角度对本批测试结果进行了深入的剖析，帮助读者全面理解系统稳定性的保障情况，总结了影响系统稳定性的四大关键因素。 分布式系统稳定性实验室成员/专家团亮相中国信通院分布式系统稳定性实验室自2021年成立以来，受到业内专家、企业的大力支持，目前实验室共有五十多个成员单位和23位资深专家。会上，中国信通院为分布式系统稳定性实验室成员单位和专家团成员举行了亮相仪式。 证书及案例发布 中国信通院向通过首批数据系统稳定性保障能力评估(STAR-A)的企业颁发了证书。“STAR-A评估”是由中国信通院分布式系统稳定性实验室推出首个针对系统稳定性保障体系的评估项目，旨在帮助参评企业全方位梳理系统稳定性保障体系，排除潜在风险点。经过严格评估，首批共筛选出涵盖金融、电信、政务、医疗、互联网等诸多行业的12个一线系统。 随后峰会颁布了“系统平稳运行优秀案例”。“系统平稳运行优秀案例”由中国信通院分布式系统稳定性实验室发起，旨在评选出高稳定性系统，树立行业标杆。该案例的评审采用拨测方式，模拟真实用户对系统进行访问，检测50余个大型系统半年的平均无故障时间，筛选故障时间最短的前14家企业，覆盖银行、证券、电信、互联网、交通、媒体等多个领域，展示了我国系统稳定性保障领域的领先成果。 主题演讲 大会邀请到了交通、电商、通信行业的嘉宾，就各自领域稳定性的实践探索进行了分享与探讨。 中国铁道科学研究院集团有限公司首席研究员、12306科创中心副主任单杏花就《铁路12306稳定性保障》主题进行演讲。 京东零售集团京东大促备战技术总架构师李军亮进行了主题为《京东大促稳定性保障经验分享》的演讲。 浙江移动SRE架构师史军艇以《运营商大型系统的稳定性经验分享》为题进行演讲。 蚂蚁集团数字科技事业群技术副总经理石世群以《支付宝双十一稳定性保障经验分享》为题进行演讲。 在下午的会议中，中国信通院王卓对《信息系统稳定性建设保障指南（1.0）》进行了解读，王超伦带来了分布式系统稳定性保障能力标准和首批评估结果解读。中国信通院杨佳星、田稼丰分别发布了《系统稳定性保障平台能力要求》及《数据系统灾备能力成熟度模型》。 大会还邀请到了新炬网络、数列科技、博睿数据、阿里云及京东科技的嘉宾，就各自领域的稳定性保障成果进行分享。从稳定性保障的各项技术到产品如何实现高稳定性，多角度展示了我国数据系统稳定性保障领域取得的成就。 来源：大数据技术标准推进委员会

4月23日，中国邮政储蓄银行新一代个人业务分布式核心系统全面投产上线。该系统是大型商业银行中首家同时采用企业级业务建模和分布式微服务架构，基于鲲鹏硬件底座、openGauss开源数据库与GaussDB分布式云数据库共同打造的全新个人业务核心系统，是中国银行业金融科技关键技术可控的重大实践。邮储银行新一代个人业务核心系统通过企业级业务建模实现化繁为简，重塑核心交易流程；组件化模型驱动业务敏捷，从容应对市场变化与客户需求；分布式单元化部署实现弹性扩展，实时支撑业务变化；在线迁移方式实现客户无感切换，保障业务连续性，降低切换风险，为客户带来了新体验。新感受，更加快速高效。改版界面、优化流程、减少人工依赖，大幅缩短客户业务办理时间；新功能，更加智能强大。依托线上触达渠道，重点着眼于客户需求复杂的查询类业务，满足客户长周期、多元化、个性化需求；新设计，更加安全、可靠。完善的实时反欺诈系统，提高操作风险管控能力，同时帮客户降低潜在欺诈风险。鲲鹏、openGauss开源数据库与GaussDB分布式云数据库作为邮储银行新一代个人业务核心系统IT数字化底座组成部分，在其中承担了先进算力平台和高性能企业级数据库的重要角色，系统上线后可支撑海量交易、弹性伸缩、金融核心级高可靠和高可用，可具备为全行6.37亿个人客户、4万个网点提供日均20亿笔，峰值6.7万笔/秒的交易处理能力。邮储银行新一代个人业务核心系统全面投产上线，使邮储银行科技金融再添一部新引擎，将为邮储银行提供源源不断的科技动能，加速建设“一流大型零售银行”。同时鲲鹏、openGauss开源数据库与GaussDB分布式云数据库将继续全力支持邮储银行数字化升级，共同为同业积累经验，探明路径，树立标杆。

一、全球计算产业趋势——数据中心的重新架构每隔数十年，新架构重塑数据中心上一次大规模的数据中心迁移发生在90年代，从 RISC处理器转移到了更低成本的PC衍生X86架构。 英特尔凭借着PC市场的规模效应颠覆了相对更高 端的竞争对手。 今天，ARM处理器正在利用移动生态系统的规 模来颠覆英特尔。将开源原理应用于硬件， RISC-V也正在凭借低成本侵蚀市场。 ARK Invest认为，ARM和RISC-V的组合将从 2020年的0%市场份额上升到2030年服务器市场 的的71%。英特尔的发展似乎陷入停滞作为曾经世界半导体制造业的领导者，英特尔似乎 已经失去了方向 ；英特尔将其10nm处理器推迟了4年，使其竞争对手 台积电和AMD的机会在2020年引领市场 ；截至2021年，英特尔仍然没有出货10nm服务器芯 片。而台积电正在大规模生产5nm处理器，比英特 尔领先了整整一代。到2030年,ARM可以为多数开发用PC提供足够的性能几乎所有的软件开发人员都在英特尔的x86电脑上编写 代码，运行Windows、Mac或Linux操作系统 ；苹果公司计划在未来两年内将每三个开发者中就有一个 使用的Mac从x86过渡到基于ARM的中央处理器（CPU） ；与此同时，微软正在加倍努力支持ARM处理器上的 Windows；根据ARK的研究，到2030年，大多数开发者的PC可能 由ARM CPU驱动，标志着英特尔x86 时代的结束。ARM可能成为云计算的新标准公共云(Public cloud)作为投放新应用程序的默 认平台， 在2020年全球收入达到1400亿美元 ；AWS--世界上最大的公共云供应商--在2020年 推出了Graviton 2 ARM CPU， 减少了其从英 特尔和AMD购买芯片的需求；AWS Graviton 2比英特尔CPU更便宜、更快、 每一美元的性能高出48% ；在未来，AWS可能会把其大部分服务器迁移 到基于ARM的处理器。到2030年ARM或将成为新的处理器标准采用ARM处理器的PC和服务器将创建第一个具有足够 规模、丰富工具和供应商支持的生态系统，来挑战英特 尔的x86架构 ；2020年，全球服务器市场约912亿美元，同比增长4.2%， 出货量约1218万台。中国服务器市场出货量为350万台， 同比增长9.8%，厂商收入达到227.5亿美元，同比增长 19.0%；ARM服务器的收入可以扩大100倍，从2020年不到10亿 美元到2030年的1000亿美元，甚至比今天的x86更高的 水平。同时，RISC-V也可以做出非常有意义的贡献；与大型处理机一样，安装X86的电脑市场规模可能会继 续扩大，但其收入可能相比现在会被削减一半。到2030年，硬件加速器（Accelerator)或将取代CPU成为主要的服务器计算引擎如GPU、张量处理单元（TPU）和现场可编程门 阵列（FPGA）等硬件加速器可以执行最大算量的 计算任务，包括人工智能（AI）、数据分析、药 物开发和云游戏。尽管竞争激烈，但我们相信GPU凭借其无可比拟 的可编程性和软件堆栈(Softwaare stack)，在未来 五年内仍将继续主导硬件加速器市场。二、全球软件产业趋势——开源软件正在改变IT行业开源软件正在改变 IT 行业开源是当今基础软件在全球范围内取得成功最优路径。全球软件应用的四次浪潮：IBM为代表的软硬件一体大型计算机系统；客户端/服务器端系统架构、软硬件分离牵引独立 商业软件迅猛崛起；云计算带来技术架构和软件商业模式变化，并催生一批SaaS、PaaS软件公司；开源带来生态巨大繁荣 和商业模式创新。过去10年，开源软件商业化能力得到市场正向反馈，企业估值持续高涨。开源软件项目纷纷成立开源软件公司，进入商 业化运营，开源软件开始更多侧重企业级商业化 应用 ；开源软件公司逐渐找到或者创新商业模式，并 被市场和用户所接受认可；庞大的用户基数和生态基础带来开源软件公司 营收的高速成长，叠加创新的商业模式，高成长 高估值。开源软件市场流行度逐渐超越商业软件。过去10年开源license数据库流行度（一定程度代表使用度）逐步接近商业license数据库。2013年，开源license数据 库流行度/受欢迎程度明显落后于商业license数据库，自2013年以来开源数据库受到市场持续关注追捧，流行度呈现 不断上升趋势。2021年，开源数据库流行度已经超过商业数据库。云计算也在加速改变软件行业SnowFlake做对了什么？技术选择：高性能和拓展性，Snowflake定位于云原生OLAP，并将OLAP传统架构的计算和存储分离，用户可以更灵 活地选择服务级别，而公有云部署方式能够根据需求快速增减节点数量商业模式：在Snowflake前，OLAP通常是公有云PaaS服务， 而Snowflake做成了支持多云的SaaS产品，简单易用。云 服务一般有两种收费模式：资源预留、包月包年与按量付费。与传统的SaaS公司不同，Snowflake是根据计算量*时长 计费定价的。销售方式：Snowflake总结自己的Go-To-Market (GTM) 就是针对大企业高层的direct sales，这种销售模式成本高，导致 它的销售占比是在SaaS公司中是最高的。SnowFlake营收持续增长SnowFlake上市以来，营收持续翻倍增长，2021Q1-Q3实现营收8.36亿美金，同比增长73.31%，预计今年全年收入达到11.3亿 美金，同比增长103%，公司整体毛利率74%。三、数据库行业演进基于提供者和数据存储单元位置/数量的发展路线数据库发展经历了三个时代：商业数据库时代（商业软件行业）→ 开源数据库时代（互联网）→ 云数据库时代（云企业和 轻型数字化企业）；从数据存储单元位置/数量发展路线演进：单机→集群部署→分布式→ 云原生。基于数据存储处理类型结构化数据（关系型/SQL）→ 非结构化数据（非关系型/NoSQL）→异构数据（大数据/多模数据）；图片、语音等非结构化数字的处理量增加带来的产品变化。云上&分布式数据库成为新秀从业务需求来讲，数据库是云上应用的关键 一环，数据库作为IaaS+PaaS的核心构件和服 务之一，必须能够满足自身业务和企业级云服 务要求；从技术能力和应用场景来看，互联网公司技 术外溢以及日益增长的高并发高吞吐应用场景， 能够持续拉动数据库系统的日益完善 ；从全球数据库产业格局来看，互联网厂商的 分布式交易型数据库成为产业最大黑马，Ama zon、Alibaba、Google市场份额进入TOP10， Tencent也进入全球TOP15。（报告来源：未来智库）四、国产数据库技术路线与发展国内数据库的四类技术路线目前来看，在商业数据库市场，我们相对看好基于开源代码重构和类Oracle模式的产品，其中阿里、TiDB主要是基于MySQL 等开源软件重构，华为基于PG（PostgreSQL）重构，头部互联网公司多数基于MySQL。开源协议限制条件存在差异，国内首个开源协议木兰诞生BSD因协议更为友好，选择PG为基础的商业数据库较多。MySQL适应互联网交易型分布式场景，也是互联网/分布式应 用的主流技术路线选择 ； 由北京大学牵头，联合华为、BAT和国内知名开源研发团队，众多开源社区与中国开源联盟共同研制而成的中国首个 开源协议“木兰”，也是中国首个国际通用的开源协议。国内数据库三类商业路径国内数据库市场，开源软件和商业软件并存，开源数据库越来越多，但是最终会走向收敛。国产数据库推进力：开源、分布式、云计算、国产化国内互联网快速发展推动国产数据库前进开源软件社区（PostgreSQL、MySQL、MongoDB、Hive、Impala等）的快速发展和繁荣，使得国产数据库发展具备了强 大的技术和生态基础；互联网、头部科技企业的高并发大吞吐业务场景，集群式架构无法满足，促使其自研分布式/云数据库产品以适应业务 高速发展需要，而事实也取得了成功（2019双11在线支付成功峰值达到54万）。伴随IT架构向分布式迁移以及国产化应用推动，国产分布式数据库中标和投产应用逐步起势。国产化需求发展推动国产数据库前进2014年，微众银行+TDSQL上线，成为分布式数据库在互联网银行核心交易系统的应用首例，1700+台x86服务器，3.46亿+ 日金融交易峰值 ；2018年，华为Gauss OLTP数据库在招商银行综合支付交易系统上线投产， 日均请求量高达8500万， 峰值TPS达到3500 ；2019年，张家港银行+TDSQL，成为分布式数据库在传统银行核心系统应用首例，同等TPS下，硬件成本仅为商业数据库1/5 ；2020年，国产数据库投产应用已经多点开花，基本集中在金融、电信和政务领域，且规模体量及核心业务系统开始增长。 传统数据库厂商受益于办公国产化开始全面推广，迎来了业绩翻倍式增长。国产数据库市占率持续提升关系型数据库市场，国内产品市占率从 2009 年的 4.2%提升至 2019 年的 18.9%。自 10 年前后提出“去 IOE”和 13 年棱镜 门事件影响后，我国一直在推动国产数据库持续扩张，近 3 年海外四巨头在国内市占率仍维持在 65%以上份额。从国内市场结构看，公有云厂商提供的云数据库产品及服务预计达到一半左右的市场份额。数据库——国产化应用中软件投资占比最高的单品服务器端软件生态链较短，对前端用户透明，云架构下对原有X86架构兼容使得服务器端国产化客观上阻力较小；2021年金融国产化投资中：服务器占据硬件36%的投资额；数据库占据软件57%的投资额。数据库是竞争最激烈的国产软件赛道数据库厂商将要面对的现实。 国产产品目录设置了围墙，最凶狠的一批玩家目前还没有进入，随着目录不断扩容、国产化走向深水区、用户关注 产品服务能力，从2022年开始国产数据库真正的战争将拉开大幕。 技术路线选择和坚持只是开始，随之而来的是交付实施（系统迁移工具、交付管理平台、产品版本迭代），而生态 和人才的培养是最大短板。 稳健是胜出的必要但不充分条件，纯商业市场竞争要求性能好、迁移快、系统稳、低成本和代表性案例。五、投资分析：未来5年是国产数据库的主战场云、开源数据库估值往往高于传统数据库市场对云数据库的估值溢价远高其他类型。以Snowflake为例，因其数据库具备数据共享、多云架构、运行效率高，毛利 率虽低于传统License的形式，但其高速成长性（100-200%的营收增速），高留存率（120%），市场给予近37-44X ps； 参考美国云计算公司估值水平，30%增速对应10X PS( 隐含条件 30%净利润率 30XPE), 50%增速对应 15X PS (30%净利 润率 50XPE），50%以上的增速则可以基于给予更高的估值。 以Lisence售卖+项目建设的数据公司，一般成长期的公司会根据PEG=1动态调整，成熟期的公司的PE水平多在25-30X；openGauss有望成为国内最主流的数据库技术路线，商业版公司有望脱颖而出目前openGauss社区合作伙伴主要有海量数据、神舟通用、云和恩墨、人大金仓等，60多家单位加入社区组织。 openGauss数据库在2020年6月开源至今，已有12家伙伴基于openGauss发布了商业发行版，其中海量数据、云和恩墨、神 舟通用等伙伴已经实现在政府、电力、制造、能源等行业的规模化应用，其中海量数据Vastbase G100、云和恩墨MogDB、 沐融科技MuDB三家公司推出的商业发行版产品通过了openGauss社区认证。达梦、金仓充分受益国产化红利，在办公国产化市场份额领先过去两年，数据库公司营收开始跃升。2019年之前，达梦数据库营收基本在2亿左右，从2019年办公国产化应用推广开 始，公司营收达到2.72亿，同比增长约30%。2020年办公国产化应用大规模启动，达梦收入创历史新高达到4.25亿，收入 规模效应也带来净利润释放，净利率达到30%；2021年预计达梦收入约7亿，净利润约2亿。2021H1达梦实现营收2.07亿元，同比增长245%，净利润0.89亿，相对去年同 期扭亏为盈，净利率高达45%。截止2021年9月底，达梦数据库出货量约1.4万套，全年预计出货达到2万套，我们预计 2021年达梦收入6-7亿。展望未来，办公应用的服务器需求小，随着电子政务、行业应用国产化带动，服务器端国产软件 将保持较高增长；人大金仓2020年收入同比增长183%达到2.41亿元。2019年，人大金仓营收0.85亿元。2020年伴随办公国产化市场推广， 公司营收达到2.41亿元。2021年随着市场规模扩大，预期公司收入3-4亿元，同时软件产品规模效应有望显现，预计公司 净利润有望达到1亿元。目前海量数据是华为openGauss社区唯一金牌合作伙伴，看好公司未来发展海量数据All-In openGauss战略：海量数据目前在openGauss开源社区中贡献度排第二，仅次于华为，是最深度参与开源 社区的发行版公司，也是华为openGauss唯一的金牌合作伙伴，凸显了公司的产品商业化和服务能力，而开源社区的发 展和成熟离不开发行版公司的深度和专业度投入；（报告来源：未来智库）华为加持：华为打造国家级根技术开源社区，将在研发方面支持openGauss商业发行版公司，市场销售端也将给予商业 版产品应用推广支持；唯一入围国产采购目录的openGauss商业版公司：海量数据自主研发的基于openGauss的商业版数据库软件Vastbase在 2021年中入围国产产品采购目录。我们预计2021-2023年公司自主数据库Vastbase软硬件收入分别达到1、3、5亿元，我们 参照国产软件公司当前估值，给予公司2023年20x PS估值，中长期看好公司发展。来源：未来智库

4月14日，“2022分布式存储线上峰会”成功举行。本次峰会由百易传媒（DOIT）与厦门大学信息学院联合主办，中国计算机学会信息存储专委会、中国计算机行业协会信息存储与安全专委会、武汉光电国家研究中心协办，吸引了近50万观众参与直播和互动交流。不久前，中共中央、国务院在“关于加快建设全国统一大市场的意见”中提到：加快培育数据要素市场，建立健全数据安全、权利保护、跨境传输管理、交易流通、开放共享、安全认证等基础制度和标准规范，深入开展数据资源调查，推动数据资源开发利用。数据要素市场的提出，为分布式存储和数据存储市场带来重要发展机遇。中国计算机学会信息存储专委会主任委员、清华大学计算机科学与技术系教授、厦门大学信息学院院长舒继武在峰会开幕致词中表示：“从技术形态来看，分布式存储在可扩展性、灵活性等方面的优势更适合解决数据要素市场发展过程中所面临的数据存储与管理问题。”主流厂商积极参与，分布式存储市场快速增长云计算、5G、物联网、人工智能等新技术的快速应用，以及传统产业的数字化转型加速，带来海量数据的规模化聚集；IDC预计，未来五年软件定义存储市场的复合增长率将达到23.4%，到2025年分布式存储的市场空间将达到325亿美元。层出不穷的数据形态、不断变化的部署环境、随时出现的安全隐患等，都对存储技术发展提出了新的要求。分布式存储凭借高安全性、可靠性、可用性以及易于扩展等特性得到了快速发展，“十四五”规划更是将超大规模分布式存储技术创新列在数字经济重点产业云计算专项的首要位置，大批优秀的分布式存储供应商争相发力这一赛道。当天的峰会上，英特尔数据中心与人工智能事业部副总裁、英特尔傲腾事业部总经理David Tuhy探讨了如何通过基础设施现代化来帮助客户实现云原生数字化转型；浪潮信息存储产品线分布式存储总经理姜乐果在主题演讲中指出，数据要素是数字经济发展核心引擎，浪潮信息是聚焦于智慧计算战略，面向智慧时代与算力、算法、数据、网络四大支柱持续构筑数字信息的基础设施；新华三集团存储产品线副总经理兼首席产品经理关天舒指出,分布式存储必须拥有极致的性能表现和极智的管理体验，新华三正以极速和智能重塑下一代分布式存储；中国电信集团有限公司云计算首席专家江峰在峰会上表示，中国电信天翼云正致力于以创新的手段减少用户不必要的投资，降低数据中心能耗，推进“双碳”国家战略。据悉，峰会还设置了分布式存储技术应用和混合云数据管理两个分论坛。分布式存储论坛上，联想凌拓资深产品经理吴静介绍了联想凌拓面向海量的非结构化数据打造全自研分布式存储及与本地硬件、芯片、操作系统和存储软件全面国产化的历程；宏杉科技产品部副总工程师谢勇介绍了宏杉MOFS分布式存储系统针对用户的业务需求提供文件、对象、大数据方面差异化的存储资源服务；深信服存储产品线副总经理田皓野表示，深信服存储始终秉持“敬畏数据、充分实践”理念，以更好的方案应对客户业务发展对存储技术架构变化带来的挑战，共同创造数据宏图；在房地产行业创造了多个信息化第一的上海锐通管理咨询有限公司总经理、房地产CIO联盟秘书长罗艳兵分析了企业数字化建设过程中遇到种种困惑，引导企业有效整合和运用内外资源快速转型突围，最终实现数据价值的最大化。此外，来自中国移动云、中国建设银行、腾讯云、阿里云智能、戴尔科技集团合作伙伴荣联科技等企业代表分别就分布式存储技术创新、分布式存储的应用、云原生与SDS、混合云与数据管理等热点话题展开讨论。把脉分布式存储市场，峰会两大研究成果发布本次峰会的亮点之一是《2022分布式存储市场调研报告》的同期发布。该报告从市场、应用和实践的维度，对分布式存储产品技术应用中的热点问题进行了深入解读，分析和预测了分布式存储市场规模。报告对坊间关于分布式存储基本概念的认识误区进行了纠偏，厘清了分布式存储与集中式存储、软件定义存储、云存储等其他相关技术的关系，并对分布式存储的发展趋势、重要特性、市场规模、参与角色、选型应用、场景及成效进行深度阐述，可以说，这篇调研报告对分布式存储概念与分类进行了“重新定义”。与此同时，“2022分布式存储企业图鉴”也于峰会当天正式发布。图鉴集中展示了分布式存储赛道上的50余家代表厂商，吸引了存储专家和企业IT用户的广泛关注。见证分布式存储产业五年变迁，驱动中国数据要素快速发展从2018年开始，分布式存储峰会已经先后在北京、深圳、上海等地连续成功举办了四届，峰会见证了分布式存储产业五年的快速发展。百易传媒（DOIT）持续跟踪分布式存储产业技术发展和行业应用趋势，与业内领军企业携手，将分布式存储领域最新的技术发展趋势和典型行业应用实践呈现给广大用户，推动各行业数字化转型进程。“计算和网络性能的提升，闪存性能的不断突破，为分布式存储的创新奠定了基础，分布式存储系统在性能、可管理性等方面也在不断进步。全球范围内，包括中国市场诞生了多家主打分布式存储技术的创新企业，而且呈现良好的发展态势。”舒继武教授最后呼吁：“让我们携手共同努力，为中国数据要素市场的发展贡献力量！“来源：IT168

本次推荐文档来自 CCF 2021年12月发表的《"十四五"数据库发展趋势与挑战》一文，其中针对数据库的精彩论断，值得从业者深入理解和思考。署名字母序作者：陈群、陈跃国、崔斌、范多锋、高云君、李国良、李战怀、毛睿、潘安群、彭智勇、钱卫宁、童咏昕、屠要峰、王晓阳、杨晓春、姚斌、袁野、周立柱主要观点：计算模式的改变和应用需求变化对数据库系统形态起到了至关重要作用，也推动了数据库架构的迭代更新。线下数据库到云数据库的转变：数据库部署形态从传统的线下部署转变到云上部署，计算存储分离的云原生数据库得到了广泛关注。集群数据库到分布式数据库的转变：数据库逐步发展到分布式数据库模型，而分布式查询优化、分布式事务和分布式一致性协议等技术也得到了快速发展。端边云协同数据库:随着移动互联网和数字孪生的普及，端边云协同的数据处理得到了广泛关注，而异构智能设备上的分布式数据协同与一致性管理需要深入研究与发展。AI 原生数据库:AI 和数据库结合，通过 AI 技术优化数据库的设计和管理(例如学习型索引、学习型代价估计、智能参数调优等)；通过数据库系统和技术降低 AI 使用门槛，普惠 AI。数据库产品分类图谱:具体来讲：计算模式改变:新型计算模式，例如云计算架构，对数据库发展起到了重要作用。云架构计算存储解耦，实现独立的计算弹性伸缩和存储的自动扩缩容，云原生数据库应运而生;随着物联网的发展和数字孪生的普及，端边云成为趋势，需要突破端边云数据处理技术来支持万物互联时代的数据管理，而目前还缺少 端边云(协同)数据库。应用需求变化:数据库从解决数据交易问题的OLTP数据库，到支持商业决策需求的OLAP数据库，再到智能时代，需要融合数据库和 AI 技术来支持实时的智能决策，因此亟待研究 AI 原生的数据库。大数据时代，更多的数据管理系统更加注重系统扩展性，因此 NewSQL 分布式数据库，例如 Spanner，得到了大型应用的青睐。云原生数据库 1.0，通过计算存储分离、日志即数据、一写多读等技术实现其优点:计算和存储的解耦和分离，计算节点无需保存数据库的状态，实现独立的计算节点弹性伸缩和存储节点弹性扩缩容;日志即数据，只写日志(redo log)，通过存储层回放数据来避免 IO 放大，降低了云基础设施的网络压力;一写多读，存储层回放的数据能够保证多份数据的一致性(通过 Paxos、Raft、Quorom协议)， 实现一写多读，支持读节点一致性读。云原生数据库 2.0 的技术挑战:分布式共享内存技术:将分布式内存虚拟化，并提供近端(本地)、远端感知的内存访问能力，在保证高可用的同时降低访问时延;计算、内存、存储分层解耦的事务处理架构:利用三层池化资源设计高效的事务处理技术实现分层解耦的数据库。网络层和存储层算子下推:需要研究存储层算子下推技术和网络层数据卸载技术，避免大批量数据传输。细粒度弹性按需计算:设计细粒度弹性按需计算机制(serverless)，实现查询级、事务级、算子级的弹性按需计算，多租户间资源隔离和复用。HTAP混合负载:利用云资源实现真正的 HTAP，例如实现实时的行转列，从而利用列存来支持复杂分析查询，难点在于高效的行转列以及智能选择。分布式数据库要解决的核心问题:分布式事务处理与查询优化: 在无法完美 sharding 的情况下，跨节点事务处理性能会急剧下降。需解决分布式事务处理和分布式优化器问题。智能数据分布技术:分布键的选择合理与否直接影响到数据库的性能指标。如何高效选择分布键是是否能做到应用透明的关键技术之一。分布式高可用技术:分布式数据库高可用应具备多层次的技术要求，以满足不同级别的故障高可用方案。难点在于高性能的基础上跨地域多活。智能运维调优技术:利用 AI 技术实现智能运维、智能调优、智能诊断、智能索引/视图推荐，是分布式数据库需要解决的主要问题之一。AI 原生数据库核心挑战。未来的 AI 原生数据库需要从 AI 需求的角度来重新设计和实现 DBMS，以友好的方式高效地支持 DB&AI 的混合处理(Hybrid DB & AI Processing)，其核心技术包括: 设计和实现统一的数据模型。设计统一的数据模型来表示异构多模态数据，并实现相应的存储方法，使之能无缝地支持关系代数操作(如选择、 投影、交)、线性代数操作(如标量、向量、张量操作)以及其他基于更复杂 AI 模型(如深度神经网络)的操作，是需要解决的核心挑战之一。设计和实现统一的操作算子。定义和实现一套 AI 原生的数据操作算子，友好高效地支持 DB & AI 的混合运算，是 AI 原生数据库需要解决的另一个核心挑战。设计和实现统一的优化引擎。在统一的数据模型和操作模型之上，AI 原生数据库 需要一个统一的执行引擎，优化 DB & AI 的混合操作。基于代价模型优化执行计划是需要解决的核心挑战之一。AI 模型的管理以及其跟执行优化的耦合也是执行引擎的核心挑战之一。利用 CPU+GPU 异构硬件实现训练和推理加速。DB 和 AI 通常需要不同的计算能力和硬件，需要充分利用多样化的计算能力。最终目标是充分利用 x86、ARM、GPU、NPU、加速器等多种计算能力。文章来源：公众号数据和云

近日，Apache ShardingSphere社区与openGauss社区再度展开合作，Apache ShardingSphere + openGauss的分布式解决方案，突破了单机性能瓶颈，使用16台服务器在超过1小时的测试中，得到了平均超过1000万 tpmC 的结果。一、ShardingSphere + openGauss, 达成1000万tpmC在本次测试中，openGauss社区基于标准BenchmarkSQL 5.0 工具，进行本轮 TPC-C 测试。在单机性能方面，openGauss突破了多核CPU的瓶颈，实现两路鲲鹏128核达到150万tpmC，内存优化表（MOT）引擎达到350万 tpmC。但业务场景及用户体验对于性能的追求是无止境的，尤其在如今海量数据的场景下，追求性能极限仍然是每一款数据库的目标。在此情况下，openGauss团队采用了7台机器运行适配了ShardingSphere-JDBC 的BenchmarkSQL测试工具，连接8台openGauss数据库，并部署了1台 ShardingSphere-Proxy用于数据初始化、一致性校验等维护操作。通过数据分片能力，ShardingSphere使总共8000仓数据（超过800GB）被分散在8台 openGauss节点。在完美Sharding的情况下进行持续超过1小时的测试后，得到了平均超过1000 万tpmC的结果，行业同等规模下性能最好。这极大突破了openGauss现有的性能极限，突破了单机性能瓶颈，满足openGauss在海量数据场景下关于性能、可用性以及运维成本这三方面的诉求。两者的结合，正在持续挑战分布式数据库的性能极限。二、ShardingSphere与openGauss的生态合作Apache ShardingSphere社区自2021年起就开始与openGauss社区展开密切合作。随着业务场景的细分以及数据体量的增长，将数据集中存储至单一节点的传统解决方案，已经难以在性能、可用性和运维成本等方面满足业务需求。诚然，数据分片能力能够解决单机数据库在性能、可用性以及单点备份恢复等问题，但也带来了分布式架构较高的系统复杂性。作为Database Plus理念的提出者和实践者，Apache ShardingSphere旨在构建异构数据库上层的标准和生态，以叠加扩展数据分片、弹性伸缩、数据加密等更多计算能力为基础，站在数据库的上层视角来关注数据库之间的协作方式，以能够合理且充分地利用数据库计算与存储能力。目前，Apache ShardingSphere已经形成了微内核 & 可插拔架构模型，并在此基础上持续完善内核及功能层面的能力，为企业及开发者用户提供更多更灵活的解决方案，以满足在不同场景下的特定需求。得益于ShardingSphere可插拔架构的设计理念，在ShardingSphere中实现对 openGauss的支持无须进行额外改造，只需要基于ShardingSphere各个模块所提供的SPI扩展点，增加对应openGauss数据库的实现。在Apache ShardingSphere 5.0.0 版本，已正式完成对openGauss数据库的支持。双方在合作过程中，通过将openGauss强大的单机性能与Apache ShardingSphere生态所提供的分布式能力结合，打造出了适用于高并发OLTP场景的国产分布式数据库解决方案；除功能层面的合作外，ShardingSphere与 openGauss在性能方面不断磨合，充分利用openGauss内核技术的创新，不断地将ShardingSphere与 openGaus 组成的国产分布式数据库解决方案的功能与性能推向极致，此次关于TPC-C的性能测试，就是双方密切合作的一次典型案例。三、使用ShardingSphere打造基于openGauss的分布式数据库解决方案当然，Apache ShardingSphere的能力不仅有数据分片，还有读写分离、数据加密、影子库等功能，在不同的场景下各项功能既可以单独使用，也可以结合使用，用户完全可以按照自己的需求组合ShardingSphere的能力。Apache ShardingSphere目前提供两种接入方式，分别为ShardingSphere-JDBC和ShardingSphere-Proxy。在业务中使用ShardingSphere-JDBC对数据库轻松进行分库分表以及读写分离等透明化操作，来解决其对于“高并发”、“低延迟” 场景的需求。同时在JDBC的基础上，ShardingSphere提供 Proxy端的部署模式，将数据库部分能力和操作部署在Proxy层面，让用户可以像使用原生数据库一样使用Apache ShardingSphere，为用户带来更加优质的使用体验。因此，建议ShardingSphere-JDBC和ShardingSphere-Proxy混合部署使用，这样可以实现维护友好与性能兼顾的平衡。在openGauss的体系中，Apache ShardingSphere能够通过水平拆分以使 openGauss的计算与存储能力实现线性扩展，性能也随着扩展准线性增长，从而有效解决单表数据量膨胀问题；此外结合业务流量，灵活平滑进行数据节点的扩缩容，智能读写分离，实现分布式数据库的自动负载均衡。 四、后续发展 本次Apache ShardingSphere与openGauss两个社区的合作，向外界展示了开源社区之间的合作潜力。随着应用场景的细化以及数据体量的增长，未来对于数据库性能的要求只会更高。此次合作的成功只是双方构筑数据库协作生态的一个开始，相信ShardingSphere与openGauss这种合作模式，一定会有更加广阔的发展空间。关于 Apache ShardingSphereApache ShardingSphere是一款开源分布式数据库生态项目，由 JDBC、Proxy 和 Sidecar（规划中）3款产品组成。其核心采用可插拔架构，通过组件扩展功能。对上以数据库协议及 SQL 方式提供诸多增强功能，包括数据分片、访问路由、数据安全等；对下原生支持多种数据存储引擎。Apache ShardingSphere项目理念，是提供数据库增强计算服务平台，进而围绕其上构建生态。充分利用现有数据库的计算与存储能力，通过插件化方式增强其核心能力，为企业解决在数字化转型中面临的诸多使用难点，为加速数字化应用赋能。关于 TPC-CTPC-C (Transaction Processing Performance Council Benchmark C)用于比较在线事务处理(OLTP)系统性能的基准测试标准规范，由TPC于1992年发布，目前最新的规范为2010年更新的TPC-C v5.11。TPC-C具有多种事务类型、复杂的数据库和整体执行结构。TPC-C涉及五个不同类型和复杂性的并发事务的混合，事务会实时执行或进入队列延迟执行。数据分布在数据库九种类型的表中，表的数据量各不相同。TPC-C以每分钟事务数（tpmC, transactions per minute C）衡量。虽然TPC-C 模拟了批发供应商的业务，但TPC-C并不限于任何特定业务部门的活动，而是代表必须管理、销售或分销产品或服务的任何行业。来源：openGauss

HarmonyOS是新一代的智能终端操作系统，给开发者提供了设备发现、设备连接、跨设备调用等丰富的分布式API。随着越来越多的开发者投入到HarmonyOS分布式应用开发，分布式应用如雨后春笋般涌现。然而分布式应用测试却面临质量差、效率低等挑战。HarmonyOS如何应对这些挑战？下面，让我们一探究竟！一、分布式应用测试挑战 自HarmonyOS 2.0发布以来，开发者在测试和上架HarmonyOS分布式应用过程中遇到很多挑战和困难。总体可归纳为以下三点：分布式应用上架测试通过率低：开发者提交上架的分布式应用基础质量较差。如图1所示，基础功能问题和UX显示问题占比率高达85%。图1 HarmonyOS分布式应用上架问题分析分布式应用测试效率低：分布式应用涉及多台设备协同时，由于没有统一的测试框架，使得分布式应用测试效率较低。安全隐私问题拦截难：分布式应用涉及多台设备协同时，由于缺乏全面且高效的隐私合规检测方案，安全隐私问题拦截难度较大。鉴于以上HarmonyOS分布式应用测试面临的挑战，华为DevEco Testing提供了一套HarmonyOS分布式应用测试解决方案，具体方案介绍如下。二、分布式应用测试解决方案 DevEco Testing是一款全新的HarmonyOS测试解决方案。如图2所示，是DevEco Testing测试能力全景视图，基于开发旅程不同阶段的测试活动，给开发者提供对应测试工具和测试服务能力。图2  DevEco Testing测试能力全景视图基于分布式应用的关键特征及开发者面临的关键问题和挑战，DevEco Testing从测试标准、测试服务及云测服务三个方面提供分布式应用测试的解决方案。下面，我们将逐一介绍。1. 测试标准测试标准定义App的入门级测试要求，重点覆盖消费者用户最关心的HarmonyOS特征和体验指标。HarmonyOS提供了流转、兼容性、安全、性能、功耗、稳定性、游戏，共7项测试标准，帮助开发者快速上手HarmonyOS分布式应用测试，如图3所示。  图3 测试标准范围定义目前，测试标准已经上线HarmonyOS应用开发者官网测试专区，建议开发者上架HarmonyOS分布式应用前参照该测试标准进行自检和测试，可以有效提升上架效率。 点击进入测试标准官网文档>>2. 测试服务测试服务给开发者提供全面且高效的自动化测试方案，目的是帮助开发者提升测试质量和测试效率。目前DevEco Studio3.1 Beta已集成了单元测试框架、分布式UI测试框架、评分工具、远程真机/远程模拟器及云测平台接入Portal共5项测试服务，详见图2。 针对分布式应用测试面临的挑战，我们接下来将重点介绍分布式UI测试框架和评分工具。（1）分布式UI测试框架分布式UI测试框架，定位于解决HarmonyOS分布式应用UI自动化测试及测试效率问题。主要包含以下特性：① 提供30+测试API，覆盖控件查找、控件操作、按键注入等，并支持基础的分布式UI自动化测试，如：findComponent, getText等。② 提供远程和本地描述方式一致的分布式测试API，仅参数不同，使用简单方便。通过UIDriver来实现。③ 分布式UI测试框架集成于IDE，开发者一键式开展自动化测试执行。点击进入分布式UI测试框架详细的使用教程官网>>（2）HarmonyOS分布式应用评分工具HarmonyOS分布式应用评分工具定位于帮助开发者本地快速测试，快速闭环问题，如图4所示。 图4 评分工具评分工具主要包含以下特性：  本地速测，无需编写用例支持兼容性/设计约束/UX/性能/稳定性测试支持源码级测试能力已支持24个检测项，执行时长<5分钟集成于DevEco Studio3.1 Beta版本3. 云测服务云测服务包含兼容性、安全、UX、性能、功耗、稳定性6项测试能力，支持流转、服务卡片等HarmonyOS关键特征自动化测试，同时还支持华为1+8多设备运行，帮助开发者全方位看护App基础质量。针对分布式应用测试面临的挑战，接下来重点介绍UX测试服务以及安全测试服务。（1）UX测试服务前面已经介绍过，HarmonyOS应用上架过程中UX问题占比很高，尤其在折叠屏、PAD等设备上，文字截断、布局错乱等问题较为突出。为此，HarmonyOS提供全新的UX测试服务，聚焦UX平台规范满足度以及UI显示异常故障检测，并支持在华为1+8设备上复用。检测能力如图5所示。 图5 检测能力概览UX平台规范是指HarmonyOS通用的UX平台规范，如：流转图标规范，可以在HarmonyOS应用开发者官网获取到。（2）安全测试服务安全测试服务包括隐私合规和漏洞检测两大部分。隐私合规检测能力对标“国际”、“国内隐私法规”及“行业规范”进行构建，主要定位于帮助开发者识别隐私违规的问题，减少因隐私问题导致的应用下线。检测能力包括公开透明、最小化、权限合规等6个大类，已支持20+自动检测能力，能较好地覆盖隐私设计原则。目前，隐私合规自动化测试存在功能场景自动化遍历、敏感数据提取和敏感行为检测、隐私声明一致性分析等关键技术难点，测试成本高，难度大，HarmonyOS通过如下测试技术，能有效解决检测自动化率和准确率的问题，处于业界领先。AI自动遍历技术，提升界面遍历深度和广度。OCR文本识别技术，提取UX界面的文字，识别隐私声明。 NLP语义分析技术，提取隐私敏感数据描述。动态沙箱仿真技术，构建敏感操作（如：改变位置信息模拟）的模拟能力。安全漏洞检测能力基于HarmonyOS安全管理要求进行构建，主要定位于识别并构建Ability安全、权限安全、加密安全、网络安全等8类漏洞检测能力，目前已经覆盖60+漏洞扫描规则，能有效帮助开发者充分识别漏洞隐患，如图6所示。图6 安全漏洞检测转载于华为开发者联盟服务微信公众号