F周刊：2017-03-05
How Discord Stores Billions of Messages
又一篇从MongoDB迁到其他数据库的文章，迁出的原因以及整个过程跟我之前写过的为何我们要将设备的实时数据库迁到HBase的文章如出一辙：都是对Mongo的Sharding不满意。
客观来讲，除了分布式存储，我还是很喜欢Mongo滴！文中提到的一句话也深得我心：
build quickly to prove out a product feature, but always with a path to a more robust solution.
如果摆拖那种“读完了事”的心理，速度和多读倒并非矛盾。我同意文中的观点：多读之后会提高阅读速度。因为见得多了，自然也就敏锐度提高，进而阅读速度自然就会上来。当然，前提是短时间内集中大量阅读同一领域的内容，否则，来回切换会效率不高。
Paxos算法难以理解，于是Raft应运而生，在看论文之前看看这个动画会更有助于理解整个协议和算法。论文的中译本在这里，infoq的这篇文章则给出了一个jgroup-raft的例子。
Building Scalable Applications Using Event Sourcing and CQRS
看完这篇文章的同学应该对于CQRS、Event Store和Event Sourcing有感觉了，有概念有实做，不难懂。但也要注意，正如文章提到的，这种编程观念的转变不容忽视。对于那些以验证概念为目的的应用而言，个人认为架构还是太复杂。自从创业以来，我已经形成这样的架构观点：
- 跟组织一样，公司发展的不同阶段，需要不同的应用架构。
- 起步阶段讲究“快糙猛”，但思想上要知道，现在的架构绝不是我们想要的架构，故需留些伏笔，以免未来架构变迁时流血过多。
- 进入高速发展阶段之后，应用架构的考虑就要兼顾稳定性和伸缩性，别因为架构的问题影响业务的高速发展。
换句话说，如果公司已经开始腾飞，尽快将架构迁至这类架构下不失为明智之举。而且，在微服务当道的今天，CQRS可能是最好的选择。作为上文的补充，这里还有一篇用Go和Kafka实现的范例。
Twenty Years Old, PostgreSQL Maintains its Vigor in the Big Data Age
自从转到PG，很多让人纠结的问题也迎刃而解。之前曾担心它的生态不如MySQL，但后来才发现这种担心存属多余。正是因为之前的不关心，导致对其不了解，产生了不活跃的错觉。而且拜Oracle所赐（收购MySQL），PG的未来说不定会越来越好。
除开稳定性和性能，丰富的数据类型和扩展、完善的SQL语法支持都是PG值得尝试的理由，而且FDW真心不错，希望有条件时可以尝试一下。此外，Mongo的BI支持实际上也是建立在PG之上。
Getting Started with Deep Learning
一篇明显标题党的文章，但内容还是有可取之处：如何在众多的DL工具之间进行选择，恐怕这也有不少初学者为之困扰。而且，文章专门提到了在工具选择时要考虑prebuilt model，这也是让众多如我这般的初学者容易忽视的地方。
文章重点考察的工具主要集中于Python、C++/Lua系框架，对于其他语言的框架，可以查看这个全面的比较。诚如作者所言，在进行选择时，优先考虑那些支持团队熟悉语言的框架。
量子密鑰傳輸（Quantum Key Distribution）
一篇讲述在量子计算中如何分发密钥的短文，有意思。
An Introduction to Genetic Algorithms In Java
10+年前的文章，但对于了解遗传算法这个目的而言，已经够了。文后附有完整的源代码。如果说是要在工程上用的话，不妨看看Jenetics，不仅支持Java 8且活跃度还不错。
来自一线互联网公司的PG运维经验，里面有很多经验是公司初创阶段和小团队不会遇到的，比如：
- 为每个团队设置一个db role
- 利用PGBouncer的Virtual Schema实现不同客户端连接池的相互隔离
- 设置statement的timeout
- ……
谁知道你的应用会不会做大呢？趁现在未雨绸缪吧，;)
