这是一个创建于 1606 天前的主题，其中的信息可能已经有所发展或是发生改变。
大佬们好，我对 es 不太熟悉，之前公司里有日志内容解析和检索的项目用到 es 做数据库，我没有参与，但是从同事平时言语中对 es 的性能多有赞赏。
最近公司又接到一个项目，预计数据量也比较大，但是与内容检索无关，多是一些将数据转换成业务需要的结构的应用场景。我提议使用 mongoDB，文档字段相对自由能应对数据结构可能需要经常改动的场景，但是似乎他们仍然想使用 es 做为数据库，原因是 es 横向扩展能自动分片，可以使用 json 格式保存数据，据同事描述使用 json 格式连 schema 都没有，想存什么就存什么，es 搜索也快。
我感觉不太靠谱，但是对 es 不熟悉没什么能反驳的，只是之前看过一些文章都说不建议使用 es 做为非文字检索功能的数据库，但是并没有细说为什么。
想问问各位大佬，使用 es 作为数据库有什么利弊，以后会有些什么坑？
我想先作好以后填坑的准备。
谢谢。
 |
1
misaka19000 2020-08-03 23:11:53 +08:00
没什么坑，直接用就行了
|
 |
2
dobelee 2020-08-03 23:56:53 +08:00 via iPhone
1. es 是不可靠的
2. es 是近真实时的（即非实时） |
 |
3
Finch 2020-08-03 23:56:54 +08:00 via iPhone
好用
|
 |
4
GoLand 2020-08-03 23:57:27 +08:00
es 做搜索引擎合适，但是做数据库还是不太行的。想想数据库的特性，套到 es 上合不合适。再捋一下你们的业务场景，需要使用的特性是不是 es 都符合。你这里感觉还是 mongo 合适。做点压测之类的说服同事吧。
|
 |
5
billlee 2020-08-04 00:03:47 +08:00
* es 是异步索引，保存进去的东西不能立刻查出来
* 不设置 mapping 的话，自动生成的 mapping 会默认打开全文索引，资源消耗很大 * 冷启动的时候，会有一个中间状态，可以接受查询，但查不到数据或只能查到部分数据 * 没有事务 * 不支持 join * 不支持 compound index 总之，这根本不是一个传统意义上的数据库。 |
 |
6
libook 2020-08-04 11:17:48 +08:00
ES 和传统意义上的业务数据库不同，它其实是个搜索引擎，存储功能只是其为了更好提供搜索功能而包含的附属功能，但在实时性和一致性方面远不如业务数据库。
比如 ES 写入数据后不能马上被查询出来变化，必须等 ES 的刷新周期对索引完成刷新后才能搜索出来变化，实时业务上通常无法接受这种不一致。比如用户一开始有 100 元钱，买了产品后向 ES 请求扣除 80 元钱，紧接着用户查询余额就还是 100 元，于是用户可能又购买了一次 80 元的产品。如果硬上 ES，肯定要做大量的工作在最终一致性上。 那么 ES 的用武之地在哪呢？全文检索。 举个例子，比如你有一个查询表单，里面有 20 个字段，功能需求是用户只需要至少给定任意多于等于 1 个字段就可以进行查询，如果使用业务数据库的话，查询性能完全依赖于索引的设计，但是对于上述功能需求来说，由于用户可能使用任意字段的组合来进行查询，20 个字段就需要设置从 C1,20 到 C20,20 的所有组合的和这么多的索引，由于多数数据库都是索引越多写性能越差，所以基本不可能使用索引来达到最佳优化。 ES 以其特殊的数据结构和查询算法能够非常轻松地解决这种问题。 所以看你们的使用场景是怎样的，对数据实时性是否有要求（只要是不查最新数据的场景都是可以的），如果仅仅是看重 ES 的横向扩展能力，虽然 ES 这方面做得确实很棒，但放弃其他指标的代价有点大，而且其他业务数据库合理配置也能达到同样的效果。 如果是清洗数据的需求（比如对数据格式进行转化或计算，再灌入数据仓库或业务数据库），可以考虑一些 ETL 方案。 最后就是也可以考虑业务数据库和 ES 同时使用，数据以业务数据库为主，复制一份放在 ES 里，根据查询需求的不同可以在不同的地方查询，当然肯定是需要确保 ES 和业务库的最终一致。 |
Select Language