处理样本而不是整个数据库

我想知道创建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进行采样。

一个好的做法是拥有一个空的数据库。然后，有可以发出一系列插入来加载示例数据的脚本。然后，任何开发人员都可以拥有自己的示例数据库来处理他的代码。 –

我永远不会做你正在考虑的事情。我会添加一个索引到我在where子句中使用的字段。另外，对于您的具体示例，我会在where子句中添加日期范围。 –

好的做法是使用正确的工具。大多数关系型数据库在进行在线事务处理（OLTP）时都非常擅长，因为它们的发展主要是为了在上世纪80年代和90年代解决这个问题。像你提出的查询是一种不同的类型，他们是分析查询（OLAP）。要运行分析工作负载，有更好的工具。

Columnstores是更适合分析处理的工具的主要示例，而今天几乎所有平台都有列存储引擎。

在内存引擎如SQL Server Analysis Services是另一种方法。

或者完全抛弃数据库，只处理Hadoop中的Web日志进行分析。

问题是，为您的“产品”和提供另一个OLAP系统用于分析洞察力的OLTP系统存在问题。当然，您可以设置一个ETL过程来保持OLAP系统的最新状态，但并不容易。

它的要点在于，您有两个相互矛盾的力量将系统撕裂：OLTP对服务页面的要求与OLAP对您的分析的要求。你不会找到'一刀切'的答案，任何试图解决这两个问题的单一系统都将是一个妥协，这里有基本面。

因此，短时间内，您可能获得WEBSITE_TRAFFIC适当指数的一些里程。您可以进行一些预先聚合和分段，批量更新和一些延迟。但没有银弹，答案很简单。

2014-01-10 18:05:47

感谢您的回答。我根本不是技术人员，我不决定使用哪种工具。我只是使用数据库上传数据并进行统计分析。有时他们问我，我们的客户中有哪些人这样做，抽样似乎是加速查询的好方法，但似乎没有人这样做，所以对我来说这看起来是错误的做法。 – user3178882

回答