Question

我正在寻找一个可以处理（在合理时间内在列上创建索引并在不到3秒内为选择查询提供结果）超过5亿行的数据库。低端机器（Core 2 CPU 6600,4GB，64位系统，Windows VISTA）上的Postgresql或Msql会处理如此大量的行吗？

更新：提出这个问题，我正在寻找我应该在低端机器上使用哪个数据库的信息，以便提供结果来选择在where子句中指定的一个或两个字段的问题。没有加入。我需要创建索引 - 它不能像mysql那样需要很长时间 - 来实现我的选择查询的足够性能。这台机器是一台进行实验的测试PC。

表架构：

 create table mapper {
        key VARCHAR(1000),
        attr1 VARCHAR (100),
        attr1 INT,
        attr2 INT,
        value VARCHAR (2000),
        PRIMARY KEY (key),
        INDEX (attr1), 
        INDEX (attr2)   
    }

Answer 1

MSSQL可以很好地处理那么多行。查询时间完全取决于更多因素，而不仅仅是简单的行数。

例如，它将取决于：

这些查询的加入次数
您的索引的设置情况
机器中有多少内存
处理器的速度和数量
硬盘的类型和主轴速度
查询中返回的行/数据量的大小
网络接口速度/延迟

很容易有一个小的（少于10,000行）表，这将花费几分钟来执行查询。例如，使用大量连接，where子句中的函数和Atom处理器上的零索引，总RAM为512MB。 ;）

确保所有索引和外键关系都很好，需要做更多工作，优化查询以消除不必要的函数调用，并仅返回实际需要的数据。此外，您还需要快速硬件。

这一切都归结为您想要花多少钱，开发团队的质量以及您正在处理的数据行的大小。

<强>更新由于问题的变化而更新。

此处的信息量仍然不足以给出真实世界的答案。您只需要测试它并根据需要调整数据库设计和硬件。

例如，我可以很容易地在具有这些规范的计算机上的表中有10亿行，并运行“从tableA（nolock）中选择top（1）id”查询并以毫秒为单位获得答案。出于同样的原因，您可以执行“select * from tablea”查询，这需要一段时间，因为尽管查询执行得很快，但通过网络传输所有数据需要一段时间。

重点是，你必须测试。这意味着，设置服务器，创建一些表，并填充它们。然后，您必须进行性能调整才能使您的查询和索引正确。作为性能调优的一部分，您不仅要了解查询需要如何重构，还要了解机器的哪些部分可能需要更换（即：磁盘，更多ram，cpu等）基于锁定并等待类型。

我强烈建议您雇用（或签约）一个或两个DBA为您执行此操作。

Answer 2

大多数数据库都可以处理这个问题，它是关于您将如何处理这些数据以及如何执行此操作。大量的RAM将有所帮助。

我会从PostgreSQL开始，它是免费的，对RAM没有限制（与SQL Server Express不同）并且没有许可证的潜在问题（处理器太多等）。但这也是我的工作：）

Answer 3

几乎每个非愚蠢的数据库都可以轻松处理十亿行。即使在32位系统上也可以实现5亿（尽管64位确实有帮助）。

主要问题是：

你需要有足够的内存。多少钱取决于您的查询。
您需要有足够好的光盘子系统。这意味着如果你想做大量的选择，那么对于一切来说，单个拼盘是完全不可能的。需要许多主轴（或SSD）来处理IO负载。

Postgres和Mysql都可以轻松处理5亿行。在适当的硬件上。

Answer 4

您要查看的是数据库软件强加的表大小限制。例如，在撰写本文时，MySQL InnoDB has a limit of 64 TB per table，而PostgreSQL has a limit of 32 TB per table;既不限制每个表的行数。如果配置正确，这些数据库系统应该无法处理数十或数百亿行（如果每行足够小），更不用说5亿行了。

为了获得处理极大量数据的最佳性能，您应该拥有足够的磁盘空间和良好的磁盘性能 - 这可以通过适当的RAID中的磁盘和大量内存以及快速处理器来实现（理想情况下）服务器级Intel Xeon或AMD Opteron处理器）。毋庸置疑，您还需要确保配置数据库系统以获得最佳性能，并确保表的索引正确。

Answer 5

以下文章讨论了在Microsoft SQL中导入和使用 16 十亿 行表。 http://sqlmag.com/t-sql/adventures-big-data-how-import-16-billion-rows-single-table

