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

为推进金融科技安全创新发展，金融科技产业联盟积极组织会员单位进行前瞻性研究，汇集研究成果及实践经验，形成《金融科技发展专报》，供监管部门和产业机构参考。当前，金融等重点行业都在进行数字化转型，而分布式数据库作为数据承载工具，为数字化转型提供了有力的支撑。分布式数据库近年来发展迅猛，在产品成熟度上有了很大提升，但在行业应用和生态建设上仍有很多挑战。本文分析了分布式数据库发展情况、分布式数据库应用的主要问题，从行业应用的角度给出了分布式数据库发展的建议。一、发展情况过去三十年，以金融业为代表的核心信息系统架构依托IOE（即IBM、Oracle、EMC）技术，构建了一套集中、专用、封闭的稳态技术体系。但是，随着互联网及云化时代的到来，企业业务架构产生巨大变化，以银行为代表的金融业需加速构建敏态体系，推动底层数据库的分布式改造和互联网金融业务创新。分布式数据库具有满足行业关键应用的高扩展性、高性能、高可用性及软硬件解耦等特性，是金融等重点行业信息系统数字化转型的基石。（一）产品成熟度提升随着分布式数据库在金融等重点行业的不断应用，产品成熟度得到很大提升。一是新技术的不断发展使得分布式数据库在自身固有的优势领域，如扩展性、高可用等方面进一步强化，已有多个应用在重点行业核心业务中落地。二是国产分布式数据库的性能已经实现了与其他商业数据库持平甚至超越，这在多个大型企业机构产品准入测试及业内国际基准测试（如在线交易场景TPCC、在线分析场景TPCH等）中得到充分证明，可对行业核心业务起到重要的支撑作用。三是更多厂商开始提供对主流国产分布式数据库的功能支持，产品的兼容性取得显著进展。管理控制软件、迁移工具等配套设施逐渐完善，极大地降低了数据库的使用门槛和迁移成本。（二）生态逐步完善一是加快推动分布式数据库在重点行业落地，主流分布式数据库厂商纷纷与众多大型银行、企业等开展联合创新活动，取得了许多突破性的成果。以某厂商的分布式数据库为例，在与大型商业银行的联创过程中，已完成10个以上业务系统的分布式数据库替换，覆盖银行A类到C类全场景业务。二是通过一站式的迁移解决方案，实现以较小的业务改造工作量从传统数据库向分布式数据库转型，迁移成本相对较低。而且使用分布式数据库后，业务系统运行稳定，可靠性和扩展性有所增强，从各项指标看，已基本具备承接Oracle及DB2大机下移的能力。三是分布式数据库相关的行业标准和评价体系逐步健全，对产品发展起到较强的规范引领作用。（三）总体发展情况向好当前国产分布式数据库已经渡过了“能用”阶段，正在迈向“好用、易用”阶段。横向来看，我国分布式数据库的发展基本与国际同步，tpcc、sysbench等性能指标和RTO、RPO等可靠性指标甚至具有优势，在应用领域取得些许领先。纵向来看，以金融业为例，分布式数据库应用取得较大进展，不管是在互联网新核心业务，还是传统核心业务中，分布式数据库行业应用落地数量大幅增加，有逐步替代集中式数据库的趋势。二、面临的主要问题（一）主体改造意愿不强，行业实践尚不充分一方面，原有数据库系统改造为分布式数据库，对用户及应用单位提出了较高的要求。改造所面临的成本问题，以及改造完成后分布式运维实施的复杂性，使得部分金融机构对于全面应用分布式还存在有一定的疑虑，主动改造意愿不强。另一方面，分布式数据库在行业典型应用场景中的落地仍处于摸索阶段。由于部分项目中存在一定的需求定制化，应用解决方案与产品的边界不够清晰，产品的规模化复制能力仍有待加强，行业最佳实践相对缺乏。这些因素也影响了金融机构对迁移采用分布式数据库技术的积极性。（二）分布式数据库的生态建设仍需加强生态建设是当前我国基础软件相对薄弱的一环，特别是对基于自研的分布式数据库厂商而言，虽然在实现技术和产品更加自主可控，但在生态建设方面仍需积极应对投入转化慢、门槛高、市场接受程度低等挑战。一方面，部分产品的技术体系相对封闭，用户无法从市场快速获取合格的开发运维人员，导致业务改造及生产运维仍严重依赖原厂，规模化复制效应较差。另一方面，部分产品的开放性仍有待提升，与其他平台数据互联互通的能力不足在客观上造成了业务“上车容易下车难”的现实困境，增加了用户被锁定的风险。（三）可持续发展的盈利模式需进一步探索我国数据库的发展可以追溯到30多年前，在这样一个相对较长的发展周期内，技术和产品都取得了显著进展，但在产业化方面，知识产权的保护不够充分等诸多问题造成部分参与主体的市场化盈利能力较弱，产业整体规模难以做大。分布式数据库虽然已取得了一定进展，但“池子深才能养大鱼”，如何依托当前政策窗口，真正形成可持续发展的商业模式，还需进一步探讨。三、行业的应用建议 尽管存在一些问题，但我们坚信分布式是数据库未来的发展趋势。如果将分布式数据库和单机数据库类比为“高铁”和“轿车”，因两者定位不同，期望“高铁”像“轿车”一样简单易用既不现实也不科学。所以应避免将分布式数据库的应用简单地理解为对单机或者集中式数据库的一对一替换，而要深入考虑如何充分发挥分布式数据库的技术优势。遵循以上思路，我们对于分布式数据库在金融等重点行业的应用提出以下几点建议：（一）通过技术创新和最佳实践，推动行业应用不断深入一方面，要探索利用人工智能等新技术提升产品服务效能。人工智能技术可实现自动数据分区规划、故障自动诊断和自愈、自动负载均衡、面向混合负载的自调优等功能。目前人工智能技术在分布式场景已经有了一些单点突破，但距离全场景落地、实现整体成本的全面降低还有很长的一段路要走，需要继续加以积极的行业引导，推进技术交流和产业落地。另一方面，需充分发挥好示范项目效应。在金融等重点行业典型应用场景如分布式架构设计、多地多中心容灾等，形成最佳解决方案，并在行业推广落地。在此过程中，提炼出更适合分布式数据库的开发、运维、硬件建设等相关要求，研究制定数据库开发、运维、应用方面的标准规范，提高行业的标准化水平，引导各参与主体规范应用分布式数据库，推进行业转型。同时应约束不必要的定制化需求，减少无序竞争，实现技术聚焦。（二）积极推动生态建设，发挥产业引领作用从软件发展历史看，生态建设是基础软件产业化的重要一环。任何一款商业上真正成功的软件产品，无一不是生态建设上获得广泛认可的成功案例。首先，充分发挥产业联盟桥梁纽带作用，推动产业发展。在行业内积极进行资源引流，逐步提升技术营运效率及影响力，搭建高端对话平台，促进分布式数据库应用方、应用开发方及厂商更好地交流，共同面对分布式转型下的业务及技术挑战，推进行业生态繁荣；加强与分布式中间件、分布式服务框架的合作与交流，通过开源、社区等形式建立广泛的赋能体系；鼓励应用软件厂商全面向分布式架构转型，建立相应的培训体系和检测认证体系。其次，完善技术生态，鼓励引入第三方软件垂直提供商。在运维管控、工具端以及解决方案层面实现更多差异化的平台能力，加厚行业整体的技术底盘；鼓励第三方产品服务化和上下游集成，推进各产品的互联互通，打造良好技术生态，促进行业健康发展。再次，建立基础软件开放生态体系，推动开源建设。应鼓励有研发实力的厂商基于国产开源数据库做发行商，有运维能力的厂商基于优质的国产数据库打造适用于自主可控要求的数据库解决方案。数据库厂商和合作伙伴应基于数据库代码开源、产品开放等形式，使数据库产业从封闭商业生态走向产业共赢的开放生态，共同打造开放的数据库生态体系。最后，进一步推进政产学研合作，加强人才储备。明确人才发展战略，梳理多层次行业人才资源地图。加强厂商与各科研院所合作，推进高校在包括数据库在内的基础软件方面专业投入，鼓励有条件的厂商和高校开展课程共建、实践共建，为联合推进分布式数据库关键技术在理论和实践层面的难点问题攻关储备智力资源。（三）全面拥抱云，开展行业可持续发展的尝试与探索数据库上云已逐步成为产业共识。根据Gartner的统计，到2021年，云数据库在整个数据库市场中的占比将首次达到50%；而到2023年，75%的数据库将会跑在云平台之上。发展云数据库，不仅是对技术和产品的重要升级，更是对数据库良性健康发展的商业模式有益探索，对于实现主体可控、支撑行业长期稳定发展具有重要的现实意义。分布式数据库与单机数据库不同，需要更大的集群规模才能实现资源的更有效利用。分布式数据库与云计算是天然伴生关系，通过云化部署，能够帮助分布式数据库扬长避短，充分发挥分布式数据库在扩展性、资源调度方面的灵活性和优势，在提升资源利用效率同时，显著降低运维成本，实现真正业务价值。一是云化基础设施可以通过智能调度、运维系统高效管理更为丰富的应用，并通过多云及边缘计算将应用扩展到多种场景中。二是软硬协同可为应用提供更好的性能，提升应用隔离性等。三是云数据库和云基础设施结合，如利用云基础设施本身的能力实现数据库的跨数据中心访问等，可使存储具备理解、预处理数据库语义的能力。 基于以上，一是建议扩大云数据库在金融行业的应用规模。云数据库已经在互联网、电子政务等各行业得到了广泛应用，在金融行业的应用及推广也在稳步推进中。应引导重点用户单位与厂商尝试在行业落地云数据库及云平台，鼓励技术共创，共同探索基于现代云平台的分布式数据库运维及业务开发体系。二是建议推进行业云发展以提高行业标准化程度。在满足合规营运的前提下，应实现底层基础设施共享，降低中小用户对于分布式数据库的使用门槛和人才需求，减少重复投资，实现集约化营运，充分发挥分布式数据库的规模化优势。厘清各参与主体运营职责与边界，依托业内现有的成熟云平台技术，形成一个或若干个云技术底座，鼓励传统非云数据库厂商根据自身产品技术特点完成与云平台的对接，最终形成行业的云上产品集市，逐步简化并统一运维及交付界面，降低行业应用门槛，提高行业标准化程度。 来源：发展研究部

