即将上线:清源文本检测新一波贴心技能上线啦，快来get一下吧！

　　即将上线:清源文本检测新一波贴心技能上线啦，快来get一下吧！

　　如果在线检测是解放眼睛的第一步

　　那么网站检测就是第二步了

　　你有责任保持平稳

　　清源持续为您的在线文件保驾护航

　　清远本次迭代新增网站检测模块

　　

　　包括自动巡检和抽样检测两种检测机制

　　从发帖前到发帖后

　　全程为您提供内容审核小工具

　　01

　　自动检测——

　　网站及时复查

　　网站是一个单元重要的外网显示窗口。错别字、敏感词和违禁词的出现可能会轻而易举地影响印象，最坏的情况可能会给组织造成声誉和业务损失。

　　但是网站通常收录多级页面，要查看的内容很多。与单个文章的内容纠错相比，网站纠错的工作量和难度更大。

　　另外，为了保证部分网站信息的及时性，由于时间关系，在发表前的审稿工作难免会出现一些疏忽。针对这一痛点，清远在本次迭代中增加了对网站检测模块的自动检测以供选择。

　　“自动检测”是为网站设置自动检测已发布文章的任务。拉文章网站，复制粘贴文字内容，手动逐字校对？抛弃这种傻瓜式方法。

　　只需输入需要审核的网站域名，等待网站分析约2个工作日后，系统会每分钟自动分析网站帖子的内容采集 并检测。

　　一次性录入，自动检测，为网站中的文章内容筑起一道坚固的墙，有效保障网站已发表文本内容内容检测的全面性和及时性。

　　采集文章之后会以清远的智能词库和用户自定义词库为检测依据，利用智能检错技术自动检测文章并生成检错率（Error文章号码/已经采集文章号码）。

　　测试完成后，可以在链接列表中查看文章的原文和测试结果，点击标题直接跳转到原文网址。同时可以导出测试结果。

　　

　　清远会将被测文章的原文保存在网上。即使稍后删除网站文章，清远采集的文章和测试结果也不会受到影响。影响消失了。这也是一个很好的云备忘录方法。

　　02

　　抽样检测——

　　随机检测在线帖子

　　与网站的自动检测所有新发布的文章相比，抽检是针对需要检测的部分文章。采样检测可以有效控制错误检测字的过度使用，节省系统成本。

　　抽检的流程与自动抽检基本相同，但用户需要在采集成功文章列表中主动选择想要的文章，然后点击抽检进行智能在线错误检查。测试结果即时生成，还支持导出。

　　如果需要检测网站中的某个文章，并实现对文章错误内容的分析，选择抽样检测是最好的选择。比如网站发布的内容的检测方式需要在检查和抽样之间切换，可以通过点击转移来实现。

　　无论是巡检还是抽检，都支持根据时间和状态查询检测和张贴的内容。超长时间范围选择，准确确定时间区间，更有助于实现准确的文章检测结果查询。

　　现在已经开放试用权限，每位客户支持1次试用网站，有兴趣的请联系我们！

　　最佳实践:直播分享| 腾讯云 MongoDB 智能诊断及性能优化实践

　　本次直播主要分为五个部分：

　　1

　　MongoDB的核心优势是什么？

　　MongoDB 是一个用 C++ 语言编写的基于分布式文件存储的数据库。首先，我们来看看它的核心优势。这里有几个：

　　MongoDB是开源的分布式数据库，可以解决传统数据库存储容量的瓶颈问题，用户不再需要提前考虑分库分表等操作。同时，MongoDB也是一个天然的高可用数据库。比如一主两从的工作模式，当主节点意外宕机时，从节点会接管主节点的工作，整个过程不需要依赖任何第三方组件.

　　MongoDB的表结构比较自由，添加字段方便快捷。与传统数据库中的大表添加字段相比，运维成本大大降低。

　　MongoDB早期使用MMAPv1存储引擎，后来换成了WiredTiger存储引擎，支持行级粒度锁定、热数据缓存等特性，为MongoDB带来高性能、低延迟、高吞吐。

　　在默认配置下，MongoDB使用snappy压缩算法，平均可以实现2到4倍的文本数据压缩能力。如果使用zlib压缩算法，可以提升到3到7倍，但是zlib对性能有一定的影响，所以网上一般使用默认配置即可。经测试，默认配置下，相同数据写入MongoDB、MySQL、ES的实际磁盘消耗比例约为1:3:6。

　　MongoDB 支持五种平衡访问策略：

　　primary：读取主节点。当主节点异常时，可能会导致短期业务异常。

　　primaryPreferred：首选Primary，当Primary异常时可以读取Secondary。

　　secondary：读取slave节点，将流量均衡分配到多个slave节点，实现负载均衡。

　　secondaryPreferred：首选从节点。如果从节点异常，则读取主节点。

　　最近：最近的访问。在多机房场景下，就近访问可以避免跨机房访问。

　　2

　　腾讯云MongoDB核心优势

