面試經(jīng)典問題，如何提高數(shù)據(jù)庫的性能？

作者：聞數(shù)起舞 2022-06-28 15:00:28

一個有趣的面試問題，我已經(jīng)聽到并問過很多次了。"你將如何提高數(shù)據(jù)庫的性能？"

簡介

一個有趣的面試問題，我已經(jīng)聽到并問過很多次了。

"你將如何提高數(shù)據(jù)庫的性能？"

我喜歡這個問題，因?yàn)椋拖裎矣懻撨^，它從更廣泛的角度來衡量候選人的技能。云計(jì)算架構(gòu)師會考慮數(shù)據(jù)庫的架構(gòu)，考慮讀取復(fù)制和分片，后端或全棧工程師可能會考慮應(yīng)用層面的變化，如優(yōu)化的SQL查詢、連接池，而數(shù)據(jù)庫人員可能會考慮數(shù)據(jù)庫的配置、插件等。

這個問題可能有很多答案，因?yàn)槲蚁肷钊肓私饷總€答案，所以我將分別寫三篇文章，每篇都針對某一類答案。

第一篇將更多地討論應(yīng)用層面和SQL的變化。這些可能是我對直接編寫代碼的開發(fā)人員的期望（例如，編寫與數(shù)據(jù)庫服務(wù)器互動的NodeJS、Python應(yīng)用程序的開發(fā)人員）。

第二種是要更注重架構(gòu)層面的變化，管理服務(wù)等。他們會更關(guān)注云計(jì)算架構(gòu)師或?qū)ο到y(tǒng)設(shè)計(jì)概念有良好了解的人。

第三組答案將更注重于數(shù)據(jù)庫和操作系統(tǒng)的配置。

請記住，這是一個非常廣泛的話題，這是我對如何回答這個問題的看法，我將提供進(jìn)一步閱讀的鏈接，并盡可能多地提供實(shí)際的例子。

我也在使用軟件工程的stackexchange數(shù)據(jù)集作為我的例子，你可以找到在使用Pandas將數(shù)據(jù)加載到Postgres之前，我還對數(shù)據(jù)進(jìn)行了一些轉(zhuǎn)換和調(diào)整，如果你有興趣了解更多，請告訴我，我可以分享jupyter-notebook。這些數(shù)據(jù)相當(dāng)容易理解，我的大多數(shù)例子應(yīng)該僅限于Posts表，它簡單地定義了StackOverflow上發(fā)布的問題，屬性包括標(biāo)題、正文、創(chuàng)建日期等。

問題

問題是，"我的數(shù)據(jù)庫越來越慢，你會如何提高它的性能？". 在這篇文章中，我假設(shè)是一個SQL數(shù)據(jù)庫，特別是Postgres。

把這個問題看成是一個兩部分的問題，盡管它沒有明確這樣說。第一部分是 "為什么"，第二部分是如何解決。為了理解 "為什么"，你需要對問題進(jìn)行調(diào)試，一旦你知道了數(shù)據(jù)庫性能緩慢的原因，你就可以提出一個可能的解決方案。

為了便于閱讀，我從可能的答案開始，涵蓋與每個答案相關(guān)的權(quán)衡，然后我將解決你需要提出的反面問題，以調(diào)試問題的原因。

在你向下滾動之前，想一想你會如何回答這個問題，如果你發(fā)現(xiàn)我的文章中沒有包括的內(nèi)容，請?jiān)谠u論中告訴我。

可能的答案

請記住，每一個答案都是有取舍的。

索引

如果你的SELECT查詢變得非常慢，因?yàn)槟阍跈z查某個條件，索引可以提供一種方法來改善你的數(shù)據(jù)庫讀取性能。

你可以在一組特定的列上創(chuàng)建一個索引，數(shù)據(jù)庫將創(chuàng)建一個數(shù)據(jù)結(jié)構(gòu)來保存數(shù)據(jù)庫的這些列，這樣你就可以得到這些列的快速查詢。

