1
qiyuey 2020-03-20 11:27:48 +08:00
不要这样做,ES 安心做搜索引擎就好
|
2
Livid MOD 是否可以把你的问题理解为:如果只用 Elasticsearch 作为主要的文档数据库使用会有什么问题?
|
3
piapia123 OP @Livid 嗯,可以这么理解。
近期的工作是清洗存储大量的日志,我一直也有 1 楼的想法,数据存 mongo,再用 ES 做索引,然而实际使用日志结果时,我发现我几乎用不到 mongo,于是开始思考 mongo 在我的使用场景中的意义是什么,如果只存 ES 会有哪些问题? |
4
iConnect 2020-03-20 12:23:40 +08:00 via Android 1
es 时间久了会产生大量冗余数据,影响检索销量,这个时候可以 reindex,甚至从源一次,这个情况只有 es 就麻烦了
|
5
ddup 2020-03-20 12:27:53 +08:00 1
确实有项目数据库和搜索都用的 ES,比如 Exceptionless
|
6
dtsdao 2020-03-20 12:48:47 +08:00 1
我觉得直接存 ES 就挺好,数据迁入迁出好麻烦的
|
7
chendy 2020-03-20 13:35:32 +08:00 1
去年尝试过,感觉 es 的数据更新 api 比较难受,批量操作也难受,还是只做搜索吧
最后回到了 mongodb,订阅 change-stream 同步进 es 就舒服多了 |
8
sadfQED2 2020-03-20 13:45:48 +08:00 1
如果你项目没有强实时性的要求,可以把 es 当成 nosql 来用。我们公司目前就有这样用,亿级别数据,也没任何问题。但是!有个前提,es 有索引更新延时,也就是说,你新数据在索引没更新前,是搜索不到的。如果你业务对没有要求,完全可以拿 es 存。
但是 only es 的话,可能开发过程中偶尔遇到强实时性的要求的时候,程序会非常麻烦 |
9
sadfQED2 2020-03-20 13:46:44 +08:00
最推荐的架构还是 DB 同步 ES,或者 DB ES 双写,ES 只做搜索功能
|
10
Mithril 2020-03-20 13:49:42 +08:00 1
官方并不建议这么做。
之前看过官方的说法:确实有很多人把 ES 作为主要数据存储,而且他们也做了很多工作保证数据不会丢失,但是 ES 本身设计并不是为了持久化数据用的。 多加个 MongoDB 只是为了保险,用不用其实取决于你的数据有没有那么重要。日志这种东西个人觉得没那么重要,直接 ES 就好了。 如果觉得担心,你可以直接把数据存文件,顺序写入性能不会差的。 |
11
optional 2020-03-20 13:54:39 +08:00 1
都不建议,es 的快全靠内存,内存可金贵了,最好只存索引数据
|
12
mutoulbj 2020-03-20 13:58:24 +08:00 1
假设你之前用的 ES 2,想要升级到 ES 7,感受下...
|
13
sss495088732 2020-03-20 15:16:46 +08:00
@mutoulbj ....可以直接提离职了
|
14
zhuzhiqiang 2020-03-20 15:22:57 +08:00
建议数据写库 es 只做列表或者搜索
|
15
Tn5ohB1Yecdk3qCK 2020-03-20 15:31:07 +08:00
最好双写
|
16
Encloud 2020-03-20 18:09:16 +08:00
|
17
xcstream 2020-03-20 18:28:02 +08:00
可靠性多少个 9 可以维护么 出错了删库了好恢复么
|
18
Navee 2020-04-28 21:32:14 +08:00
非常的不建议
如#8 所说,es 是一个搜索引擎,他查询的结果是准实时的 对一个文档的变更时,es 先把内容写到内存,此时内容是不生效的,当达到 refresh 要求时,内存中的数据将生成一个 segment 加入到当前的 index,当完成 refresh 操作时你的变更才会体现到查询结果中 所以你就会面临 2 个选择 1. 变更时实时 refresh,这样会有非常大的性能损耗,因为 es 会生成非常多的 segment 2. 等 index 配置策略自动 refresh,那么你的变更将会有延迟 |