Business Profile Service 可以使用2个DB吗？一个就是普通的MySQL，用来存Business Profile Related，另一个是Menu DB，用来存和菜单相关的，这个用 elastic search 存储，因为搜索菜单相关内容需要用到文本的索引，这个elastic search会提供。
我觉得这个比所有东西都存在elastic search要好吧？毕竟elastic search并不适合存储结构化的数据。
Search Service 只是读写一个 Geo Partition DB，里面用存储 Geo Hash 和 Business profileId 的对应关系就可以了？
地理位置查询的时候，可以先访问ID，然后根据ID再去business profile service里面做更深入的查询。我觉得如果没有菜单的话，也许都可以不使用elastic service了？
需要按照地理位置加上某些 filter（比如营业时间）一起查询的时候，就需要 elastic search。你提的这个方案不能解决。一个 Geohash 里面的商家是很多的，用 elastic search 会更高效一些。
@logic 我在这里有个疑问，Search Service 查的Business Index DB 指的是什么呀？是elastic search吗？
Business Profile indexer 又是什么呢？不是说elastic search会自动建好索引吗？为什么还要indexer呢？
是 elastic search 的 index。这几块可以用 elastic search 来实现。如果不用，也可以自己写。
再确认一下，那个就是 Business Index DB 指的是 elastic search 了？
这个indexer也指的是elastic search的indexer？
business index table 是 elastic search 里存 index 的表。主表是 business profile，对于某几个 column 会做专门的 reverse index。
indexer 就是 elastic search 的 index 没错
明白了，谢谢老师。
我来说复述一下我理解，那就是search都是经过elastic search的，因为有index。整个系统的business profile 的 source of truth 还是 Business Profile DB.
如果商户更新了一个Business Profile Table 的一个row，我们会调用图中的indexer对Business index进行update？
嗯嗯 就是这个意思