例如，如果我想獲取用戶user8創(chuàng)建的帖子，我可以運(yùn)行以下查詢

SELECT * FROM posts WHERE owner_display_name='user8';

然而，這迫使數(shù)據(jù)庫掃描表中的所有行，以找到owner_display_name為 "user8 "的帖子。這種類型的掃描被稱為順序掃描，因?yàn)閿?shù)據(jù)庫正在掃描整個表。正如名字所暗示的，這種類型的查找不是最優(yōu)化的解決方案。

運(yùn)行上面的查詢，大約需要150ms的時(shí)間來執(zhí)行。這個查詢的查詢計(jì)劃（數(shù)據(jù)庫對如何為你的查詢讀取表所做的規(guī)劃）也表明，它將對這個查詢進(jìn)行順序掃描

面試經(jīng)典問題，如何提高數(shù)據(jù)庫的性能？

要得到同樣的結(jié)果，一個更好的方法是在列owner_display_name上創(chuàng)建一個索引。這將創(chuàng)建一個單獨(dú)的數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)庫可以使用這個新的數(shù)據(jù)結(jié)構(gòu)快速查詢該列的特定值。

創(chuàng)建一個索引很簡單。

CREATE INDEX posts_owner_display_name_idx ON posts (owner_display_name)。

一旦我們創(chuàng)建了索引，我們就不需要做任何其他事情來使用它。數(shù)據(jù)庫足夠聰明，知道什么時(shí)候使用索引，什么時(shí)候不使用。運(yùn)行同樣的查詢。

SELECT * FROM posts WHERE owner_display_name='user8';

我們現(xiàn)在得到了完全不同的結(jié)果。現(xiàn)在查詢在2ms左右就完成了！這比沒有索引時(shí)快了50倍。這比沒有索引時(shí)快了50倍!

查詢計(jì)劃還指出，數(shù)據(jù)庫現(xiàn)在正在使用我們所創(chuàng)建的索引

面試經(jīng)典問題，如何提高數(shù)據(jù)庫的性能？

雖然沒有什么是免費(fèi)的，索引也有一定的成本。

由于我們現(xiàn)在正在創(chuàng)建一個不同的數(shù)據(jù)結(jié)構(gòu)來存儲你表中的相同數(shù)據(jù)，所以你的表的每一行都需要更多的存儲空間。除此之外，現(xiàn)在數(shù)據(jù)庫必須確保每當(dāng)你向表中添加新的行時(shí)，索引都是最新的，所以在編寫新的行時(shí)，它也為數(shù)據(jù)庫增加了更多的工作。

索引可以是修復(fù)數(shù)據(jù)庫讀取性能的一個好方法，但可能會減慢寫入性能。

索引本身就是一個復(fù)雜的話題，網(wǎng)上有很多資源可以更深入地討論其性能影響。如果你想更多地了解與索引相關(guān)的權(quán)衡，那么 "索引 "是一個很好的起點(diǎn)。如果你想了解更多關(guān)于索引的信息，視頻也更詳細(xì)地解釋了索引。

創(chuàng)建物化視圖

你可以在數(shù)據(jù)庫中創(chuàng)建兩種類型的視圖，簡單視圖和物化視圖。

簡單視圖作為查詢的別名，而物化視圖則存儲查詢的結(jié)果。這意味著，你可以預(yù)先計(jì)算查詢，將結(jié)果存儲在物化視圖中，并在用戶實(shí)際要求時(shí)快速向用戶顯示結(jié)果，而不是在用戶請求時(shí)運(yùn)行查詢。

讓我們用一個例子來討論這個問題。假設(shè)我想根據(jù)帖子的瀏覽量來了解帖子的類別 --

面試經(jīng)典問題，如何提高數(shù)據(jù)庫的性能？

做到這一點(diǎn)的一個方法是運(yùn)行以下查詢

