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

結果顯示，我們的 API 需要約 70 秒的時間才能對常規(guī)流量下的客戶端做出響應。開什么玩笑……

先向大家匯報一下我們的這個慢速 API 是做什么，又是怎么做的。

在這款應用程序中，我們把書籍及其作者的目錄存儲在 MySQL 數(shù)據庫中。其中共包含約 6800 萬本書，每本書對應一家出版社。

下面來看書籍和作者的表結構。

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`)
)

再說回 API，其用例是在 UI 上提供自動補全功能，方便用戶更好地查找特定出版社出版的書籍，同時保證用戶的查詢字符串同書籍名稱或描述的前綴相匹配。

API 中使用的 MySQL 查詢如下所示：

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;

即使查詢在單表上就能完成，不需要連接作者表，這條 SQL 查詢也需要 7 秒左右才能執(zhí)行完成。

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

1、display_name 和 description 等列屬于 VARCHAR 類型。

2、會在 VARCHAR 類型列上使用帶有 OR 子句的 LIKE 運算符。

3、會使用 ORDER BY。

4、 WHERE 子句中使用的所有列，都缺少復合索引。

5、表中共包含 5800 萬條記錄。

我們曾嘗試在查詢中使用的各列上創(chuàng)建一個復合索引，但最終發(fā)現(xiàn)無濟于事。因為對于 RDBMS 數(shù)據庫內的大表來說，在 VARCHAR 列上搜索文本的效率就不可能太高。

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

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

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

我們?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 響應速度直接縮短至 70 毫秒以內。

API 響應速度提高了 1000 倍！

關于 OpenSearch 全文搜索的一些細節(jié) ：

在 ElasticSearch 中對文檔進行索引（創(chuàng)建）時，AWS OpenSearch 會對字符串類型的字段使用文本分析器。

文本分析器會將字符串字段拆分為多個 token，為各 token 構建內部索引，然后根據查詢中提供的 token 進行匹配。

為了避免重寫整個服務，同時盡快在 MySQL 切換至 AWS OpenSearch 后恢復正常生產，我們決定只在這個特定用例中使用 OpenSearch。

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

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

希望我們的經歷能給大家?guī)硪稽c啟發(fā)，祝編程愉快！