- 综合排序
- 最热优先
- 最新优先
- 来自专栏数据和云
“去O”不如“减O”
去IOE的话题最近很火，而来自四川电信的客户访问，其中有一段颇有借鉴意义：去“O”不如减“O”。 “去O”不如“减O” - 在成功去掉小型机之后，TechTarget记者还向梁天健询问了关于去E（EMC存储）和去O（Oracle数据库）的话题。 再谈到去O，梁天健的态度很明确，从技术层面来讲，目前很多企业连Oracle这样具有高可用、高性能、易用性强的数据库都没有用好，去O根本无从谈起。 对于这些企业，他们的首要目标应该是提升运维和开发水平，而不是为了去而去。真要谈去O，可能MySQL会是首选。而MySQL数据库在复杂SQL、数据存储等方面都有着不少的缺点。 梁天健认为答案是否定的：“我们不去O，但是我们可以尝试减O。何谓‘减O’？就是将假设现在的200个独立的Oracle数据库整合到20个更大型的Oracle数据库中去。”
2.1K60发布于 2018-03-05 - 来自专栏数据和云
去O入云的探索--Oracle到MySQL的迁移改造方案
2.数据迁移 数据迁移的前提是表结构改造完成，并已经在MySQL中创建。 Oracle数据迁移到MySQL采用三步走的策略：Oracle到MySQL的全量同步；Oracle到MySQL的增量同步；MySQL到Oracle的增量同步。 3.O2M全量数据初始化 Oracle OGG初始化本地采用File to replicat的方式进行。即先在源端抽取出数据生成文件投递到目标端，在目标端再去复制到数据库中。 /defgen paramfile /home/oracle/ogg/dirprm/defgensource.prm scp o2msource.def root@192.168.56.225:/root 现负责公司Oracle、MySQL、Postgres数据库运维方面的技术工作；热衷于运维故障处理、备份恢复、升级迁移、性能优化的学习与分享。 END
2.2K40发布于 2021-08-27 - 来自专栏腾讯云数据库(TencentDB)
2019，为什么“去O” 势在必行？
最为常见的误区有以下几种： 误区 — 去O一定能省成本 可以说，这是很多公司做去O的，做原始的初衷。但在实际操作中，大家也逐步认识到去O是会增加成本的，或者说起码在短期内会增加成本。 误区 — 去O就是用MySQL替换Oracle 去O的方案可能有很多种，MySQL只是其中之一，我们要根据项目情况从多种技术方案中酌情选定，不能一概而论。可参考一下之前整理的去O方案小结，如下图。 误区 — 去O难点在于新数据库运维 去O的主要困难不在于新数据库运维，而是数据一致性和性能方面的挑战，其本质是数据架构管控的争夺。 各大企业都着力打造自己的核心数据库产品，同时在产品设计上也考虑与传统数据库的兼容问题，甚至提供了”一键式”的迁移咨询方案。这都大大降低了企业去O的顾虑。 总结 二O一九，“去O”元年，天时已到，地利成熟，人心所向，“去O”正当时！
10.6K50发布于 2019-06-13 - 来自专栏韩锋频道
去O：为什么这么难
去O的话题，可谓由来已久。从十年前阿里提出了这一口号，并率先在公司内部实现了数据库的整体去O开始，到后面从互联网公司到传统企业也纷纷跟进，可以说去O的理念已逐步深入人心。 笔者之前曾有过这样的体验，某项目去O迁移（包括应用改造等）总共花费三天时间，但上线后的优化足足花了一个月，甚至很多代码不得不重写。 这其中还需要考虑新老系统的共存、数据迁移带来的应用适配等种种问题。可以说这方面带来的工作量，是整个去O工作中的主体部分，也是关乎到其最终替换效果能否达到预期的关键。 很多企业也是看到这一点，因而才考虑去O的。 选择了去O，仅从经济投入角度也会带来很大一笔投入。 去O本身并不是目的，如何在未来基础软件使用发展上有着自主能力才是关键。大势所趋，乘风而上；希望更多企业在去O中磨练自身能力，同时助力开源、国产数据库技术长远发展。
1.4K20发布于 2020-11-05 - 来自专栏韩锋频道
三谈去O之“数据库画像”
很多公司在考虑去O的时候，经常面临这样的问题—"对自己的数据库不够了解"，也不免有这样一些疑惑： [管理者] 数据库去O成本高嘛？ 工作量大不大？ 工期长吗？ 是否存在什么风险？ 基于上面的数据库画像，对去O工作全周期进行指导，包括以下方面都将大有裨益： 决策阶段：整体难度、成本（人财时）、技术风险 架构阶段：技术方案、对象结构、性能评估 研发阶段：兼容性、复杂度、测试 迁移阶段 不仅可作为去O评估依据，亦可作为后续改造的数据参考。 画像解读 下面针对报告数据进行解读，并对常见的去O选型-MySQL进行说明。 1 概要信息 ? 显示收集的目标的概要信息，包括IP、实例、用户等。 在具体去O工作中，新技术方案是否满足需要，可通过此方法进行评估验证。更多用业务的语言，来对比去O前后的承载力变化。这也是决策技术方案是否可行的考虑因素之一。 写在最后 去O是项系统工程，需要做好充分的评估。本文通过自研工具，生成数据库画像，为去O评估提供一手数据，希望给大家带来借鉴。
1.6K20发布于 2019-06-19 - 来自专栏韩锋频道
再谈去O之天时地利人和
“去O”，是近些年来一直很火的一个话题。但2019年，也许有着更加特殊的意义。随着国家监管要求、外部环境变化、国产数据库兴起等多种因素，相信今年会是“去O”井喷发展的一年。 最为常见的误区有以下几种： 误区 — 去O一定能省成本 可以说，这是很多公司做去O的，做原始的初衷。但在实际操作中，大家也逐步认识到去O是会增加成本的，或者说起码在短期内会增加成本。 误区 — 去O就是用MySQL替换Oracle 去O的方案可能有很多种，MySQL只是其中之一，我们要根据项目情况从多种技术方案中酌情选定，不能一概而论。可参考一下之前整理的去O方案小结，如下图。 误区 — 去O难点在于新数据库运维 去O的主要困难不在于新数据库运维，而是数据一致性和性能方面的挑战，其本质是数据架构管控的争夺。 各大企业都着力打造自己的核心数据库产品，同时在产品设计上也考虑与传统数据库的兼容问题，甚至提供了”一键式”的迁移咨询方案。这都大大降低了企业去O的顾虑。
78240发布于 2019-06-15 - 来自专栏宜信技术实践
通过自研数据库画像工具支持“去O”评估
“去O”，是近些年来一直很火的一个话题，随之也产生了各种疑惑，包括现有数据库评估、技术选型等。去O是项系统工程，需要做好充分的评估。 一、常见疑惑 很多公司在考虑去O的时候，经常面临这样的问题—"对自己的数据库不够了解"，也不免有这样一些疑惑： [管理者] 数据库去O成本高嘛？ 工作量大不大？ 工期长吗？ 是否存在什么风险？ 基于上面的数据库画像，对去O工作全周期进行指导，包括以下方面都将大有裨益： 决策阶段：整体难度、成本（人财时）、技术风险 架构阶段：技术方案、对象结构、性能评估 研发阶段：兼容性、复杂度、测试 迁移阶段 不仅可作为去O评估依据，亦可作为后续改造的数据参考。 三、画像解读 下面针对报告数据进行解读，并对常见的去O选型-MySQL进行说明。 3.1 概要信息 ? 在具体去O工作中，新技术方案是否满足需要，可通过此方法进行评估验证。更多用业务的语言，来对比去O前后的承载力变化。这也是决策技术方案是否可行的考虑因素之一。
1.4K20发布于 2019-07-23 - 来自专栏腾讯云数据库(TencentDB)
保险业深度去 O 的“因地制宜”解法
点击可查看大图 目前，腾讯云TDSQL已成为多家头部保险公司数字化转型的坚实底座，以中国太平为例，中国太平大部分业务系统是基于Oracle一体机建设的，2021年开始启动分布式数据库选型采购，经过产品迁移验证 中国太平基于腾讯云TDSQL完成了2021、2022年业务系统国产化建设改造，从OA等外围系统逐步深入切换到核心系统，1个月完成6套业务系统从异构数据库迁移到TDSQL分布式数据库，2022年平稳支撑业务快速增长
38610编辑于 2023-12-21 - 来自专栏腾讯云数据库(TencentDB)
保险业深度去 O 的“因地制宜”解法
点击可查看大图 目前，腾讯云TDSQL已成为多家头部保险公司数字化转型的坚实底座，以中国太平为例，中国太平大部分业务系统是基于Oracle一体机建设的，2021年开始启动分布式数据库选型采购，经过产品迁移验证 中国太平基于腾讯云TDSQL完成了2021、2022年业务系统国产化建设改造，从OA等外围系统逐步深入切换到核心系统，1个月完成6套业务系统从异构数据库迁移到TDSQL分布式数据库，2022年平稳支撑业务快速增长
42310编辑于 2023-12-21 - 来自专栏PingCAP的专栏
陆金所金融核心场景数据库的去 O 之路
陆金所全站去 O 成果 [up-733824c8ca29448d9c2bd07e0bbda029017.png] 陆金所全站去 O 项目从 2018 年中开始，整个项目迁移过程中没有做任何的服务降级， 在这样一个多团队参与的项目中，去 O 过程需要有严格的标准，并且要有严格的流程去监控这些规则是否有效落实到每一行代码的改造和变更上，否则任何一个环节出现失误都可能导致数据迁移过程中不一致，或者业务逻辑在迁移过程中发生变化 金融系统去 O 的主要工作 金融系统去 O 分为以下四个步骤： 第一，应用层的服务化改造； 第二，从 Oracle 数据库到开源数据库的数据字典的转换，包括数据的迁移，以及迁移后云端和目标端数据一致性的校验 [up-1953317db66b63fd3938a5c01441e19e4c5.png] 在这种架构中，去 O 工作很难有效推进，因为如果要迁移一张表，可能上层有很多关联的应用要同时进行改造，应用间的相互依赖 流水线式去 O 改造效率提升效果 [up-3624fb8a386a5d189498331550d1323656b.png] 我们可以看到去 O 过程中大部分工作集中在数据库的迁移，还有开发人员的 SQL
1.2K20发布于 2021-01-22 - 来自专栏AI科技评论
单语言表征如何迁移到多语言去？
作者 | 刘旺旺 编辑 | 唐里 论文：On the Cross-lingualTransferability of Monolingual Representations 单语言表征的跨语言可迁移性的研究 这篇文章主要设计实验去评判上述的观点。 证明了零样本迁移既不需要共享的子词词汇，也不需要联合的多语言训练。 发现每一种语言的有效词汇量是训练多语言语言模型的重要因素。 证明单语模型学习跨语言泛化的语义抽象。 一定需要上述三个因素才能有一个好的模型去解决跨语言的任务吗？文本设计了方法进行了探究。 证明了这些模型在标准的零样本跨语迁移基准上的表现是相似的，这表明在多语言模型中既不需要共享词汇，也不需要联合的预训练。
75010发布于 2019-11-26 - 来自专栏别先生
时间复杂度o(1), o(n), o(logn), o(nlogn)
1、时间复杂度o(1), o(n), o(logn), o(nlogn)。算法时间复杂度的时候有说o(1), o(n), o(logn), o(nlogn)，这是算法的时空复杂度的表示。 O后面的括号中有一个函数，指明某个算法的耗时/耗空间与数据增长量之间的关系。其中的n代表输入数据的量。 2、时间复杂度为O(1)。 哈希算法就是典型的O(1)时间复杂度，无论数据规模多大，都可以在一次计算后找到目标（不考虑冲突的话） 3、时间复杂度为O(n)。 就代表数据量增大几倍，耗时也增大几倍。 比如常见的遍历算法。 再比如时间复杂度O(n^2)，就代表数据量增大n倍时，耗时增大n的平方倍，这是比线性更高的时间复杂度。 比如冒泡排序，就是典型的O(n^2)的算法，对n个数排序，需要扫描n×n次。 5、时间复杂度为O(nlogn)。 就是n乘以logn，当数据增大256倍时，耗时增大256*8=2048倍。这个复杂度高于线性低于平方。 归并排序就是O(nlogn)的时间复杂度。
2K10发布于 2019-10-15 - 来自专栏全栈程序员必看
O2O网站
与O2O还有其它模式的有B2B.B2C.C2C。 的成分，也包含O2O以外的东西，完全可以称为采用O2O模式运营的网站非常少，美乐乐家居网算是比较典型的例证。 ，再到线下去享受服务，最后到平台去评价商品和服务质量以达到和消费者互动的目的。 我们发现，酒吧、KTV、餐馆、加油站、理发店、健身房、干洗店等等，是不能把它的服务送到我们面前的，而必须我们到线下实地去享受服务。 因此，团购让O2O模式发挥了淋漓尽致的效果。但团购是低折扣的临时性促销，甚至商家并没有真正参与到 电子商务运营中来，还不能说是完全的O2O模式。
1.3K20发布于 2021-10-18 - 来自专栏人人都是极客
算法复杂度O(1),O(n),O(logn),O(nlogn)的含义
相信很多开发的同伴们在研究算法、排序的时候经常会碰到O(1)，O(n)，O(logn)，O(nlogn)这些复杂度，看到这里就会有个疑惑，这个O(N)到底代表什么呢？带着好奇开始今天文章。 首先o(1), o(n), o(logn), o(nlogn)是用来表示对应算法的时间复杂度,这是算法的时间复杂度的表示。不仅仅用于表示时间复杂度，也用于表示空间复杂度。 index = a; a = b; b = index; //运行一次就可以得到结果 时间复杂度的优劣对比常见的数量级大小：越小表示算法的执行时间频度越短，则越优； O(1)<O(logn)<O(n)< O(nlogn)<O(n2)<O(n3)<O(2n)//2的n方<O(n!) <O(nn)//n的n方
8.5K30发布于 2020-04-14 - 来自专栏叶子的开发者社区
O0 O1 O2 O3优化原理
为了加快代码执行的效率，很多OJ平台都会自动开启O2优化。 在这里我们讲讲到底是怎么优化的。 O0优化 #pragma GCC optimize(0) 1、把变量分配到寄存器。 O1优化 #pragma GCC optimize(1) 包含O0的各种优化功能，并增加了： 1、在变量赋值时，将数值直接赋给变量而不是给出变量的地址。 2、去掉没有用的变量和表达式。 O2优化 #pragma GCC optimize(2) 包含O1的各种优化功能，并增加了： 1、去掉全局通用的子表达式。 2、去掉全局没有用的分配变量和表达式。 3、化解循环。 当只用-O选项时优化器自动进行-O2优化。 O3优化 #pragma GCC optimize(3) 包含O2的各种优化功能，并增加了： 1、去掉未调用的函数。 2、简化返回值未使用的函数。
1.1K20编辑于 2023-07-30 - 来自专栏卯金刀GG
【转】算法中时间复杂度概括——o(1)、o(n)、o(logn)、o(nlogn)
在描述算法复杂度时,经常用到o(1), o(n), o(logn), o(nlogn)来表示对应算法的时间复杂度。这里进行归纳一下它们代表的含义:这是算法的时空复杂度的表示。 O后面的括号中有一个函数，指明某个算法的耗时/耗空间与数据增长量之间的关系。其中的n代表输入数据的量。 比如时间复杂度为O(n)，就代表数据量增大几倍，耗时也增大几倍。比如常见的遍历算法。 再比如时间复杂度O(n^2)，就代表数据量增大n倍时，耗时增大n的平方倍，这是比线性更高的时间复杂度。比如冒泡排序，就是典型的O(n^2)的算法，对n个数排序，需要扫描n×n次。 二分查找就是O(logn)的算法，每找一次排除一半的可能，256个数据中查找只要找8次就可以找到目标。 O(nlogn)同理，就是n乘以logn，当数据增大256倍时，耗时增大256*8=2048倍。 归并排序就是O(nlogn)的时间复杂度。 O(1)就是最低的时空复杂度了，也就是耗时/耗空间与输入数据大小无关，无论输入数据增大多少倍，耗时/耗空间都不变。
1.8K10发布于 2019-07-26 Oracle替代之路：企业去O过程中常见的坑与避坑指南
关键词：Oracle替代、国产数据库、去O、数据库迁移、信创、兼容性、高可用大家好！我是数据库小学妹最近发现一个有意思的现象：不管是金融、运营商还是政务单位，聊到数据库规划，三句话不离"去O"。 一、为什么要去O？三个现实压力先说说为什么企业非要换Oracle。成本：账单是真的疼上次跟一个保险公司的DBA大哥吃饭，从他口中得知他们公司的Oracle年账单高达七八百万授权费，还不算维保。 成本、合规、性能，三座大山压下来，去O已经是箭在弦上。二、Oracle替代的三大痛点搞过迁移的都知道，去O最怕的不是决策，是执行。我把跑项目中看到的最大痛点归为三个。 五、避坑清单：去O前必须做的几件事踩了这么多坑，总结了5条实操建议：1️⃣先摸底，别拍脑袋搞清楚现在Oracle里到底有什么：多少张表、多少个存储过程、数据量多大、高峰QPS多少。 金仓在兼容性、迁移工具、高可用和性价比这几块投入比较均衡，是国产数据库里去O赛道上一个值得认真考察的选项。技术没有最好，只有最适合。少走弯路，就是成功。
13110编辑于 2026-05-22- 来自专栏ThoughtWorks
去腾讯去豆瓣去外企去国内的企业去创业去考研去北京回老家去创新工场去ThoughtWorks？
每年一到要找工作的时候，我就能收到很多人给我发来的邮件，总是问我怎么选择他们的offer，去腾讯还是去豆瓣，去外企还是去国内的企业，去创业还是去考研，来北京还是回老家，该不该去创新工场？ 我说去腾讯吧，他说腾讯最近组织调整，不稳定。我说那就去豆瓣吧，慢公司，发展很稳当。他说，豆瓣的盈利不清楚，而且用Python，自己不喜欢。 朋友拉他去创业，觉得创业挺好的，锻炼大，但是朋友做的那个不知道能不能做好。 还有一网友在创新工场的某团队和考研之间抉择，不知道去创新工场行不行，觉得那个项目一般，但是感觉那个团队挺有激情的，另一方面觉得自己的学历还不够，读个研应该能找到更好的工作。 或者我们在过十字路口的时候，要从到对角线的那个街区时，我们也会使用贪婪算法——哪边的绿灯先亮了我们就先过到那边去，然后再转身90度等红灯再过街。 这样的例子有很多。
1.4K100发布于 2018-04-18 - 来自专栏NewBeeNLP
B O O M
连接图像和文本，更多的多模态文章可以看博主整理过的系列（跨界出圈 | 谈谈BERT跨模态预训练），本篇文章主要整理一下OpenAI发表的2篇文章。其中CLIP 能够完成图像与文本类别的匹配，DALL·E 则可以直接基于文本描述生成图像，且性能十分优异。
1K20发布于 2021-10-20 - 来自专栏数据和云
去O渐成过去式,Cloud进入现在时-Oracle技术嘉年华精彩回放
这次“Oracle技术嘉年华”大会让我深为感触的有以下几点： 去O渐成过去式，Cloud进入现在时 - 在5年的技术嘉年华大会历程中，2014年是低谷，源于大家对“去IOE”热衷，而经过2年多的实践，越来越多的企业认识到 ，盲目去O是不现实的，回归理性，让适合MySQL走向MySQL，让适合Oracle的O下去，没有必要将正常的技术演化为情绪。 Oracle在很多领域存在独特的竞争优势，去O已成过去式，Cloud进入现在时。 ? 用戴总的话来说：SQL审核承担了“廉政公署”的角色，辅助用户监督和帮助开发商去完善SQL，改善性能，从而确保上线之后的稳定运行。 ? 四川电信的张明张总，则是介绍了他们在去小型机转向X86化的成功经验，在中国电信的各省公司中，四川的技术创新、转型一直走在前列，从去年的CRM系统云化，去小型机取得了成功，今年则同云和恩墨联合，通过zData
1.4K70发布于 2018-03-05
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号