这些表对于SQL Server或Oracle来说太大了

Question

我不是一个数据库专家,所以我想要一些建议.

背景

我们有4个表当前存储在Sybase IQ中.我们目前没有任何选择,我们基本上坚持别人为我们决定的.Sybase IQ是一个面向列的数据库,非常适合数据仓库.不幸的是,我的项目需要进行大量的事务更新(我们更多的是一个操作数据库)所以我正在寻找更多的主流替代品.

题

1. 鉴于这些表的维度,有人会认为SQL Server或Oracle是一个可行的替代方案吗？

   • 表1:172列*32百万行
   • 表2:453列*700万行
   • 表3:112列*1300万行
   • 表4:147列*250万行

2. 鉴于数据的大小,在数据库选择,服务器配置,内存,平台等方面,我应该关注哪些事项？

Answer 1

是的,两者都应该能够处理你的表(如果你的服务器适合它).但是,我会考虑重新设计你的数据库.即使在您对数据进行非规范化的数据仓库中,包含453列的表也不正常.

Answer 2

这实际上取决于列中的内容.如果有很多大的VARCHAR列 - 并且它们经常被填充到接近容量 - 那么你可能会遇到一些问题.如果它是所有整数数据那么你应该没问题.

453 * 4 = 1812      # columns are 4 byte integers, row size is ~1.8k
453 * 255 = 115,515 # columns are VARCHAR(255), theoretical row size is ~112k

经验法则是行大小不应超过磁盘块大小,通常为8k.正如您所看到的,如果大表完全由4字节整数组成,但是如果它由255-char VARCHAR列组成,那么您的大表在这方面不是问题,那么您可能会大大超出限制.这个8k的限制曾经是SQL Server的硬限制,但我认为这些日子只是一个软限制和性能指南.

请注意,VARCHAR列不一定消耗与您为其指定的大小相称的内存.这是最大尺寸,但它们只消耗它们所需的量.如果VARCHAR列中的实际数据总是3-4个字符长,那么无论您是将它们创建为VARCHAR(4)还是VARCHAR(255),size都将与整数列的大小相似.

一般规则是您希望行大小较小,以便每个磁盘块有很多行,这样可以减少扫描表所需的磁盘读取次数.一旦你达到8k以上你就会每行读两次.

Oracle还有另一个潜在的问题,即ANSI连接对连接中所有表中的列总数有一个硬限制.您可以通过避免使用Oracle ANSI连接语法来避免这种情况.(有些等同物不会受到这个bug的影响.)我不记得限制是什么或它适用于哪个版本(我不认为它已被修复).

您正在谈论的行数应该没有问题,假设您有足够的硬件.