Change stream是什么？ 官方文档 :
Change streams allow applications to access real-time data changes without the complexity and risk of tailing the oplog. Applications can use change streams to subscribe to all data changes on a single collection, a database, or an entire deployment, and immediately react to them. Because change streams use the aggregation framework, applications can also filter for specific changes or transform the notifications at will.
读一些预训练模型的文章时，常常会把这些模型进行分类，比如说这是个autoencoder，另一个是autoregressive自回归模型。它们是什么意思，又有什么区别？
升级Hexo到v8.5.0之后，发现mathjax不能正确显示公式。看了下
文档
，发现推荐的hexo renderer是hexo-renderer-pandoc，而目前使用的是hexo-renderer-kramed，而且这个包已经不再更新也不推荐使用了。
卜算子自嘲 丁元英
本是后山人， 偶做前堂客。 醉舞经阁半卷书， 坐井说天阔。
大志戏功名， 海斗量福祸。 论到囊中羞涩时， 怒指乾坤错。
# 提升Hexo NexT主题加载速度 中留了个尾巴，优化到最后发现最影响PageSpeed Insights得分的竟然是Google Auto Ads。 这里 有个有意思的讨论，说加上auto ads之后页面加载得分显著变低，采纳答案说“你啥也做不了，也不用care”，下面有人反对这个观点，加载速度评测认为网站慢就会导致搜索排序降低。我赞成后者的观点，风一样的加载速度即我所欲也，本来无一物，何处惹尘埃！
网站加载速度是影响搜索引擎排名的一个重要因素。 # Google Page Speed Insight 是个很好的网页性能分析工具，可以根据它的分析结果有针对性地对网页进行优化。
说起牛肉面，第一反应可能是“兰州拉面”。可兰州人民已经澄清了这个概念：兰州没有拉面，只有牛肉面。去 甘肃旅游 时也吃过正宗的兰州牛肉面，确实不错。帝都的兰州拉面馆不少，个人觉得马华的还原度就挺高。
最近折腾博客比较多，也看了不少使用Hexo博主所用的评论系统，觉得Valine不错，NexT也天然支持（配置也就简单）。正想切换时发现它存在安全性问题，于是就调研了一下可用的评论系统，简单总结：
希望在Hexo的NexT主题中增加自定义分类的菜单，即一个指向特定分类的链接，且页面显示的是类似主页的标题+摘要风格。
之前有一个比较粗暴的实现： # Hexo添加自定义分类菜单项并定制页面布局 。由于直接修改了源码，属于侵入式实现，导致以后升级Hexo和主题时需要手动再改代码，不推荐。
Hexo的NexT主题可以天然支持友链，即在NexT主题的配置文件_config.yml中有一个# Blog rolls块，可以添加友链，然后在左边栏的底端会显示它们。但这样的问题在于边栏的空间有限，友链比较多的话会影响布局，而且分散主题。于是考虑单独创建一个友链页面，搜索发现已经有成型的方案，大体思路与
# Hexo添加自定义分类菜单项并定制页面布局
一样，增加菜单项和友链模版，再修改主页模板。这样做可以解决问题，但是不够优雅，属于侵入式的定制（直接修改了主题文件模板），但绝大多数人都采用了这种方案 :-)。
最近一直想简化每篇博客的永久链接，现在的永久链接大概长这样：
/2021/03/21/migrateopsmanager.en/
希望能把中间的日期去掉，变成这样：
/migrateopsmanager.en/
原因在于短链接更作为标识更为合理，而URL上带有日期字符串并没有实际的用处，除非重名的博客太多。但这不可能发生，因为所有博客都写在source/_post文件夹，博客重名会引起文件名冲突。
生产环境有个SQL Server云数据库，花钱不少，性能却很差。最近发现跑一些并不太复杂的存储过程却需要好几分钟。其中一个常用的存储过程是将几张表通过一个键值关联并返回结果，这几张表都在千万级大小。分析了下执行计划，发现index seek花去了90%以上的时间，进而发现这些表的索引碎片化都极为严重。由于这个老DB几经易手，没人知道这些表和存储过程是做什么的，于是需要手动分析这些表的schema和存储过程所依赖的表。基于这些结果再对索引重建提升性能。下面就是用来分析DB的一些重要Query。
.NET中使用MongoDB非常简单，一般来说可以直接使用BsonDocument，也可以使用定义好的数据类型对文档进行CRUD操作。本文通过实例对比一下两种方式的优劣，通常，通过强类型Collection对文档进行操作更为便捷。
MongoDB事务是个很好的功能，但对于高并发场景下的多文档事务，写冲突难以避免。一个写冲突的实例:
Exception: Command update failed: Encountered error from mongodb.svc.cluster.local:27017 during a transaction :: caused by :: WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction..
在一个分片MongoDB集群上并发执行transaction时遇到许多MongoCommandException错误: code 251, codename NoSuchTransaction:
Command find failed: cannot continue txnId 4 for session 38604515-2584-45a5-a17a-5eb5d34ea6c4 - = with txnId 5. Command find failed: cannot continue txnId 4 for session 38604515-2584-45a5-a17a-5eb5d34ea6c4 - = with txnId 6. Command insert failed: cannot continue txnId 31 for session 3ed7ea61-eae1-440f-8d95-b6e066b35b69 - = with txnId 34.
Sharded cluster是MongoDB部署中最复杂的形式，因为Sharded cluster的组件较多，部署步骤也更为繁琐。在实际部署中还有几个部署ReplicaSet时没遇到的证书和TLS问题。阅读本文前，强烈建议先阅读 创建用户数据库(replicaset) 作为基础。
本文为系列第五部分，用生成的自签名证书打开userdb的TLS和AUTH，并且完成userdb的公网域名访问。
整个系列：
开始之前，先解释下部署中不同层面的TLS加密：Secure Connections to Ops Manager, Secure Connections to Application Database, Secure Connections to MongoDB Deployments，我们需要的是最后一个，Enable TLS to MongoDB Deployments。而且这个配置不能直接通过界面完成，因为需要将生成的自签名证书“上传”到userdb的每个server上，然后才能配置这些证书所在的路径。
本文为系列第四部分，相对独立，先生成一个自签名CA证书，然后生成MongoDB各个server证书。
整个系列：
自签名证书不推荐在生产环境使用，虽然它可以保证通信过程中的加密，但不能避免中间人攻击。Public Key Infrastructure (PKI)相关的内容也不在本文的讨论范围，这里假设读者对PKI已有基本的认识。
本文为系列第三部分，使用第二部分创建好的userdb可以从公网访问，方法是通过Kubernetes Service暴露userdb pod到公网上。
本文为系列第二部分，使用第一部分安装好的MongoDB Ops Manager创建用户数据库。
整个系列：
所谓的Application Database是MongoDB Ops Manager的后端DB，并不能用来存放用户数据，所以我们需要用Ops Manager创建用户数据库。使用Ops Manager创建的MongoDB叫做Deployment，注意此Deployment是MongoDB Deployment，与kubernetes的Deployment不是一码事。