以下所有条目都来源于互联网文章的二次加工，如有雷同，概不承认

没做过相关工作，纯理论分析一波，欢迎讨论：

条目一：如果是创业初期，直接用最熟悉的数据库就好

比如MySQL。

这样的做是有好处的，就是糙快猛。创业初期，最重要的是把项目做出来并上线。业务能不能活下来还不一定呢，想太多高性能、高可靠、易运维的事都没有太大的意义。

简单可靠才是最需要关注的。

条目二：不建议使用MySQL的TEXT类型

像blob和text这样的字段，名义上是为存储很大的数据而设计的类型。但这正因为如此，这跟关系数据库使用table的设计理念是冲突的。table中的每一列数据都是定长的，比如varchar(32)。但blob和text的上限太长了，MySQL不可能将它们存储在table中，因而会使用专门的外部存储区域进行存储，数据行内存储指针。这样做的其中一个结果是会导到多一次磁盘IO，性能开销比较严重。

条目三：新闻类文本直接静态化扔Nginx或OSS就好

频繁读不频繁写的新闻资讯类文本，在保存的时候，直接写成静态的html，访问的时候直接从nginx返回。这样做，不仅可以节省服务器资源，还可以利用CDN加速，把文件放到离用户最近的CDN服务器上，既便宜又快。

OSS是另一个可选的方案。OSS的优势是对图片和视频存储做了大师针对性优化，比如缩放图片和视频转码。另外，几乎所有的OSS云服务都自带CDN加速服务。

熟悉程度和价格可能仍然是很重要的选择因素。

条目四：笔记类产品MongoDB可能是个不错的选择

简述MongoDB的特点如下：偶尔丢数据：在开发者水平相当的情况下，MongoDB更容易鼓励开发者做出不恰当的设计从而导致数据丢失。如果你的数据特别重要(金融、交易)，那么关系型数据库可能是个更好的选择。对笔记类产品吧，可能没那么疼，忍一忍就过去了。

无schema：不需要预定义的schema，以文档(json, bson)形式保存数据，同一个集合(对应关系数据库的表)中的不同文档可以使用不同的结构，并支持随时向扩展任意字段。这个特点导致MongoDB特别适合存储商品参数这类名目繁多又不尽相同的参数。在在游戏、电商、社交、直播、物流等领域都能看到MongoDB的身影。

当然，随之而来的问题就是如果代码结构不够清晰，很可能导致没有任何人知道数据库中存储的数据是什么格式。对接手他人代码的人员，如果不能确定文档中有哪些字段 ，则可能导致相当危险的结果。如果你的数据模式比较固定的话，一个变通的方案是通过protobuf这种序列化协议引入外部模式。

这对笔记类产品谈不上好或者坏，毕竟笔记的主要内容是大段不需要解析的文本。

单文档查询速度快：MongoDB使用BTree结构(对比MySQL使用B+Tree)，针对单文档的查询做了大量节约IO的优化，因此查询速度很快，当然吃内存也是毫不含糊。

多表联查功能弱：笔记产品不太需要。

事务功能弱：4.0以上的版本已经支持基于Replica Set的事务，但在此之前只支持单文档的原子操作。对笔记来产品来说，弱化事务的使用可以提高数据写入效率。

提供全文索引，这个对笔记类搜索有用(但中文支持弱不少 = = )。

原生支持sharding(分片)，升级数据库容量时分片间的数据可以自动迁移，这对海量数据的扩容简直不要太nice。

条目五：其它数据库产品MySQL，关系数据库，强在事务和关联查询

Redis/Memcache，内存数据库，主要用作缓存，不适用于长文本处理

ElasticSearch，全文搜索，虽然楼主没提，但在笔记类产品的确有这种需求。但仔细想一下，个人笔记量是否真的需要上ES才能满足需要呢？