【好药师】支持直接用ES语法查询
jacobfan opened this issue · comments
好药师“小刀”提出：
能否给一个灵活的匹配方式，匹配语句由我们直接输入
将这个query参数，能否直接给放出来，
我们按ES的格式来构建这个东东
当然也有问题，如果之后，推荐宝不用ES来做搜索引擎，就需要做一个大的变动
或者，你们提供一个类似的语法构造器
最好不要直接暴露出去，因为目前来看ES、Lucene及其他的引擎都会有安全漏洞的问题。会增加安全风险。
- 安全有风险
- 性能可能会有问题
- 耦合 -- 客户需要知道我们的 mapping 是什么样的; 我们对 mapping 的改动，也需要客户跟着修改他们的代码
我们需要和客户讨论一下，这种需求出现背后的真正原因，看有没有更好的解决方式。
@lisztli @sunliwen
我们需要和客户讨论一下，这种需求出现背后的真正原因，看有没有更好的解决方式
真正的需求是他们有开发人员，希望有一些自己定制的搜索需求，能快速地实现，不需要经过我们这边的开发迭代周期。
不支持我们的依赖直接暴露。
我赞同大家上述的意见，从技术和产品的严谨性来看，的确是不宜向外层暴露底层的细节，而我的本意也并非是说直接用传递ES的Query，但是，对于一个商用的搜索平台，我们需要一些自定义搜索条件，这中间在非常多的业务逻辑，如，根据应用平台，调整词条的权重，或直接忽略某些关键字，也同时需要调整哪些字段来匹配。目前方式过于死板，检索需求一有变化，就需要重新改代码。针对精确匹配的问题，更多是业务问题，而不是技术问题，从现在代码看，我明明可以指定某一关键字对应某一个字段匹配，但就直接抛异常。的确不应该将底层依赖对外暴露，就像ORM会隐藏总会底层数据库的细节，但它也会提供其它自定义查询的机会啊。
以下为和老范的QQ聊天，我也贴上来
小刀 16:55:24
之前的一些需求可能不是很合理的，是基于业务层面提的，在实现上，是可以通过一些变通的方式来处理的，包括调整查询分词算法，过滤，选择不同的匹配字段和权重，这些都是业务驱动的，如果让你们来面对不同公司如此个性化的需求，并要快速响应，我自己感觉是比较困难的，因为我之前就面对过这种场景，所以，我希望有一种灵活的方式将一部分需求在我们这块消化掉，即基于你们的平台二次开发，这对于你们也是有帮助的，但要实现平台，肯定也有更高的要求
小刀 16:57:23
前几天我们讨论的插件化，参数化，包括自定义mapping,都是很好的思路和办法，也希望我们能一起来做成这个事情
@brook-peng 谢谢小刀兄回复，之前跟你和兴华在广州的头脑风暴非常有启发。
之前的结论：精简核心，从而给二次开发提供一个更灵活可维护的基础架构确实是个挑战，但也基本确定是下一步的目标。