　　腾讯云MongoDB目前已服务于游戏、电商、社交、教育、新闻、金融、物联网、软件服务、汽车出行、音视频等多个行业。

　　相比用户自建的MongoDB数据库，腾讯云MongoDB在智能运维、可用性、安全性、性能等方面更具优势。同时通过DBbrain提供一站式监控诊断分析，并能给出相应的优化建议。还集成了官方常用工具，方便用户使用。

　　此外，腾讯云 MongoDB 在内核上也做了一些定制化开发，比如解决表数达到百万级时的性能问题，提供 SQL 限流功能，减少流量过大导致的集群不可用问题。安全方面，腾讯云MongoDB可在7天内将数据恢复到任意点，并提供24小时专业支持服务。此外，它还自然地在云端集成了高可用、高性能等通用能力。

　　3

　　云上 MongoDB 集群常见问题

　　3.1。使用分片集群

　　云上分片集群遇到的常见问题如上，主要包括大表不启用分片、分片方式次优、分片构建选择不当、高峰期集群抖动未设置平衡窗口等。

　　有的用户有一个误区，就是从副本集切换到多分片集群，认为什么都不做，集群的自然性能是副本集的几倍，存储容量是副本的几倍默认设置。

　　如果分片集群中没有开启分片功能，数据和流量会默认到主分片，主分片是分片集群中的一个分片。因此，对于数据量大、流量大的集群，记得开启分片功能。

　　通常情况下，如果用户主要查看，比如通过order id，可以选择hash sharding方式，这样既保证了读性能，又保证了数据离散写入不同的shard，保证了写入性能和避免了由于数据不平衡导致的大量moveChunk操作。

　　如果用户查询主要是范围查询，一般推荐使用范围分片。

　　如果有大量的检查点和大量的范围查询，为了避免范围查询引起的所有分片广播查询，建议进行范围分片，这样检查点和普通范围查询都可以从一个分片获取数据。

　　对于分片集群分片，通常选择高频查询字段作为分片字段。同时注意insert、update等写操作必须收录sharding字段，否则mongos会因为不知道写哪一部分而返回异常信息。切片数据。

　　分片集群的很多抖动都与 moveChunk 有关。moveChunk操作会增加锁、资源消耗，还会涉及到路由刷新等过程。因此，建议分片集群设置一个平衡窗口期，尽量在业务低峰期进行平衡操作。

　　

　　分片方式和分片构造的选择比较特殊，与业务使用方式密切相关。因此，需要提取和评估以确保最佳的读写性能。

　　3.2. 索引问题

　　注意索引问题包括索引操作过程问题和索引内容问题，下面将详细介绍。

　　以给副本集添加索引为例，createIndex创建索引成功实际上是在主节点成功后返回，而从节点还没有成功添加索引。如果用户进行读写分离，从节点上的压力比较大，从节点上执行索引的时间可能会更长。如果用户的主节点执行成功，createindex 返回并立即添加其他索引。此时，可能有多个索引。在从节点执行的情况下，从节点的压力会很大。

　　另外，如果用户添加索引“成功”，此时从节点实际上还在执行索引，用户立即删除表的索引。此时从节点将无法访问，因为删除索引会添加一个 MODE_X 排他锁。

　　如果业务很核心，不允许有任何抖动，也可以采用滚动添加索引的方式来添加索引。有关详细信息，请参阅：

　　4

　　MongoDB智能索引推荐实现

　　智能指标推荐主要是基于指标规则和成本估算来实现的。整体架构如下：

　　智能指数推荐分为四个模块：

　　其中agent模块和kafka模块的逻辑比较简单，这里主要介绍日志分类模块和成本估算模块。

　　4.1。日志分类模块实现步骤

　　第一步：提取有效的慢日志。

　　并非所有慢查询日志都需要处理。只需要提取存在索引问题的慢查询，例如次优索引和全表扫描。如果判断指标不是最优的？

　　答案是比较数据扫描的行数和使用索引时实际返回的行数。如果差异较大，则判断指标不是最优的，需要进一步优化。

　　步骤2：根据过滤器对SQL进行分类。

　　同一个数据库表中有很多查询，查询条件不同。属于同一类的 SQL 需要满足几个条件，即数据库、表、命令、查询条件完全相同。前三个条件很容易区分。比如在同一个数据库同一个表的情况下，查询条件（包括find、update、delete等）同一个类别，同一个查询条件的前提是查询关键字必须相同且运算符属于同一类别。也忽略查询字段顺序。

　　日志聚合处理

　　定期从DB中获取分类后的SQL信息，发送给成本估算模块进行处理。

　　4.2. 指标成本计算模块处理流程

　　4.3. 候选指数成本计算

　　成本计算的主要步骤：

　　假设有一个候选索引[{work:1, city:1,province:1}, {city:1,province:1,age:1}])，成本计算过程如下图所示：