三个mon节点配置，重启1个mon节点观察现象：mon部署到node1,node2,client1上 ， client1没有OSD重启mon.client1,查看集群状态，可见 1/3 mons down, quorum node1,node2 告警等待复位的mon节点重新启动完成，查询状态恢复健康：vdbench业务流量也不受影响，未观察到明显波动； 剩余2个mon节点时，集群有告警，但功能与性能正常三个mon节点配置，重启2个mon节点验证：mon节点与OSD分开部署：（mon on node1 client1 client3三台服务器）重启2个mon节点此时VDbench压力不受影响，但是命令会卡住（只有1个mon节点），启动后，集群恢复健康，可正常执行命令：vdbench业务流量，未观察到明显变化，没有影响流量，但1个mon节点已经影响了命令执行，mon恢复后，集群恢复正常所以至少要有2个mon节点正常工作

验证触发mgr主备切换时，对集群性能是否有影响先给集群打上背景流量：ceph -s状态：停掉node3的mgr(active mgr)服务：systemctl stop ceph-mgr@node3ceph -s 观察，完成mgr@node3到mgr@node1的倒换，集群健康状态正常，client流量无明显波动。

通过手动触发的方式去验证scrub能力：找一个OSD目录：ls /var/lib/ceph/osd/ceph-5/current/pg 121.e9 删掉一个文件：手动执行：ceph pg scrub 121.e9检测结果：手动执行修复ceph pg repair 121.e9连续监控 ceph -s 状态，从 ERR变为OK