SELECT
 CASE
  WHEN view_count < 10 THEN 1
  WHEN view_count < 100 THEN 2
  WHEN view_count < 1000 THEN 3
  WHEN view_count < 10000 THEN 4
  WHEN view_count < 100000 THEN 5
  ELSE 6
 END as view_count_category_index,
 CASE
  WHEN view_count < 10 THEN '0-10'
  WHEN view_count < 100 THEN '10-100'
  WHEN view_count < 1000 THEN '100-1000'
  WHEN view_count < 10000 THEN '1000-10000'
  WHEN view_count < 100000 THEN '10000-100000'
  ELSE '100000+'
 END as view_count_category,
 COUNT(*)
FROM
 posts
GROUP BY view_count_category, view_count_category_index
ORDER BY view_count_category_index ASC;

執(zhí)行時(shí)間: 257.556 ms

250毫秒比我想要的要高一點(diǎn)。我希望它能低得多，比如說<50ms。創(chuàng)建一個視圖非常簡單，我只需要運(yùn)行CREATE VIEW [VIEWNAME] AS [QUERY]。讓我們創(chuàng)建一個簡單的（非化的）視圖。

CREATE VIEW non_mat_view_count_view AS
SELECT
 CASE
  WHEN view_count < 10 THEN 1
  WHEN view_count < 100 THEN 2
  WHEN view_count < 1000 THEN 3
  WHEN view_count < 10000 THEN 4
  WHEN view_count < 100000 THEN 5
  ELSE 6
 END as view_count_category_index,
 CASE
  WHEN view_count < 10 THEN '0-10'
  WHEN view_count < 100 THEN '10-100'
  WHEN view_count < 1000 THEN '100-1000'
  WHEN view_count < 10000 THEN '1000-10000'
  WHEN view_count < 100000 THEN '10000-100000'
  ELSE '100000+'
 END as view_count_category,
 COUNT(*)
FROM
 posts
GROUP BY view_count_category, view_count_category_index
ORDER BY view_count_category_index ASC;

然后嘗試從視圖中獲取結(jié)果。

SELECT * FROM non_mat_view_count_view;

它確實(shí)給了我正確的輸出。但是當(dāng)用EXPLAIN ANALYZE運(yùn)行時(shí)，我得到的執(zhí)行時(shí)間仍然非常相似，為250-260ms。發(fā)生這種情況的原因是，簡單的視圖只是存儲了查詢，當(dāng)我們試圖使用該視圖時(shí)，會重新執(zhí)行該查詢。

然而，創(chuàng)建一個物化視圖是不同的。在這里，當(dāng)我們創(chuàng)建物化視圖時(shí)，它實(shí)際上會存儲查詢的結(jié)果，當(dāng)用戶請求這些數(shù)據(jù)時(shí)，它不需要計(jì)算結(jié)果，由于它只需要獲取結(jié)果，所以它可以比執(zhí)行查詢或簡單視圖快很多。

創(chuàng)建物化視圖與創(chuàng)建簡單視圖非常相似，只是我們使用CREATE MATERIALIZED VIEW而不是CREATE VIEW。

CREATE MATERIALIZED VIEW mat_view_count_view AS
SELECT
 CASE
  WHEN view_count < 10 THEN 1
  WHEN view_count < 100 THEN 2
  WHEN view_count < 1000 THEN 3
  WHEN view_count < 10000 THEN 4
  WHEN view_count < 100000 THEN 5
  ELSE 6
 END as view_count_category_index,
 CASE
  WHEN view_count < 10 THEN '0-10'
  WHEN view_count < 100 THEN '10-100'
  WHEN view_count < 1000 THEN '100-1000'
  WHEN view_count < 10000 THEN '1000-10000'
  WHEN view_count < 100000 THEN '10000-100000'
  ELSE '100000+'
 END as view_count_category,
 COUNT(*)
FROM
 posts
GROUP BY view_count_category, view_count_category_index
ORDER BY view_count_category_index ASC;

當(dāng)我們運(yùn)行EXPLAIN ANALYZE SELECT * FROM mat_view_count_view；我們得到的執(zhí)行時(shí)間是0.027ms。這比執(zhí)行查詢或使用我們以前的簡單視圖要快得多!事實(shí)上，這是12000倍的速度!

