ITPub博客

3月25日，在春暖花开之际，OceanBase举办了自己的首届开发者大会，加速构建开发者生态。大会发布了OceanBase 4.1版本，公布两大友好工具，升级文档易用性，统一企业版和社区版代码分支，全面呈现了OceanBase打造极致的开发者友好数据库的成果。

关于优化中的大势判断前些年我也写过一篇，优化就像下围棋一样，需要在大势判断正确的情况下，做出很多提前布局，确保每一步落子都能获得相关支撑。

当前大部分企业都在做数字化转型，但盲目者也不在少数，所以造成了项目实施难、上线难、应用难，造成最终价值体现难，如何解呢？

要想让一道菜好吃，炒菜的主料配料选择与配比十分关键，只有主料一味未免单调，而选择比较抢戏的配料也不合适，会把主料的味道给冲了，让菜的味道变得比较怪异。合适的主配料搭配和配比是一道菜好吃不好吃的基础。

在容器化部署成为主流的现在，降低集群中单个容器的资源需求的意义已经不只限于更少的硬件成本，同时也意味着整个集群更加轻量化，这通常会带来一系列其他优势

不少DBA朋友都觉得对于系统，只要是优化就一定是有效的，因此哪怕做的不对症，也没有关系，大不了就是没效果呗。而事实上不是这样，一个糟糕的优化工作可能带来的负面影响是十分巨大的。

业务负责人和CIO需更加重视利用人工智能/机器学习和数据分析技术，来感知和预测客户、市场、生态系统和商业环境的波动，有助于了解客户在整个关系生命周期中交换和累积的价值。

3月25日，OceanBase首届开发者大会将在北京举办，大会下设一个主论坛和场景与最佳实践专场、产品技术专场、开源生态专场、数据管理与服务技术专场四个专场。届时，所有对开源分布式数据库感兴趣的开发者们将汇聚一堂，与行业大咖共同探讨单机分布式、云原生、HTAP等数据库前沿技术发展趋势。

近日在甲方群里与CIO们聊天，大家感到数字化转型越做越迷茫了，传统企业里数字化的预算越来越少，有的行业甚至已经没有了预算。

原始数据(通常称为源数据或原始数据)是尚未经过处理、编码、格式化或分析以获取有用信息的数据。虽然原始数据是一种宝贵的资源，但由于它在视觉上杂乱无章且缺乏凝聚力，因此很难理解或采取行动。

对操作系统指标的理解，是要经过大量案例的磨练，并不断的通过知识学习来完成的，而实际上我们在学习这些知识的时候，往往会看到很多过时的，甚至错误的知识。

做一个自动化工程平台实际上并不是把一些自动化脚本整理好，做个工具就可以了。运维生产安全日益被企业所重视的今天，不管是工具化、自动化还是智能化，运维的本质安全是最为关键的。

要提高数据库的故障自愈能力，0数据丢失备机或者共享存储RAC集群是十分关键的能力。要想实现复杂场景中的故障自愈，重启或者切换依然是应用系统最容易实现的手段，但是在应用系统中切换主数据库并不是一件容易的事情。

通过分析LOAD PROFILE，可以帮助DBA评估数据库系统的负载情况，并作出相应的优化决策。例如，如果LOAD PROFILE报告物理读非常高，那么可以尝试增加内存缓存，减少物理读取的次数，以提高数据库的性能，或者优化后端存储的IO性能。

所谓一方消费者数据(后面也可能简称为一方数据)，是企业自己获取到，并能够被企业自己有拥有的消费者的数据。在我们有互联网有数字化之前，第一方数据就已经是企业的关键性数据。比如，在企业的客户关系管理体系中，以订单数据、交易数据为主的数据。

大家都清楚数字化转型需要技术与业务的融合，线上与线下的统筹，但具体到相关落地层面，大部分企业面对数字化又会显得无所适从，今天就来总结一下影响企业数字化应用效果的几大因素

今天我们聊聊新人产品经理在实践中经常会犯的一些问题。很多新人产品经理写PRD，一上来就是先开始写系统交互、功能用例。觉得前面一大片的背景描述、范围描述、功能清单，都不是重点。认为真正的PRD精华内容就是在说需求细节。

Oracle数据库很复杂，想管好、优化好技术就要在管理Oracle的技术需要下大功夫，一旦掌握了，反而管理起来很简单，很顺手了。而PG数据库相对简单，想管好，优化好，在技术上并不复杂，掌握技术难度不大，但是你需要更为精细的去管理它，才能用好它。

数字化建设中的需求调研环节不仅仅是一个沟通过程，更是一个达共识的过程，只有业务部门、信息部门、软件公司三方以需求为基础，以共识为中心就建设方向、实施路径达成一致，后期的数字化实施过程才会一帆风顺，达到预期的效果。

单个产品的优化相对于整条产品线的规划来说是简单很多的。为什么产品线需要经营呢?因为每个产品都有它的周期，出生，兴盛，衰亡。