某业务方在使用MongoDB过程中遇到不少线上故障问题，由于公司目前仅支持线上查询Hive和Mysql数据，因此定位分析只能靠公司基础部门提供的ELK日志平台去分析处理，如果恰好没有打印相关逻辑日志，则往往只能重新改造代码加些详细日志重新发布上线再去定位，这无疑增加了业务方整个定位问题的时间周期而且非常麻烦。试想，如果我们能够提供实时查看线上MongoDB集合数据的入口再结合ELK日志分析，这将使业务方更方便快速定位线上问题。

于是我们调研了各种技术方案，比如Presto、Calcite等查询引擎，由于Presto对MongoDB支持不够友好，比如需要单独部署服务端，Schema动态支持不够友好，MongoDB集合元数据字段无法准确获取导致需要对线上数据进行特殊处理等问题，而Calcite则相对比较轻量级，而且更加成熟，因为Calcite在Hive、Flink、Drill和Storm等知名大数据开源框架中都有广泛使用，有不少范例可供参考改进，我们只需在项目中简单依赖一些Calcite相关Jar且完成较为简单的二次开发即可集成到项目中使用。

本文分享的是 Bytedoc 3.0 关于集群交付方面的内容以及一些云原生的实践：如何将 Bytedoc 3.0 与云原生的能力结合起来，交付用户一个开箱即用的集群，与软件层的能力相匹配，最大化展示 Bytedoc 3.0 具备的“弹性”能力。

MongoDB是一个强大的分布式存储引擎，天然支持高可用、分布式和灵活设计。MongoDB 的一个很重要的设计理念是：服务端只关注底层核心能力的输出，至于怎么用，就尽可能的将工作交个客户端去决策。这也就是 MongoDB 灵活性的保证，但是灵活性带来的代价就是使用成本的提升。与MySql相比，想要用好MongoDB，减少在项目中出问题，用户需要掌握的东西更多。本文致力于全方位的介绍MongoDB的理论和应用知识，目标是让大家可以通过阅读这篇文章之后能够掌握MongoDB的常用知识，具备在实际项目中高效应用MongoDB的能力。本文既有MongoDB基础知识也有相对深入的进阶知识，同时适用于对MonogDB感兴趣的初学者或者希望对MongoDB有更深入了解的业务开发者。

详细介绍MongoDB。

腾讯 MongoDB目前广泛应用于游戏、电商、ugc、物联网等场景，很多客户在使用过程中库表数量会大量增长，甚至达到百万级别，导致性能急剧下降，严重影响客户业务。腾讯数据库研发中心CMongo团队在进行深入性能分析之后，改造底层引擎为共享表空间架构，新架构在百万级库表的场景下，相比原生版本读写性能提升 1-2 个数量级，内存消耗显著降低，启动时间从原先小时级缩短到一分钟内。

讲述 vivo 评论中台在数据库设计上的技术探索和实践。

在好大夫在线内部，S3系统负责各业务方操作日志的集中存储、查询和管理。目前，该系统日均查询量数千万次，插入量数十万次。随着日志量的不断累积，主表已经达到数十亿，单表占用磁盘空间400G+。新项目命名为：LogStore。

本文分析了一些故障的根本原因，包括客户端配置使用不合理、MongoDB内核链接认证不合理、代理配置不全等一系列问题。

现在聊天和视频会议应用火遍全球。 Slack、Microsoft Teams、Zoom、Google Meet、Facebook Rooms等应用程序越来越受欢迎。这是因为Covid-19大流行，我们所有人不得不呆在家里，所以掌握在线工作和协作的能力变得非常必要。聊天和视频会议应用解决了我们的困境，并提供了有效的远程团队协作工具，所以其用&#