如何处理大数据入库和查询问题

DB的SQL查询所带来的编程方面的灵活，是其他NoSQL方式的存储和查询几乎无法取代的。

就拿ElasticSearch的存储和查询来举例，它是很快，处理亿级数据是小Case。但是：

1.结构发生变化怎么办？举个例子，很多时候，都会由于业务的变更而某些表增加字段的情况。对于DB来说，只需要alter table *** add column *** 即可以了；但是ElasticSearch却涉及重建索引的问题

2.对很多灵活的查询，多个条件嵌套子查询、多表关联查询都几乎不能支持。

今天看了一篇文章，他每天处理3亿多条数据，包括入库和查询。方式很受启发。

1.分表，这是必须的

2.如何能够快速入库，就是表上不带任何索引

3.如何能够快速查询，就是表上经常查的字段得带索引；而且写SQL时，带索引的字段在where中应该居前

可以看到，2和3是相悖的。

那么就分两个库，一个是读写库一个是只读库。

读写库只存放1个小时内的数据，要查一个小时内的数据就从这里面查。它上面不加任何索引。---保证入库的速度

只读库定时将读写库中的数据入库，建立索引。---保证查询的速度

个人认为，目前的NoSQL技术不足以取代SQL DB。至少难以面对业务的变更对存储的影响，以及灵活查询的挑战。未来的大方向应该是结合搜索引擎和传统关系型数据库。