云计算、数据库爱好者

RAG：适合需要动态检索外部知识的任务，依赖外部知识库，生成结果更丰富。微调：适合特定领域的任务，依赖任务特定的数据，模型性能更优。选择依据：根据任务需求（是否需要外部知识、数据可用性等）选择合适的方法，或结合两者使用。

众所周知，国产化算力发展迅猛，以为华为、寒武纪、壁仞科技和摩尔线程为代表的新型算力企业不断展露头角，在算力能力上完全不输英伟达的高端显卡，910B面世以来，主要以支撑高能级的训练任务为主，但是他适合推理场景吗？支持大规模模型的推理，如自然语言处理（NLP）中的BERT、GPT，以及计算机视觉中的ResNet、YOLO等，910B不仅适合训练任务，也能高效支持推理场景，尤其是在需要高性能、低延迟和大规模模型推理的场景中表现突出。应用领域：智能客服、语音助手、内容审核。应用领域：智能制造、智慧城市、智能家居。

ES: 适合全文检索，即文本和向量结合的搜索。MySQL: 适合向量与结构化数据结合，且对向量部分检索性能要求不高的场景。PostgreSQL: 适合复杂查询和事务处理。Redis: 适合低延迟、高吞吐量的场景。选择时需根据具体需求权衡性能、扩展性和功能。

基于算网大脑和数据传输工具，构建支持RDS、NOSQL、Elasticsearch、分布式的多活数据库，将典型的数据库 高可用场景，解决方案产品化，支持用户任意需求的多活、灾备能力的构建，和一键升级，且保持整体TCO的最低。

企业要坚定迈入云原生化时代，必须开展高阶上云工作，即相对于传统的订购云主机、存储等资源外，全面的将生产流程、研发流程、运营和运维完全融入云计算，释放云计算的最大价值。

计算机领域推荐的常见的主流中文论文如下。

同时也分析了主要的只能算力的服务模式，包括提供IDC、智能算力租赁、定制化项目和一站式解决方案（融入业务）四种典型模式，具体来讲那种模式最适合，最有前景，还是得从发展的不同阶段来看：（1）发展初期：无疑基础设施的建设、大量的智能算力卡配置是关键，（2）发展中期：而后需要解决智算paas的问题，那就包括针对大模型的管理和服务平台、训练推理过程中的数据管理平台，甚至新型的智算存储、智算数据库、智算中间件等，也包括智算资源纳管的管理平台，支持资源纳管、训练管理、断点续训、资源调度等。

由云向算的技术演进，彻底的变革了新时代企业对于传统云计算新基建的需求，云计算的概念得到了扩充，算力和网络开始融合，并成为企业上层业务发展的“第三阶段”。企业数字化转型发展三个阶段在企业上云的初级阶段，企业对于云计算的需求，依然还是聚焦在“静态部署能力、静态平台服务能力和常规应用软件”，即使在第二阶段的“高阶用云”，也是通过整合云计算的IaaS/PaaS/SaaS中的部分能力到自身业务中，实现一定程度的能力复用和共享，企业业务的整体IT架构、业务模式远远没有改变，所以影响业务生存和长久发展的关键因素并没有改变

在国家“1朵央企云统领，N朵行业云共载，M朵私有云共生”的央国企上云建设大背景下，央国企上云用云取得积极进展。近年来，国内相关机构对央国企上云标准规范进行了研究探索，然而由于不同行业、细分领域实际情况调研不足、情况了解不到位，导致对企业上云过程缺乏有效指导，不少企业在上云过程中边摸索边实践，导致企业上云“变形走样”。明确企业上云的不同阶段（如资源上云、数据上云、云原生等从低阶到高阶），帮助企业找到适合自己的上云节奏与路径，且对于上云所带来的风险、价值有清醒认识，打消上云的疑虑。

算力网络时代，数据的架构设计，基于云原生技术，将数据库推向算网时代。超大型分布式数据库、超大型智能数据库。未来就是超级数据库的时代。

云计算和大数据时代对数据库提出了更高的要求，需要支持大规模数据存储和处理。新型数据库技术如NewSQL和分布式数据库成为云计算和大数据时代的趋势。数据库需要具备分布式和并行计算能力，以满足高性能和可扩展性的需求。注：本文为chatGPT配合生成，如有涉及侵权，请留言联系我处置。

