这些表对于SQL Server或Oracle是否太大

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

这真的取决于列中的内容。如果有很多大的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

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

一般规则是希望行大小较小,以便每个磁盘块有许多行,这样可以减少扫描表所需的磁盘读取次数。一旦超过8k,每行有两次读取。

Oracle还有一个潜在的问题,那就是ANSI联接对联接中所有表中的列总数有一个硬限制。您可以通过避免使用OracleANSI连接语法来避免这种情况(我不记得限制是什么,也不记得它适用于哪个版本(我认为它还没有被修复)。

假设您有足够的硬件,您正在谈论的行数应该不会有任何问题。

有了合适大小的硬件和I/O子系统来满足您的需求,这两个都是非常充分的—尽管您有很多列,但行数非常低—我们通常使用以数十亿而不是数百万表示的数据集(只是不要在SQL 2000上尝试它:))

Oracle 11g在此类数据和结构方面没有问题。

http://neworacledba.blogspot.com/2008/05/database-limits.html

当做

Oracle limitations

SQL Server limitations

此外,这些表足够大,因此硬件考虑是性能的一个主要问题。您需要一位经验丰富的DBA来帮助您使用RDBMS规范和设置服务器。正确配置磁盘子系统至关重要。您可能还需要考虑表分区以帮助性能,但这完全取决于如何使用数据。

1) 隔离实际更新的数据与或多或少只读(或不经常)的数据 4) 在必要时,使用内部联接连接到大表以检索数据。

正如其他人所指出的,您正试图让DB同时执行OLTP和OLAP,这是很困难的。对于这两种情况,服务器设置需要进行不同的调整。

SQL Server或Oracle都可以工作。我也使用普查数据,我的giganto表大约有300多列。我使用的是SQLServer2005,它抱怨说,如果所有列都被填充到它们的容量,它将超过记录的最大可能大小。我们以OLAP的方式使用人口普查数据,所以有这么多列也没什么大不了的。

应用程序是否更新了所有这些表中的所有列?

您可以考虑在白天更新数据集市(即操作或在线数据存储),然后将新记录迁移到主仓库中?我这么说是因为大量列的插入和更新速度会较慢,所以您可能需要考虑将特定的在线体系结构调整到应用程序的更新要求。

要求一个数据库同时充当操作和仓库系统仍然是一项艰巨的任务。我会考虑使用SQL Server或Oracle操作系统,并有一个单独的DW用于报告和分析,可能保持系统。

如果您需要对DW进行快速更新,您可以考虑 EP for ETL

考虑到您正处于这方面的早期阶段,请看看Microsoft project Madison ,这是一款可自动扩展的DW设备,最大容量为100s TB。他们已经运送了一些装置。

我会仔细考虑从面向列的数据库切换到关系型数据库。面向列的数据库确实不足以进行操作工作,因为更新速度非常慢,但它们足以提供报告和商业智能支持。

Sybase有一个名为RAP的产品,它将IQ与ASE(它们的关系数据库)的内存实例结合在一起,该实例旨在帮助解决此类情况。

你的数据不是那么大,以至于你不能考虑移动到一个面向行的数据库,但是,根据数据的结构,你可能会使用相当多的磁盘空间并减慢许多种类的查询。

免责声明:我确实为Sybase工作,但目前不在ASE/IQ/RAP端。