经常有这样的 case ，业务线开发同学需要 DBA 帮助其在不同的 PostgreSQL 数据库或集群之间同步数据。

数据量较小时，使用 pg_dump 工具或 copy 命令即可完成同步需求。但当数据量较大时，直接同步数据容易引发源 DB 或目标 DB 出现 slow query 或主从同步延迟等问题，容易对数据库的性能及稳定性造成不良影响。

而且无论数据量大小与否，有时候手工或写定时任务同步数据都很容易出错，且目标DB的数据如果恰好有人在使用极易与同步数据的任务相互阻塞。

是否存在其他数据同步方案避免上述问题呢？通过调研加实践，PostgreSQL中运用FDW与Materialized View可以较好的优化上述问题。

探讨高性能网关核心设计、实现与治理经验。

文章通过MySQL官方文档和MySQL源码两个方面，分析了MySQL主从复制延迟参数Seconds_Behind_Master是如何计算的。

近年来，人工智能逐渐在安防，教育，医疗和旅游等工业和生活场景中落地开花。在携程旅游业务上，AI技术同样广泛覆盖了多个旅游产品和旅游服务领域，携程度假AI研发根据旅游的特定场景和业务需求，将自然语言处理，机器翻译，计算机视觉，搜索排序等主流AI技术成功应用于旅游度假的多个业务线，例如自由行，跟团游，签证，玩乐和租车等。

从技术角度，为了适应不同的业务场景需求，涉及到多种AI技术，包括传统机器学习，卷积神经网络，Transformer等深度学习模型结构，以及知识图谱和图神经网络等技术领域。同时，为了充分挖掘AI技术的优势，模型设计复杂度日渐提升，包括模型深度，宽度以及结构复杂度等各个维度，计算量的增大使得AI推理性能瓶颈日益凸显，尤其是实时性的业务需求对推理速度要求更高。为了追求最佳推理性能，往往需要手动进行逐个优化，涉及的开发，部署和沟通成本都很高。主要问题集中在：

• 模型结构种类多，性能瓶颈差异较大，适用的优化方法各有不同，手动优化成本高；
• 优化方法众多，自上而下，涉及多种模型压缩方式，系统级，运行时优化等，手动优化门槛高；
• 逐个手动优化，可推广性差，技术覆盖面有限；
• 硬件平台的差异，需要针对性调优，导致优化的人力成本和部署成本都很高；
• 新模型的发布和迭代，需要应用优化方法，涉及较高的沟通和接入成本，同时带来了性能的不稳定性；
• 模型压缩技术对不同模型的优化效果有所差异，可能需要进行模型的再训练，训练和数据准备流程较长，效率低下；

因此，为了降低优化，部署和迭代成本，提高工作效率，并保证性能稳定，我们尝试搭建模型自动化优化平台，旨在为算法模型提供更全面易用，稳定性更好，使用和维护成本更低的优化解决方案。

用量化的思维解决慢查询。

聊聊大数据元数据管理重要的一环字段血缘。

最近组内同学遇到一个问题，说数据库被业务打死了，无响应，只好用 kill -9 pid 杀掉，然后重启，幸好此时的数据库角色是从库，影响不大。同学自述，在杀掉重启的时候，心里默念，千万别启不来啊，这个库的数据量有点大，快要达到 4T 了。做运维的人都知道，事情就不能念叨，一念叨，这事儿就准发生。这次也不例外，确实是出现了。现象是长时间启动不了，基本卡死状态。

一道 Sequence 的“开水白菜”，敬请“享用”。

随着携程海外酒店业务的发展，遍布全球的海外供应商与携程总部IDC之间的数据传输量快速增长。技术上，这种日益增长的数据量对跨境网络专线的带宽、延迟等提出了更高的要求；业务上，由于当前有限的跨境网络专线资源对业务处理效率及用户体验也造成了一定的影响；成本上，跨境网络专线作为一种昂贵的资源，通过单纯的专线扩容又会给IT成本造成巨大压力。所以我们开始思考是否可以通过公有云结合酒店直连的业务特性来解决日益增长的带宽压力和供应商接口延迟的问题。

酒店直连系统主要是使用自动化接口实现供应商或集团与携程之间的系统对接，实现静态信息、动态信息、订单功能等都通过系统的方式流转交互。目前携程大量海外酒店业务是通过酒店直连系统对接。

本文将主要从携程酒店直连服务迁移部署至AWS过程中所进行的应用架构调整及云原生改造，使用AWS后取得的技术和业务收益，在部署过程中对EKS（Amazon Elastic Kubernates Service）、DNS查询延时和跨AZ流量降低所做的成本优化等几方面进行详细介绍。

一个表的数据量达到一定程度后，稳定性和性能就会出现瓶颈，"化整为零"对DBA 来说无疑是一个很好的选择，此时如何分表就成为摆在业务线开发同学和 DBA 面前的一道不可回避的课题。

相对于传统的开发同学自己根据业务及自己在应用代码中实现分表的方案，本文介绍一下 PostgreSQL 中如何实现对业务相对透明的分区方案。

Qunar 机票作为 Qunar 的核心业务之一，每天都有成千上万用户在 Qunar 的平台上完成搜索预定生单等操作， Qunar 也一如既往地为用户提供优质的出行体验和保证。

探索采用非人工标注文本数据的方式来建立训练数据集的可行性。

Google Play 商店在 2021 年第 3、4 季度正式加强对应用 targetSdkVersion 的限制，要求应用必须以 API 级别 30 (Android 11) 或更高版本为目标运行环境。

作为第一个强制要求分区存储的 API 级别，Android 11无疑是近几年适配工作较为复杂的版本，各个 APP 的适配进度也被寄予期盼。Trip.com APP 在 2021 年第一季度进行了 Android 11 的适配，本文将从方案设计和技术改造等⻆度，聊一聊我们的实践与感想。

随着公司业务的不断扩张，无论是后端、前端抑或是客户端，都面临着应用越来越复杂，越来越庞大以至于难以维护和治理的问题，为了解决这个问题，后端的微服务架构就应运而生了；同理，前端的业务也遇到了类似的问题，自然而然的微服务架构的思想照搬到前端，于是前端的微前端架构应用而生：

一种由独立交付的多个前端应用组成整体的架构风格。具体来说就是将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。

在进入页面的过程中，用户不可避免地会看到一个加载动画。但加载动画往往比较古板，如果加载耗时稍微长一点，用户就会失去耐心离开页面。为了让用户有更好的浏览体验，骨架屏是一种较好的渐进式加载方案。

骨架屏的实现，也是视觉稿直出代码实现方案的 MVP (Minimum Viable Product)。本文会探讨骨架屏方案的优劣，以及一种前端智能化的骨架屏代码自动生成方案实践。

随着国际火车票业务的高速发展，订单量快速增长，单数据库瓶颈层面的问题逐渐显露，常规的数据库优化已无法达到期望的效果。同时，原先的底层数据库设计，也存在一些历史遗留问题，比如存在部分无用字段、表通过自增主键关联和各个应用直连数据库等问题。

为此，经过讨论后，我们决定对订单库进行分库分表，同时对订单表进行重构，进而从根本上解决这些问题。