简易筛选器模型

最近接触到一些名词 TQL Elasticsearch，在做筛选器时候技术选择方面的思考

需求：

无全局搜索
对单个实体集筛选（涉及跨表查询）

技术分析：

筛选条件之间是 AND 关系，且无大量文本搜索需求，比如账户名，可以通过正则实现
筛选条件是已知的，无太复杂的筛选条件

TQL：语法解析（针对复杂的筛选条件）
Elasticsearch：作用是用于分词索引，本身无法保证数据准确性

• 已知的筛选条件：AND
  类型（keyword） = IN
  时间 > >= < <=
  数字 > >= < <=

• 根据产品设定的字段加全部索引
  key operator value
  举例：
  options 多选类型
  $or.push[{
  }]

• 跨表搜索且关联大表
  账户： 签约 产品（通过产品搜索账户，实际上是搜索签约，只要未挂载其他与签约筛选无关字段，目前数据模型试用）
  量级别大的情况可以将产品IDs 挂载在账户列表
  再量大的情况查询表单独出来（可独立加索引，进程单独去同步读表，CQRS，时间差）

• 未知的复杂查询：
  允许 OR
  增加索引（允许未知的数据库索引）

模型：

body.conditions [{
    key
    operator
    value
    valueType
}]

注：条件之间大多数是AND的关系，但也有可能是OR，按业务定

分析：

key: 需要查询的关键字
operator：操作符

• 模糊查询 $like（适用于字符串）
• 完全匹配 $= （适用于字符串数字）
• 多个匹配 $in（适用于多选）
• 大于 $>（适用于数字时间）
• 大于等于 $>= （适用于数字时间）
• 小于 $<（适用于数字时间）
• 小于等于 $<=（适用于数字时间）

valueType：匹配的值类型
value：匹配的值

举例：

查询账户名含有 test 的账户:

body.conditions [{
    key: 'realName',
    operator: '$like',
    valueType: 'string',
    value: 'pay'
}]

查询账户名含有 test 的账户 并且 含有 产品 CRM 的签约:

body.conditions [{
    key: 'realName',
    operator: '$like',
    valueType: 'string',
    value: 'test'
}, {
    key: '_productId',
    operator: '$in',
    valueType: 'array',
    value: ['5b711e7645af99110054678b']
}]

注意：查询符合条件总个数 与 结果集 API 分开请求