DBAIOps的博客

其使用场景也是多样化的，最常用的是实现数据库安装部署时的操作系统优化的标准化，通过部署tuned profile并在操作系统启动时启动，可以十分便捷的管理数据库运行环境的操作系统参数。因为tuned profile设置是全局性的，因此根据你的OS的内存等不同，这些参数设置需要进行测试，而不要简单的照抄上面的作业。下面我们利用同样的方法来配置一个PG的tuned profile，里面使用的标准化的操作系统参数是利用2017年IBM实验室在zlinux上针对PG的操作系统优化的最佳实践。

因此分层计算成为必然。这位大哥实际上是知道的，目前的数据中台里压根没有实时数仓，目前数仓里的数据是T+1的，即席查询是肯定没戏的。比如面向客户服务类应用的用户画像，当用户和我们的信息系统交互的时候，系统应该很快的对该用户进行精准的画像，从而更好的为这个客户服务，为客户提供个性化的信息与服务。实时数仓是相对于传统数仓而言的，以前的传统的数仓都是T+N的，因为数据要从生产环境到ODS再经过ETL进入数仓成为明细数据，经过计算加工形成轻度汇总汇总数据和统计数据，再根据主题组织为数据集市，再提供给数据应用使用。

最近这几年数据库领域有一个十分热门的词汇，就是HTAP。如果你家的数据库不是HTAP数据库，都不好意思拿出来和别人见面。对于HTAP数据库这个概念老白是一头雾水的。在20年前，我在给客户做oracle数据库培训的时候，就会提到HTAP负载，OLTP负载和OLAP负载是天然不同的两种不同的负载。OLTP负载是日常的交易型工作负载，其特点是高并发和小事务，SQL语句一般都相对简单，不过并发访问量很大，数据修改的量很大；OLAP负载是一种低并发，少修改，复杂查询的工作负载，一些SQL可能需要进行大规模的数据扫描，

而这种设计会让单一的数据库太重了，一旦这个数据库出现一点点问题，可能就会影响整个企业的业务，这是我们无法承受的。目前来说，电是不可大规模存储的资源，而且电源侧发出的电必须平衡的被消耗掉，否则多发出来的电必须被尽快消耗掉，而某个局部网络上的电能不足时，就只能拉闸限电，确保电能在网络上整个是平衡的。只是说，目前我们的国产数据库的HTAP能力建设还处于初级阶段，目前大多数国产数据库能够提供的HTAP能力大部分可以通过业务系统优化来避开，而真正对HTAP强需求的场景，我们的产品的支撑能力还不足。

对于分布式数据库来说，无法在P99延时内执行完某条SQL，但是数据库服务还是能承接相关业务的，这种情况是比较常见的故障场景，也是我们的DBA面对的束手无策的常见场景。而如果此时叠加一些其他的因素，比如某块硬盘的IO延时过大、某个网卡出现丢包、某个节点的操作系统出现严重换页，那么整个分布式数据库环境就有可能出现了正常的处理逻辑无法承受的临界状态，再叠加上数据库本身就存在的一些对此类情况处理不周的BUG，那么数据库出现严重的问题，甚至出现无法对外提供服务的情况，也是必然的。”状态，此时数据库服务质量大幅下降。