如果我们将滴滴中与打车相关的订单数据存储在 Cassandra 后,司机的 id 可以作为每个列分区的 column key,当我们想要查询特定时间段内该司机的路程,Cassandra 就可以立即帮我们在对应列中查询到这些数据,但这时,当我们想要查询某个日期内乘客的乘车记录,由于客户 ID 并不是分区 column key,因此 Cassandra 就需要查询整个分区,这时 Cassandra 性能就会大打折扣!
这种情况下,我们可以使用不同的分区 key 将相同的数据复制到另一个表或列中,这时,当我们收到有关客户 ID 和日期的查询时,我们可以将其直接定向到分区 kay 为客户 ID 的表中,这就是查询的种类少但数据量大的意思,只要查询的类型相似,Cassandra(和 HBase)就可以无限扩展,但如果查询的种类非常多的话,我们就必须为每个分区 key 一次又一次地复制,直到达到一定的限制。
我们再以淘宝为例,对于一个商品来说,库存中只有一件,但是很多用户想要买,那么最终应该只能卖给一个用户,这就需要我们的数据库拥有 ACID 性质,因此,需要 MySql 这类关系型数据库,但是淘宝中的商品数据也在不断增加,属性也多种多样,我们也需要使用 Cassandra 这种列存储模型的 NoSQL 数据库。我们应该选择哪一种?在实际项目中,我们通常会混合使用这两种数据库,例如,将尚未交付的订单数据存储在 MySQL 数据库中,一旦订单完成,我们就可以将其移至 Cassandra 进行永久存储。
我们的需求还会变得更复杂,假如我们需要为购买商品的客户构建一个报告系统,淘宝上的商品通常会由不同品牌、不同版本向不同的客户出售,因此,报告也不能针对单个产品,而应针对产品的子集,这类需求可以使用 Cassandra 或 MySQL 实现,但是更好的方案是使用 Mongo DB 这类文档型数据库,我们可以将订单数据的子集保存在 MongoDB 中,这些数据可以告诉我们哪些用户在什么时候,什么日期购买了某种商品的数量。
因此,如果我们要查询有多少人在上个月购买了 MacBook,我们可以从 MongoDB 中获得订单 ID,并使用此订单 ID 来从 Cassandra 或 MySQL 中查询其他的数据。