在這普通的一天，我們用著普通的 API，突然發(fā)現(xiàn)響應(yīng)速度過(guò)慢的警報(bào)意外亮起。

結(jié)果顯示，我們的 API 需要約 70 秒的時(shí)間才能對(duì)常規(guī)流量下的客戶(hù)端做出響應(yīng)。開(kāi)什么玩笑……

先向大家匯報(bào)一下我們的這個(gè)慢速 API 是做什么，又是怎么做的。

在這款應(yīng)用程序中，我們把書(shū)籍及其作者的目錄存儲(chǔ)在 MySQL 數(shù)據(jù)庫(kù)中。其中共包含約 6800 萬(wàn)本書(shū)，每本書(shū)對(duì)應(yīng)一家出版社。

下面來(lái)看書(shū)籍和作者的表結(jié)構(gòu)。

CREATE TABLE `book` (
  `id` int NOT NULL AUTO_INCREMENT,
  `book_uuid_bin` binary(16) NOT NULL,
  `publishing_house_uuid_bin` binary(16) NOT NULL,
  `display_name` varchar(750)  NOT NULL,
  `normalized_name` varchar(750) NOT NULL,
  `description` varchar(1000) DEFAULT NULL,
  `level` varchar(50) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `unique_book_uuid_bin` (`book_uuid_bin`),
  KEY `book_description_idx` (`description`(768)),
  KEY `book_display_name_idx` (`display_name`),
  KEY `book_normalized_name_idx` (`normalized_name`),
  KEY `publishing_house_uuid_bin_idx` (`publishing_house_uuid_bin`),
  KEY `book_uuid_bin_idx` (`book_uuid_bin`)
)

CREATE TABLE `publishing_house` (
  `id` int NOT NULL AUTO_INCREMENT,
  `publishing_house_uuid_bin` binary(16) DEFAULT NULL,
  `display_name` varchar(750) NOT NULL,
  `normalized_name` varchar(750) NOT NULL,
  `alias_uuid_bin` binary(16) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `unique_publishing_house_uuid_bin` (`author_uuid_bin`),
  KEY `publishing_house_normalized_name_idx` (`normalized_name`),
  KEY `publishing_house_display_name_idx` (`display_name`)
)

再說(shuō)回 API，其用例是在 UI 上提供自動(dòng)補(bǔ)全功能，方便用戶(hù)更好地查找特定出版社出版的書(shū)籍，同時(shí)保證用戶(hù)的查詢(xún)字符串同書(shū)籍名稱(chēng)或描述的前綴相匹配。

API 中使用的 MySQL 查詢(xún)?nèi)缦滤荆?/p>

select book_uuid_bin,
       display_name,
       normalized_name,
       description,      
       author_uuid_bin 
from book
where
     ((lower(display_name) like lower("%Software E%") or  lower(description) like lower("%Software E%")) and publishing_house_uuid_bin = UUID_TO_BIN("d2230981-e570-5ba4-9a3a-16028c51d54f"))order by display_name asc limit 100;

即使查詢(xún)?cè)趩伪砩暇湍芡瓿桑恍枰B接作者表，這條 SQL 查詢(xún)也需要 7 秒左右才能執(zhí)行完成。

我們?cè)?where 子句所使用的列上建立了索引。但這一實(shí)現(xiàn)還是存在問(wèn)題，包括：

1、display_name 和 description 等列屬于 VARCHAR 類(lèi)型。

2、會(huì)在 VARCHAR 類(lèi)型列上使用帶有 OR 子句的 LIKE 運(yùn)算符。

3、會(huì)使用 ORDER BY。

4、 WHERE 子句中使用的所有列，都缺少?gòu)?fù)合索引。

5、表中共包含 5800 萬(wàn)條記錄。

我們?cè)鴩L試在查詢(xún)中使用的各列上創(chuàng)建一個(gè)復(fù)合索引，但最終發(fā)現(xiàn)無(wú)濟(jì)于事。因?yàn)閷?duì)于 RDBMS 數(shù)據(jù)庫(kù)內(nèi)的大表來(lái)說(shuō)，在 VARCHAR 列上搜索文本的效率就不可能太高。

我們知道 Elasticsearch 提供全文本搜索功能，所以想在自己的用例中試試看。我們一直在用 AWS 的云服務(wù)，因此選擇了相應(yīng)的 AWS OpenSearch 服務(wù)。

Amazon OpenSearch 托管服務(wù)能幫助用戶(hù)輕松在 AWS 云中部署、操作和擴(kuò)展 OpenSearch 集群。Amazon OpenSearch 是 Amazon Elasticsearch 的繼任方案。

我們通過(guò)腳本將表數(shù)據(jù)從 MySQL 加載到了 AWS OpenSearch 集群當(dāng)中。整個(gè)數(shù)據(jù)遷移過(guò)程大概用了幾個(gè)小時(shí)。

我們?yōu)樗饕Ａ袅?5 個(gè)分片和 1 個(gè)副本因子。

我們還為用例編寫(xiě)了一條等效的 OpenSearch 查詢(xún)，具體如下所示：

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 毫秒以?xún)?nèi)。

API 響應(yīng)速度提高了 1000 倍！

關(guān)于 OpenSearch 全文搜索的一些細(xì)節(jié) ：

在 ElasticSearch 中對(duì)文檔進(jìn)行索引（創(chuàng)建）時(shí)，AWS OpenSearch 會(huì)對(duì)字符串類(lèi)型的字段使用文本分析器。

文本分析器會(huì)將字符串字段拆分為多個(gè) token，為各 token 構(gòu)建內(nèi)部索引，然后根據(jù)查詢(xún)中提供的 token 進(jìn)行匹配。

為了避免重寫(xiě)整個(gè)服務(wù)，同時(shí)盡快在 MySQL 切換至 AWS OpenSearch 后恢復(fù)正常生產(chǎn)，我們決定只在這個(gè)特定用例中使用 OpenSearch。

而且速度提升 1000 倍的代價(jià)，就是多了一套需要在 OpenSearch 當(dāng)中維護(hù)的數(shù)據(jù)副本。但由于我們的數(shù)據(jù)大多是靜態(tài)的，持續(xù)更新量非常有限，所以維護(hù)強(qiáng)度和成本都很低。

可以看到，選擇正確的數(shù)據(jù)庫(kù)引擎往往會(huì)給業(yè)務(wù)用例帶來(lái)翻天覆地的提升。

希望我們的經(jīng)歷能給大家?guī)?lái)一點(diǎn)啟發(fā)，祝編程愉快！