我眼中的十大数据库，openGauss、Oceanbase、Tidb、He3DB、虚谷、Milvus、doris、GoldenDB、AntDB、PorlaDB

3 月 25 日，OceanBase 推出 4.1 版本，据称，4.1 版本实现了事务处理（TP）性能提升 40%，数据分析（AP）性能提升 15%，全面兼容开源数据库 MySQL8.0 及相关系统函数、窗口函数等。4 月 4 日，TiDB 7.0 正式发布。1 月 10 日，KaiwuDB（原：开务数据库） 发布了 KaiwuDB 1.0 时序数据库，其运用到实时就地运算等核心专利技术，专为工业物联网、数字能源、交通车联网、智慧产业等场景设计。7 月 4 日，腾讯云发布 AI 原生向量数据库。

在传统的关系型数据库中，数据是以表格的形式存储的，而在向量数据库中，数据则是以向量的形式存储的。这种新型的数据库技术，能够更有效地处理和分析大数据，因此在大数据时代中受到了广泛的关注和应用。随着AI 应用的大规模落地普及，数据量得到了暴涨，数据复杂度也大幅提升，数据库需要提高对向量分析和 AI 应用的支持能力。所以向量数据库也是人工智能与数据库结合发展的一个趋势。多模能力（包括向量检索）让应用可以把结构化数据和非结构化数据统一处理，所以说向量数据库也是“数据库一体化”发展的一个体现。

数据库到底能不能跑在容器里，如果不能，那么那么多的云服务商的云数据库产品不都跑在容器里面吗？数据库一般是有状态的，对于容器的快速扩展十分不利，除非存储服务单独提供，同样对于产品的设计难度要求更高。主要是担心容器被rm掉时，容器里的数据会丢失，即使使用数据卷挂载存储数据，由于容器数据卷对Union FS 镜像的持久存储依赖，数据安全缺乏保证，同时如果容器崩溃时，若数据库未正常关闭，可能会损坏数据。数据库一般对IO要求较高，一台物理机上的多个数据库容器将提升对服务器的IO压力。

随着阿里云、华为云的PolarDB、guessDB都在大力演进serverless版本的发布，部分特性已经发布公测，国内的另外两家云服务商移动云、天翼云也相继推出serverless版本，并计划近期公测，可以看出。数据库的系统架构相对稳定，内核层面尤其是在资源调度部分相对成熟，自成体系，面对这serverless的演进，挑战不言而喻。了，所以进行serverless的改造成本，相比传统数据库来说，小多了，是可以实现的，但是这个改造的深度就要看各大云服务商的投入了，我还是那句话，

节点中的每一个Pod发生变化以后，结果是保存在API Server中。而后API Server会生成一个通知事件，Kube-Proxy负责接收API Server的通知事件，一旦发现了某一个Service背后的Pod信息发生了改变（IP、Port等），由Kube-Proxy负责在每一个节点上将变化后的service转换成IPVS或IPtables规则中。它负责观测每一个node上总共可用的cpu计算和存储资源，并根据用户请求创建的容器所需要的资源量在众多node中挑选出一个符合条件的node来创建容器。

用户原有业务通过不同版本型号、不同操作系统的主机承载，形式上包括物理服务器、虚拟机、公有云主机等。随着业务不断扩张，需要将其业务云化转型，必须保证上云过程数据完整，业务平滑过度。如果将所有业务系统都重新部署、重新配置服务，并需要将大量的用户数据进行传输拷贝，将会耗费大量的人力和时间。并且，将业务系统切换到新环境的的过程中，需要进行大量的测试工作，以保证业务系统迁移的成功率。

对象存储与块存储、文件存储并列为云计算三大存储模型。提供海量存储空间服务，具备快速的数据存取性能、高可靠和数据安全性，通过标准的RESTful API接口和丰富的SDK包来提供服务，支持容量和处理能力的弹性扩展。

Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java语言开发的，并作为Apache许可条款下的开放源码发布，是一种流行的企业级搜索引擎。Elasticsearch用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。官方客户端在Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby和许多其他语言中都是可用的。

在实现一个具有复杂业务逻辑的应用系统时，大多数情况下，编码过程中必定会包含着较多的数据访问方法（java中称之为方法）或函数（c中称之为方法），同样也就意味着多次的数据库连接。一方面复杂的逻辑会将程序的响应时间拖延过长，另一方面多次的数据库连接势必会给数据库带来过多的访问压力。

