2020-03-10(应该正视存储)

    早晨上班路上，想了下业务对elasticsearch的使用，最初公司选型此中间件是因为业务上数据量比较大，但又不想使用mysql分库分表方式解决，希望有个分布式存储中间件能自动扩容来满足存储要求，业务层面不去关注这种业务无关性的需求。出发点肯定是对的，但使用elasticsearch来解决此问题，还是实时业务，其实还是值得探讨的。

    Es更偏重搜索和聚合，对index分片以及属性的修改都不是很灵活的，对于不稳定或者高速发展的业务，应对成本很高。在集群安全以及权限控制都不是很细粒度。另外有个更重要的点需要考量，那就是es从文档被index到能够查询到数据不是实时的，官方默认的参数是1秒(虽然可以调整但官方不建议，这是es为了优化写操作而作的妥协。对于有强实时场景下，第一存储不应该选择es。公司业务是通过而外写redis来解决立刻读的问题，但需要强一致场景这种方式也不合适。这是最近几天在研究es对业务使用的一个反思，后续会更深入的研究下es以及存储这个领域。技术选型需要对每个技术做全方位评估，了解其底层实现，要选择一个满足自身业务场景的数据库，而不是随热度去尝试，不遇到大问题还好，否则将被其完虐。