想问一下 ElasticSearch 作为大数据数据库的可能性

[gdtdpt]

大佬们好，我对 es 不太熟悉，之前公司里有日志内容解析和检索的项目用到 es 做数据库，我没有参与，但是从同事平时言语中对 es 的性能多有赞赏。

最近公司又接到一个项目，预计数据量也比较大，但是与内容检索无关，多是一些将数据转换成业务需要的结构的应用场景。我提议使用 mongoDB，文档字段相对自由能应对数据结构可能需要经常改动的场景，但是似乎他们仍然想使用 es 做为数据库，原因是 es 横向扩展能自动分片，可以使用 json 格式保存数据，据同事描述使用 json 格式连 schema 都没有，想存什么就存什么，es 搜索也快。

我感觉不太靠谱，但是对 es 不熟悉没什么能反驳的，只是之前看过一些文章都说不建议使用 es 做为非文字检索功能的数据库，但是并没有细说为什么。

想问问各位大佬，使用 es 作为数据库有什么利弊，以后会有些什么坑？

我想先作好以后填坑的准备。

谢谢。

[misaka19000]

没什么坑，直接用就行了

[dobelee]

1. es 是不可靠的
2. es 是近真实时的（即非实时）

[Finch]

好用

[GoLand]

es 做搜索引擎合适，但是做数据库还是不太行的。想想数据库的特性，套到 es 上合不合适。再捋一下你们的业务场景，需要使用的特性是不是 es 都符合。你这里感觉还是 mongo 合适。做点压测之类的说服同事吧。

[billlee]

* es 是异步索引，保存进去的东西不能立刻查出来
* 不设置 mapping 的话，自动生成的 mapping 会默认打开全文索引，资源消耗很大
* 冷启动的时候，会有一个中间状态，可以接受查询，但查不到数据或只能查到部分数据
* 没有事务
* 不支持 join
* 不支持 compound index

总之，这根本不是一个传统意义上的数据库。

[libook]

ES 和传统意义上的业务数据库不同，它其实是个搜索引擎，存储功能只是其为了更好提供搜索功能而包含的附属功能，但在实时性和一致性方面远不如业务数据库。

比如 ES 写入数据后不能马上被查询出来变化，必须等 ES 的刷新周期对索引完成刷新后才能搜索出来变化，实时业务上通常无法接受这种不一致。比如用户一开始有 100 元钱，买了产品后向 ES 请求扣除 80 元钱，紧接着用户查询余额就还是 100 元，于是用户可能又购买了一次 80 元的产品。如果硬上 ES，肯定要做大量的工作在最终一致性上。

那么 ES 的用武之地在哪呢？全文检索。
举个例子，比如你有一个查询表单，里面有 20 个字段，功能需求是用户只需要至少给定任意多于等于 1 个字段就可以进行查询，如果使用业务数据库的话，查询性能完全依赖于索引的设计，但是对于上述功能需求来说，由于用户可能使用任意字段的组合来进行查询，20 个字段就需要设置从 C1,20 到 C20,20 的所有组合的和这么多的索引，由于多数数据库都是索引越多写性能越差，所以基本不可能使用索引来达到最佳优化。
ES 以其特殊的数据结构和查询算法能够非常轻松地解决这种问题。

所以看你们的使用场景是怎样的，对数据实时性是否有要求（只要是不查最新数据的场景都是可以的），如果仅仅是看重 ES 的横向扩展能力，虽然 ES 这方面做得确实很棒，但放弃其他指标的代价有点大，而且其他业务数据库合理配置也能达到同样的效果。
如果是清洗数据的需求（比如对数据格式进行转化或计算，再灌入数据仓库或业务数据库），可以考虑一些 ETL 方案。

最后就是也可以考虑业务数据库和 ES 同时使用，数据以业务数据库为主，复制一份放在 ES 里，根据查询需求的不同可以在不同的地方查询，当然肯定是需要确保 ES 和业务库的最终一致。