4

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

我将存储的数据是

  • 约会时间
  • IP地址
  • 链接ID
  • 可能是其他与字符串相关的数据

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

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

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

编辑：它将基于云。因此，我一直在研究我已经广泛使用的 SQL Azure，但是随着行数的增加，它开始引起问题。

4

2 回答 2

4

由于您正在寻找一般指导，我觉得可以提供一个您过早驳回的答案;-)。Microsoft SQL Server 绝对可以处理这种情况（一般意义上的拥有这些字段和数十亿行的表）。我亲自研究过一个有 4 个节点的数据仓库，每个节点都有一个主事实表，其中包含 1.2 到 15 亿行（并且还在增长）并且对查询的响应速度足够快，尽管数据模型和索引的某些方面可能有做得更好。它是一个基于 Web 的应用程序，许多用户整天都在使用它（尽管一天中的某些时段比其他时段更难）。此外，该事实表比您描述的表要宽得多，除非“可能是其他与字符串相关的数据” 相当大（但也有一些方法可以正确建模）。诚然，免费的 Express 版可能无法满足您的需求，但 Standard Edition 可能会满足您的需求，而且价格也不是很贵。企业有一个很好的功能来进行在线索引重建，但仅凭这一点可能无法保证许可费用的大幅上涨。

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

祝你好运 ：）

编辑：

  • 当我（上面）说查询“足够快”返回时，我的意思是 1 到 90 秒，具体取决于各种因素。请记住，这些不是简单的查询，在我看来，可以对数据建模和索引策略进行一些改进。
  • 我故意省略了表分区功能，不仅因为它仅在企业版中提供，而且因为它更容易被误解，因此被误用，而不是被正确理解和使用。SQL Server 中的表/索引分区不是“分片”的一种方式。
  • 我也没有提到列存储索引，因为它们仅在企业版中可用。然而，对于大到足以证明成本合理的项目，列存储索引当然值得研究。它们是在 SQL Server 2012 中引入的，并带有一旦创建列存储索引就无法更新表的限制。在某种程度上，您可以使用表分区来解决这个问题，但在 SQL Server 2014 中，该限制将被删除。
于 2013-11-03T05:44:42.733 回答
1

鉴于这需要基于云并且您使用.Net / C#，如果您真的只是在谈论几个表（到目前为止，只是陈述的一个和隐含的“链接”表——LinkID 的来源），因此可能不需要关系或其他一些 RDBMS 功能，那么一种选择是使用 Amazon 的 DynamoDB。DynamoDB 是 AWS（亚马逊网络服务）的一部分，是一个 NoSQL 数据库。他们的低端免费层使开发甚至推出项目的初始阶段变得更加容易。截至 2013 年 11 月 4 日，DynamoDB 主页面指出：

AWS 免费套餐包括 100MB 存储、5 个写入容量单位和 10 个 Amazon DynamoDB 读取容量单位。

这是一些文档：概述、如何使用 .Net 查询和通用 .Net SDK。

请注意：在调查您认为它可能花费多少时，请务必包括相关的 AWS 部分，例如网络使用情况等。

于 2013-11-04T21:11:50.843 回答