關於處理大型數據庫，我需要知道些什麼？

Question

我想知道什麼具體問題/解決方案/建議/最佳做法[不要懲罰我這個詞]在處理大型數據庫時出現。

在巨大的我暗示數據庫，其中有數百萬行和/或數據庫與PB數據表的表。

面向平臺的答案也很棒。

Answer 1

一些想法

• 瞭解具體的數據庫引擎的細節，它是如何工作

• 如何優化查詢（提示，執行計劃）

• 如何調整數據庫（不僅是索引，還有物理存儲和表示，操作系統集成）。

• 查詢「技巧」之類的臨時表來存儲可重複使用的臨時結果，

• 如何評價非規範化的必要性性能改進

• 如何使用分析工具，數據庫，找出瓶頸。

Answer 2

如果RDBMS變得非常大，任何RDBMS都可能遭受較差的性能，尤其是在使用複雜的連接條件時。數據庫模式的設計也需要針對大量流量進行擴展。大多數系統在處理負載方面都非常出色，但如果有一個數據庫需要分佈在多臺計算機上，也可能遇到問題。

很多新的工具正在彈出來處理數據庫的可伸縮性。其中最有前途的是Memcached，它將大量數據存儲在內存中，從而可以更快速地訪問並幫助多個數據庫服務器之間的同步。一些NoSQL解決方案增強了傳統SQL系統的體​​繫結構，但不強制實施模式。

NoSQL技術的一些示例是Cassandra，CouchDB，Google BigTable和MongoDB。一些人發誓，這些系統將成爲管理「即將到來的數據爆炸」的關鍵。

Answer 3

我的第一個建議是聘請一個知道自己在做什麼而不依靠SO的人，否則你可能會遇到一些非常昂貴的錯誤。我的第二個將是選擇合適的平臺硬件和軟件。細節將取決於需求。

Answer 4

一對夫婦從生產DBA諮詢件（我的經驗是MS SQL，但這些應該適用於其他平臺）：

• 維護成爲顯著問題（夜間備份，DBCCs，每週重新索引/優化作業等）。很容易開始超出合理的夜間或週末維護窗口。這不僅僅是一個技術問題問題，它也是一個業務問題（「你是什麼意思，它將需要4個小時從最後一個良好的備份恢復數據庫？「）

• 開發人員需要了解他們可能需要以不同的方式工作。」你的意思是我不能只是DELETE (500m rows) FROM MassiveTable，並期望它工作？

我敢肯定，我會想更多...

Answer 5

強烈建議您閱讀本介紹有關SQL反模式 http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back

該報告將幫助（是的，它幫助我很多）找到了解決看似僵局的解決方案。

Answer 6

就設計和管理而言，數據庫有兩個方面比尺寸更重要。

首先是複雜性。有多少個用戶表？這些表中有多少列？在架構中有數百個用戶表的數據庫和這些表中的千列以上的數據庫非常複雜。具有六個表格的數據庫不是很複雜，即使它包含PB數據。

第二個是數據共享的範圍。如果數據庫被構建爲在六個或更多應用程序之間共享數據，由不同的編程團隊開發，那麼您應該設計和管理與嵌入單個應用程序的數據庫相比完全不同的數據庫。

SO中提到的大部分數據庫問題都與單個應用程序數據庫有關。

除了已經提到的內容之外，還有一些需要學習的東西。

瞭解表分區和表分解的區別。有些人將表分解成多個表，所有表都使用相同的列，分區會更好地爲他們提供服務。

瞭解數據的圖形模型和數據的關係模型之間的真正區別。有些人設計數據庫就好像外鍵本質上與指針一樣。他們最終得到的是一個系統，它捕捉關係系統的所有遲緩和圖表系統的所有不可管理性。

（注意：圖模型通常被稱爲分層或網絡模型）。設計一個真正的關係數據庫比設計一個僞裝成關係模型但實際上是圖模型的數據庫更加微妙，而且更值得一看。