mongodb 是不是不适合搜索逻辑复杂且不固定的场景？

[BeautifulSoap]

初学 mongodb，对于 mongodb 的索引比较迷惑，希望大家能解答下我的疑惑

假设 mongodb 里保存着这样的数据，这数据有挺多键，但是有多少键不定

{
    "a1":1,
    "a2":2,
    "a3":3,
    "a4":"a",
    ......
    "a39": "ff"
    "a40": "gg",
    ......
    "aXX": xxx
}

我希望 a1~aXX 的所有字段都能搜索，并且字段之间还能互相组合成较为复杂的搜索逻辑，并且根据哪个字段排序也是不可知的。如下面这些搜索逻辑

• a1<10 and a4="a" order by a4,a1
• (a4!="a" and a10>100) or (a2>200 and a40="gg") order by a40
• ......

如果我要创建索引的话，是不是只能为 a1,a2,a3,...,aXX 各自创建单键索引(Single Field Indexes)？这样的话遇到复杂的查找逻辑是不是性能会很差？

而且我保存的数据不止这一种类型，别的类型的数据也都需要每个键都可搜索的话，索引数量可能会有成百上千个，数据量一大是不是内存占用会非常庞大？

PS：本来考虑 mysql，但是因为需求是保存的数据结构不定，mysql 不太适合，所以才常识学习 mongodb

PS2： 如果 mongodb 不适合的话，有没有什么 db 是适合这种数据结构不定且所有字段都要能搜索的场景的？

[yamedie]

既然场景是搜索, 那我盲猜 ES? (猜错的话抱歉我是前端

[opengps]

非关系型数据库本身就是为了简化关系型包袱的一个重要出发点，所以对于复杂查询，确实不提倡用 nosql （ mongodb 属于 nosql ）
查询作为重点，确实 es 更加合适些

[billlee]

key 不确定那 ES 也搞不定啊，这种数据结构就设计得有问题

[BeautifulSoap]

@billlee 这可不一定，你这么说的话就等于否定了 mysql 中 json 字段的意义了

key 不固定的需求非常多，mysql 有时常用的的 EAV 设计就是专门用来解决这一问题的。之后 mysql 的 json 字段也是用来解决这一问题： https://blog.huoding.com/2016/06/29/522

一天前的这个帖子实际上也是业务字段不确定，预计将来会有扩展需求的一个体现 https://www.v2ex.com/t/761703

对于这种结构不定的需求其实是部适合 sq 的，所以我才尝试学习 nosql 看看有没有更好的解决方法

[ch2]

如果你的数据量不大的话 mongo 这样查也无妨
大量的数据得用 clickhouse 这种列式数据库，多少个索引都无所谓，天生按字段单独存储

[BeautifulSoap]

@ch2 看了下 clickhouse 的文档，似乎 clickhouse 和 mysql 一样需要定义表结构的样子？数据的结构不定的话没法像 mongodb 一样轻松添加删除键吧

[billlee]

@BeautifulSoap #4 你说的对。我没理解到原来的问题。这个场景准确的说，是列比较稀疏，可能会在运行过程中增加新的列，但列的数量还是有限的。这种场合的搜索需求，最合适的应该是 elasticsearch.

Mongodb 的索引看起来也是部分支持 intersection 的

//docs.mongodb.com/manual/core/index-intersection/#index-intersection-and-compound-indexes

[cps]

@BeautifulSoap 老哥还在日本吗，求推荐日本 it 公司

[BeautifulSoap]

@cps 推荐日本的 it 公司那肯定 line 、雅虎、DeNA 这些啊

[cps]

@BeautifulSoap 这些大手都进不去啊，有没有一般点的公司推荐下