Datomic多属性跨字段全文搜索性能问题问询

听起来你碰到了Datomic里多属性全文OR查询的典型性能瓶颈——单个属性的全文索引跑得飞快，但把名、中间名、姓氏三个字段用OR组合起来查就拉胯了对吧？结合你的数据量（600万条），我给你几个实用的解决方案，按推荐优先级排序：

1. 预合成全文字段（最推荐，性能最优） #

这是最简单也最有效的办法：新增一个专门用于全文搜索的属性，比如:person/full-name-combined，把名、中间名、姓氏拼接成一个字符串，然后给这个属性单独建全文索引。这样查询的时候只需要扫这一个索引，性能和你单独查姓氏的100ms基本一致。

具体操作： #

• 写入/更新时维护合成字段：可以在事务里手动拼接，或者用Datomic的事务函数自动处理，确保原字段更新时合成字段同步更新，避免数据不一致。比如：

  ;; 示例事务数据
  {:db/id #db/id[:db.part/user]
   :person/first-name "John"
   :person/middle-name "Michael"
   :person/last-name "Smith"
   :person/full-name-combined "John Michael Smith"}
  

  如果用事务函数，能自动处理更新场景：

  (defn update-person-full-name
    [db eid first middle last]
    [{:db/id eid
      :person/first-name first
      :person/middle-name middle
      :person/last-name last
      :person/full-name-combined (str first " " middle " " last)}])
  

• 查询时直接用合成字段：

  (d/q '[:find ?e
         :in $ ?search-term
         :where
         [(fulltext $ :person/full-name-combined ?search-term) [[?e]]]]
       your-db "smith")
  

优点： #

• 完全复用单个全文索引的高性能，逻辑简单易懂
• 维护成本低，只需要确保合成字段和原字段同步
• 支持更灵活的搜索（比如用户输入“John Smith”也能直接匹配）

2. 用or-join优化多属性查询（无需新增字段） #

如果不想改动数据模型，那可以用Datomic的or-join来替代普通的or逻辑，它能更高效地合并多个全文查询的结果集，减少内存开销和重复计算。

错误写法（性能差的原因）： #

直接用or连接三个fulltext子句，Datomic会分别执行三个全文查询，然后在内存里合并去重，600万条数据下这个合并过程会非常慢：

(d/q '[:find ?e
       :in $ ?search-term
       :where
       (or [(fulltext $ :person/first-name ?search-term) [[?e]]]
           [(fulltext $ :person/middle-name ?search-term) [[?e]]]
           [(fulltext $ :person/last-name ?search-term) [[?e]]])]
     your-db "smith")

优化后的or-join写法： #

(d/q '[:find ?e
       :in $ ?search-term
       :where
       (or-join [?e ?search-term]
         [(fulltext $ :person/first-name ?search-term) [[?e]]]
         [(fulltext $ :person/middle-name ?search-term) [[?e]]]
         [(fulltext $ :person/last-name ?search-term) [[?e]]])]
     your-db "smith")

原理： #

or-join会优化结果集的合并逻辑，避免不必要的重复扫描，相比普通or能显著提升大数据集下的查询速度，但性能还是不如预合成字段的方案。

3. 调整全文索引配置（辅助优化） #

不管用上面哪种方案，都可以通过调整Datomic全文索引的配置来进一步提升性能：

• 选择适合人名的分词器：比如用keyword分词器（不拆分单词），或者自定义分词规则，避免把人名拆成不必要的词
• 关闭停用词过滤：人名里一般没有停用词，关闭后能减少索引大小，提升查询速度
• 索引配置示例：

  {:db/ident :person/full-name-combined
   :db/valueType :db.type/string
   :db/fulltext true
   :db/fulltext-config {:analyzer "keyword"
                        :stopwords []}
   :db/cardinality :db.cardinality/one}
  

额外注意事项 #

• 测试的时候一定要用600万条的真实数据，小数据集下性能差异不明显
• 用Datomic的查询监控工具查看执行计划，确认每个查询都命中了全文索引，没有出现全表扫描
• 对于高频搜索词，可以考虑用缓存（比如Redis）来缓存查询结果，进一步减轻Datomic的压力

内容的提问来源于stack exchange，提问作者Ivan Grishaev