新开传奇网站刚开一秒,seo软文是什么,男女性男女直接做的视频网站,网上推广企业2022年#xff0c;OceanBase发布4.0版本“小鱼”#xff0c;并首次公开提出了单机分布式一体化这一理念#xff0c;旨在适应大小不同规模的工作负载#xff0c;全面满足用户数据库“从小到大”全生命周期的需求。当时#xff0c;我们所说的“从小到大”主要聚焦于数据库的…2022年OceanBase发布4.0版本“小鱼”并首次公开提出了单机分布式一体化这一理念旨在适应大小不同规模的工作负载全面满足用户数据库“从小到大”全生命周期的需求。当时我们所说的“从小到大”主要聚焦于数据库的“内功”即数据库内核技术。然而一个好的数据库产品仅有深厚的“内功”是远远不够的还需要有“外功”支撑即数据库生态产品体系。
接下来让我们从管控产品的视角回顾OceanBase在“外功”方面的成长与进步看看它是如何助力开发者满足从小到大的多样化需求的。
初学者的上手成本
首先来看初学者需要什么初学者主要关注两个方面——部署成本和部署难度。
1、部署成本
自2021年OceanBase开源以来我们一直在做产品小型化的迭代从64G的配置要求优化到如今的2C6G配置要求期间我们从未讨论存储因为相比CPU和内存58GB的存储太廉价了。
直到我们和来自高校的学生交流时才发现原来我们忽略了一个非常关键的细节。
通常还未走出校门的学生使用的电脑是Windows或MacOS而OceanBase目前只支持lLnux系统。很多同学会选择从云厂商购买Linux服务器。下图是主流厂商满足OceanBase配置要求2C6G的最廉价的一套配置。 我们发现无论上图中哪种配置都无法满足最低58GB的配置需求因此学生在买机器时就需要额外增加存储成本更糟糕的是买完机器后发现50GB难以支撑系统运行还得再买58GB最终购买了108GB这都是额外成本对学生来说非常敏感。
2024年我们把58GB的配置要求优化为20GB配置要求且其中的16GB是真正数据存储预留4GB日志存储大大降低首次启动的存储开销降低学生的上手门槛。
2、部署难度。
分布式系统部署一直都是“老大难”。2023年我们针对易用性做了很多优化比如OceanBaseD demo快速体验环境、OceanBaseD WED图形化部署还推出了all in one一键式安装包。但我们发现不管使用哪套模式都会遇到共同的问题那就是用户需要额外下载一个安装器这并不符合Linux开发者心目中的安装模式。
什么样的安装模式符合Linux开发者预期在Centos上使用yum isntall在Ubuntu上使用apt-get install。而在OceanBase 4.2.1版本开始我们支持原生yum/apt-get install支持使用 systemctl 管理数据库。
同时我们还与许多操作操作系统社区紧密结合例如实现在龙蜥OpenAnolis和欧拉OpenEuler社区的制品平台上完成从源码到制品的构建且制品包被两个社区官方仓库收录。这意味着在OpenAnolis和OpenEuler中安装OceanBase将不再需要添加额外的仓库源开发者只需使用以下两条指令就能快速启动OceanBase数据库。
yum install oceanbase-ce
systemctl start oceanbase
当然我们不会止步于此未来我们将推动OceanBase与更多的操作系统社区合作让开发者可以用最简单直接的方式安装OceanBase。
同样的我们也在积极推进对Windows和MacOS的编译适配工作。任何曾尝试过大型C项目跨平台编译的开发者都深知实现像OceanBase这样大型C项目的跨平台构建既复杂又具有挑战性。
尽管如此我们仍旧坚持推进下去。也希望开发者们参与共建在社区和我们一起共同克服困难。
企业开发者需要什么
当一个开发者进入企业或开始管理自己的项目时他们面临的数据库管理需求显著提升。这时他们需要的是一个能够提供全面管理功能的数据库管控台用以高效、便捷地管理数据库环境。为此OceanBase社区版提供了两款针对性的产品来满足这类需求OCP 及其轻量版本OCP-Express。
OCP-Express 设计理念是提供一个轻量级的解决方案它专注于本地集群的管理。该平台的优势在于功能的聚焦性和简化性部署时不需要额外的MetaDB成本非常适合初期阶段或小型项目的需求。通过OCP-Express开发者可以享受到快速、直接的数据库管理体验无需承担过多的技术和财务负担。
随着项目规模的扩大和数据管理需求的增长集群数目也可能随之增加这种情况下OCP 成为了更合适的选择。OCP提供了更全面的多集群管理功能支持规模化的管控操作。这意味着对于那些管理着大规模集群或多项目集群的企业和开发者来说OCP能够提供更灵活、更强大的数据库管控解决方案。然而选择OCP的同时也意味着面对更多的部署考虑包括额外的部署工作及相应的MetaDB成本。
那么怎么打通从yum/apt-get install到ocp-Express再到ocp的链路呢这里就需要用到OceanBaseDOceanBasedeployer。OceanBaseD是随着OceanBase开源的第一批产品顾名思义这是一个专注于部署的软件。但早期开源社区管控的产品不是很成熟因此我们基于OceanBaseD做了一些轻量的运维功能。当下随着管控生态完善我们可以使OceanBaseD专注于其本应承担的核心职责——软件包管理和部署。
在OceanBaseD的2.8版本中我们引入了一项新功能——接管集群。通过一个简单的命令——OceanBased cluster takeover -h host -p password deploy-name开发者可快速将用yum/apt-get install部署的OceanBase集群纳入OceanBaseD的统一管理之下。一旦集群被OceanBaseD接管便可以在现有基础上增加新的组件。
在OceanBaseD 2.4.0版本新增了组件变更能力使开发者能在已有的OceanBase集群上加装新的组件比如 OCP Express。了解OceanBaseD的朋友可能会说“这个为已有集群安装OCP Express的功能你们一年前就做了新版上有什么不同吗”
我们可以看到下图的配置对比。左边是我们旧版本共51行其中大量的配置与OceanBase相关。此前由于没办法在已部署的配置上直接追加新组件如OCP-Express我们每次添加新组件都需要从头编写一个全新的配置文件并手动为这些组件添加与其相关组件的配置信息导致冗长的配置过程作业繁重且易出错。 现在请看右边这份新版本的配置在优雅的区别中它仅包含18行代码。真正关键的设置只在第17和18行提供了配置路径和内存规格要求大部分配置都涉及基础的组件信息和集群拓扑。得益于新版本的功能我们可以使用depends关键字将OCP-Express与OceanBase集群简洁、有效地关联起来。OCP-Express能够从OceanBase集群中自动获取其需要的设置信息而OceanBase也能感知到OCP-Express的加入自动为其创建Meta租户。完成新的配置文件编写后我们只需要一条命令即可完成组件追加——OceanBased cluster component add deploy-name -c new_conf.yaml。新版本中的自动化流程大大简化了整个部署过程消除了以往繁杂的手动步骤确保了新增组件的平滑与稳定。
随着业务增长和集群数量的增多我们需要具有多集群管理能力的OCP。此前OCP的部署也是一个令人头疼的问题但随着更新OCP与OceanBaseD的结合让该问题得到了解决。OceanBaseD现在能够支持通过命令行的方式自动化部署OCP当然通过之前提到的组件变更功能也同样适用于OCP的部署。但我不推荐大家这么做。虽然OCP可以对自己的MetaDB进行一定的运维管理但这种管理并非全面。此外我们不建议拿业务集群来承担OCP的MetaDB。原因在于业务集群通常需要应对业务带来的压力一旦业务负载增强OCP对自身MetaDB的连接可能会受到影响。在业务压力大时如果不能通过OCP及时对业务集群进行扩容以缓解负载就可能陷入一个恶性循环。
为了简化部署过程推荐大家使用OceanBaseD的Web界面部署的MetaDB和OCP。使用这种方法MetaDB将由OceanBaseD部署而OceanBaseD本身就能为该集群提供基础的管理功能包括但不限于扩容、升级启停等服务。
OCP部署完成后我们便可以将现有的OceanBase集群接入到OCP中。OCP自社区版发布起就具备接管OceanBase集群的能力但过程较为繁琐需要多达五个步骤——选择连接方法、填写连接信息、添加主机信息、选择主机类型、添加登录证书。为了简化这一流程OceanBaseD V2.4.0引入了一个新命令 OceanBased cluster export-to-ocp允许用户一键将OceanBaseD管理的集群导入到OCP中导入完成后也便不再需要OCP-Express。这里可以继续使用OceanBaseD的组件管理能力通过OceanBased cluster component del deploy-name ocp-express命令直接从现有的集群中移出OCP-Express。
基于Kubernetes的新运维
随着全面上云时代的到来OceanBase也不例外为了迎合不同用户的需求提供了多样化的选择方案。对于喜欢公有云服务的用户可直接在各大云平台上购买OceanBase的公有云服务享受便捷的数据库体验。而对于那些偏好将数据库系统完全掌握于手中的用户我们推出了一套基于Kubernetes operator的方案——OceanBase-Operator。OceanBase-Operator项目首次亮相于2022年4月在2023年的开发者大会上的workshop上同大家一起体验了基于yaml编排的方法创建和管理集群。
为了进一步简化操作我们引入了operator Dashboard通过这个可视化界面用户可以更加便捷地管理其集群。仅需四条简单的命令就能完成OceanBase-operator和Dashboard的部署。随后就可以完全摆脱YAML文件在图形化的界面中运维集群。
那么在Kubernetes上我们能获得的全新体验是什么
在传统的物理机环境下向OCP添加一个节点需要经过一系列繁琐的步骤包括准备物理机、将其加入OCP接着加入相应的Zone并最后提交任务。现在利用Kubernetes的能力这个过程变得极其简单不再需要在考虑新的物理机在哪里只需要在Dashboard 上调整副本数——比如从1增加到2并提交即可。OceanBase-Operator随后自动完成所有必要操作实现快速而无缝的扩容。
如果出现节点或整个可用区故障的情况传统的运维方式将是一场噩梦。运维人员需要将新的主机一台台加入OCP并一一配置到对应的Zone中。而在Kubernetes中这一切将完全自动化。一旦OceanBase-Operator检测到副本数量减少它会自动调度新的Pod来恢复服务无需任何手动干预。OceanBase-Operator根据存储介质是否可用OceanBase-Operator会自动决策是重启服务还是通过挂载新的PV以扩容形式迅速恢复服务。
我们计划未来将支持HPAHorizontal Pod AutoScaler功能。用户将通过设定具体的扩缩容指标OceanBase-Operator能在系统负载升高时自动进行扩容负载下降时则自动缩容。这一功能在极大减轻运维人员的工作压力的同时还为企业节约了成本。
统一运维接口
上面提到的都是OceanBase原厂提供的管控服务而对于那些有自建管控平台需求或希望将OceanBase 集成到已有自建平台中的用户可以使用OceanBaseShell。在OceanBase 4.2.1或更高版本中我们可以在OceanBaseserver执行文件旁边发现一个新的二进制文件名为OceanBaseshell。OceanBaseShell是一个结合命令行操作和OpenAPI的软件它不仅适用于日常运维还能在OCP或OceanBaseD出现故障时提供应急运维支持如应急启停、扩缩容、升级等。 OceanBaseShell还提供了一套统一的运维API为运维动作提供了标准接口。利用OceanBaseShell实现的功能我们实现了yum/apt-get install部署集群未来我们还将基于OceanBaseShell完善这套方案包括扩容、缩容、升级等。同时OceanBaseD也部分接入了OceanBaseShell这也是其能接管yum/apt-get install部署的集群的原因。后续我们将继续推进管控产品全面接入OceanBaseShell以实现统一标准的运维和任务状态的同步。
此前当一个由OceanBaseD部署的集群被OCP接管之后我们会建议用户不再使用OceanBaseD对该集群进行运维操作以避免可能发生的运维冲突。全线接入OceanBaseShell之后所有的运维任务都将通过OceanBaseShell的接口下发从而确保无论任务是由OceanBaseD、OCP还是用户自建的管控台发起的都不会发生冲突。
目前社区已经准备好了OceanBaseShell的GO语言SDK并计划提供包括Python在内的更多语言的SDK。如果大家需要其他语言的SDK欢迎在社区提出需求。
同时我们欢迎开发者加入社区一起参与OceanBaseShell以及其他生态产品的建设。