组件介绍CephCeph 是一个专注于分布式的、弹性可扩展的、高可靠的、性能优异的存储系统平台，可以同时支持块设备、文件系统和对象网关三种类型的存储接口。本文介绍的调优手段包括硬件层面和软件配置层面的优化，暂不涉及软件源码层面的优化。通过调整系统和Ceph配置参数，Ceph可以更充分的发挥系统硬件性能。Ceph PG分布调优和OSD绑核旨在让磁盘负载更平均，避免个别OSD成为瓶颈。此外，均衡型场景下，用NVMe SSD做Bcache也可以提升性能。Ceph架构如图1所示。图1 Ceph架构Ceph的模块及组件说明如表1所示。表1 模块说明模块名称功能描述RADOSRADOS（Reliable Autonomic Distributed Object Store，RADOS）是Ceph存储集群的基础。Ceph中的一切都以对象的形式存储，而RADOS就负责存储这些对象，而不考虑它们的数据类型。RADOS层确保数据一致性和可靠性。对于数据一致性，它执行数据复制、故障检测和恢复，还包括数据在集群节点间的recovery。OSD实际存储数据的进程。通常一个OSD daemon绑定一个物理磁盘。Client write/read数据最终都会走到OSD去执行write/read操作。MONMonitor在Ceph集群中扮演者管理者的角色，维护了整个集群的状态，是Ceph集群中最重要的组件。MON保证集群的相关组件在同一时刻能够达成一致，相当于集群的领导层，负责收集、更新和发布集群信息。为了规避单点故障，在实际的Ceph部署环境中会部署多个MON，同样会引来多个MON之前如何协同工作的问题。MGRMGR目前的主要功能是一个监控系统，包含采集、存储、分析（包含报警）和可视化几部分，用于把集群的一些指标暴露给外界使用。Librados简化访问RADOS的一种方法，目前支持PHP、Ruby、Java、Python、C和C++语言。它提供了Ceph存储集群的一个本地接口RADOS，并且是其他服务（如RBD、RGW）的基础，此外，还为CephFS提供POSIX接口。Librados API支持直接访问RADOS，使开发者能够创建自己的接口来访问Ceph集群存储。RBDCeph块设备，对外提供块存储。可以像磁盘一样被映射、格式化和挂载到服务器上。RGWCeph对象网关，提供了一个兼容S3和Swift的RESTful API接口。RGW还支持多租户和OpenStack的Keystone身份验证服务。MDSCeph元数据服务器，跟踪文件层次结构并存储只供CephFS使用的元数据。Ceph块设备和RADOS网关不需要元数据。MDS不直接给Client提供数据服务。CephFS提供了一个任意大小且兼容POSlX的分布式文件系统。CephFS依赖Ceph MDS来跟踪文件层次结构，即元数据。VdbenchVdbench是一个命令行实用程序，旨在帮助工程师和客户生成用于验证存储性能和存储数据完整性的磁盘IO负载。还可通过输入文本文件指定Vdbench 执行参数。Vdbench工具参数很多，表2列举了几个重要的常用参数。表2 常用参数配置项说明-f指定一个压力测试的脚本文件-o指定输出报告的路径，默认是当前路径lun测试的LUN设备或文件size设置测试LUN或测试文件的大小rdpct读所占百分比，100表示全读，0表示全写seekpct随机数据所占百分比，100代表全随机，0代表顺序elapsed定义本次运行测试时间环境介绍物理组网Ceph块设备物理环境采用“两层网络+三节点”的部署方案，其中，MON、MGR、MDS节点与OSD存储节点混合部署。在网络层面，Public网络与Cluster网络分离，两者均采用25GE光口来进行网络间的通信。物理组网如图1所示。图1 物理组网硬件配置Ceph所使用的环境如表1所示。表1 硬件配置服务器名称TaiShan 200服务器（型号2280）处理器鲲鹏920 5230处理器核数2*32核主频2600MHz内存大小12*16GB内存频率2666MHz（8*Micron 2R）网卡IN200网卡4*25GE硬盘系统盘：RAID1（2*960GB SATA SSD）均衡型配置数据盘：RAID模式下使能JBOD（12*4TB SATA HDD）NVMe SSD均衡性配置加速盘：1*ES3600P V5 3.2TB NVMe SSD高性能配置数据盘：12*ES3600P V5 3.2TB NVMe SSDRAID卡Avago SAS 3508软件版本使用到的相关软件版本如表2所示。表2 软件版本软件版本OSCentOS Linux release 7.6.1810openEuler 20.03 LTS SP1Ceph14.2.x Nautilusceph-deploy2.0.1Vdbench5.04.06节点信息主机的IP网段规划信息如表3所示。表3 节点信息主机类型主机名称Public 网段Cluster 网段OSD/MON节点node1192.168.3.0/24192.168.4.0/24OSD/MGR节点node2192.168.3.0/24192.168.4.0/24OSD/MDS节点node3192.168.3.0/24192.168.4.0/24组件部署对于Ceph块设备集群，其相关服务组件部署方式如表4所示。表4 组件部署物理机名称OSDMONMGRnode112*OSD1*MON1*MGRnode212*OSD1*MON1*MGRnode312*OSD1*MON1*MGR集群检查可以输入ceph health查看集群健康状态，显示HEALTH_OK表示集群正常。调优原则与思路块存储调优主要分为：均衡型配置调优以机械硬盘（HDD）作为数据盘，并配置适量固态硬盘（SSD）作为DB/WAL分区、元数据存储池的场景。高性能配置调优即所有数据盘都是用固态硬盘（SSD）的场景。请根据实际场景选择一种配置进行调优。调优原则在性能优化时，需要遵循一定的原则，主要有以下几个方面：对性能进行分析时，要多方面分析系统的资源瓶颈所在，如CPU利用率达到100%时，也可能是内存容量限制，导致CPU忙于处理内存调度。一次只对一个性能指标参数进行调整。分析工具本身运行可能会带来资源损耗，导致系统某方面的资源瓶颈情况更加严重，应避免或降低对应用程序的影响。调优思路调优分析思路如下：很多情况下压测流量并没有完全进入到后端（服务端），在网络接入层（云化的架构，比如：SLB/WAF/高防IP，甚至是CDN/全站加速等）可能就会出现由于各种规格（带宽、最大连接数、新建连接数等）限制或者因为压测的某些特征符合CC和DDoS的行为而触发了防护策略导致压测结果达不到预期。接着看关键指标是否满足要求，如果不满足，需要确定是哪个地方有问题，一般情况下，服务器端问题可能性比较大，也有可能是客户端问题（这种可能性非常小）。对于服务器端问题，需要定位的是硬件相关指标，例如CPU，Memory，Disk IO，Network IO，如果是某个硬件指标有问题，需要深入的进行分析。如果硬件指标都没有问题，需要查看中间件相关指标，例如：线程池、连接池、GC等，如果是这些指标问题，需要深入的分析。如果中间件相关指标没问题，需要查看数据库相关指标，例如：慢查SQL，命中率，锁、参数设置。如果以上指标都正常，应用程序的算法、缓冲、缓存、同步或异步可能有问题，需要具体深入的分析。可能的瓶颈点如表1所示。表1 可能的瓶颈点瓶颈点说明硬件/规格一般指的是CPU、内存、磁盘IO方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）。中间件一般指的是应用服务器、web服务器等应用软件，还包括数据库系统。例如：中间件weblogic平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。应用程序一般指的是开发人员开发出来的应用程序。例如，JVM参数不合理，容器配置不合理，慢SQL，数据库设计不合理，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够、无缓冲、无缓存、生产者和消费者不协调等），造成系统在大量用户方位时性能低下而造成的瓶颈。操作系统一般指的是Windows、UNIX、Linux等操作系统。例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。网络设备一般指的是防火墙、动态负载均衡器、交换机等设备。当前更多的云化服务架构使用的网络接入产品：包括但不限于SLB/WAF/高防IP/CDN/全站加速等等。例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。调优的通用步骤：调优通用步骤如图1所示。图1 调优通用步骤均衡型配置调优1. 硬件调优：硬件调优_鲲鹏BoostKit分布式存储使能套件_调优指南_Ceph块存储 调优指南_均衡型配置调优_华为云 (huaweicloud.com)2. 系统调优： 系统调优_鲲鹏BoostKit分布式存储使能套件_调优指南_Ceph块存储 调优指南_均衡型配置调优_华为云 (huaweicloud.com)3. ceph调优：  Ceph调优_鲲鹏BoostKit分布式存储使能套件_调优指南_Ceph块存储 调优指南_均衡型配置调优_华为云 (huaweicloud.com)4.  KAE zlib压缩调优： KAE zlib压缩调优_鲲鹏BoostKit分布式存储使能套件_调优指南_Ceph块存储 调优指南_均衡型配置调优_华为云 (huaweicloud.com)高性能配置调优1. 硬件调优高性能配置调优目的保证两个CPU负载较为均衡。方法将NVMe SSD与网卡均衡地插在两个CPU上。硬件类型优化项备注网卡NUMA资源均衡例如将板载网卡插到CPU1所属的PCIe槽位，将Mellanox CX4插到CPU2所属的PCIe槽位，使两个CPU负载较为均衡存储NUMA资源均衡例如将其中6*NVMe SSD插到CPU1所属的PCIe槽位，将另外6*NVMe SSD插到CPU2所属的PCIe槽位，使两个CPU负载较为均衡2. 系统调优OS配置调优目的调整系统配置选项，充分发挥系统硬件性能。方法具体优化项详见表1。表1 OS配置参数参数名称参数含义优化建议配置方法vm.swappinessswap为系统虚拟内存，使用虚拟内存会导致性能下降，应避免使用。默认值：60现象：用到swap时性能明显下降修改建议：关闭swap内存的使用，将该参数设定为0执行命令：sudo sysctl vm.swappiness=0 MTU网卡所能通过的最大数据包的大小，调大后可以减少网络包的数量以提高效率。默认值：1500 Bytes现象：可以通过ip addr命令查看修改建议：网卡所能通过的最大数据包的大小设置为9000 Bytes执行命令：vi /etc/sysconfig/network-scripts/ifcfg-$(Interface) 并增加MTU="9000"说明：${Interface}为网口名称。完成后重启网络服务。service network restartpid_max系统默认的“pid_max”值为32768，正常情况下是够用的，但跑重量任务时会出现不够用的情况，最终导致内存无法分配的错误。默认值：32768现象：通过cat /proc/sys/kernel/pid_max查看修改建议：设置系统可生成最大线程数为4194303执行命令：echo 4194303 > /proc/sys/kernel/pid_maxfile_max“file-max”是设置系统所有进程一共可以打开的文件数量。同时一些程序可以通过setrlimit调用，设置每个进程的限制。如果得到大量使用完文件句柄的错误信息，则应该增加这个值。默认值：13291808现象：通过cat /proc/sys/fs/file-max查看修改建议：设置系统所有进程一共可以打开的文件数量，设置为cat /proc/meminfo | grep MemTotal | awk '{print $2}'所查看到的值执行命令：echo ${file-max} > /proc/sys/fs/file-max说明：${file-max}为cat /proc/meminfo | grep MemTotal | awk '{print $2}' 所查看到的值。read_aheadLinux的文件预读readahead，指Linux系统内核将指定文件的某区域预读进页缓存起来，便于接下来对该区域进行读取时，不会因缺页（page fault）而阻塞。鉴于从内存读取比从磁盘读取要快很多，预读可以有效的减少磁盘的寻道次数和应用程序的IO等待时间，是改进磁盘读IO性能的重要优化手段之一。默认值：128 KB现象：预读可以有效的减少磁盘的寻道次数和应用程序的IO等待时间。通过/sbin/blockdev --getra /dev/sdb查看修改建议：通过数据预读并且记载到随机访问内存方式提高磁盘读操作，调整为8192 KB执行命令：/sbin/blockdev --setra /dev/sdb说明：此处以“/dev/sdb”为例，对所有服务器上的所有数据盘都要修改。I/O_SchedulerLinux IO调度器是Linux内核中的一个组成部分，用户可以通过调整这个调度器来优化系统性能。默认值：CFQ现象：要根据不同的存储器来设置Linux IO调度器从而达到优化系统性能修改建议：IO调度策略，HDD设置为deadline，SSD设置为noop执行命令：echo deadline > /sys/block/sdb/queue/scheduler说明：此处以“/dev/sdb”为例，对所有服务器上的所有数据盘都要修改。nr_requests在Linux系统中，如果有大量读请求，默认的请求队列或许应付不过来，Linux可以动态调整请求队列数，默认的请求队列数存放在“/sys/block/hda/queue/nr_requests”文件中默认值：128现象：通过适当的调整nr_requests参数可以提升磁盘的吞吐量修改建议：调整硬盘请求队列数，设置为512执行命令：echo 512 > /sys/block/sdb/queue/nr_requests说明：此处以“/dev/sdb”为例，对所有服务器上的所有数据盘都要修改。NUMA亲和优化方法保证网络和存储资源均衡地分配到各个NUMA节点。目的此处以12块NVMe SSD和4个网口为例，均衡分配到4个NUMA节点。NVMe SSD编号0~11，网口名为enps0f0,enps0f1,enps0f2,enps0f3。for i in {0..11}; do echo `expr ${i} / 3` > /sys/class/block/nvme${i}n1/device/device/numa_node; done for j in {0..3}; do echo ${j} > /sys/class/net/enps0f${j}/device/numa_node; done3. Ceph调优Ceph配置调优目的调整Ceph配置选项，充分发挥系统硬件性能。方法所有的ceph配置参数都是通过修改“/etc/ceph/ceph.conf”实现的。以上操作只是对当前Ceph节点生效，需要修改所有Ceph节点的“ceph.conf”文件并重启Ceph守护进程才对整个Ceph集群生效。表1 Ceph参数配置参数名称参数含义优化建议[global]osd_pool_default_min_sizePG处于degraded状态不影响其IO能力,min_size是一个PG能接受IO的最小副本数。默认值：0修改建议：1cluster_network配置一层不同于public network的网段，用于OSD间副本复制/数据均衡，缓解public network网络压力。默认值：/修改建议：192.168.4.0/24osd_pool_default_size副本数设置。默认值：3修改建议：3mon_max_pg_per_osd阈值项：调大PG告警阈值默认值：250修改建议：3000mon_max_pool_pg_num阈值项：调大PG告警阈值默认值：65536修改建议：300000debug_none关闭debug开关，减少日志打印开销修改建议：0/0debug_lockdepdebug_contextdebug_crushdebug_mdsdebug_mds_balancerdebug_mds_lockerdebug_mds_logdebug_mds_log_expiredebug_mds_migratordebug_bufferdebug_timerdebug_filerdebug_striperdebug_objecterdebug_radosdebug_rbddebug_rbd_mirrordebug_rbd_replaydebug_journalerdebug_objectcacherdebug_clientdebug_osddebug_optrackerdebug_objclassdebug_filestoredebug_journaldebug_msdebug_mondebug_moncdebug_paxosdebug_tpdebug_authdebug_cryptodebug_finisherdebug_reserverdebug_heartbeatmapdebug_perfcounterdebug_rgwdebug_civetwebdebug_javaclientdebug_asokdebug_throttledebug_refsdebug_xiodebug_compressordebug_bluestoredebug_bluefsdebug_bdevdebug_kstoredebug_rocksdbdebug_leveldbdebug_memdbdebug_kineticdebug_fusedebug_mgrdebug_mgrcdebug_dpdkdebug_eventtracethrottler_perf_counter默认开启，可以观察阈值是否达到瓶颈。性能调节到最佳后，建议关闭，tracker影响性能默认值：True修改建议：Falsems_dispatch_throttle_bytes等待调度的最大消息数，建议调大，提高消息处理效率默认值：104857600修改建议：2097152000ms_bind_before_connect消息队列绑定，保证多网口流量均衡默认值：False修改建议：True[client]rbd_cache关闭客户端cache。关闭后rbd cache一直是writethrough模式默认值：True修改建议：False[osd]osd_max_write_sizeOSD一次可写入的最大值（MB）默认值：90修改建议：256osd_client_message_size_cap客户端允许在内存中的最大数据（Bytes）默认值：524288000修改建议：1073741824osd_map_cache_size保留OSD Map的缓存（MB）默认值：50修改建议：1024bluestore_rocksdb_optionsrocksdb配置参数默认值： compression=kNoCompression,max_write_buffer_number=4,min_write_buffer_number_to_merge=1,recycle_log_file_num=4,write_buffer_size=268435456,writable_file_max_buffer_size=0,compaction_readahead_size=2097152,max_background_compactions=2 修改建议：compression=kNoCompression,max_write_buffer_number=64,min_write_buffer_number_to_merge=32,recycle_log_file_num=64,compaction_style=kCompactionStyleLevel,write_buffer_size=4MB,target_file_size_base=4MB,max_background_compactions=16,level0_file_num_compaction_trigger=64,level0_slowdown_writes_trigger=128,level0_stop_writes_trigger=256,max_bytes_for_level_base=6GB,compaction_threads=8,flusher_threads=4,compaction_readahead_size=2MBbluestore_csum_type不指定checksum type类型默认值：crc32c修改建议：nonemon_osd_full_ratio将OSD视为已满之前使用的磁盘空间的百分比。数据量超过这个百分比后会停止一切读写操作，直到扩容或清除数据量至小于该百分比默认值：0.95修改建议：0.97mon_osd_nearfull_ratio将OSD视为近似之前使用的磁盘空间的百分比。数据量超过这个百分比后会产生告警，提示空间即将耗尽默认值：0.85修改建议：0.95osd_min_pg_log_entriesPGLog记录条数下阈值默认值：3000修改建议：10osd_max_pg_log_entriesPGLog记录条数上阈值默认值：3000修改建议：10bluestore_cache_meta_ratiobluestore cache中分配给meta的比例默认值：0.4修改建议：0.8bluestore_cache_kv_ratiobluestore cache中分配给kv的比例默认值：0.4修改建议：0.2具体优化项详见表1。比方说要修改默认副本数为4，则在“/etc/ceph/ceph.conf”文件中添加“osd_pool_default_size = 4”这一行字段，然后systemctl restart ceph.target重启Ceph守护进程使之生效。PG分布调优目的调整每个OSD上承载的PG数量，使每个OSD的负载更加均衡。方法Ceph默认为每个存储池分配8个“pg/pgp”，在创建存储池的时候使用ceph osd pool create {pool-name} {pg-num} {pgp-num}指定“pg/pgp”数量，或者使用ceph osd pool set {pool_name} pg_num {pg-num}和ceph osd pool set {pool_name} pgp_num {pgp-num}修改已创建好的存储池的“pg/pgp”数量。修改完成后使用ceph osd pool get {pool_name} pg_num/pgp_num查看存储池的“pg/pgp”数量。PG分布参数配置如表2所示：说明：每个OSD上承载的PG数量应相同或非常接近，否则容易出现个别OSD压力较大成为瓶颈，运用balancer插件可以实现PG分布优化，可通过ceph balancer eval或ceph pg dump随时查看当前PG分布情况。通过ceph balancer mode upmap以及ceph balancer on使Ceph PG自动均衡优化，Ceph每隔60秒会调整少量PG分布。通过ceph balancer eval或ceph pg dump随时查看当前PG分布情况，若PG分布情况不再变化，则说明分布已达到最佳。上述每个OSD对应的PG分布主要影响写入的负载均衡。除了每个OSD对应的PG数量优化外，主PG的分布情况也需要视情况优化，即尽可能地将主PG均匀分布到各个OSD上。表2 PG分布参数配置参数名称参数说明优化建议pg_numTotal PGs = (Total_number_of_OSD * 100) / max_replication_count，得出的结果向上取到最近的2的整数次幂。默认值：8现象：pg数量太少的话会有warning提示修改建议：根据计算公式具体计算得到的值pgp_numpgp数量设置为与pg相同。默认值：8现象：pgp数量建议与pg数量相同修改建议：根据计算公式具体计算得到的值ceph_balancer_mode使能balancer均衡器插件，并设置均衡器插件模式为“upmap”。默认值：none现象：若PG数量不均衡会出现个别OSD负载较大而成为瓶颈修改建议：upmap“ceph balancer mode”默认为“none”，用ceph balancer mode upmap命令调整为“upmap”。“ceph balancer”功能默认不打开，ceph balancer on/off用来打开/关闭“ceph balancer”功能。OSD绑核目的建议将OSD进程绑定到固定CPU上。方法通过修改“/etc/ceph/ceph.conf”文件，添加“osd_numa_node = <NUM>”即可。表3 OSD绑核参数配置参数名称参数说明优化建议[osd.n]osd_numa_node将osd.n守护进程绑定到指定空闲NUMA节点上，此处的空闲NUMA节点指处理网卡软中断的节点以外的节点。默认值：无现象：若OSD进程所在CPU和与网卡中断相同，可能会出现个别CPU和压力过大的情况修改建议：分离CPU负载压力，避免OSD进程与网卡中断或其他高CPU消耗的进程运行在同一NUMA节点上说明：Ceph OSD守护进程应当与网卡软中断在不同的NUMA节点上处理，否则在网络压力大的时候容易出现CPU瓶颈。Ceph默认会将OSD进程均匀地分不到所有CPU core，可以在ceph.conf中加入osd_numa_node配置选项，避免OSD进程与网卡中断或其他高CPU消耗的进程运行在同一NUMA节点上。网络性能调优将网卡软中断绑定到所属NUMA节点的CPU core上，当网络压力较大时，绑定了软中断的CPU core利用率较高，建议将osd_numa_node设置为与网卡不同的NUMA节点。例如，通过命令cat /sys/class/net/ <网口名> /device/numa_node查询到网卡归属于NUMA节点2，则设置osd_numa_node = 0或者osd_numa_node = 1，尽量避免OSD与网卡软中断使用相同的CPU core。具体优化项如表3所示。

