这是一个创建于 839 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们要做个系统，最后卡在上层界面展示的数据库存储选型上了。
我们初期用的 es ，因为数据量很大，可能在 20-30 亿，然后要求每个字段都可以模糊匹配，也能做一些统计。
因为 es 不能比较好的关联，所以我们把所有的业务数据，都放在一个很大的 json 中了，就一个表，每个表就存储了很多一模一样数据结构的大 json ，第一阶段这样没啥问题。
但是 2.0 的需求上升了数据维度，举个栗子：
1.0 版本，我们的 json 存储了 班级、人员、喜好 等信息，我们只要通过喜好=xxx 就可以直接查询到 班级、人员、喜好...
2.0 版本，我们想在 es 搜索喜好，但是只想要班级、人员信息，不需要把喜好的数据带出来：
输入 喜好=xxx 输出 班级 A 人员 A 班级 B 人员 B
由于我们所有信息都放在一个 json 里面了，所以会有很多 班级 A 人员 A 喜好 A 班级 A 人员 A 喜好 B ... 这种结构，就不能直接输出 班级 A 人员 A 班级 B 人员 B ，是需要过滤的
而且后面的需求，比如 喜好苹果的人都在哪些班级里面，通过一个大 json 这种格式，就不能直接检索，肯定要在结果去重，而数据量又很大，就存在很多问题。
我也不知道我说没说清楚哈，大致就是这样，所以我们想修改为关系型数据库，但是迫于数据量很大，也有模糊搜索的需求，就不知道该怎么办了。总觉得需求又需要模糊匹配，也需要多表关联。这个场景，一般大家是怎么应对的呢？大佬们帮帮忙~~~
我们初期用的 es ，因为数据量很大，可能在 20-30 亿，然后要求每个字段都可以模糊匹配，也能做一些统计。
因为 es 不能比较好的关联，所以我们把所有的业务数据，都放在一个很大的 json 中了，就一个表，每个表就存储了很多一模一样数据结构的大 json ，第一阶段这样没啥问题。
但是 2.0 的需求上升了数据维度，举个栗子：
1.0 版本，我们的 json 存储了 班级、人员、喜好 等信息，我们只要通过喜好=xxx 就可以直接查询到 班级、人员、喜好...
2.0 版本，我们想在 es 搜索喜好，但是只想要班级、人员信息，不需要把喜好的数据带出来：
输入 喜好=xxx 输出 班级 A 人员 A 班级 B 人员 B
由于我们所有信息都放在一个 json 里面了，所以会有很多 班级 A 人员 A 喜好 A 班级 A 人员 A 喜好 B ... 这种结构，就不能直接输出 班级 A 人员 A 班级 B 人员 B ，是需要过滤的
而且后面的需求，比如 喜好苹果的人都在哪些班级里面，通过一个大 json 这种格式，就不能直接检索，肯定要在结果去重，而数据量又很大，就存在很多问题。
我也不知道我说没说清楚哈，大致就是这样，所以我们想修改为关系型数据库，但是迫于数据量很大，也有模糊搜索的需求，就不知道该怎么办了。总觉得需求又需要模糊匹配，也需要多表关联。这个场景，一般大家是怎么应对的呢？大佬们帮帮忙~~~
 |
1
lingly02 2022-08-09 17:35:23 +08:00
大数据量统计分析，可以看下 ClickHouse. 全文检索方面，还是 ES 占优，可以想办法结合一下。
|
 |
2
TimePPT 2022-08-09 17:36:46 +08:00
写入和查询分离，写入时候关系型数据库分库表分字段，es 同步索引。查时候走 es?
|
 |
3
yjhatfdu2 2022-08-09 18:51:15 +08:00
clickhouse,模糊匹配用 ngrambf_v1 索引, 性能和灵活性比 es 高太多了。https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree#available-types-of-indices
|
 |
4
liprais 2022-08-09 18:54:05 +08:00 via iPhone
你不知道用啥就用 pgsql
|
 |
5
server 2022-08-09 19:05:18 +08:00
meilisearch
|
 |
6
fox0001 2022-08-09 22:51:07 +08:00
感觉不是存储问题，是查询问题。
复杂的查询，我们使用 Solr 解决。Solr 是以文档的形式存储数据，可以实现所有字段都索引。数据关系可以分解成多个表（ Solr 称为 core ）进行关联。 如果数据太多，考虑用 Hadoop ？但是我不知道现在 Hadoop 现在还流不流行。 |
 |
7
kingjpa 2022-08-09 23:25:11 +08:00
留名 学习一下。
|
 |
8
misaka19000 2022-08-09 23:46:42 +08:00
es 查询的时候支持 exclude 数据啊
|
 |
9
nomagick 2022-08-09 23:49:38 +08:00  1
你这不是选型的问题，是设计问题，到底有几种实体，实体之间有几种关系，好好梳理抽象一下
|
 |
10
kkeep 2022-08-10 08:53:22 +08:00 via Android
对，可以 es 查询后提取数据过滤，按 id 去拿实体，配合前端做个去重就行。
|
 |
11
jifengg 2022-08-10 09:28:33 +08:00
我支持 @nomagick 的说法，没看出是选型问题。你所说的“大 json”，是字段多，还是有很多数组之类的数据。需求 2.0 ，完全就是 es 没用好，es 可以只返回指定字段。
另外，你应该不会只用 es 而没有用其他关系型数据库吧？ |
 |
12
dtgxx OP @jifengg #11 是的，只是用了 es ，目前 es 有 100 多个字段，大约有 20 多亿的数据，当时只是做展示，目前需要有多表关联了。。
@kkeep #10 嗯嗯 这个方式打算考虑考虑 @nomagick #9 好的，之前就是整个大 json 存储，其实即使是用关系型数据库，每个表也有非常多条数据，就查不动了 @misaka19000 #8 我们了解一下 @yjhatfdu2 #3 clickhouse 的单独属性检索性能太低了 |
 |
14
guangming3055 2022-08-10 14:22:16 +08:00 1
主要还是看结构设计，规划好了应该没有问题。这边主体数量三亿以上，然后其他关联数据使用 nested 嵌套文档，总共大概四十亿数据，两百多个字段
注意 es 只存需要查询的字段，其他的数据还是通过 id 到数据库取 不过 es 不太支持多对多的情况，还是需要好好设计结构才行 |
|
15
dtgxx OP |
Select Language