然而，這也是有代價(jià)的。由于結(jié)果是預(yù)先計(jì)算的，對表的任何更新都不會自動更新結(jié)果。你需要手動運(yùn)行REFRESH MATERIALIZED VIEW mat_view_count_view來更新視圖。如果你想實(shí)現(xiàn)自動化，有很多方法可以做到這一點(diǎn)，正如在《MATERIALIZED VIEW》中解釋的那樣。但所有這些方法都有一些缺點(diǎn)。缺點(diǎn)包括數(shù)據(jù)不一致（例如，用戶獲取過時(shí)的視圖計(jì)數(shù)類別數(shù)據(jù)），以及數(shù)據(jù)庫服務(wù)器的性能問題，因?yàn)楦乱晥D意味著再次計(jì)算這個查詢，等等。

因此，雖然物化視圖是提高讀取性能的好方法，但在向數(shù)據(jù)庫寫入時(shí)可能會導(dǎo)致性能問題或一致性問題。當(dāng)數(shù)據(jù)的更新頻率較低，并且可以容忍輕微的數(shù)據(jù)不一致或不準(zhǔn)確時(shí)，這種解決方案可能是有意義的。

應(yīng)用層面上的連接池

在我談?wù)撨B接池之前，讓我解釋一下什么是連接。

要連接到一個數(shù)據(jù)庫，你的應(yīng)用程序需要建立一個數(shù)據(jù)庫連接。把這個連接看成是一個假想的管道，請求和響應(yīng)將通過這個管道流動。

面試經(jīng)典問題，如何提高數(shù)據(jù)庫的性能？

你需要數(shù)據(jù)庫主機(jī)名、數(shù)據(jù)庫名、憑證等來建立一個新的連接，這個連接確實(shí)有一些數(shù)據(jù)與之相關(guān)。我認(rèn)為維基百科上關(guān)于連接的文章把它說得非常好。

"數(shù)據(jù)庫連接是有限的和昂貴的，相對于在其上進(jìn)行的操作來說，創(chuàng)建的時(shí)間可能長得不成比例。當(dāng)一個應(yīng)用程序需要更新數(shù)據(jù)庫時(shí)，創(chuàng)建、使用和關(guān)閉數(shù)據(jù)庫連接的效率很低。"

一旦你有一個連接，你就可以開始向數(shù)據(jù)庫發(fā)送請求。大多數(shù)數(shù)據(jù)庫只允許你在每個連接上一次執(zhí)行一個操作。這意味著，如果一個事務(wù)的執(zhí)行需要100毫秒，那么每個連接只能實(shí)現(xiàn)每秒10個事務(wù)（或10TPS）。因此，使用單一連接限制了你可以運(yùn)行的事務(wù)數(shù)量。

因此，讓我們回顧一下。我們知道打開和關(guān)閉連接是昂貴的，我們也知道我們不能使用單一的連接，因?yàn)槟菚刮覀兊南到y(tǒng)陷入瓶頸。

那么，解決方案是什么呢？

好吧，我們可以維護(hù)一些連接并重復(fù)使用它們。這就是所謂的連接池。想象一下一個連接池，如果這能讓人更容易記住的話。

幸運(yùn)的是，大多數(shù)客戶端庫都具備相當(dāng)好的連接池功能，我們可以在代碼中快速編寫。

事實(shí)上，它是如此廣泛，以至于pg庫文檔中的例子，這是一個非常流行的用于postgres的nodejs庫，它同時(shí)具有連接到數(shù)據(jù)庫的連接池方法和直接客戶端方法

const { Pool, Client } = require('pg')

// pools will use environment variables
// for connection information
const pool = new Pool()
pool.query('SELECT NOW()', (err, res) => {
  console.log(err, res)
  pool.end()
})

// you can also use async/await
const res = await pool.query('SELECT NOW()')
await pool.end()

// clients will also use environment variables
// for connection information
const client = new Client()
await client.connect()

const res = await client.query('SELECT NOW()')
await client.end()

