可处理> 5亿行的数据库

Ska*_*rab 42 database sql-server postgresql

我正在寻找一个可以处理(在合理的时间内在列上创建索引并在不到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)   
    }
Run Code Online (Sandbox Code Playgroud)

Not*_*tMe 52

MSSQL可以很好地处理那么多行.查询时间完全取决于比简单行计数更多的因素.

例如,它将取决于:

  1. 这些查询有多少次加入
  2. 您的索引设置得如何
  3. 机器里有多少内存
  4. 速度和处理器数量
  5. 硬盘的类型和主轴速度
  6. 查询中返回的行/数据量的大小
  7. 网络接口速度/延迟

拥有一个小的(少于10,000行)表可能需要几分钟才能执行查询.例如,使用大量连接,where子句中的函数和Atom处理器上的零索引,总RAM为512MB.;)

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

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

UPDATE 更新由于问题的变化.

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

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

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

我强烈建议您雇用(或签约)一个或两个DBA为您执行此操作.

  • @alci:最初的问题是"Msql".(注意缺少的第二个字母,它会定义它)我最初读这个MSsql而不是MySQL因为它被标记为"sql-server"; 这是微软产品的标签,因此呼吁微软的数据库服务器.在事实上他实际上使用了"mysql"这个词之后的评论中.因此,在发布此答案时,OP使用的实际DB服务器并不清楚. (3认同)

Fra*_*ens 23

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

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


小智 9

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

主要问题是:

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

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


bwD*_*aco 8

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

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


Cha*_*rns 5

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

来自文章:

以下是我的一些经验提炼:

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

与数PB的纳斯达克OMX数据库相比,即便这样也很小,数据库在SQL Server上容纳了数十亿(数千TB)和数万亿行.