存储大量分析数据

Question

我通常在我所做的所有项目中都使用SQL Server和C＃，但是我正在研究一个可能跨越数十亿行数据的项目，我觉得在SQL Server中这样做并不舒服。

我将存储的数据是

• datetime
• ipAddress
• linkId
• 可能是其他字符串相关数据

我之前只处理过关系数据库，因此正在寻找关于哪种数据库技术最适合此类数据存储的一些指导。可以扩展并以低成本进行扩展（与分片SQL Server相比）

然后我需要根据linkId提取这些数据。

我还可以在查询中对数据库进行排序，还是最好在应用程序中完成？

编辑：这将是基于云的。因此，我正在研究SQL Azure，我已广泛使用它，但它只是在行数增加时才开始引起问题。

Answer 1

由于您正在寻找一般性指导，我觉得可以提供您过早被解雇的答案;-)。 Microsoft SQL Server绝对可以处理这种情况（通常意义上有这些字段和数十亿行的表）。我个人在一个有4个节点的数据仓库上工作，每个节点的主事实表都有1.2到15亿行（并且还在增长），并且对查询的响应速度很快，尽管数据模型和索引的某些方面可能有做得更好。它是一个基于Web的应用程序，许多用户整天都在使用它（尽管一天中的某些时段比其他时段更难）。此外，该事实表比您描述的表宽得多，除非“可能其他字符串相关数据”相当大（但也有方法正确建模）。没错，免费的Express版本可能无法满足您的需求，但标准版可能会这样，并且它不会超级昂贵。企业有一个很好的功能来进行在线索引重建，但仅此一点可能无法保证许可证费用的大幅增加。

请记住，对于使用此数据实际尝试完成的内容几乎没有描述，我很难说MS SQL Server肯定会满足您的需求。但是，鉴于您似乎完全基于您可能获得的大量行来排除它，我至少可以说明这种情况：良好的数据建模，良好的索引设计和定期索引维护，MS SQL Server绝对可以处理数十亿行。现在，它是否是您项目的最佳选择取决于您要做的事情，客户对维护的满意程度等等。

祝你好运：）

编辑：

• 当我说（上面）查询“足够快”回来时，我 意味着1到90秒，取决于各种因素。 请记住，这些不是简单的查询，在我看来， 可以对数据建模和索引进行一些改进 策略。
• 我故意遗漏了表格分区功能 因为它只在企业版中，但也因为它更多 经常被误解，因而被滥用而不是理解和使用 正常。 SQL Server中的表/索引分区是不是的一种方法 “分片”。
• 我也没有提到Column Store索引，因为它们只是 企业版中提供。但是，对于足够大的项目 为证明成本合理，Column Store索引当然值得 调查。它们是在SQL Server 2012中引入的 列无法更新表的限制 存储索引已创建。你可以在一定程度上解决这个问题 表分区，但在SQL Server 2014中将受到限制 除去。

Answer 2

鉴于这需要基于云并且您使用.Net / C＃，如果您真的只是谈论几个表（到目前为止只是所述的表和隐含的“链接”表 - LinkID的来源）因此可能不需要关系或某些其他RDBMS功能，然后一个选项是使用亚马逊的DynamoDB。 DynamoDB是AWS（Amazon Web Services）的一部分，是NoSQL数据库。开发甚至是推出项目的初始阶段，它们的低端免费等级更容易实现。截至2013-11-04，主要的DynamoDB页面指出：

  

AWS免费套餐包括100MB存储空间，5个写入容量单位，   Amazon DynamoDB提供10个读取容量单位。

以下是一些文档：Overview，How to Query with .Net和general .Net SDK。

请注意：在考虑您认为可能需要多少费用时，请确保包含相关的AWS部分，例如网络使用情况等。