什么时候适合NoSQL

突然感悟了什么时候需要NoSQL。当BaseModel不确定模式的时候。

例如，一个管理mysql集群的webapp，很容易想到的model有cluster对象，一个cluster对象有1到多个mysqlapp对象。mysqlapp的字段可能有id, clusterid, hostip, mysqlport, mysqlrole(slave or master), installtype(vm or docker)等。

mysqlapp表结构时固定的。
但是如果集群管理的webapp加强功能，还支持presto类型的集群管理。cluster表需要增加一个字段clustertype，表明是mysql或者presto，但是需要配套一个prestoapp表，因为其字段和mysqlapp不同，字段数量和名字都不同。

如果只是固定支持这两种cluster，还是可以用SQL来存储。但是如果再加强，要求能够管理各种各样的类型的cluster，例如hdfs cluster，spark cluster等，需要提供动态的创建app表schema的能力，这个就很困难了。

这时如果转为NoSQL（例如MongoDB）存储，app表的每一条数据的字段没有类型和名称限定。前端传递的JSON Model很容易直接存储到Mongo，而作为底层hostmanager的api接收model进行install app的时候，不用限定model的字段，需要什么就直接从中get。

现在用RDB作为后端存储，使用app这一张表来存储各种类型的app对象，实际上是所有信息都存储到string类型的detail字段，而有一些固定字段抽取出来只是方便查询。但是数据有重复和冗余，意味着每次修改都需要做两次，而且ORM映射的时候也比较麻烦，这时候NoSQL就很方便了。

可以看出来对于简单的model，model的类型稳定，用rdb更好，如果需要model动态可扩展，那么就是NoSQL更方便。再比如存储metrics的表，如果平台需要支持动态的metric来源和类型，那么metricData类型就会动态，其中的字段类型，名称以及数量都不统一，这个时候也比较适合用NoSQL存储。

之所以NoSQL最近流行起来（准确说也是流行不短时间了，但是比RDBMS流行的迟），主要是因为webapp的发展，与早期的大部分简单的webapp不同，越来越多的场景有动态数据的产生。