鍵.png)
使用NestJS和Prisma構(gòu)建REST API：身份驗證
你可能也喜歡這些API文章!
即使查詢在單表上就能完成，不需要連接作者表，這條 SQL 查詢也需要 7 秒左右才能執(zhí)行完成。
我們在 where 子句所使用的列上建立了索引。但這一實現(xiàn)還是存在問題，包括：
1、display_name 和 description 等列屬于 VARCHAR 類型。
2、會在 VARCHAR 類型列上使用帶有 OR 子句的 LIKE 運算符。
3、會使用 ORDER BY。
4、 WHERE 子句中使用的所有列，都缺少復(fù)合索引。
5、表中共包含 5800 萬條記錄。
我們曾嘗試在查詢中使用的各列上創(chuàng)建一個復(fù)合索引，但最終發(fā)現(xiàn)無濟(jì)于事。因為對于 RDBMS 數(shù)據(jù)庫內(nèi)的大表來說，在 VARCHAR 列上搜索文本的效率就不可能太高。
我們知道 Elasticsearch 提供全文本搜索功能，所以想在自己的用例中試試看。我們一直在用 AWS 的云服務(wù)，因此選擇了相應(yīng)的 AWS OpenSearch 服務(wù)。
Amazon OpenSearch 托管服務(wù)能幫助用戶輕松在 AWS 云中部署、操作和擴(kuò)展 OpenSearch 集群。Amazon OpenSearch 是 Amazon Elasticsearch 的繼任方案。
我們通過腳本將表數(shù)據(jù)從 MySQL 加載到了 AWS OpenSearch 集群當(dāng)中。整個數(shù)據(jù)遷移過程大概用了幾個小時。
我們?yōu)樗饕Ａ袅?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 響應(yīng)速度直接縮短至 70 毫秒以內(nèi)。
API 響應(yīng)速度提高了 1000 倍！
關(guān)于 OpenSearch 全文搜索的一些細(xì)節(jié) ：
在 ElasticSearch 中對文檔進(jìn)行索引（創(chuàng)建）時，AWS OpenSearch 會對字符串類型的字段使用文本分析器。
文本分析器會將字符串字段拆分為多個 token，為各 token 構(gòu)建內(nèi)部索引，然后根據(jù)查詢中提供的 token 進(jìn)行匹配。
為了避免重寫整個服務(wù)，同時盡快在 MySQL 切換至 AWS OpenSearch 后恢復(fù)正常生產(chǎn)，我們決定只在這個特定用例中使用 OpenSearch。
而且速度提升 1000 倍的代價，就是多了一套需要在 OpenSearch 當(dāng)中維護(hù)的數(shù)據(jù)副本。但由于我們的數(shù)據(jù)大多是靜態(tài)的，持續(xù)更新量非常有限，所以維護(hù)強(qiáng)度和成本都很低。
可以看到，選擇正確的數(shù)據(jù)庫引擎往往會給業(yè)務(wù)用例帶來翻天覆地的提升。
希望我們的經(jīng)歷能給大家?guī)硪稽c啟發(fā)，祝編程愉快！
文章轉(zhuǎn)自微信公眾號@世界人工智能論壇
