如何快速實現REST API集成以優化業務流程
你可能也喜歡這些API文章!
即使查詢在單表上就能完成，不需要連接作者表，這條 SQL 查詢也需要 7 秒左右才能執行完成。
我們在 where 子句所使用的列上建立了索引。但這一實現還是存在問題，包括：
1、display_name 和 description 等列屬于 VARCHAR 類型。
2、會在 VARCHAR 類型列上使用帶有 OR 子句的 LIKE 運算符。
3、會使用 ORDER BY。
4、 WHERE 子句中使用的所有列，都缺少復合索引。
5、表中共包含 5800 萬條記錄。
我們曾嘗試在查詢中使用的各列上創建一個復合索引，但最終發現無濟于事。因為對于 RDBMS 數據庫內的大表來說，在 VARCHAR 列上搜索文本的效率就不可能太高。
我們知道 Elasticsearch 提供全文本搜索功能，所以想在自己的用例中試試看。我們一直在用 AWS 的云服務，因此選擇了相應的 AWS OpenSearch 服務。
Amazon OpenSearch 托管服務能幫助用戶輕松在 AWS 云中部署、操作和擴展 OpenSearch 集群。Amazon OpenSearch 是 Amazon Elasticsearch 的繼任方案。
我們通過腳本將表數據從 MySQL 加載到了 AWS OpenSearch 集群當中。整個數據遷移過程大概用了幾個小時。
我們為索引保留了 5 個分片和 1 個副本因子。
我們還為用例編寫了一條等效的 OpenSearch 查詢，具體如下所示：
API — POST /books-catalog/_search
{
"query": {
"bool": {
"must": [
{
"match_phrase": {
"publisherUuid": "1f754fc0-610c-5b29-b22b-fa8140afb7be"
}
},
{
"bool": {
"should": [
{
"match_phrase": {
"displayName": "Software E"
}
},
{
"match_phrase": {
"description": "Software E"
}
}
]
}
}
]
}
},
"size": 100,
"sort": [
{
"displayName.keyword": {
"unmapped_type": "keyword",
"order": "asc"
}
}
]
}我們的 API 響應速度直接縮短至 70 毫秒以內。
API 響應速度提高了 1000 倍！
關于 OpenSearch 全文搜索的一些細節 ：
在 ElasticSearch 中對文檔進行索引（創建）時，AWS OpenSearch 會對字符串類型的字段使用文本分析器。
文本分析器會將字符串字段拆分為多個 token，為各 token 構建內部索引，然后根據查詢中提供的 token 進行匹配。
為了避免重寫整個服務，同時盡快在 MySQL 切換至 AWS OpenSearch 后恢復正常生產，我們決定只在這個特定用例中使用 OpenSearch。
而且速度提升 1000 倍的代價，就是多了一套需要在 OpenSearch 當中維護的數據副本。但由于我們的數據大多是靜態的，持續更新量非常有限，所以維護強度和成本都很低。
可以看到，選擇正確的數據庫引擎往往會給業務用例帶來翻天覆地的提升。
希望我們的經歷能給大家帶來一點啟發，祝編程愉快！
文章轉自微信公眾號@世界人工智能論壇
