我需要能够为数十亿条记录存储少量数据(大约50-75字节)(一年约30亿/月).
唯一的要求是对具有相同GUID的所有记录进行快速插入和快速查找,并且能够从.net访问数据存储.
我是一个SQL服务器人,我认为SQL Server 可以做到这一点,但随着所有关于BigTable,CouchDB和其他nosql解决方案的讨论,它听起来越来越像传统RDBS的替代品可能是最好的,因为优化分布式查询和扩展.我尝试了cassandra,.net库目前没有编译或者都可以更改(以及cassandra本身).
我已经研究了许多可用的nosql数据存储,但找不到满足我作为强大的生产就绪平台的需求.
如果你必须存储360亿个小而扁平的记录,以便它们可以从.net访问,那会选择什么以及为什么？
存储~3.5TB的数据并插入大约1K/sec 24x7,并且还以未指定的速率查询,可以使用SQL Server,但还有更多问题:
您有什么可用性要求？正常运行时间为99.999%,或者足够95%？
你有什么可靠性要求？缺少一个插页会花费你100美元吗？
你有什么可恢复性要求？如果您丢失一天的数据,这有关系吗？
你有什么一致性要求？是否需要保证在下次读取时可以看到写入？
如果您需要我强调的所有这些要求,那么您建议的负载将在关系系统,任何系统上花费数百万美元的硬件和许可,无论您尝试什么噱头(分片,分区等).根据他们的定义,nosql系统不能满足所有这些要求.
显然你已经放松了一些这些要求.有一个很好的视觉指南,比较了基于Visual Guide to NoSQL Systems的'pick 2 of 3'范例的nosql产品:
OP评论更新后
使用SQL Server,这将是直接实现:
一个单表聚类(GUID,时间)键.是的,将会变得支离破碎,但碎片会影响预读,只有大范围扫描才需要预读.由于您只查询特定的GUID和日期范围,因此碎片无关紧要.是的,是一个宽键,所以非叶页的密钥密度很低.是的,这会导致填充因子不佳.是的,可能会发生页面拆分.尽管有这些问题,但鉴于要求,仍然是最佳的集群关键选择.
按时间对表进行分区,以便通过自动滑动窗口实现有效删除过期记录.通过上个月的在线索引分区重建来增加此功能,以消除由GUID群集引入的不良填充因子和碎片.
启用页面压缩.由于首先是GUID的聚簇密钥组,因此GUID的所有记录将彼此相邻,从而使页面压缩很有可能部署字典压缩.
你需要一个快速的IO路径来存储日志文件.您对高吞吐量感兴趣,而不是日志的低延迟以保持1K插入/秒,因此剥离是必须的.
分区和页面压缩都需要企业版SQL Server,它们不能在标准版上运行,两者都非常重要,可以满足要求.
作为旁注,如果记录来自前端Web服务器场,我会将Express放在每个Web服务器上而不是后端的INSERT,我会SEND使用本地连接/事务将信息发送到后端在Express上与Web服务器位于同一位置.这为解决方案提供了更好的可用性故事.
这就是我在SQL Server中的表现.好消息是,您将面临的问题得到很好的理解,解决方案也是众所周知的.这并不一定意味着这比使用Cassandra,BigTable或Dynamo所能达到的要好.我会让一些人知道更多的东西,而不是sql-ish来论证他们的情况.
请注意,我从未提及编程模型,.Net支持等.老实说,我认为它们在大型部署中无关紧要.它们在开发过程中有很大的不同,但是一旦部署,开发的速度并不重要,如果ORM开销会导致性能下降:)
与流行的看法相反,NoSQL不是关于性能,甚至是可扩展性.它主要是关于最小化所谓的对象 - 关系阻抗不匹配,但也是关于水平可伸缩性与RDBMS 的更典型的垂直可伸缩性.
对于快速插入和快速查找的简单要求,几乎任何数据库产品都可以.如果要添加关系数据或联接,或者需要强制执行任何复杂的事务逻辑或约束,那么您需要一个关系数据库.没有NoSQL产品可以比较.
如果您需要无模式数据,那么您需要使用面向文档的数据库,例如MongoDB或CouchDB.松散的架构是这些的主要内容; 我个人喜欢MongoDB并在一些自定义报告系统中使用它.当数据要求不断变化时,我发现它非常有用.
另一个主要的NoSQL选项是分布式键值存储,例如BigTable或Cassandra.如果要在运行商用硬件的许多计算机上扩展数据库,这些特别有用.显然,它们在服务器上运行良好,但是没有利用高端硬件以及SQL Server或Oracle或其他专为垂直扩展而设计的数据库,显然,它们不是关系型的,并且不利于实现规范化或约束.此外,正如您所注意到的,.NET支持最多也是不稳定的.
所有关系数据库产品都支持有限排序的分区.它们不像BigTable或其他DKVS系统那样灵活,它们不容易在数百台服务器上进行分区,但它听起来并不像您正在寻找的那样.他们非常擅长处理数十亿的记录数,只要您正确地索引和规范化数据,在强大的硬件上运行数据库(特别是如果你能负担得起的SSD),并在2或3或5个物理磁盘上进行分区.必要.
如果您符合上述标准,如果您在公司环境中工作并且有资金用于合适的硬件和数据库优化,那么我现在就坚持使用SQL Server.如果您正在吝啬并且需要在低端的Amazon EC2云计算硬件上运行,那么您可能希望选择Cassandra或Voldemort(假设您可以使用.NET).
很少有人在数十亿行集大小的情况下工作,并且大多数时候我在堆栈溢出时看到这样的请求,数据不会接近报告的大小.
假设没有停机时间,每月约360亿,每月约30亿,每天大约1亿,每小时4.16万,每分钟约70,000行,每秒1.1千行进入系统,持续12个月.
这些数字并非不可能长期,我已经做了更大的系统,但你想要仔细检查这是你的意思 - 很少有应用真的有这个数量.
在存储/检索和非常重要的方面,你没有提到老化数据的老化 - 删除不是免费的.
正常的技术是分区,但是,基于GUID的查找/检索会导致性能不佳,假设您必须在整个12个月内获得每个匹配值.您可以在GUID列上放置聚簇索引,以使您的关联数据聚集为读/写,但是在这些数量和插入速度下,碎片将太高而无法支持,并且它将落在地板上.
如果这是一个具有OLTP类型响应速度的严重应用程序,我建议你需要一个非常不错的硬件预算,这是通过一些近似的猜测,假设很少的开销索引,大约2.7TB的数据.
在SQL Server阵营中,您可能想要查看的唯一内容是新的并行数据仓库版本(麦迪逊),其设计更多用于分离数据并对其运行并行查询以提供针对大型数据集市的高速度.
京公网安备 11010802040832号 | 京ICP备19059560号-6 