還有一些重要的配置，我們可以在數(shù)據(jù)庫服務(wù)器上做連接池，這可能會影響性能，但由于我想在另一篇文章中介紹數(shù)據(jù)庫服務(wù)器和操作系統(tǒng)的配置，我現(xiàn)在先不談這個。

說到權(quán)衡，我不認(rèn)為連接池有什么大的權(quán)衡，至少我沒有遇到過，也沒有讀到過。如果你碰巧知道，請留言幫助我，也幫助其他會讀這篇文章的人。

最后。這是一個了不起的起點(diǎn)，如果你想了解更多關(guān)于連接池的信息。

應(yīng)用層面的緩存

對于很多應(yīng)用來說，大多數(shù)的讀取只針對少量的數(shù)據(jù)。考慮一下Twitter的情況。大多數(shù)被瀏覽的推文可能是重要和受歡迎的人，如政治家、名人等。類似的趨勢也可能存在于許多流行的閱讀量大的網(wǎng)站上。

事實(shí)上，讓我們看看到目前為止我們一直在使用的數(shù)據(jù)。請記住，這是來自softwareengineering.stackexchange.com的真實(shí)流量數(shù)據(jù)。

為了分析這些數(shù)據(jù)，我按瀏覽量對數(shù)據(jù)進(jìn)行排序，然后按十分位數(shù)進(jìn)行分組。簡而言之，下圖顯示了哪一個十分位數(shù)獲得了多少百分比的總瀏覽量。

面試經(jīng)典問題，如何提高數(shù)據(jù)庫的性能？

數(shù)據(jù)顯示，前10%（第一個十分位數(shù)）的帖子占了約95%的瀏覽量，接下來的10%（第二個十分位數(shù)）占了約4.8%的瀏覽量。

面試經(jīng)典問題，如何提高數(shù)據(jù)庫的性能？

SELECT
 (SUM(view_count) * 100.0) / (SELECT SUM(view_count) FROM actual_posts) as percentage,
    SUM(view_count),
    decile
FROM (
    SELECT
        post_id,
        view_count,
        ntile(10) over (order by view_count DESC) as decile
    FROM actual_posts
) sum_data
GROUP BY decile
ORDER BY decile

當(dāng)按百分位數(shù)而不是十位數(shù)計(jì)算時(shí)，瀏覽量的差異更加明顯，前1%的帖子占了50%以上的瀏覽量。

面試經(jīng)典問題，如何提高數(shù)據(jù)庫的性能？

這意味著，通過找到一種方法來服務(wù)前1%的帖子，你可以加快你得到的50%的請求，或者找到一種方法來服務(wù)前10%的帖子，你可以加快你得到的95%的請求!由于這為其他請求釋放了你的服務(wù)器，其他請求也可以使用更多的資源，因此速度會更快！"。

因此，讓我們來看看問題的陳述，我們需要找到一種方法來存儲相對較少的數(shù)據(jù)，但能夠非常快速地獲取它。另一方面，我們?nèi)匀恍枰鎯ζ溆嗟臄?shù)據(jù)，但我們不需要超快的檢索。

實(shí)現(xiàn)這一目標(biāo)的一個好方法是將經(jīng)常被獲取的少量數(shù)據(jù)存儲在RAM中，而將大量數(shù)據(jù)存儲在SSD中。這樣，你就可以非常迅速地滿足大部分的請求，并在需要的時(shí)候偶爾打到SSD上。這就是所謂的高速緩存。

有很多方法可以實(shí)現(xiàn)這一點(diǎn)，但由于我在這篇文章中討論的是應(yīng)用層面的變化，所以一個簡單的實(shí)現(xiàn)方法是在你的應(yīng)用中添加一個簡單的哈希圖。請注意，這絕對不是最好的方法，還有其他更好的緩存方案，但我將在后面介紹更復(fù)雜的方案。