1、大中型企业第一个需求就是，云数据库需要适配企业的管理架构，不同部门之间的数据传递、共享一般都有独立的平台部门维护，同时每个部门又有定制部分，整个企业内部最关键的是要维护企业数据模型的稳定一致。该层是根本解决数据库扩展性的一层，事务层的扩展能力决定了数据存储的上限，因为CAP理论之下，不可能无限的舍弃其中任意一环，实现租户级别的单独扩展能力，则需要依赖内存块级别的节点资源占用调度。2、私有云数据库系统：成本节约的同时，保证了系统和数据逻辑独占的需求，提升了自主和安全感等级，是大中型企业客户的选择。

4、人设进一步树立，坚决、结果导向，敢于批评与自我批评。1、技术领域事业打开，打开一半，另一半要谨慎。3、攻坚克难打开，打开一半，关系管理要加强。2、管理思路打开，打开一半，另一半靠落实。

云计算和数据库的下半场才刚开始，网络和数据库之间的缘分还没开启呢

5种算法初始值均为20（总合为100），当一次异常的判断后，比如算法1/2/3都判定是异常，算法4/5都判定为非异常，那么最终结果为判定为异常，系统向运维人员发出告警，当运维人员在平台上通过指标横向对比、请求下钻、事件挖掘之后发现该时刻的指标确实为异常，那么运维人员会将这个告警处理掉，那么此时后台就会默认向投票正确的算法的权重倾斜，为其权重加1，同时为投票错误的算法权重扣分（但总分仍保持100分）；人工智能那么强大，应用场景十分的广泛，当然也包括运维领域，而且面向业务型的智能运维更是运维发展的热点趋势。

但是有一点不得不说，企业也需要有一定的人员投入，一方面充分理解云服务产品的最佳使用方法，一方面也要知悉云产品带来成本效益的同时，需要配合分享该防范，当然这一部分也可以通过云服务配套解决，但是企业需要改变观念去投入，去解决，不能完全依靠云服务商，毕竟云服务商提供的还是标准化的产品服务，用的好与不好直接决定上云业务的质量。2，产品新版发布，建议技术创新角度使用新型数据库，如云原生数据库、数据仓库，对于生产需求不匹配带来的需求，建议选型不变，过渡期间完成选择，云数据库是首选。发展态势，是否公司主流业务。

云原生已经成为企业数字化转型、业务创新升级的首选，我们正在迈入构建以应用为中心的云原生基础设施的Cloud Native2.0时代。“云原生定义未来架构”--Cloud Native Define Futrue Architectrue 云原生是一种新的模式，基于云丰富的能力与产品，可以组合形成非常多形态的SaaS产品。传统的云原生定义是“微服务、容器化和DevOps”，但是现在转变为“底层技术、编排及管理技术、安全技术、监测分析技术以及场景化应用”等众多分支。运维模式：分为开发部+运维部，交钥匙的方式。

方法二：在方法一的基础上为每个算法加入权重值，5种算法初始值均为20（总合为100），当一次异常的判断后，比如算法1/2/3都判定是异常，算法4/5都判定为非异常，那么最终结果为判定为异常，系统向运维人员发出告警，当运维人员在平台上通过指标横向对比、请求下钻、事件挖掘之后发现该时刻的指标确实为异常，那么运维人员会将这个告警处理掉，那么此时后台就会默认向投票正确的算法的权重倾斜，为其权重加1，同时为投票错误的算法权重扣分（但总分仍保持100分）；如此经过长时间的不断调整，算法组合就越来越接近于准确。

智能运维（AIOps-Algorithmic IT Operations基于算法的IT运维）是人工智能技术在IT运维领域的运用，引用Gartner 的报告的一段话“到2020年，将近50%的企业将会在他们的业务和IT运维方面采用AIOps，远远高于今天的10%”，最近2-3年智能运维的概念随处可见，各大互联网公司、传统IT公司、金融业等都在谈他们的智能运维设想，同时也有人谈AI色变，觉得人工智能只是一个愿景，要落地很难。传统运维系统收集了大量的运维数据，但是却缺乏有效的手段加以分析和利用；

