简要概念：
关于GS设计的一些体会，纯属个人理解。
解耦是在做系统设计时，最应该铭记于心的原则，解耦的目的是让系统组件可以独立变化，构建易于理解，测试，维护的系统。
解耦的手段通常有如下几种：
依赖倒置的原则：上层模块不应该依赖于下层模块，它们共同依赖于一个抽象。抽象不能依赖于具象，具象依赖于抽象。
依赖倒置原则的目的是把高层次组件从对低层次组件的依赖中解耦出来，这样使得重用不同层级的组件实现变得可能。如模块A依赖于模块B，那么在A和B之间加一层接口(interface)，A调用(依赖)该接口，B实现(依赖)该接口，这样，只要接口稳定，A，B即可独立变化。
这种依赖抽象的思想，在GOF的设计模式中，有大量宝贵实践，如策略模式，模板方法模式等。
MongoDB目前支持三种存储引擎：MMAPv1 Storage Engine，In-Memory Storage Engine, WiredTiger Storage Engine。
MongoDB3.2之前版本的默认引擎。
文档在磁盘中连续存放，文档所占用的磁盘空间包括文档数据所占空间和文档填充(padding)。
摘自：MongoDB MMAPv1内部实现：http://www.mongoing.com/archives/1484
当执行find操作的时候，只是返回一个游标，并不立即查询数据库，这样在执行之前可以给查询附加额外选项。几乎所有游标对象的方法都返回游标本身，因此可以按任意顺序组成方法链。以下查询是等价的：
> var cursor = db.foo.find().sort({"x":1}).limit(1).skip(10)
> var cursor = db.foo.find().limit(1).sort({"x":1}).skip(10)
> var cursor = db.foo.find().skip(10).limit(1).sort({"x":1})
此时，我们只是构造了一个查询，并没有执行实际操作，当我们执行：
> cursor.hasNext()
这时，查询被发往服务器，sell立即获取第一个块(前101个文档或前1M数据，取其小者)，这样下次调用next或hasNext时，就不必再次向服务器发起一次查询。客户端用完了第一组结果，shell会再次向服务器获取下一组结果(大小不超过4MB)， 直至结果全部返回。可通过batchSize设置游标返回的块的文档数量。
注：如果在shell中，没有将返回的游标赋给一个var，shell将自动迭代游标20次，显示出前20调记录。
erl -sname n2 -setcookie 123
(n2@T4F-MBP-11)1> //^G
User switch command
--> r 'n1@T4F-MBP-11'
--> c
Eshell V8.1 (abort with ^G)
(n1@T4F-MBP-11)1>
erl -setcookie abc -name node_2@127.0.0.1 -remsh node_1@127.0.0.1
和第一种JCL方式是同一个原理，这也是rebar2 remote_console的实现方式。
erl_call -s -a 'erlang memory ' -name node_1@127.0.0.1 -c abc
run_erl -daemon tmp/ log/ "exec erl -eval 't:start_link().'"
run_erl是随OTP发布的命令，它通过管道来与Erlang节点交互，仅类Unix系统下可用。上面的命令启动Erlang节点，将tmp/目录设为节点管道目录，之后run_erl会在tmp下创建erlang.pipe.1.r erlang.pipe.1.w两个管道文件，外部系统可通过该管道文件向节点写入/读取数据。可用OTP提供的to_erl命令通过管道连接到节点:
所有能用binary的地方都用binary，配置，协议，DB，网络接口，等等，如果驱动或第三方库不能很好地支持binary，就换一个或者重写接口，如果项目一开始就这么做，会在后期省掉很多麻烦。
atom不被Erlang GC，在代码中要时刻警惕诸如list(binary)_to_atom/2和binary_to_term/1等动态生成atom的API，特别是这些API的输入源来自于网络或客户端等不可信源，可用list(binary)_to_existing_atom/2和binary_to_term/2替换之，前者只能转换为已经存在的原子，否则会报错，后者功能类似，确保不会生成新的atom，函数引用，Pid等(这些资源都是不会被GC回收的)。
可通过erlang:memory/0来观察atom内存使用状况。