這個想法很簡單，為你經(jīng)常收到的請求在哈希姆中建立一個小的緩沖區(qū)。當(dāng)用戶請求一個帖子時(shí)，檢查它是否存在于你的緩存中，如果存在，那么就把帖子發(fā)給用戶，如果不存在，那么你就可以沖擊你的數(shù)據(jù)庫，把數(shù)據(jù)存儲在SSD中。對我們來說，幸運(yùn)的是，已經(jīng)有很多庫實(shí)現(xiàn)了這一點(diǎn)。

不過這也有很大的缺點(diǎn)。

一個大的問題是與數(shù)據(jù)的一致性有關(guān)。如果你在RAM上存儲了少量的數(shù)據(jù)，你需要確保在數(shù)據(jù)庫中的數(shù)據(jù)被更新時(shí)更新這些數(shù)據(jù)，這樣用戶就不會收到過時(shí)的數(shù)據(jù)。這就打開了一個難題，因?yàn)楝F(xiàn)在你需要決定你更新數(shù)據(jù)的頻率，是每分鐘、每秒鐘、每一次交易等等。

這個解決方案可能會出現(xiàn)的另一個問題（盡管我們在未來的文章中可能會討論的其他緩存解決方案不會出現(xiàn)這個問題）是使你的服務(wù)器更加復(fù)雜和有狀態(tài)。終止你的服務(wù)器將意味著失去這些存儲在RAM中的數(shù)據(jù)，而啟動新的服務(wù)器將意味著從數(shù)據(jù)庫中快速獲取大量的數(shù)據(jù)（這被稱為 thundering herd problem).當(dāng)一個新的服務(wù)器突然出現(xiàn)時(shí)，這種大量的取數(shù)會使數(shù)據(jù)庫在短時(shí)間內(nèi)變慢。

別擔(dān)心，這些問題的解決方案是存在的，在很多情況下，緩存是一個非常好的通用解決方案，特別是當(dāng)數(shù)據(jù)一致性不是問題的時(shí)候。

編寫優(yōu)化的SQL查詢

在應(yīng)用層面，提高性能的一個好方法是編寫優(yōu)化的SQL查詢。即使性能不是一個問題，為了未來的可擴(kuò)展性，編寫優(yōu)化的SQL查詢?nèi)匀皇歉玫淖龇ā?/p>

有相當(dāng)多的方法可以讓你寫出優(yōu)化的SQL查詢，例如，試圖避免OFFSET和找到更好的方法來實(shí)現(xiàn)分頁，或者避免SELECT * ，等等。網(wǎng)上有很多很好的資源，有助于幫助你理解優(yōu)化的SQL查詢。

另一個好的組織技術(shù)可以是編寫非物化視圖，并在應(yīng)用層面的SQL中使用它們來代替長的SQL語句。

對于那些不知道什么是非物化視圖的人來說，可以把它看作是一種查詢的別名。例如，我們假設(shè)我有一個名為post的表。這個表有以下的模式---

面試經(jīng)典問題，如何提高數(shù)據(jù)庫的性能？

在大多數(shù)情況下，我們將考慮到以下欄目

面試經(jīng)典問題，如何提高數(shù)據(jù)庫的性能？

比方說，我想寫一個SQL查詢，用于根據(jù)帖子的瀏覽量進(jìn)行分類，例如，如果我想要這樣的輸出

面試經(jīng)典問題，如何提高數(shù)據(jù)庫的性能？

這方面的查詢是。

SELECT
 CASE
  WHEN view_count < 10 THEN 1
  WHEN view_count < 100 THEN 2
  WHEN view_count < 1000 THEN 3
  WHEN view_count < 10000 THEN 4
  WHEN view_count < 100000 THEN 5
  ELSE 6
 END as view_count_category_index,
 CASE
  WHEN view_count < 10 THEN '0-10'
  WHEN view_count < 100 THEN '10-100'
  WHEN view_count < 1000 THEN '100-1000'
  WHEN view_count < 10000 THEN '1000-10000'
  WHEN view_count < 100000 THEN '10000-100000'
  ELSE '100000+'
 END as view_count_category,
 COUNT(*)
