處理樣本而不是整個數據庫

Question

我想知道創建CUSTOMER_RANDOM_VALUE（0到100之間）是否常見，以便處理隨機樣本而不是整個數據庫。

我們舉一個例子：管理Webstore的CDW並使用增量CustomerID。

如果你想知道誰訪問特定產品的頁面的用戶數的，你需要做的是：

SELECT COUNT(DISTINCT CUSTOMER_ID) 
FROM WEBSITE_TRAFFIC 
WHERE PRODUCT_KEY= 134 

問題是這樣的表是如此巨大，這可能需要1小時就知道這一點，你必須整天回答很多這類問題。

爲什麼不爲每個客戶創建一個random_value：

Customer_Id | Random Value 
1    13 
2    41 
3    8 
4    87 

和1％這樣的一個樣本工作：

SELECT COUNT(DISTINCT CUSTOMER_ID) 
FROM WEBSITE_TRAFFIC 
WHERE PRODUCT_KEY= 134 
AND CUSTOMER_RANDOM_VALUE<1 

問題：它是一個共同的初步實踐時數據量很大，要使用CUSTOMER_RANDOM_VALUE進行採樣。

Answer 1

好的做法是使用正確的工具。大多數關係型數據庫在進行在線事務處理（OLTP）時都非常擅長，因爲它們的發展主要是爲了在上世紀80年代和90年代解決這個問題。像你提出的查詢是一種不同的類型，他們是分析查詢（OLAP）。要運行分析工作負載，有更好的工具。

Columnstores是更適合分析處理的工具的主要示例，而今天幾乎所有平臺都有列存儲引擎。

在內存引擎如SQL Server Analysis Services是另一種方法。

或者完全拋棄數據庫，只處理Hadoop中的Web日誌進行分析。

問題是，爲您的「產品」和提供另一個OLAP系統用於分析洞察力的OLTP系統存在問題。當然，您可以設置一個ETL過程來保持OLAP系統的最新狀態，但並不容易。

它的要點在於，您有兩個相互矛盾的力量將系統撕裂：OLTP對服務頁面的要求與OLAP對您的分析的要求。你不會找到'一刀切'的答案，任何試圖解決這兩個問題的單一系統都將是一個妥協，這裏有基本面。

因此，短時間內，您可能獲得WEBSITE_TRAFFIC適當指數的一些里程。您可以進行一些預先聚合和分段，批量更新和一些延遲。但沒有銀彈，答案很簡單。