用于超快速查询的数据库

我们有一个300 Gb +数据数组，我们想尽可能快地查询。传统的SQL数据库（特别是SQL Server）不能像我们需要的那样有效地处理这个卷（比如，在少于10秒的时间内在where子句中使用10-20个条件执行select），所以我正在调查其他解决方案来解决这个问题。用于超快速查询的数据库

我一直在阅读有关NoSQL，这整个事情看起来很有希望，但我更愿意听到那些在现实生活中使用过它的人。

您能在这里建议什么？

编辑澄清我们之后。

我们是一家开发应用程序的公司，用户可以通过该应用程序搜索旅游行程并执行上述行程的预订，并使用塑料卡支付。这整件事肯定是俄罗斯特有的，所以请耐心等待。

当用户登录到该网站，她呈现类似下面的形式：

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

在这里，用户选择在那里，她从叶和她去，日期，时间和所有这一切。

点击“搜索”后，请求会发送到我们的数据库服务器，该服务器无法处理这种负载：查询包括各种参数。分片也不能很好地工作。

所以我所追求的是一种伪数据库，它可以做闪电般的查询。

来源

2010-02-09 Anton Gogolev

如果您添加一些关于域或您正在处理的数据和查询结构的信息，将会更容易提供有用的答案。 – nawroth 2010-02-09 18:20:50

嗨，我正面临类似的问题，你能告诉我你用什么来解决它吗？ – user902383 2016-11-21 20:36:42

@ user902383交换作业:)对不起。 – 2016-11-22 06:57:03

我不知道我会同意，传统的SQL数据库无法处理这些卷，我可以通过这些时间范围内更大的数据集查询，但它已被专门用来处理这种工作，并放在合适的硬件，特别是用于处理大量数据请求的IO子系统。

来源

2010-02-09 13:46:52 Andrew

这实际上取决于您在WHERE中拥有哪些条款以及您需要什么样的投影数据。

这可能足以在您的表上创建适当的索引。

此外，即使拥有最佳数据结构也没有用，因为如果您必须每个查询读取100GB，因为这也需要花费时间。

来源

2010-02-09 13:47:21

NoSQL，因为你可能已经读过，是不是关系数据库。

这是一个存储键值对的数据库，您可以使用专有的API进行遍历。

这意味着您需要自己定义数据的物理布局，以及进行任何代码优化。

我对此已经过时了，但几年前我参与了一个BerkeleyDB项目，处理的数据量略少但仍然很高（约为100Gb）。

这对我们的需要确定。

请注意，尽管对您而言可能很明显，查询可以进行优化。您可以发布您在此使用的查询吗？

来源

2010-02-09 13:48:23 Quassnoi

NoSQL只是一个营销术语，而不是数据库，甚至是一种数据库。 – 2016-04-07 23:05:33

如果您想对报告或分析进行临时查询，那么最好使用可与现成报告工具搭配使用的产品。否则，你可能会发现自己总是被拖出来写小报告程序来查询数据。这是对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 /秒的速度，并且无需诉诸真正特殊的硬件就可以做到这一点。

来源

2010-02-09 13:55:14 ConcernedOfTunbridgeWells

从我了解的很少，传统的RDBMS是基于行优化的插入速度。但是，基于列的存储系统可以最好地实现检索速度优化。

有关更详尽的说明，请参见Column oriented DBMS比我可以给

来源

2010-02-09 14:00:08

一个正确设置SQL服务器应该能够处理在T字节数据，而不必性能问题。我有几个管理SQl服务器数据库的朋友，他们的大小没有性能问题。

您的问题可能是一个或更多的这些：

不足的服务器规格
缺乏好的分区
可怜的索引
可怜的数据库设计
可怜的查询设计包括使用的像LINQ这样的工具可能会写表现不佳的代码为数据库大小。

它确实不是SQL Server处理这些负载的能力。如果你有一个数据库的规模，你需要聘请一个专业的dba，在优化大型系统方面有丰富的经验。

来源

2010-02-09 14:46:08 HLGEM

+1肯定需要员工/人员进行高端处理。 – Andrew 2010-02-09 15:05:19

我希望一个“常规”数据库可以做你想做的事情，只要你适当地为你正在做的查询构造你的数据。

您可能会发现，为了可生成报告，您需要汇总生成（或加载，转换等）数据并汇总汇总数据。

SELECT的速度与WHERE子句中的条件数（通常）无关（大多数情况下直接），但它与解释计划和检查的行数有关。有些工具会为你分析这个。最终，在300G（这不是那么大）时，您可能需要至少在某些时间将某些数据保留在磁盘上（=慢），因此您希望开始减少所需的IO操作数。减少IO操作可能意味着使用不同的聚簇索引来覆盖索引，汇总表和数据副本。这让你的300G变大了，但是谁在乎。

IO OPS是王:)

显然做这些事情是非常昂贵的开发时间方面，所以你应该在这个问题抛出大量硬件的启动，只有尝试与软件一旦修复变得不足。大量的RAM是一个开始（但它不能以当前的成本效益水平一次性存储> 10-20％的数据集）。即使SSD近来也不是那么昂贵。

来源

2010-02-10 07:50:36 MarkR

用于超快速查询的数据库

回答

相关问题