27

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

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

你可以在这里提出什么建议？

编辑以澄清我们所追求的。

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

当用户登录到该站点时，她会看到一个类似于此的表单：

替代文字 http://queenbee.alponline.ru/searchform.png

在这里，用户选择她从哪里离开和去哪里、日期、持续时间等等。

点击“搜索”后，一个请求会发送到我们的数据库服务器，该服务器无法处理此类负载：查询包含各种参数。分片也不好用。

所以我追求的是某种伪数据库，它可以进行闪电般的快速查询。

4

8 回答 8

19

如果您想对报告或分析进行临时查询，您最好使用可以与现成报告工具很好地配合使用的东西。否则，您可能会发现自己一直被拖到编写小的报告程序来查询数据。这是对 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-09T13:55:14.363 回答
16

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

于 2010-02-09T13:46:52.610 回答
14

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

您的问题可能是以下一项或多项：

  • 服务器规格不足
  • 缺乏良好的分区
  • 索引不佳
  • 糟糕的数据库设计
  • 糟糕的查询设计，包括使用诸如 LINQ 之类的工具，这些工具可能会为这种大小的数据库编写性能不佳的代码。

它肯定不是 SQL Server 处理这些负载的能力。如果您有这么大的数据库，则需要聘请具有优化大型系统经验的专业 dba。

于 2010-02-09T14:46:08.847 回答
6

我希望“传统”数据库可以做你想做的事，只要你为你正在做的查询适当地构建你的数据。

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

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

最终，在 300G（不是那么大）的情况下，您可能需要至少在某些时候将一些数据保留在磁盘上（=慢速），以便开始减少所需的 IO 操作数量。减少 IO 操作可能意味着使用不同的聚集索引来覆盖索引、汇总表和数据副本。这会让你的 300G 更大，但谁在乎呢。

IO 操作为王 :)

显然，就开发人员的时间而言，做这些事情是非常昂贵的，因此您应该首先投入大量硬件来解决问题，并且只有在不够用时才尝试用软件修复它。大量 RAM 是一个开始（但它无法以当前的成本效益水平一次存储超过 10-20% 的数据集）即使 SSD 现在也不是那么昂贵。

于 2010-02-10T07:50:36.117 回答
3

这实际上取决于您在 WHERE 中有哪些子句以及您需要对数据进行什么样的投影。

在您的表上创建适当的索引可能就足够了。

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

于 2010-02-09T13:47:21.533 回答
3

据我所知，传统的 RDBMS 是基于行的，可以优化插入速度。但检索速度优化最好通过基于列的存储系统来实现。

请参阅面向列的 DBMS以获得比我能给出的更全面的解释

于 2010-02-09T14:00:08.340 回答
2

NoSQL，正如您可能已经阅读的那样，它不是关系数据库。

它是一个存储键值对的数据库，您可以使用专有的API.

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

我在这方面已经过时了，但几年前我参与了一个BerkeleyDB处理稍微少一点但仍然大量数据的项目（大约100Gb）。

完全可以满足我们的需求。

另请注意，尽管对您来说似乎很明显，查询可以优化。您能否在此处发布您使用的查询？

于 2010-02-09T13:48:23.813 回答
1

试试Clickhouse，它的基准测试结果在大多数情况下甚至在 MemSQL 中都更快，但您无法更新记录，只能插入/删除

于 2019-04-25T15:08:16.173 回答