　　上面候选索引对应的执行计划流程为：如果查询选择候选索引执行，则执行计划先进入索引扫描阶段，再进入OR阶段。OR阶段执行完毕后，会启动fetch操作，最终得到结果整个进程扫描了多少行数据，获得了多少行数据，以及整个进程的执行时间。

　　腾讯云的成本估算是通过旁路模块实现的，实现难度大，需要对整个内核执行计划有透彻的了解。因此，对于自研用户，如果研发人力有限，可以将数据采样到新的MongoDB集群中。根据候选索引规则，可以根据内核现有能力计算出字段区分度和候选索引成本。最后得出执行索引扫描的结论。多少行，返回多少行，执行时间多长，最终可以得到最优索引。

　　

　　智能指数推荐已服务，将逐步向用户开放。有兴趣的可以去体验一下。索引推荐基本可以在半小时内找到实例上存在的索引问题。除了推荐最优索引外，还可以找出实例上的无用索引和重复索引，使最少的索引能够满足用户的需求和性能。等等会更好。

　　4.4. 腾讯云 MongoDB 索引推荐总结

　　快：在慢查询产生后半小时左右启动最优索引。

　　标准：推荐指标是候选指标中计算成本最低的指标

　　稳定：采样计算过程对云上集群影响不大，在索引添加过程中增加了保护措施。同一实例最多可以同时添加一个索引。

　　5

　　MongoDB内核SQL限流实现

　　5.1。SQL为什么要限流？

　　首先我们来思考这样一个问题：SQL为什么要限流？

　　一方面，当流量过大，负载过高，数据库抖动可能导致雪崩时，可以限制流量，保证部分请求可以正常返回。另一方面，为了节省成本，有些用户将多个用户的数据写入同一个实例的不同表中。在某个时刻，用户的新界面可能不正确或者出现其他异常情况，导致流量非常大，这会影响到这个实例上的其他核心服务，可以通过current来限制异常或者不太重要的表的流量限制以确保核心业务流量可以正常访问。另外还有一些突然的表扫描、高危操作等，可以通过限流来限制。

　　5.2. 内核在哪里添加限流功能？

　　那么，我们在内核中哪里做SQL限流功能呢？

　　首先，我们来看看MongoDB的整体架构。它是分层的。第一层是网络收发模块。网络发送和接收后，命令处理模块解析SQL，然后SQL会进入查询引擎模块、读写模块和并发控制模块等流程。

　　5.3. SQL限流核心实现

　　我们整个SQL限流模块是在命令处理模块之后添加的。在这里添加它有什么好处？因为这里已经获取了详细的SQL，并且在并发控制之前实现了SQL限流，避免了SQL限流中的操作影响并发控制和数据库读写访问，防止与下层发生冲突级并发控制模块。

　　内核SQL限流的整体流程如下：

　　首先，可以在DBbrain界面上配置策略规则，比如SQL类型、并发度，可以配置定时关机或者手动关机。定时关机是指最大运行时间。手动关闭是指打开后一直执行，除非手动关闭停止。

　　然后根据读写SQL关键字，配置规则后，可以限制指定库、表或指定SQL语句的流量。整个过程是先在DBbrain控制台下发规则。以分片集群为例，下发给分片集群的配置服务器。配置服务器收到后，将规则写入配置服务器的表中。分片服务器 每个 mongod 都会定期从配置服务器获取这些规则，并将它们加载到自己的内存中。所有 mongod 节点的内存中都会有完整的规则数据。当一个请求发起时，它会通过客户端到达代理，然后到达 mongod 节点。, 匹配限流规则，触发限流操作。

　　至于为什么选择对mongod而不是mongos做限流。主要原因是mongos上的流量控制是客户端根据IP进行hash，可能会造成流量不均。另外，线上有副本集的集群，也有分片集群。在mongod上做可以实现代码统一。对mongos做限流，因为mongos是无状态的，不能保证一定程度的相互控制。最后瓶颈一般在mongod节点上，所以我们选择在mongod上限流。

　　5.4. SQL限流规则和规则匹配限流流程

　　下面继续分享腾讯云MongoDB SQL限流的限流规则和规则匹配限流流程。

　　至于SQL限流规则中收录的信息，主要包括SQL类型（如增删改查）、限流时间和并发数。并发数可以限制某种类型的请求同时访问我们的DB的并发量，另外一个就是关键字，可以匹配也可以匹配表，甚至可以匹配详细的SQL，这样指定可以限制库、表和某些类型的 SQL。

　　当请求到达MongoDB时，具体的处理流程是首先检查该实例是否开启了SQL限流功能。如果开启，则提取用户请求中的库、表和SQL关键字信息，下一步与配置的限制流规则进行匹配，判断该类型SQL是否有可用的ticket。

　　Ticket 代表并发控制中的并发数。如果没有可用的票证，例如票证值为0，则直接限制请求并返回客户端异常。如果有可用的ticket，则将ticket value 减1，同时访问DB。访问DB后，将数据返回给客户端，同时释放当前ticket，后续请求可以继续复用。这是整个限流工作流程。.

　　SQL限流经验如下：

　　6