SQL數據庫列中的數組 - 或 - 一個鍵/值noSQL存儲？

Question

我提前感謝你的時間。 您的經驗分享非常寶貴。

假設有4個用戶可以提交帖子並提升其他帖子的情況。 在數據庫中，從上述方法來看，查詢執行時間最好嗎？ 它是3列SQL數據庫還是2列NoSQL鍵/值存儲？

查詢的一個例子：獲得post_3的upvoters。

謝謝

第一種方法（例如MySQL）

第二種方法

編輯（僅基於John Tseng的回答）

create table post (post_id int, author_id int); create table upvote (user_id int, post_id int).

我應該得出這樣的結論：

2個表（= 3個讀取）是否比從php處理的一個表讀取長字符串更好？

我想要指出，在實施項目之前優化速度（或至少學習如何）是我覺得重要的事情。 我不希望我的桌子在未來成為TB並且表現緩慢，因為重新設計將是有風險的並且需要大量工作。 我害怕將一個大柱子從一張桌子移到另一張桌子上。 這就是為什么我花了很多時間為我的數據庫找到最好的設計，並從一開始就詢問是否使用鍵/值存儲是好的。 我是否會錯過理解鍵值存儲，是否在第一台機器上沒有使用它們。

The way you store your data is very important, and you should make it logical before optimizing for speed.

為什么不創建一個可以在未來輕松優化速度的邏輯設計？

從您寶貴的答案中我需要了解的是，SQL數據庫的良好設計是唯一需要和使用Key-Value存儲后會很容易的。

Answer 1

如果您要求查詢這一查詢的查詢執行時間，那么它肯定是只需要一次讀取的模式（第一種方法）。

但是，我不認為這是存儲數據的好方法。 如果有一天你想要查詢：用戶3是否支持用戶1的任何帖子怎么辦？

我會做兩張桌子：

create table post（post_id int，author_id int）; create table upvote（user_id int，post_id int）;

這將使您的示例查詢更慢，但我認為您不應該優化速度。 存儲數據的方式非常重要，您應該在優化速度之前使其成為邏輯。 您將擁有大量的方法來提高數據庫的速度， 而無需以奇怪的方式存儲數據。

當你每秒達到數千個請求時，你會想要做一些非規范化和NoSQL，但我認為你應該遠離初始設計中的那些東西。

當人們說NoSQL不能擴展時，它們意味着數據庫按TB的順序排列，請求數量級為每秒數千。 在幾年內，它們將意味着數十TB，每秒一萬次請求。 已經可以使關系數據庫使用非常強大的機器來處理數十TB和每秒一萬個請求。 幾年后它會更加實惠。

總之，在關系數據庫中進行初始設計，規范化所有教科書風格。 當您開始最大化RAM（在其他關系數據庫優化之后），那么您可以考慮這些問題。

編輯

對於這一個查詢，確實從表中讀取一行更快。 但是，良好的數據庫設計應該足夠靈活，以容納多個查詢，而不僅僅是一個。 在你的情況下，一旦你有成千上萬的追隨者甚至數百萬的贊成者，你將遇到一些嚴重的問題。 要修改單個upvote，您需要進行大量處理。 要查找任何單個更新，您需要解析整個字符串。

雖然我理解你一開始就想要優化速度的願望，但很多人的經驗表明，擁有邏輯代碼比純粹以性能指標為中心的代碼要好得多。 正如我們在這個簡短的例子中看到的那樣，因為你加快了這個查詢的速度，所以你大大減慢了其他查詢的速度。

此外，理解SQL結構要比NoSQL結構容易得多。 在學習NoSQL方法之前，你一定要學習SQL方法。 一個原因是NoSQL 不是 SQL，而且有很多選擇。

回到這個特定的查詢。 使用正確的索引，查詢將發出三次連續讀取，這將與單次讀取具有非常相似的性能。 我認為加快此查詢的正確方法不是以笨拙的方式將數據存儲在數據庫中，而是將尷尬的存儲留給緩存層。 您將在數據庫中查詢查詢的正確答案，然后將其存儲在緩存中。 每次后續讀取都將從緩存中獲取數據。 緩存將被非規范化，如：

key: Post_3_upvotes value: [1, 3]

這與將所有數據存儲在鍵/值存儲中的區別在於，將對關系數據庫進行修改，這將對修改很有幫助。 使用許多同時用戶修改鍵/值存儲將使您遇到比性能更大的問題。