Kurator Customers 搜尋

數據

https://docs.google.com/spreadsheets/d/1ekMoE8DEugwkH-U6xCtAg3J5Yjm4EX8eFLnZ9IljaYY/edit#gid=274134963

結論

建議使用 project_id index 搭配 ILIKE 或 lower LIKE，移除 trgm 或 bigm 直到大型專案的客戶有反應為止。

• project_id 的 index 對大部分的粉專有效
• trgm 或 bigm 只對超大型粉專有幫助
  • 當搜尋的內容是英文 3 個字時：trgm 有效
  • 當搜尋的內容是中文 1～2 個字時：bigm 有效
• 需要實測在 server 上的數據

觀察到的細節

• 比較 ILIKE 與 lower LIKE 神奇的發現：

  • where lower LIKE 的效能跟 where ILIKE 差不多
  • 但 where project_id and lower LIKE 的效能比 where project_id and ILIKE 好很多

• project_id 的 index

  • 在 1 萬人的粉專表現非常理想
  • 在 80 萬人的粉專表現不佳
  • 隨著客戶數增加，可以預想 project_id index 的重要性也會隨之增加，因為 customers 的數量增加時，80萬人粉專佔總 customers 人數相對下降，index 的作用就顯現。

• 加完 index 後必須執行 ANALYZE 才能確保抓到的數據正確

  • 重現的步驟
    1. create index bigm_lower
    2. where lower LIKE ‘lax’ offest 100 limit : 500ms
    3. explain: Seq Scan
    4. ANALYZE customers
    5. where lower LIKE ‘lax’ offest 100 limit: 22ms
    6. explain: Bitmap Index Scan

• 多重 index 組合

  • 發動的時候效能也沒有比較好的感覺
  • 應是資料分布所造成，資料量更大的情況下或許會有幫助

• 新電腦所需的耗時是舊電腦的一半，在我的新電腦上：

  • project_id and LIKE 無 index： 600 ms
  • project_id and ILIKE 無 index：2000 ms
  • project_id and lower LIKE 無 index： 500 ms (why)
  • project_id and LIKE project_id index： 500 ms
  • project_id and ILIKE project_id index： 700 ms
  • project_id and lower LIKE project_id index： 500 ms