目  录1 软件介绍2 环境配置3 软件安装3.1 BishengJDK安装3.2 Maven安装3.3 Ratis-thirdparty安装3.4 Alluxio编译安装3.5 迁移结果检测4 软件运行4.1 运行alluxio5 其他1 软件介绍Alluxio是一个基于内存的分布式文件系统，它是架构在底层分布式文件系统和上层分布式计算框架之间的一个中间件，主要职责是以文件形式在内存或其它存储设施中提供数据的存取服务。  2 环境配置本文档基于TaiShan 200服务器硬件环境展开。服务器TaiShan 200 2280处理器2*KunPeng 920 4826内存16*32G 2666MHz系统盘1 * 1.2T SATA HDD数据盘1 * 960G SSD网络1 * GE(板载)  1 * 10GE(1822)  软件平台软件名称版本号安装方法备注CentOS7.6https://support.huawei.com/enterprise/zh/doc/EDOC1100088654/3e971c8d本文档安装过程选择的环境为“Server with GUI”，并附加了“Development Tools”。BishengJDK8u272详见4.1章节OpenJDK或者毕昇JDK 均可，要求1.8后的版本Maven3.6.1详见4.2章节要求3.3.9或其后的版本Ratis-thirdparty0.5.0详见4.3章节Alluxio v2.4.1依赖于该jar包的0.5.0版本  3 软件安装3.1 BishengJDK安装3.1.1 下载并解压BishengJDK 8u272版本本文档将文件解压到/opt目录，请根据实际需要选择解压目录wget https://mirrors.huaweicloud.com/kunpeng/archive/compiler/bisheng_jdk/bisheng-jdk-8u272-linux-aarch64.tar.gz tar –zxvf bisheng-jdk-8u272-linux-aarch64.tar.gz -C /opt3.1.2 配置环境变量vi /etc/profile # 将以下环境变量信息粘贴到profile文件最末尾。 # 注意：如果步骤1修改了目录，请修改JAVA_HOME为实际路径 export JAVA_HOME=/opt/bisheng-jdk1.8.0_272 export JRE_HOME=$JAVA_HOME/jre export CLASSPATH=$JAVA_HOME/lib;$JRE_HOME/lib:$CLASSPATH export PATH=$JAVA_HOME/bin:$PATH3.1.3 生效环境变量source /etc/profile3.1.4 检查版本信息java -version3.2 Maven安装3.2.1 下载并解压Maven 3.6.1版本本文档将文件解压到/opt目录，请根据实际需要选择解压目录wget https://archive.apache.org/dist/maven/maven-3/3.6.1/binaries/apache-maven-3.6.1-bin.tar.gz tar –zxvf apache-maven-3.6.1-bin.tar.gz -C /opt3.2.2 配置环境变量vi /etc/profile # 将以下环境变量信息粘贴到profile文件最末尾。 # 注意：如果步骤1修改了目录，请修改MAVEN_HOME为实际路径 export MAVEN_HOME=/opt/apache-maven-3.6.1 export PATH=$MAVEN_HOME/bin:$PATH3.2.3 生效环境变量source /etc/profile3.2.4 检查版本信息mvn -v3.3 Ratis-thirdparty安装3.3.1 下载并解压ratis-thirdparty 0.5.0-rc0版本本文档将文件解压到/opt目录，请根据实际需要选择解压目录wget https://github.com/apache/ratis-thirdparty/archive/0.5.0-rc0.tar.gz tar –zxvf 0.5.0-rc0.tar.gz -C /opt cd ratis-thirdparty-0.5.0-rc03.3.2 添加插件源参考vi pom.xml 将以下仓库信息粘贴到properties标签后。 <pluginRepositories> <pluginRepository> <id>kunpeng</id> <url>http://mirrors.huaweicloud.com/kunpeng/maven</url> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> <pluginRepository> <id>huaweicloud-plugin</id> <url>http://mirrors.huaweicloud.com/repository/maven</url> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> </pluginRepositories>3.3.3 修改misc/pom.xml中x86链接库为aarch64链接库vi misc/pom.xml #删除x86_64相关的dll和jnilib信息，将so改为aarch64 <exclude>META-INF/native/libnetty_tcnative_linux_aarch64.so</exclude> <fileSet> <sourceFile>${project.build.directory}/classes/META-INF/native/libnetty_tcnative_linux_aarch64.so</sourceFile> <destinationFile>${project.build.directory}/classes/META-INF/native/lib${ratis.thirdparty.shaded.native.prefix}netty_tcnative_linux_aarch64.so</destinationFile> </fileSet>3.4.4 编译安装。cd misc mvn clean install -DskipTests如果没有修改maven依赖包的保存路径，默认会在~/.m2/repository/下生成相关的jar，如下3.4.5 检验jar包迁移结果安装鲲鹏代码迁移工具Porting advisor（指导书见：https://support.huaweicloud.com/ug-pa-kunpengdevps/kunpengpt_06_0004.html ），并对生成的ratis-thirdparty-misc-0.5.0.jar进行扫描，结果如下3.4 Alluxio编译安装3.4.1 下载依赖库 yum install –y git3.4.2 下载alluxio v2.4.1源码不建议采用github的releases包，编译过程缺少git版本信息，需要修改部分文件才能完成编译。如无外网环境，可在其他机器下载源码再转发到服务器上。git clone --branch v2.4.1 https://github.com/Alluxio/alluxio.git cd alluxio3.4.3 修改依赖仓库源和插件源vi pom.xml #在repositories标签内头部添加Kunpeng镜像仓 #在repositories标签后添加插件源 <repositories> <repository> <id>kunpeng</id> <url>https://mirrors.huaweicloud.com/kunpeng/maven/</url> <releases> <enabled>true</enabled> </releases> </repository> … <pluginRepositories> <pluginRepository> <id>kunpeng</id> <url>http://mirrors.huaweicloud.com/kunpeng/maven</url> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> <pluginRepository> <id>huaweicloud-plugin</id> <url>http://mirrors.huaweicloud.com/repository/maven</url> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> </pluginRepositories>3.4.4 修改x86链接库信息vi shared/client/pom.xml将x86_64的链接库信息修改为aarch643.4.5 编译alluxio如果添加其他插件的支持，请参考官方文案（见第六章）mvn clean install -DskipTests3.5 迁移结果检测3.5.1 安装鲲鹏代码迁移工具Porting advisor指导书见：https://support.huaweicloud.com/ug-pa-kunpengdevps/kunpengpt_06_0004.html 3.5.2 将alluxio文件夹复制到指定目录下登录Porting advisor并创建用户后，将文件夹复制到扫描的目录cp –r alluxio /opt/portadv/portadmin/package3.5.3 使用“分析软件包”功能扫描alluxio由于整个alluxio文件夹较大，无法一次性完成扫描，所以分多次扫描子目录，以下图片仅展示部分结果 4 软件运行4.1 运行alluxio4.1.1 创建默认存储目录默认配置下文件夹为underFSStorage，必须手动创建，如需修改请先复制conf/alluxio-env.sh.template为conf/alluxio-env.sh并修改cd alluxio mkdir ./underFSStorage4.1.2 执行环境验证 ./bin/alluxio validateEnv local4.1.3 执行格式化 ./bin/alluxio format4.1.4 启动服务./bin/alluxio-start.sh local SudoMount4.1.5 运行自带的简单测试./bin/alluxio runTests4.1.6 登录后台查看具体详情 http://localhost:19999 5 其他参考文档：https://docs.alluxio.io/os/user/stable/en/contributor/Building-Alluxio-From-Source.html建议查看英文文档，中文文档部分章节久未更新，与实际使用不符            

