最近接触到一些名词 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 分开请求