FROM
 posts
GROUP BY view_count_category, view_count_category_index
ORDER BY view_count_category_index ASC;

這有點(diǎn)復(fù)雜。我可以創(chuàng)建一個視圖，而不是在我的代碼中寫這個。??

CREATE VIEW view_count_category_view AS
SELECT
 CASE
  WHEN view_count < 10 THEN 1
  WHEN view_count < 100 THEN 2
  WHEN view_count < 1000 THEN 3
  WHEN view_count < 10000 THEN 4
  WHEN view_count < 100000 THEN 5
  ELSE 6
 END as view_count_category_index,
 CASE
  WHEN view_count < 10 THEN '0-10'
  WHEN view_count < 100 THEN '10-100'
  WHEN view_count < 1000 THEN '100-1000'
  WHEN view_count < 10000 THEN '1000-10000'
  WHEN view_count < 100000 THEN '10000-100000'
  ELSE '100000+'
 END as view_count_category,
 COUNT(*)
FROM
 posts
GROUP BY view_count_category, view_count_category_index
ORDER BY view_count_category_index ASC;

那么我就可以不在代碼中寫這個SQL邏輯，而是簡單地使用

SELECT * FROM view_count_category_view

當(dāng)我在上面的視圖上執(zhí)行查詢時(shí)，在幕后，數(shù)據(jù)庫實(shí)際上會執(zhí)行創(chuàng)建視圖的實(shí)際查詢。

?這使得我的代碼更加簡潔，而且在將來，我可以更新視圖邏輯，而不需要在應(yīng)用層面上進(jìn)行修改和重新部署。還有一種方法可以實(shí)現(xiàn)類似的功能，叫做存儲過程

在回答問題前先反問

在回答這個問題之前，你一般應(yīng)該問幾個反面的問題，以幫助更好地理解這個問題。這些可以幫助你衡量系統(tǒng)中的瓶頸問題。整個系統(tǒng)可能相當(dāng)復(fù)雜，可能有很多原因?qū)е聰?shù)據(jù)庫開始表現(xiàn)不佳。為了更好地了解原因，并更好地了解系統(tǒng)的要求，你可以向面試官提出一些問題，這些問題可以幫助你找出最佳解決方案。

由于這一部分需要對上面的答案有一定的了解，所以我在討論了可能的答案后將其列入，但你在回答之前可能應(yīng)該提出反問。

是讀取性能慢還是寫入性能慢？

一個非常重要的因素可以推動你的決策，就是有關(guān)數(shù)據(jù)庫的讀寫性能如何。許多改善一個的解決方案可能也會以消極的方式影響另一個。例如，創(chuàng)建物化視圖會改善你的讀取性能，但會在數(shù)據(jù)庫服務(wù)器上增加額外的負(fù)載，可能會影響寫入性能。

我們使用的是哪個數(shù)據(jù)庫？?

另一個重要因素可能是我們正在使用的數(shù)據(jù)庫。每個數(shù)據(jù)庫都是為一個特定的使用情況而建立的。使用錯誤的數(shù)據(jù)庫類型會嚴(yán)重影響你的性能。

?例如，當(dāng)你想進(jìn)行分析性查詢時(shí)，使用Postgres這樣的關(guān)系型數(shù)據(jù)庫通常不是一個好的做法。雖然關(guān)系型數(shù)據(jù)庫可以執(zhí)行大量的分析功能，但它們在該領(lǐng)域的功能和性能比專門為這些類型的操作建立的數(shù)據(jù)庫（例如，Cassandra或Redshift）要有限得多。

很多數(shù)據(jù)庫都是為特定的問題而存在的，一般來說，它們在處理問題陳述時(shí)的表現(xiàn)會好很多。有一些數(shù)據(jù)庫用于搜索（例如ElasticSearch），用于地理空間數(shù)據(jù)（例如Neo4J），用于時(shí)間序列數(shù)據(jù)（例如Prometheus），用于存儲臨時(shí)數(shù)據(jù)（例如Redis或Memcached），等等。