存储集群配置7200转硬盘，更换其中一块为5900转的硬盘模拟慢盘观察ceph性能相关统计插入一块 5900rpm 硬盘模拟慢盘：vdbench 对存储集群打上背景压力：iostat，可见性能差的盘“sdn”占用率较高,优先达到瓶颈，会影响整体性能同时观察osd延时，sdn（osd.0）明显高于其他osd，左边osd0，右边osd1ceph daemonperf osd.0 ceph daemonperf osd.1抓取 ceph osd perf记录，200次，观察ceph osd tree 延时的平均值，if [ $# != 1 ]thenecho "please input the num, example: ./$0 200"exit 1fia=$1file="log_perf.log"mv $file ${file}_`date +%Y%m%d%H%M%S`.logfor((i=1;i<=$a;i++))doceph osd perf >> $filesleep 1echo "times= $i " >> $file#t1=`date +%T`t1=`date`echo "time: $t1" >> $fileecho "*****************************************************************************************"for j in {0..35}doif [ $j -lt 10 ]thencat $file |grep -E '^ '${j}'' |awk -F " " '{sum += $3} END { print "osd = " '$j' "," "round = " NR "," "sum = " sum "," "lat_average(ms) = " sum/NR }'elsecat $file |grep -E '^ '${j}'' |awk -F " " '{sum += $3} END { print "osd = " '$j' "," "round = " NR "," "sum = " sum "," "lat_average(ms) = " sum/NR }'fidonedone可观察到osd.0延时明显大于其他osd：slow ops模拟：osd_recovery_max_active = 100osd_recovery_max_single_start = 30osd_max_backfills = 30观察集群状态：

大家好！我是酷哥，数据库相关资讯，带您速览，欢迎大家阅读。 **本期整理如下：** ----------------------------------------------- **本期精选** ------------------------------------------------ - 华为、腾讯、阿里、字节等纷纷布局东数西算 - 解码高瓴的数据库布局：开源、分布式、图数据库、实时数据 - GreenPlum完全兼容欧拉开源操作系统 - 开源数据库MariaDB通过SPAC再**，开启新征程 - 通用数据库管理工具DBeaver 21.3.5 发布 - SQLite 3.38正式发布：改进JSON支持 增强CLI体验 - PostgreSQL 开始支持 Zstd - 最快的SQL计算引擎MatrixOne 0.2.0 发布 - 云迁移将持续深入，今年企业IT支出将超过1.3万亿美元 - 观远数据完成老虎**基金领投的2.8亿元C轮融资 - 时序数据库 Timescale 完成C轮1.1亿融资，数据库领域添独角兽 - 中国自主的数据库评测，是如何开展的？ - 中国信通院——开源分布式关系型数据库专刊正式启动 ------------------------------------------------ **资讯全文** ------------------------------------------------ - 华为、腾讯、阿里、字节等纷纷布局东数西算 **摘要：** 财联社《TMT时报》上海报道 作为数字经济的核心基础设施，数据中心正迎来新一轮发展契机。华为、腾讯、阿里、字节等纷纷布局东数西算。 “东数西算”工程于近日正式全面启动，计划在京津冀、长三角、粤港澳大湾区、成渝、贵州、内蒙古、甘肃、宁夏8地布局建设全国一体化算力网络国家枢纽节点，并规划10个国家数据中心集群。国内数据中心产业链上下游企业均有望受益。 **文章详情：** https://tieba.baidu.com/p/7735484697 - 解码高瓴的数据库布局：开源、分布式、图数据库、实时数据 **摘要：** 过去一年是国产数据库诞生以来投融资最为火热的一年。作为基础软件的“三驾马车”之一，这个过往的冷门赛道，在2021年内，出现了几个指标性拐点数字：明星公司PingCap估值高达180亿，超过20家数据库企业获得新融资，而以高瓴、红杉、腾讯为代表的头部基金们出手数据库的次数均超过了3家。 **文章详情：** https://tieba.baidu.com/p/7738189880 - GreenPlum完全兼容欧拉开源操作系统 **摘要：** 近日，Greenplum 社区和欧拉开源社区深化合作，在欧拉开源操作系统（openEuler，简称“欧拉”）编译测试了高级分析数据平台 Greenplum，用实践证明了 Greenplum 与支持多样性计算的欧拉开源操作系统完全兼容，是 Greenplum 深入合作的典型模板，大大丰富了产品应用生态。 基于本次合作内容，Greenplum开源社区与欧拉开源社区联合发布白皮书《开源Greenplum新篇章：兼容欧拉开源操作系统的数据平台，支持国产生态的高级分析数据平台》。 **文章详情：** https://tieba.baidu.com/p/7735489906 - 开源数据库MariaDB通过SPAC再**，开启新征程 **摘要：** 元老级数据库企业MariaDB，借助SPAC，携手Angel Pond实现资本新**。 在数据库创投热中，最新的一个爆炸性消息发生在2022年2月初，开源关系型数据库MariaDB宣布完成1.04亿美元的D轮融资。然而不仅如此， MariaDB同时还宣布打算通过与特殊目的收购企业 Angel Pond Holdings 合并，于2022年下半年在纽约证券交易所公开上市。届时该公司将更名"MariaDB plc"，并由现任首席执行官 Michael Howard 继续领导。预计交易完成后，新公司或拥有6.72亿美元估值，获得包括来自Angel Pond以信托方式持有的2.65亿美金以及1800万美元的PIPE投资。 **文章详情：** https://tieba.baidu.com/p/7739194200 - 通用数据库管理工具DBeaver 21.3.5 发布 **摘要：** DBeaver 正式21.3.5 发布。DBeaver 是一个免费开源的通用数据库工具和 SQL 客户端，支持 MySQL, PostgreSQL, Oracle, DB2, MSSQL, Sybase, Mimer, HSQLDB, Derby, 以及其他兼容 JDBC 的数据库。DBeaver 提供一个图形界面用来查看数据库结构、执行SQL查询和脚本，浏览和导出数据，处理BLOB/CLOB 数据，修改数据库结构等等。适用于开发人员和数据库管理员。 **文章详情：** https://tieba.baidu.com/p/7735426577 - SQLite 3.38正式发布：改进JSON支持 增强CLI体验 **摘要：** 作为 2022 年的首个新版，SQLite 3.38 也是 SQLite 的一次盛大更新。SQLite 是一个小型、快速、自包含、高可靠性、全功能的嵌入式 SQL 数据库引擎。早在 2015 年发布的 SQLite 3.9 版本中，开发者就已经为它添加了对 JSON1 模块的支持。现在，随着 2022 年首个重大更新的发布，该模块已在 SQLite 3.38 中被默认包含、而无需启用编译时选项。 **文章详情：** https://tieba.baidu.com/p/7738195534 - PostgreSQL 开始支持 Zstd **摘要：** PostgreSQL 现已通过其 TOAST 存储技术提供压缩支持，并且在过去的一年里构建了 LZ4 压缩支持——用于压缩 WAL、备份压缩以及其他用途，现在 PostgreSQL 开发者正准备通过 Zstd 支持进一步扩展其压缩能力。 Zstd (Zstandard) 是由 Facebook 开源的快速无损压缩算法，主要应用于 zlib 级别的实时压缩场景，并且具有更好的压缩比。Zstd 还可以以压缩速度为代价提供更强的压缩比，速度与压缩权衡可通过小增量进行配置。 **文章详情：** https://tieba.baidu.com/p/7735437424 - 最快的SQL计算引擎MatrixOne 0.2.0 发布 **摘要：** 在数月的打磨和努力开发之下, MatrixOne 0.2版本正式发布啦！ 项目文档网站 https://docs.matrixorigin.io/0.2.0/ 相比于0.1版本，0.2版本在以下几方面有着明显改进：性能大幅提升、完整的分布式能力、新Feature、文档更新、 Bug Fixes等。 **文章详情：** https://tieba.baidu.com/p/7739181210 - 云迁移将持续深入，今年企业IT支出将超过1.3万亿美元 **摘要：** 2月21日消息，Gartner预测预测，2025年有效细分市场中的企业在公有云计算领域的IT支出将超过传统IT服务支出。 Gartner云迁移研究包括可以迁移到云的企业IT市场，即应用软件、基础设施软件、业务流程服务和系统基础设施市场。2025年在这四个市场中将有51%的IT支出从传统解决方案转向公有云(2022年为41%)。 Gartner预测，2022年企业IT支出将因云迁移而超过1.3万亿美元，2025年将增长至近1.8万亿美元。分布式云等新技术的出现将扩大云在IT市场引发的持续变革。 **文章详情：** https://tieba.baidu.com/p/7736599583 - 观远数据完成老虎**基金领投的2.8亿元C轮融资 **摘要：** 2月22日，BI服务商观远数据宣布完成新一轮2.8亿元C轮融资。本轮融资由全球知名的老虎**基金(Tiger Global)领投，红杉中国、线性资本、襄禾资本、独秀资本(Unicorn Capital Parnters)等老股东全线跟投。据观远数据创始人&CEO苏春园介绍，此轮融资将主要用于三大方面，智能分析产品矩阵的深化、客户成功体系的升级、重点行业与用户生态的建设。 数字化时代正在加速到来，商业智能将广泛普及，以数据驱动决策将成为企业的常态。IDC预测，2025年，中国商业智能软件市场规模将达到13.3亿美元，未来5年整体市场年复合增长率(CAGR)达到17.9%。 **文章详情：** https://tieba.baidu.com/p/7736623942 - 时序数据库 Timescale 完成C轮1.1亿融资，数据库领域添独角兽 **摘要：** 2022 年 2 月 22 日，Timescale 宣布其在近日完成了 C 轮融资，在 2021 年、2019 年和 2018 年，Timescale 分别完成了 4000 万美元、1500 万美元和 1600 万美元的融资，总融资金额达到 1.8 亿美元。本轮融资由 Tiger Global 领投，现有投资者 Benchmark、New Enterprise Associates、Redpoint Ventures、Icon Ventures 和 Two Sigma Ventures 均参与跟投。目前，Timescale 估值超过 10 亿美元，成为数据库领域的又一独角兽企业。 **文章详情：** https://tieba.baidu.com/p/7738209746 - 中国自主的数据库评测，是如何开展的 **摘要：** 此前，较受认可的评测是由 TPC（ Transaction Processing Performance Council，事务处理性能委员会）推出的 TPC-C 评测标准，而 TPC-C 也一度成为每个主流数据库都会尝试一下的评测。但 TPC-C 也有自身的问题，首先，它面向的是 OLTP 数据库，并不能满足所有场景的数据库测试。实际上，TPC 只给出了标准规范，特别场景需要厂商自行处理。另外，TPC 的审核人员人数很少，且全部在**，沟通不便。从开销的角度讲，TPC-C 也较为昂贵，比如 Oracle 从 2010 年开始，就基本退出了 TPC-C 评测。 种种因素，使数据库评测处于一个事实上的空白领域。这也促使国内许多机构开始尝试进行数据库标准评测，信通院作为我国工业和信息化部直属事业单位，有推动我国 ICT 领域健康、快速发展的直接责任，因此从 2015 年开始推出各类数据库评测，在整个行业都产生了较大的影响力。 **文章详情：** https://tieba.baidu.com/p/7736427945 - 中国信通院——开源分布式关系型数据库专刊正式启动 **摘要：** 近年来，开源生态发展势头迅猛，开源在推动技术创新、促进产业协作、加快各行业数字化进程方面发挥的作用日益凸显。过去一年，开源生态进一步发展成熟，并呈现全新态势。开源生态从个人参与到企业参与，从开源技术交流到开源生态协同，逐步形成产业供应关系。自上而**系化构建方式与自下而上竞争式模式相结合，不断推动开源生态发展。 开源已成为企业的主流趋势，也将成为企业的战略方向和商业模式。开源改变了信息产业的格局和商业模式，推动全球信息技术发生了全局性、持续性的重大变革，促进了全球范围内的技术创新成果落地。基于此背景，中国信息通信研究院前期已成功编写并发布了《开源发展态势洞察报告——消息中间件专刊》。 中国信通院第二期《开源发展态势洞察报告》—开源分布式关系型数据库专刊现公开征集参与单位，欢迎社会各界广泛参与！ **文章详情：** https://tieba.baidu.com/p/7739152732 [上一期：【技术之声】第九期（20220221）一周精选](https://bbs.huaweicloud.com/forum/thread-180163-1-1.html) *声明：文章源于第三方公开的信息，如内容中涉嫌侵权或存在信息不实时，请及时联系删除。* |整理者：酷哥

       很荣幸能参与到华为鲲鹏众智计划的项目中，这次项目的经历让我收获很多。开源使能-分布式存储软件适配项目主要是完成开源分布式存储组件Lustre、FastDFS、MinIO和BeeGFS在鲲鹏平台的兼容性工作，对开源分布式存储组件在鲲鹏平台进行编译安装、基本功能用例和性能用例的测试，查找适配过程中可能出现的问题并对功能异常进行说明，同时自动化用例输出自动化测试脚本。       千里之行始于足下，项目最困难的往往是开始阶段，如何规划项目进度以及团队分工十分重要。最开始也最繁琐的Lustre文件系统适配几乎占据了项目的一半时间。网上很少有Lustre在ARM架构上适配的相关资料，Lustre又需要对系统内核上打补丁，这涉及了给内核源码打补丁以及内核源码编译的问题，而Lustre文件系统网络的配置也十分繁琐，这个过程遇到了很多问题，我们通过查询相关资料以及咨询相关领域的专家慢慢地解决了问题，并对问题进行了记录。在对实际分布式存储软件情况调研和进一步的实践验证中，我们与华为对接的专家讨论了项目具体要求版本等信息，使得合作的任务需求更加完善。一个分布式存储软件的适配需要团队分工完成，合理地对任务进行分配能够极大地提升团队效率，通过第一个分布式存储软件的适配，渐渐找到了团队配合的方式，最终使得项目顺利完成。        项目实践的过程也是学习的过程，通过文件系统的适配过程，我不仅了解了每个文件系统的优缺点以及适用的场景，也熟练掌握了每个文件系统具体的编译安装流程和参数配置。问题带来的不只有烦恼，还有收获。例如在对BeeGFS文件系统适配过程中，进行磁盘随机读写测试时会出现内核崩溃情况，检查发现是armv8.2的PAN和UAO特性限制了用户空间的访问，这让我进一步了解了armv8.2架构和Linux内核空间和用户空间的知识；由于性能用例测试需要多个客户端，而由于机器数量的限制，就考虑使用多个kvm虚拟机进行测试。实践和解决问题的过程让我拓宽了思路，开阔了眼界，为我今后的道路打下了基石。       从鲲鹏916到鲲鹏920芯片，华为逐步把鲲鹏系列推向市场，做大ARM生态。与X86相比，ARM架构虽然具有低功耗、IP授权等方面优势，但生态环境堪忧。而生态系统需要广大的开发者一起构建，华为的鲲鹏众智计划正是汇集学界和产业界的诸多力量，构建鲲鹏平台的基础软件生态、实现生态共建共享。我很荣幸能够参与到鲲鹏众智计划中来，为鲲鹏生态系统的完善作出微薄贡献，希望能够在不远的未来见证鲲鹏计算生态的繁荣发展。                                                                                                                  兰州大学-高性能计算系统与应用研究团队-张强强，指导老师：张洋老师，陈文波老师

>摘要：GaussDB(DWS)提供了两个集群级别的视图快速识别和查询锁等待和分布式死锁信息，可实现此类问题的秒级问题的定位和分析。本文分享自华为云社区《[GaussDB(DWS)运维 -- 一键式锁等待和分布式死锁检测](https://bbs.huaweicloud.com/blogs/331625?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=ei&utm_content=content)》，作者：譡里个檔。 锁是GaussDB(DWS)实现并发管理的关键要素，GaussDB(DWS)锁类别有表级锁、分区级锁(和表级锁一致)、事务锁、咨询锁等，当前业务最常用的是表级锁、分区级锁(和表级锁一致)、事务锁。不同的SQL语句执行时需要申请并持有对应的锁，当这些锁资源存在互斥时，对应的业务SQL就会产生等待；这种等待会产生下面几种后果： 1. 持锁的一方释放锁(一般对应的动作为持锁的事物提交)，等待锁的一方申请到锁，然后继续执行 2. 持锁的一方事物长时间未提交，等待锁的一方因为锁等待超时导致作业报错 3. A实例上持锁事物和申请锁的事物在B实例上角色互换，产生分布式死锁(具体见下文介绍)。这种场景下需要首先达到锁等待超时的事物报错回滚时释放锁资源，然后另外一个事物申请到才能正常进行 从上述的描述可以看到，锁等待特别是分布式死锁对业务影响很大，轻则产生等待导致业务性能抖动和下降，甚至业务报错。GaussDB(DWS)提供了两个集群级别的视图快速识别和查询锁等待和分布式死锁信息，可实现此类问题的秒级定位和分析。 # 1）锁等待检测视图pgxc_lock_conflicts 【功能】查询当前库里面不同节点上的锁等待信息  【解析】执行如下查询结果 postgres=# SELECT * FROM pgxc_lock_conflicts ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | username | gxid | xactstart | queryid | query | pid | mode | granted -----------+----------+----------+---------+-----------------------+----------+------+-------+---------------+-----------+----------+-------------------------------+--------------------+----------------------------------------------------------+-----------------+---------------------+--------- partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 104145741383084190 | alter table table_partition_num_3 truncate partition p1; | 140160505136896 | AccessExclusiveLock | f partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 0 | alter table table_partition_num_3 truncate partition p1; | 140160568055552 | AccessExclusiveLock | t relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 175921860444402398 | truncate xxx; | 140418767369984 | AccessShareLock | f relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 0 | truncate xxx; | 140420489144064 | AccessExclusiveLock | t (4 rows) 如上的SQL显示 - 在节点cn_5001的postgres里面的表public.table_partition_num_3的分区p1上存在分区级别(partition)的锁冲突。在当前的锁冲突中线程140160568055552持有锁(mode = true)，锁级别是AccessExclusiveLock，执行语句为alter table table_partition_num_3 truncate partition p1。线程140160568055552在等待(mode = false)AccessExclusiveLock锁，等待锁的语句也是alter table table_partition_num_3 truncate partition p1。 - 在节点cn_5002的postgres里面的表http://public.xxx上存在表级别(relation)的锁冲突。线程140420489144064持有锁AccessExclusiveLock(mode = true)，线程140418767369984在等待(mode = false)AccessShareLock锁 # 2）分布式锁等待检测视图pgxc_deadlock 【功能】查询当前库里面不同节点上的分布式死锁信息  【解析】执行如下查询结果 postgres=# SELECT * FROM pgxc_deadlock ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | waitusername | waitgxid | waitxactstart | waitqueryid | waitquery | waitpid | waitmode | holdusername | holdgxid | holdxactstart | holdqueryid | holdquery | holdpid | holdmode ----------+----------+----------+---------+---------+----------+------+-------+---------------+--------------+----------+-------------------------------+--------------------+-----------------------------------------------------+-----------------+-----------------+--------------+----------+-------------------------------+-------------+--------------+-----------------+--------------------- relation | cn_5001 | postgres | public | t2 | | | | | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 104145741383110084 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t2'; | 140160505136896 | AccessShareLock | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 0 | TRUNCATE t2; | 140160421234432 | AccessExclusiveLock relation | cn_5002 | postgres | public | t1 | | | | | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 175921860444446866 | EXECUTE DIRECT ON(dn_6001_6002) 'SELECT * FROM t1'; | 140418784151296 | AccessShareLock | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 0 | TRUNCATE t1; | 140421763163904 | AccessExclusiveLock (2 rows) 如上的SQL显示，在postgres库里面 - 节点cn_5001上 事务24112465通过线程140160421234432持有表public.t2的AccessExclusiveLock锁 事务24112406通过线程140160505136896在等待申请表public.t2的AccessShareLock锁 - 节点cn_5002上 事务24112465通过线程140418784151296在等待申请表public.t1的AccessShareLock锁 事物24112406通过线程140421763163904持有表public.t1的AccessExclusiveLock锁 如果我们把资源的持有情况按照持有到申请定义一个防线的话，可以形成如下表格  从上述可以看出，事务24112465在节点cn_5001持有表public.t2的AccessExclusiveLock锁，等待申请申请表public.t1的AccessShareLock锁；事务24112406在节点cn_5002上持有表public.t1的AccessExclusiveLock锁，等待申请申请表public.t2的AccessShareLock锁；事务24112406和事务24112465只有等待彼此提交才能申请到锁资源，让自己继续执行，这种在多个实例上的分布式等待关系形成了一个环状，我们称这种现象为分布式死锁。 # 3) 锁等待和分布式死锁的区别 对于分布式死锁，只能一个事务因为锁等待（参数lockwait_timeout）超时回滚的时候，另外一个事务才能进行下去；或者人工干预kill或者cancel其中一个事务，让另外一个事务进行下去。 对于没有分布式死锁的锁等待，这种一般不需要人工干涉，等待持锁事务正常执行完成之后另外一个事务就可以正常执行；但是如果事务持锁时间超过锁等待超时参数（参数lockwait_timeout），等待锁的事务会因为锁等待超时失败。

>摘要：一致性哈希是什么，使用场景，解决了什么问题？本文分享自华为云社区《[16 张图解 ｜ 一致性哈希算法](https://bbs.huaweicloud.com/blogs/333158?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者：小林coding。 ## 如何分配请求？ 大多数网站背后肯定不是只有一台服务器提供服务，因为单机的并发量和数据量都是有限的，所以都会用多台服务器构成集群来对外提供服务。 但是问题来了，现在有那么多个节点（后面统称服务器为节点，因为少一个字），要如何分配客户端的请求呢？  其实这个问题就是「负载均衡问题」。解决负载均衡问题的算法很多，不同的负载均衡算法，对应的就是不同的分配策略，适应的业务场景也不同。 最简单的方式，引入一个中间的负载均衡层，让它将外界的请求「轮流」的转发给内部的集群。比如集群有 3 个节点，外界请求有 3 个，那么每个节点都会处理 1 个请求，达到了分配请求的目的。  考虑到每个节点的硬件配置有所区别，我们可以引入权重值，将硬件配置更好的节点的权重值设高，然后根据各个节点的权重值，按照一定比重分配在不同的节点上，让硬件配置更好的节点承担更多的请求，这种算法叫做加权轮询。 加权轮询算法使用场景是建立在每个节点存储的数据都是相同的前提。所以，每次读数据的请求，访问任意一个节点都能得到结果。 但是，加权轮询算法是无法应对「分布式系统」的，因为分布式系统中，每个节点存储的数据是不同的。 当我们想提高系统的容量，就会将数据水平切分到不同的节点来存储，也就是将数据分布到了不同的节点。比如**一个分布式 KV（key-valu） 缓存系统，某个 key 应该到哪个或者哪些节点上获得，应该是确定的**，不是说任意访问一个节点都可以得到缓存结果的。 因此，我们要想一个能应对分布式系统的负载均衡算法。 ## 使用哈希算法有什么问题？ 有的同学可能很快就想到了：**哈希算法**。因为对同一个关键字进行哈希计算，每次计算都是相同的值，这样就可以将某个 key 确定到一个节点了，可以满足分布式系统的负载均衡需求。 哈希算法最简单的做法就是进行取模运算，比如分布式系统中有 3 个节点，基于 hash(key) % 3 公式对数据进行了映射。 如果客户端要获取指定 key 的数据，通过下面的公式可以定位节点： `hash(key) % 3` 如果经过上面这个公式计算后得到的值是 0，就说明该 key 需要去第一个节点获取。 但是有一个很致命的问题，**如果节点数量发生了变化，也就是在对系统做扩容或者缩容时，必须迁移改变了映射关系的数据**，否则会出现查询不到数据的问题。 举个例子，假设我们有一个由 A、B、C 三个节点组成分布式 KV 缓存系统，基于计算公式 hash(key) % 3 将数据进行了映射，每个节点存储了不同的数据：  现在有 3 个查询 key 的请求，分别查询 key-01，key-02，key-03 的数据，这三个 key 分别经过 hash() 函数计算后的值为 hash( key-01) = 6、hash( key-02) = 7、hash(key-03) = 8，然后再对这些值进行取模运算。 通过这样的哈希算法，每个 key 都可以定位到对应的节点。  当 3 个节点不能满足业务需求了，这时我们增加了一个节点，节点的数量从 3 变化为 4，意味取模哈希函数中基数的变化，这样会导致**大部分映射关系改变**，如下图：  比如，之前的 hash(key-01) % 3 = 0，就变成了 hash(key-01) % 4 = 2，查询 key-01 数据时，寻址到了节点 C，而 key-01 的数据是存储在节点 A 上的，不是在节点 C，所以会查询不到数据。 同样的道理，如果我们对分布式系统进行缩容，比如移除一个节点，也会因为取模哈希函数中基数的变化，可能出现查询不到数据的问题。 要解决这个问题的办法，就需要我们进行**迁移数据**，比如节点的数量从 3 变化为 4 时，要基于新的计算公式 hash(key) % 4 ，重新对数据和节点做映射。 假设总数据条数为 M，哈希算法在面对节点数量变化时，**最坏情况下所有数据都需要迁移，所以它的数据迁移规模是 O(M)**，这样数据的迁移成本太高了。 所以，我们应该要重新想一个新的算法，来避免分布式系统在扩容或者缩容时，发生过多的数据迁移。 ## 使用一致性哈希算法有什么问题？ 一致性哈希算法就很好地解决了分布式系统在扩容或者缩容时，发生过多的数据迁移的问题。 一致哈希算法也用了取模运算，但与哈希算法不同的是，哈希算法是对节点的数量进行取模运算，而**一致哈希算法是对 2^32 进行取模运算，是一个固定的值**。 我们可以把一致哈希算法是对 2^32 进行取模运算的结果值组织成一个圆环，就像钟表一样，钟表的圆可以理解成由 60 个点组成的圆，而此处我们把这个圆想象成由 2^32 个点组成的圆，这个圆环被称为**哈希环**，如下图：  一致性哈希要进行两步哈希： - 第一步：对存储节点进行哈希计算，也就是对存储节点做哈希映射，比如根据节点的 IP 地址进行哈希； - 第二步：当对数据进行存储或访问时，对数据进行哈希映射； 所以，**一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上**。 问题来了，对「数据」进行哈希映射得到一个结果要怎么找到存储该数据的节点呢？ 答案是，映射的结果值往**顺时针的方向的找到第一个节点**，就是存储该数据的节点。 举个例子，有 3 个节点经过哈希计算，映射到了如下图的位置：  接着，对要查询的 key-01 进行哈希计算，确定此 key-01 映射在哈希环的位置，然后从这个位置往顺时针的方向找到第一个节点，就是存储该 key-01 数据的节点。 比如，下图中的 key-01 映射的位置，往顺时针的方向找到第一个节点就是节点 A。  所以，当需要对指定 key 的值进行读写的时候，要通过下面 2 步进行寻址： - 首先，对 key 进行哈希计算，确定此 key 在环上的位置； - 然后，从这个位置沿着顺时针方向走，遇到的第一节点就是存储 key 的节点。 知道了一致哈希寻址的方式，我们来看看，如果增加一个节点或者减少一个节点会发生大量的数据迁移吗？ 假设节点数量从 3 增加到了 4，新的节点 D 经过哈希计算后映射到了下图中的位置：  你可以看到，key-01、key-03 都不受影响，只有 key-02 需要被迁移节点 D。 假设节点数量从 3 减少到了 2，比如将节点 A 移除：  你可以看到，key-02 和 key-03 不会受到影响，只有 key-01 需要被迁移节点 B。 因此，**在一致哈希算法中，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响**。 上面这些图中 3 个节点映射在哈希环还是比较分散的，所以看起来请求都会「均衡」到每个节点。 但是**一致性哈希算法并不保证节点能够在哈希环上分布均匀**，这样就会带来一个问题，会有大量的请求集中在一个节点上。 比如，下图中 3 个节点的映射位置都在哈希环的右半边：  这时候有一半以上的数据的寻址都会找节点 A，也就是访问请求主要集中的节点 A 上，这肯定不行的呀，说好的负载均衡呢，这种情况一点都不均衡。 另外，在这种节点分布不均匀的情况下，进行容灾与扩容时，哈希环上的相邻节点容易受到过大影响，容易发生雪崩式的连锁反应。 比如，上图中如果节点 A 被移除了，当节点 A 宕机后，根据一致性哈希算法的规则，其上数据应该全部迁移到相邻的节点 B 上，这样，节点 B 的数据量、访问量都会迅速增加很多倍，一旦新增的压力超过了节点 B 的处理能力上限，就会导致节点 B 崩溃，进而形成雪崩式的连锁反应。 所以，**一致性哈希算法虽然减少了数据迁移量，但是存在节点分布不均匀的问题**。 ## 如何通过虚拟节点提高均衡度？ 要想解决节点能在哈希环上分配不均匀的问题，就是要有大量的节点，节点数越多，哈希环上的节点分布的就越均匀。 但问题是，实际中我们没有那么多节点。所以这个时候我们就加入**虚拟节点**，也就是对一个真实节点做多个副本。 具体做法是，**不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有「两层」映射关系。** 比如对每个节点分别设置 3 个虚拟节点： - 对节点 A 加上编号来作为虚拟节点：A-01、A-02、A-03 - 对节点 B 加上编号来作为虚拟节点：B-01、B-02、B-03 - 对节点 C 加上编号来作为虚拟节点：C-01、C-02、C-03 引入虚拟节点后，原本哈希环上只有 3 个节点的情况，就会变成有 9 个虚拟节点映射到哈希环上，哈希环上的节点数量多了 3 倍。  你可以看到，**节点数量多了后，节点在哈希环上的分布就相对均匀了**。这时候，如果有访问请求寻址到「A-01」这个虚拟节点，接着再通过「A-01」虚拟节点找到真实节点 A，这样请求就能访问到真实节点 A 了。 上面为了方便你理解，每个真实节点仅包含 3 个虚拟节点，这样能起到的均衡效果其实很有限。而在实际的工程中，虚拟节点的数量会大很多，比如 Nginx 的一致性哈希算法，每个权重为 1 的真实节点就含有160 个虚拟节点。 另外，虚拟节点除了会提高节点的均衡度，还会提高系统的稳定性。**当节点变化时，会有不同的节点共同分担系统的变化，因此稳定性更高**。 比如，当某个节点被移除时，对应该节点的多个虚拟节点均会移除，而这些虚拟节点按顺时针方向的下一个虚拟节点，可能会对应不同的真实节点，即这些不同的真实节点共同分担了节点变化导致的压力。 而且，有了虚拟节点后，还可以为硬件配置更好的节点增加权重，比如对权重更高的节点增加更多的虚拟机节点即可。 因此，**带虚拟节点的一致性哈希方法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景**。 ## 总结 不同的负载均衡算法适用的业务场景也不同的。 轮训这类的策略只能适用与每个节点的数据都是相同的场景，访问任意节点都能请求到数据。但是不适用分布式系统，因为分布式系统意味着数据水平切分到了不同的节点上，访问数据的时候，一定要寻址存储该数据的节点。 哈希算法虽然能建立数据和节点的映射关系，但是每次在节点数量发生变化的时候，最坏情况下所有数据都需要迁移，这样太麻烦了，所以不适用节点数量变化的场景。 为了减少迁移的数据量，就出现了一致性哈希算法。 一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响。 但是一致性哈希算法不能够均匀的分布节点，会出现大量请求都集中在一个节点的情况，在这种情况下进行容灾与扩容时，容易出现雪崩的连锁反应。 为了解决一致性哈希算法不能够均匀的分布节点的问题，就需要引入虚拟节点，对一个真实节点做多个副本。不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有「两层」映射关系。 引入虚拟节点后，可以会提高节点的均衡度，还会提高系统的稳定性。所以，带虚拟节点的一致性哈希方法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景。

大家好！我是酷哥，数据库相关资讯，带您速览，欢迎大家阅读。 **本期整理如下：** ------------------------------------------------ **本期精选** ------------------------------------------------ - “东数西算”工程全面启动 - 国内首个事务型数据库性能测试工具正式开源 - 第二届全球数据压缩大赛完美收官，进一步逼近数据压缩极限 - SphereEx与京东科技-推进多行业数据库产业生态建设 - Oracle Autonomous 云数据库获MongoDB API支持 - 亚马逊云科技推出内存数据库 Amazon MemoryDB for Redis - 57亿元、Akamai 收购 IaaS 提供商 Linode - 工信部拟规定：对各类数据实施分级防护 - “热搜”中的分布式数据库 - 为什么2022年仍然存在数据孤岛 ------------------------------------------------ **资讯全文** ------------------------------------------------ - “东数西算”工程全面启动 **摘要：** 国家发改委2月17日消息，国家发改委、中央网信办、工业和信息化部、国家能源局近日联合印发通知，同意在京津冀、长三角、粤港澳大湾区、成渝、内蒙古、贵州、甘肃、宁夏等8地启动建设国家算力枢纽节点，并规划了10个国家数据中心集群。至此，全国一体化大数据中心体系完成总体布局设计，“东数西算”工程正式全面启动。 国家发改委高技术司相关负责人答记者问时表示，实施“东数西算”工程，推动数据中心合理布局、优化供需、绿色集约和互联互通，有利于提升国家整体算力水平，有利于促进绿色发展，有利于扩大有效投资，有利于推动区域协调发展。 **文章详情：** [https://bbs.huaweicloud.com/forum/thread-179908-1-1.html](https://bbs.huaweicloud.com/forum/thread-179908-1-1.html) - 国内首个事务型数据库性能测试工具正式开源 **摘要：** 2 月 17 日，由信通院主办的国内首款金融数据库性能测试工具开源发布会在线上召开。会上，定位于国家高端专业智库、产业创新发展平台的信通院宣布开源了该测试工具，并详细阐述了开源此工具的背景、初心、历程以及愿景。信通院云大所副所长魏凯表示，将该款测试工具开源出来，也是希望借助平台的力量推动我国数据库产业健康、可持续地发展。项目开源地址：https://gitee.com/caict-bigdata/databench-t 四年磨一剑，力求打造中国 TPC，从 2018 年年底开始，信通院联合了北京银行、建设银行一起来开发，并邀请了来自腾讯、华为、中兴等企业的多位专家来共同参与该款工具的总体设计和实现。此次发布的 Databench-T 工具，也是希望能从根本上推动我国 ICT 领域健康、快速发展，使工具能更快、更好地为相关方服务。 **文章详情：** [https://bbs.huaweicloud.com/forum/thread-179907-1-1.html](https://bbs.huaweicloud.com/forum/thread-179907-1-1.html) - 第二届全球数据压缩大赛完美收官，进一步逼近数据压缩极限 **摘要：** 2月16日，第二届全球数据压缩大赛（GDCC2021）颁奖仪式举行，此次比赛共设置5个方向13个类别，吸引了来自全球40多个国家的1万多名存储研究人员关注，200多名参赛者报名，提交了79种算法，22人获奖。所有获奖算法的性能都优于业界已知的同类型压缩算法。部分算法的压缩比超过业界基准算法30%以上，进一步接近数据压缩极限。 2020年华为联合莫斯科国立大学举办的首届全球数据压缩大赛受到全世界算法界的广泛关注。 **文章详情：** [https://tieba.baidu.com/p/7730728099](https://tieba.baidu.com/p/7730728099) - SphereEx与京东科技-推进多行业数据库产业生态建设 **摘要：** 2022 年 1 月 31 日，SphereEx 与京东科技签署战略合作协议。协议中指出，双方将在数据库领域达成深度协作，在数据库服务领域实现优势互补，探索在线交易、在线分析、弹性伸缩、同城多活、异地灾备等技术应用与落地，形成产品的联合解决方案。推进多行业数据库产业生态建设。 **文章详情：** [https://tieba.baidu.com/p/7729633815](https://tieba.baidu.com/p/7729633815) - Oracle Autonomous 云数据库获 MongoDB API支持 **摘要：** 甲骨文近期发布了Oracle Database API for MongoDB。MongoDB是一种流行的NoSQL文档数据库，通常用作启用应用程序的后端数据存储。 通过这个新API，甲骨文使其用户能够在Oracle Autonomous JSON数据库及其旗舰Oracle Autonomous数据库云服务上迁移和运行基于MongoDB的数据应用程序。 使用这个API，用户可以连接现有的基于MongoDB的应用程序，并在Oracle平台内运行数据，而无需实际运行MongoDB数据库。2021年10月，甲骨文首次发布Oracle Database API for MongoDB的技术预览版。 **文章详情：** https://tieba.baidu.com/p/7726658029 - 亚马逊云科技推出内存数据库 Amazon MemoryDB for Redis **摘要：** （全球TMT2022年2月14日讯）亚马逊云科技宣布通过与光环新网和西云数据的紧密合作，在中国区域（北京与宁夏）推出完全托管的、兼容Redis的内存数据库Amazon MemoryDB for Redis。 Amazon MemoryDB for Redis具有高可用性和高持久性，可为客户提供超高性能，尤其适用于需要亚毫秒级低延迟响应的关键业务应用。 **文章详情：** [https://tieba.baidu.com/p/7727599669](https://tieba.baidu.com/p/7727599669) - 57亿元、Akamai 收购 IaaS 提供商 Linode **摘要：** Akamai今天宣布同意斥资约9亿美元（57亿人民币）收购基础设施即服务（IaaS）平台提供商Linode。Akamai表示，收购AWS的这个竞争对手将帮助该公司将自己打造成“世界上最具特色的分布式计算平台”。 **文章详情：** [https://tieba.baidu.com/p/7729639009](https://tieba.baidu.com/p/7729639009) - 工信部拟规定：对各类数据实施分级防护 **摘要：** 2月10日，工信部网站发布再次公开征求对《工业和信息化领域数据安全管理办法(试行)》的意见，其中提到，工业和信息化领域数据处理者应当对数据处理活动负安全主体责任，对各类数据实行分级防护。 意见称，工信部组织制定工业和信息化领域数据分类分级、重要数据和核心数据识别认定、数据分级防护等标准规范，指导开展数据分类分级管理工作，制定行业重要数据和核心数据具体目录并实施动态管理。 **文章详情：** [https://tieba.baidu.com/p/7726673062](https://tieba.baidu.com/p/7726673062) - “热搜”中的分布式数据库 **摘要：** “一个数据库包打天下的时代已经结束了”四川省农村信用社联合社信息科技中心高级工程师桂俊鸿在采访中表示。事务型、联机型、NoSQL、文档型、列式存储、时序数据库、图数据库……在近年来这些数据库热词背后，是数据库技术及产品在面向不同业务场景逐渐细化分类，发挥长处，最终助力企业实现数字化目标。由于传统数据库在扩展性、容量等方面不能满足日益增长的数字化需求，架构层面从集中式向分布式转型的分布式数据库及相关产品备受关注。 **文章详情：** [https://tieba.baidu.com/p/7727904283](https://tieba.baidu.com/p/7727904283) - 为什么2022年仍然存在数据孤岛 **摘要：** 企业摆脱数据孤岛并不容易。人们需要了解什么是数据孤岛、为何难以消除数据孤岛以及如何克服这些挑战。 好消息是，如今可供企业使用的数据比以往任何时候都多。从客户注册在线帐户到向企业提供他们的详细信息，信息对于帮助企业做出关键业务决策非常宝贵。 但是，数据存储效率低下可能会给企业带来一些问题。数据孤岛不仅会让企业的团队感到沮丧，还会导致销售损失和决策不准确。 **文章详情：** [https://tieba.baidu.com/p/7726637694](https://tieba.baidu.com/p/7726637694) [上一期：【技术之声】第八期（20220214）一周精选](https://bbs.huaweicloud.com/forum/thread-179748-1-1.html) *声明：文章源于第三方公开的信息，如内容中涉嫌侵权或存在信息不实时，请及时联系删除。* |整理者：酷哥