我不是一个数据库专家，所以我想要一些建议。
背景
我们有4个表当前存储在Sybase IQ中。我们目前没有任何选择，我们基本上坚持别人为我们决定的。 Sybase IQ是一个面向列的数据库，非常适合数据仓库。不幸的是，我的项目需要进行大量的事务更新（我们更多的是一个操作数据库）所以我正在寻找更多的主流替代品。
问题
鉴于这些表的维度，有人会认为SQL Server或Oracle是一个可行的替代方案吗？
鉴于数据的大小，在数据库选择，服务器配置，内存，平台等方面我应该关注哪些事项？
答案 0 :(得分：7)
是的，两者都应该能够处理你的表（如果你的服务器适合它）。但是，我会考虑重新设计你的数据库。即使在您对数据进行非规范化的数据仓库中，包含453列的表也不正常。
答案 1 :(得分：5)
这实际上取决于列中的内容。如果有很多大的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），大小都将类似于整数列。
一般规则是您希望行大小较小，以便每个磁盘块有很多行，这样可以减少扫描表所需的磁盘读取次数。一旦你达到8k以上，你就会每行读两次。
Oracle还有另一个潜在的问题，即ANSI连接对连接中所有表中的总列数有一个硬限制。您可以通过避免使用Oracle ANSI连接语法来避免这种情况。 （有些等同物不会受到这个bug的影响。）我不记得限制是什么或它适用的版本（我认为它还没有修复）。
你所谈论的行数应该没问题，假设你有足够的硬件。
答案 2 :(得分：2)
使用合适大小的硬件和I / O子系统来满足您的需求两者都非常充足 - 您可以使用很多列，行数非常低 - 我们会定期使用数十亿而非数百万的数据集。 （只是不要在SQL 2000上试试:)）
如果您了解自己的用法和I / O要求，大多数I / O供应商都会将其转换为硬件规格。内存，处理器等再次依赖于只有你可以建模的工作负载。
答案 3 :(得分：1)
答案 4 :(得分：1)
您可能在SQL Server上很近，具体取决于您在该453列表中的数据类型（请注意每行的字节数限制，但也请阅读脚注）。我知道你说这是标准化的，但我建议查看你的工作流程并考虑减少列数的方法。
此外，这些表格足够大，以至于硬件考虑因素是性能的主要问题。您需要一位经验丰富的DBA来帮助您使用RDBMS来规范和设置服务器。正确配置磁盘子系统至关重要。您可能还需要考虑表分区以及其他方面以帮助提高性能，但这完全取决于数据的使用方式。
答案 5 :(得分：1)
根据您在其他答案中的评论，我认为我建议的是：
1）隔离实际更新的数据与哪些数据或多或少只读（或不经常） 2）将更新的数据移动到将id连接到较大表的单独表（从大表中删除这些列） 3）针对较小的，更多的关系表执行OLTP事务 4）使用内部联接钩回大表以在必要时检索数据。
正如其他人所指出的那样，您正在尝试让DB同时执行OLTP和OLAP，这很困难。对于任一情况，服务器设置都需要以不同方式进行调整。
SQL Server或Oracle都可以运行。我也使用人口普查数据，我的giganto表有大约300多列。我使用SQL Server 2005并且它抱怨如果所有列都要填充到它们的容量，它将超过记录的最大可能大小。我们以OLAP方式使用我们的人口普查数据，因此拥有如此多的列并不是什么大问题。
答案 6 :(得分：0)
您的应用程序是否更新了所有这些表中的所有列？
您可以考虑在白天更新数据集市（AKA运营或在线数据存储），然后在晚上将新记录迁移到主仓库吗？我之所以这么说是因为插入和更新大量列的行会更慢，因此您可能需要考虑根据应用程序的更新要求定制特定的在线体系结构。
答案 7 :(得分：0)
要求一个DB同时充当操作和仓库系统仍然是一个很高的订单。我会考虑将SQL服务器或Oracle用于操作系统，并使用单独的DW进行报告和分析，这可能会保留您的系统。
预计会在操作方面进行一些表格重新设计和规范化，以适应每行一行的基于行的存储限制。
如果您需要快速更新DW，可以考虑 EP for ETL 方法，而不是标准（预定）ETL。
考虑到您处于早期阶段，请查看Microsoft project Madison ，这是可自动扩展的DW设备，最高可达100 TB。他们已经安装了一些装置。
答案 8 :(得分：0)
我会非常仔细地考虑从面向列的数据库切换到关系数据库。面向列的数据库确实不适合运营工作，因为更新速度很慢，但它们足以支持报告和商业智能支持。
通常，必须将操作工作拆分为包含操作所需的当前活动（帐户，库存等）的OLTP数据库，并使用ETL过程填充数据仓库（历史记录，趋势）。面向列的DW几乎可以在任何情况下击败关系，因此我不会轻易放弃Sybase IQ。也许您可以使用您选择的关系产品来设计系统以使操作OLTP端（我会选择SQL Server，但我有偏见）并保留您现在拥有的OLAP部分。
答案 9 :(得分：0)
Sybase有一个名为RAP的产品，它将IQ与内存中的ASE实例（它们的关系数据库）相结合，旨在帮助解决此类问题。
您的数据不是很大，以至于您无法考虑迁移到面向行的数据库，但是，根据数据的结构，您最终可能会占用更多磁盘空间并减慢多种查询速度。
免责声明：我为Sybase工作，但目前不在ASE / IQ / RAP方面工作。