高效Ad-hoc SQL OLAP結構

Question

多年來，我已閱讀了很多人關於如何從SQL（Microsoft SQL Server，只是讓我們都在同一頁面上）獲得更好性能的意見......查詢。但是，它們似乎都與高性能OLTP安裝程序或數據倉庫OLAP安裝程序（立方體 - 豐滿...）緊密相關。但是，我今天的情況是在2中間，因此我的優柔寡斷。

我有[Contacts]，[Sites]，[SiteContacts]（[Sites]和[Contacts]）的聯結表，[SiteTraits]和[ContractTraits]的一般數據庫結構。我與接觸者有約50個聯繫人（在[聯繫人]和[ContactTraits]之間）約50萬個聯繫人，以及約60個與約150個聯繫點相關的站點（大約150個字段（[站點]和[SiteTraits之間]） 。基本上這是一個相當大的扁平表或視圖......大多數列是INT，位，CHAR（3），或短VARCHAR（S）。我的問題是，這些列中的很大一部分可用於用戶的即席查詢，並儘可能快地進行，因爲用於此的主UI將成爲網站。我知道最常用的過濾器，但即使對它們進行了大量索引，我認爲這仍然是一個野獸......這些數據是隻讀的，數據在一天中根本不會改變，數據庫只會在預定的停機時間內刷新最新信息。所以我看到這種情況就像一個OLAP數據庫，它具有OLTP數據庫的讀取需求。

我看到3個選項; 1.將表格拆分成更小的可分割單元子查詢所有內容，2.製作一張平坦的表格，然後真正到達索引的城鎮3.創建一個OLAP多維數據集，然後根據我沒有放入的過濾器值對其餘的子查詢作爲立方體尺寸，和。我對OLAP多維數據集並沒有做太多的工作，所以我坦白地不知道這是否是一種選擇，但是從我過去與他們做的事情來看，我認爲這可能是一種選擇。另外，爲了澄清我說的「子查詢所有內容」的含義，而不是在外部選擇上有一個WHERE子句，那麼每個表被引入到查詢中都會有一個（如果適用），然後這些表是INNER JOINed，消除一個非常大的笛卡爾積。至於這個大表的第二個選項，我聽到並且看到了與該方法相沖突的結果，因爲它將節省連接，但同時表掃描需要更長的時間。

想法任何人？我需要分享我正在吸菸嗎？如果每個人都投入2美分，我認爲這可能會變成一個非常好的討論。哦，並且隨時告訴我，如果我是基於OLAP立方體的想法，如果是這樣的話，我也是新手。

在此先感謝任何和所有的意見，並與這種困境，我發現自己的幫助。

Answer 1

你可能要考慮這是一個關係型數據倉庫。您可以將關係數據庫表設計爲星型模式（或雪花模式）。此設計與OLAP多維數據集邏輯結構非常相似，但物理結構位於關係數據庫中。

在星型模式中，您將擁有一個或多個事實表，這些事實表代表某種事務，並且通常與日期相關聯。但我不確定在這種情況下交易可能是什麼。事實可能是網站與聯繫人和表格的關聯。

事實表將引用維度表，它描述了事實。維度可能是網站和聯繫人。維度包含屬性，例如聯繫人姓名，聯繫地址等。如果您熟悉OLAP多維數據集，那麼這將是一個熟悉的邏輯體系結構。

將大量索引添加到您的架構不會是一個非常大的問題。除刷新時間外，數據庫大部分是隻讀的。更新索引時，您不必擔心讀取性能。所以，架構可以容納所有需要的索引（只要您可以投入足夠的停機時間來刷新數據）。

Answer 2

我同意bobs的答案：拋出一個OLAP前端並通過多維數據集進行查詢。之所以這會是一個好的想法，是因爲多維數據集在多維查詢（通常是預先計算）聚合時非常高效，並且它們以面向列的格式存儲數據，這種數據分析更有效。

多維數據集下的關係數據對於詳細鑽取以查找給出某個合計值的單個事實非常有用。但直接查詢關係數據總是會很慢，因爲那些聚合用戶對分析感興趣只能通過掃描大量數據來產生。 OLAP在這方面只是更好。

Answer 3

對於聚合查詢，OLAP/SSAS非常有效，而對於我的體驗來說，對於粒度數​​據來說不是那麼多。

什麼是最常見的查詢？對於單件數據或聚合？

Answer 4

如果SiteContacts的粒度與聯繫人的粒度非常接近（即大約300萬條記錄 - 大多數聯繫人僅與單個站點關聯），則可以從單個表中獲得最佳性能指標，顯然;分區也應該考慮）。另一方面，如果大多數聯繫人都與許多站點相關聯，則最好使用與當前架構接近的東西。

OLAP傾向於在彙總數據上產生最佳結果 - 聽起來好像對這些數據進行的彙總相對較少。

星形模式由尺寸懸置的事實表組成 - 取決於站點和聯繫人之間的關係，它聽起來好像您擁有一個巨大的維度表，或者兩個大型維度包含一個無事實的事實表（聽起來像是矛盾論，但在Kimball的方法論中有所描述）將它們聯繫起來。