用于超快速查询的数据库

我们有一个300 Gb +数据阵列,我们希望尽快查询.传统的SQL数据库(特别是SQL Server)无法像我们需要的那样有效地处理这个卷(比如,在不到10秒的时间内执行条款中的select10-20条件where),所以我正在研究这个问题的其他解决方案.

我一直在阅读有关NoSQL的内容,这一切看起来很有希望,但我更愿意听听那些在现实生活中使用它的人.

你能在这里建议什么？

编辑澄清我们追求的目标.

我们是一家开发应用程序的公司,用户可以通过该应用程序搜索旅游并预订所述旅行团,并使用塑料卡付款.整个事情肯定是俄罗斯特定的,所以请耐心等待.

当用户登录该站点时,会向她显示与此类似的表单:

alt text http://queenbee.alponline.ru/searchform.png

在这里,用户选择她离开的地方和去往的地方,日期,持续时间等等.

点击"搜索"后,请求进入我们的数据库服务器,该服务器无法处理此类负载:查询包括各种参数.分片也不能很好地工作.

所以我所追求的是某种伪数据库,可以快速查询.

如果您想对报告或分析进行临时查询,那么最好使用可以与现成的报告工具很好地配合使用的东西.否则,您可能会发现自己一直被拖出来编写小报告程序来查询数据.这是对NoSQL类型数据库的攻击,但根据您的具体情况,它可能是也可能不是问题.

300GB不应超出现代RDBMS平台的能力,即使是MS SQL Server.此类型的大型数据库查询的其他一些选项是:

了解您是否可以使用SSAS多维数据集和聚合来缓解查询性能问题.基于使用情况的优化可以在不必使用其他数据库系统的情况下获得足够的性能.SSAS还可以在无共享配置中使用,允许您在具有直连磁盘的相对便宜的服务器群集中划分查询.如果你这样做的话,请看ProClarity的前端.

Sybase IQ是一个RDBMS平台,它使用为报告查询而优化的底层数据结构.它的优点是它可以与各种传统的报告工具很好地配合使用.存在这种类型的其他几种系统,例如Red Brick,Teradata或Greenplum(使用PostgreSQL的修改版本).对这些系统的主要打击是它们不是大众市场项目,而且可能非常昂贵.

Microsoft在管道中有一个无共享版本的SQL Server,您可以使用它.然而,他们已将其与第三方硬件制造商联系在一起,因此您只能使用专用(因此也很昂贵)的硬件.

寻找机会使用聚合数据构建数据集市,以减少某些查询的数量.

看看你的硬件调整.直接连接SAS阵列和RAID控制器可以非常快速地通过表扫描中使用的排序I/O. 如果您通过大量镜像对对表进行分区,则可以获得非常快的流式传输性能 - 轻松实现SAS通道的饱和.

实际上,如果您需要所描述的性能目标,那么您希望从I/O子系统获得10-20GB /秒的速度,并且可以在不使用真正奇特的硬件的情况下实现这一目标.

我不确定我会同意传统的SQL数据库无法处理这些卷,我可以在这些时间范围内查询更大的数据集,但它专门用于处理这类工作并放置在合适的硬件上,特别是IO子系统,旨在处理大型数据请求.

正确设置的SQL服务器应该能够处理terrabytes中的数据而不会出现性能问题.我有几个管理SQl Server数据库的朋友,这些数据库的大小没有性能问题.

您的问题可能是以下一种或多种:

服务器规格不足

缺乏良好的分区

索引不佳

数据库设计不佳

糟糕的查询设计,包括使用LINQ等工具,这些工具可能会为大小合适的数据库编写性能不佳的代码.

肯定不是SQL Server处理这些负载的能力.如果您有一个这样大小的数据库,您需要聘请具有优化大型系统经验的专业dba.

我希望"传统"数据库可以做你想要的,只要你为你正在进行的查询适当地构建数据.

您可能会发现,为了生成相应的报告,您需要在生成(或加载,转换等)数据时汇总数据并报告摘要数据.

SELECT的速度与WHERE子句(通常)中的条件数无关(在大多数情况下直接),但它与解释计划和检查的行数有关.有一些工具可以为您分析.

最终,在300G(这不是很大)你可能需要至少在某些时候将一些数据保存在光盘上(=慢速),这样你就可以开始减少所需的IO操作数量.减少IO操作可能意味着使用不同的聚簇索引覆盖索引,汇总表和数据副本.这使你的300G更大,但谁在乎.

IO操作是国王:)

显然,就开发人员的时间而言,做这些事情是非常昂贵的,所以你应该首先在问题上投入大量硬件,并且只有在软件不足时才尝试用软件修复它.大量的RAM是一个开始(但它不能以目前的成本效益水平一次存储> 10-20%的数据集)甚至SSD现在也不那么昂贵.