来自文章：

以下是我的经验中提炼的一些提示：

您在具有已定义聚簇索引的表中拥有的数据越多，   将未分类的记录导入其中会变慢。在某一点，   它变得太慢而不实用。如果要导出表格   到最小的文件，使其成为原生格式。这效果最好   表格主要包含数字列，因为它们更多   在二进制字段中紧凑地表示而不是字符数据。我摔倒   您的数据是字母数字，通过导出它不会获得太多收益   原生格式。不允许在数字字段中使用空值   压缩数据。如果允许字段可以为空，则为字段   二进制表示将包含一个1字节的前缀，表示多少   将跟随数据字节。您不能使用BCP超过   2,147,483,647条记录，因为BCP计数器变量是一个4字节   整数。我无法在MSDN上找到任何对此的引用   互联网。如果您的表包含超过2,147,483,647条记录，   你必须以块的形式导出它或编写自己的导出例程。   在预填充表上定义聚簇索引需要大量磁盘   空间。在我的测试中，我的日志爆炸到原始表大小的10倍   在完成之前。使用时导入大量记录时   BULK INSERT语句，包括BATCHSIZE参数并指定方式   一次提交许多记录。如果您不包含此参数，   您的整个文件作为单个事务导入，这需要一个   很多日志空间。使用a将数据放入表中的最快方法   聚集索引是首先预先排序数据。然后，您可以导入它   使用带有ORDER参数的BULK INSERT语句。

与多PB的纳斯达克OMX数据库相比，即便这样也很小，数据库在SQL Server上容纳了数十亿（数千TB）和数万亿行。

Answer 6

你看过Cassandra吗？ http://cassandra.apache.org/

Answer 7

如前所述，几乎所有DB都可以处理这种情况 - 你想要关注的是你的磁盘i / o子系统。您需要配置RAID 0或RAID 0 + 1情况，尽可能多地抛出问题。另外，将Log / Temp / Data逻辑驱动器分开以提高性能。

例如，假设您有12个驱动器 - 在您的RAID控制器中，我将创建3个RAID 0分区，每个分区包含4个驱动器。在Windows中（比方说）将每个组格式化为逻辑驱动器（G，H，I） - 现在在配置SQLServer时（假设）将tempdb分配给G，将日志文件分配给H，将数据文件分配给I。

Answer 8

我没有太多关于哪种系统最好使用的输入，但也许这个提示可以帮助您获得一些您正在寻找的速度。

如果您要进行长varchar字符串的精确匹配，特别是那些比索引允许的更长的字符串，您可以执行一种预先计算的哈希：

CREATE TABLE BigStrings (
   BigStringID int identity(1,1) NOT NULL PRIMARY KEY CLUSTERED,
   Value varchar(6000) NOT NULL,
   Chk AS (CHECKSUM(Value))
);
CREATE NONCLUSTERED INDEX IX_BigStrings_Chk ON BigStrings(Chk);

--Load 500 million rows in BigStrings

DECLARE @S varchar(6000);
SET @S = '6000-character-long string here';

-- nasty, slow table scan:
SELECT * FROM BigStrings WHERE Value = @S

-- super fast nonclustered seek followed by very fast clustered index range seek:
SELECT * FROM BigStrings WHERE Value = @S AND Chk = CHECKSUM(@S)

如果您没有进行完全匹配，这对您没有帮助，但在这种情况下，您可能会查看全文索引。这将真正改变5亿行表的查找速度。

Answer 9

我需要创建索引（不需要像mysql那样花费很多时间）来为我的选择查询提供足够的性能

我不确定“创建”索引是什么意思。这通常是一次性的事情。现在，通常在加载大量数据时，删除索引，加载数据，然后再添加索引，这样数据加载速度非常快。然后，当您对数据库进行更改时，将更新索引，但不一定需要在每次运行查询时创建它们。

也就是说，数据库确实有查询优化引擎，他们将分析您的查询并确定检索数据的最佳计划，并查看如何连接表（在您的方案中不相关）以及可用的索引您希望避免全表扫描，因此性能调整和查看查询计划非常重要，正如其他人已经指出的那样。

关于校验和的上述观点看起来很有趣，甚至可能是同一个表中attr1的索引。

可以处理> 5亿行的数据库

9 个答案: