NoSQL 述评

作为主库的 nosql 只有 CockroachDB、TiKV 以及 MongoDB（从4.0后事务似乎可用了），CockrouchDB 已经收费，另外 YugabyteDB 也可选，但大家的反馈都不好。

不需要考虑事务的业务可以选择 ScyllaDB 和 mongodb。ScyllaDB 可以兼当 cache，唯属于关系模型。

当然，更专用的 cache 是 redis, garnet 等，想省钱则 kvrocks，只要响应速度能满足要求能省则省。

所谓 cache 本质上就是物化视图，也叫做 continuous view。ScyllaDB 对此有很好的支持 ScyllaDB 物化视图 | ScyllaDB 文档，最早看到这个是在 greenplumn，我也曾借助 canal 在 mysql 上实现了一个初级的 hotview。所以用 redis 做缓存从某种角度就是靠程序员手写物化视图。

不过也有人在 redis 上直接做业务的，例如秒杀——sorry，秒杀不算，秒杀场景用到的是 redis 的分布式锁功能，不属于 cache。

我们说 cache 是视图也就意味着它的变动是由数据变更后反映出来的，例如有一些场景订单量骤增，数据更新慢要排队列，因此自己先更新 cache，后面再同步，舍弃一致性以追求响应。这种做法破坏了因果链，就像论坛发帖，有些人先把帖附加在 HTML，看起来好像成功了，响应非常快，用户就把网页关了，导致帖子最终消失。我不认为是一种恰当的做法。像这种订单场景，增加一个 PENDING 状态的订单就可以了。当然 cache 派也可以继续声称这种 cache 就是订单表的 PENDING 分表，似乎也说得通，但是查询就要两头查了。

既然 ScyllaDB 可以充当 cache，并且还有牛X的物化视图，如果 ScyllaDB 支持事务，ScyllaDB 是不是最佳选择？

以前我会倾向这个看法，但我现在不这么认为。实际上所有搞关系模型的 NoSQL(NewSQL) 都有点误入歧途。这些数据库都要定义表，不同的是表有一些独特的有趣的字段类型，如 list set 等等，甚至还支持未声明的字段，看起来很酷很 nosql。的确，这种模型就有点像鸟笼，静态为主动态为辅，很有巧思，但它对 ORM 框架设计者提出了新的要求，这种 list set 类型的字段，如何映射？一个 list(int)，很可能存的都是 id，本质上是 list(subclass)。

其次，cassandra 有这些字段，别的数据库有别的字段，很难形成一套普适的 ORM 框架。这是 NewSQL 很大的误区。

因此，如果事务支持得当 mongodb 及 couchbase 是最有价值的，couchbase 已经收费，退出了竞争。mongodb 这种文档数据库结合 ODM 技术，可将 Schema 完全置于编程语言，彻底摆脱关系依赖，由此可以彻底解决阻抗失配问题，让建模变得极其简单，这是新项目弯道超车的好方案。

另一方面，假如要适配这些数据库，一套 ORM 映射是不够的，可能要针对每个数据库做一套 DO。在入库时 O -> DO 入库，查询时 DO -> O 供用户使用。这套 multi DO 观念可以兼容 redis 等 cache，后面系统可以考虑这样设计。

class User{
}

class UserRedis{
  static UserReids fromUser(User user){}
  static User toUser();
}
class UserMongo{
   ...
}
class UserPG{
  ...
}
class UserScylla{
}