DB的SQL查询所带来的编程方面的灵活,是其他NoSQL方式的存储和查询几乎无法取代的。
就拿ElasticSearch的存储和查询来举例,它是很快,处理亿级数据是小Case。但是:
1.结构发生变化怎么办?举个例子,很多时候,都会由于业务的变更而某些表增加字段的情况。对于DB来说,只需要alter table *** add column *** 即可以了;但是ElasticSearch却涉及重建索引的问题
2.对很多灵活的查询,多个条件嵌套子查询、多表关联查询都几乎不能支持。
今天看了一篇文章,他每天处理3亿多条数据,包括入库和查询。方式很受启发。
1.分表,这是必须的
2.如何能够快速入库,就是表上不带任何索引
3.如何能够快速查询,就是表上经常查的字段得带索引;而且写SQL时,带索引的字段在where中应该居前
可以看到,2和3是相悖的。
那么就分两个库,一个是读写库一个是只读库。
读写库只存放1个小时内的数据,要查一个小时内的数据就从这里面查。它上面不加任何索引。---保证入库的速度
只读库定时将读写库中的数据入库,建立索引。---保证查询的速度