随着云计算的持续发展成熟，越来越多的企业将自己的业务数据和应用迁移到云上，以寻求更快更具可扩展性的部署以及更低的成本。虽然上云能够为企业带来诸多红利，但是云迁移只不是一个迁移软件工具的使用，而是一项复杂的系统工程，需要以科学和严谨的态度面对在实践过程中的诸多挑战。4）如何选择合理的迁移路径 从技术维度看，迁移也逐步从传统的人力密集型服务，向专业技术咨询服务的方向发展。特别是对云迁移来讲，不但需要对传统业务架构有比较深入的了解，还要对各种云上的应用构建最佳实践及构建成本有非常丰富的经验。

云原生业务应用成熟度模型从企业业务应用基础设施域、应用研发域以及服务治理域等三个能力域二十个过程域综合评估企业业务应用在弹性、高可用、自愈性、可观测性以及自动化等五个维度的云原生能力成熟度水平。自动化能力成熟度 = ⌊(I1+I2+D2+D3+D4+G1+G2+G3+G4+G5+G6+G7+G8+G9)/14⌋。弹性能力成熟度 = ⌊(I1+D1+D2+D4+G1+G2+G5+G6+G7+G8)/10⌋。高可用能力成熟度 = ⌊(I1+D1+G1+G2+G3+G5+G7+G8+G9)/9⌋。

MYSQL数据库的迁移原理，以及具体两种方法介绍。

本文通过一个示例，阐述通用性业务产品架构能力的评估标准，供参考，可用性、可维护性、性能、安全性，企业可以基于此构建产品PRR模型。

这里的资源包括传统的IDC资源、服务器和硬件资源、各类数据库产品和生态工具，以及丰富可控、可智能编排的网络（云内、云间、核心传输等），这里面运营商有着巨大的优势，未来会有更多的数据库迁移到国有的云运营商上。笔者也大胆预测一条，数据库的边界与存储将进一步模糊，具有智能和管控的存储也将是数据库领域未来必将考虑的一条路，但是同时带来的产品非标的情况将进一步劣化，需要做好数据库平台化的管控方能解决这个问题。算网数据库是一个双向赋能的产物，会催生更多新型形态的数据库产品，数据库服务于算力网络、也受益于算力网络。

而普通数据库则需要通过传统的数据库软件客户端进行重新安装部署、插件增量部署，部署一次的代价相对较大，无法做到完全不停服，所以没法支持业务敏捷迭代。，而普通数据库在二者之间的权衡则需要付出巨大的代价，额外插件的引入也会使得架构变得相对复杂，一般来说高并发业务下，数据一致性往往被适当的舍弃，对于业务的影响大多无法避免。而普通的数据库则可以直接运行在本地硬件、虚拟机上，也可以基于简单的对云的应用构建基础的云数据库，但是仅限于基础调度能力上了云，内核和设计理念仍然为传统的架构。相比托管型的数据库如MySQL等，

很多上了云的业务运维团队依然在抱怨，已经花了大价钱使用了云数据库，为什么还要那么操心，每周的故障也不少，甚至比以前更多了？一、很多业务的运维团队都有这样的困扰？我相信很多运维的团队都有这样的感受，明明使用上了最先进的云数据库，但是还是在受着持续的困扰和煎熬，貌似对于云服务商的投诉也看不到效果。我这里想谈几点我自己的感想，本人做过企业开发工程师，也做过云服务商的产品架构师，其实大家对于上云一直都有或多或少的误解。

云原生化、平台化、一体化和智能化另外基于云原生构建多模数据库可是一个趋势，再次本文简单预测云数据库发展的新篇章，必然是“算力网络+云原生”的高层及结合。

将不同的功能模块服务化，独立部署和运维，标准是按照业务的关联程度来决定， 关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。1、基于业务逻辑拆分：将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。4、基于性能拆分：将性能要求高或者有性能瓶颈的模块拆分出来，避免性能压力大的服务影响其他服务。2、基于可扩展拆分：将系统中的业务模块按照稳定性排序，经常变化的服务拆分粒度较细。4、可用性提升，扩展灵活性提升，为实现高可用、可扩展提供了基础。

围绕架构设计的通用思想，从可用性、扩展性、高性能、一致性四个方面重点强调了架构设计的基本方法理论，具有较强的通用性和指导性。

国内安装k8s的四种途径：1. 使用kubeadmin通过离线镜像安装2. 使用阿里公有云平台k8s,钞能力3. 通过yum官方仓库安装,上古版本4. 二进制包的形式进行安装,kubeasz (github)