这些表对于 SQL Server 或 Oracle 来说是否太大？答案

【问题标题】：Are these tables too big for SQL Server or Oracle这些表对于 SQL Server 或 Oracle 来说是否太大？
【发布时间】：2010-12-20 17:38:15
【问题描述】：

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

背景

我们有 4 个表当前存储在 Sybase IQ 中。我们目前对此没有任何选择，我们基本上被其他人为我们决定的事情所困扰。 Sybase IQ 是一个面向列的数据库，非常适合数据仓库。不幸的是，我的项目需要进行大量事务更新（我们更像是一个操作数据库），所以我正在寻找更主流的替代方案。

问题

鉴于这些表的维度，有人会认为 SQL Server 或 Oracle 是可行的替代方案吗？
- 表 1：172 列 * 3200 万行
- 表 2：453 列 * 700 万行
- 表 3：112 列 * 1300 万行
- 表 4：147 列 * 250 万行
考虑到数据的大小，在数据库选择、服务器配置、内存、平台等方面我应该关注哪些方面？

【问题讨论】：

为什么你有一个有 453 列的表？你的桌子标准化了吗？可以进一步规范化吗？
@Dominic - 因为 Jeffrey 的数据库使用的是“面向列的数据库”的 Sybase IQ。面向列的数据库的要点是它们拒绝“规范化”的整个概念。至少是关系数据库中所理解的规范化。
明确一点 - 您是否希望将现有架构移植到新数据库？如果是这样，为什么？如果您遇到 OLTP 问题，则很可能是表设计问题，而不是 DBMS 产品本身。如果您提供更多背景信息，我们可以为您提供更好的建议。具体来说，您遇到了什么问题？您希望从迁移到 Oracle 或 MSSQL 中获得哪些优势？
@APC - 啊，谢谢。永远不会遇到 Sybase IQ。以后不知道自己在说什么的时候要学会闭嘴！ ;)
@APC - Sybase IQ 存在许多不同的问题，主要是缺乏围绕该工具的工具。我们需要使用 ADO.Net 数据提供程序（作为一个充满错误的事后才提供），我们需要高效的软件来管理数据库（Sybase Central 咬），因为它是一个“边缘”数据库，它的支持比其他数据库少数据库，在我工作的地方几乎没有一个支持社区，等等。最重要的是：我们不只是加载数据库并以恶心的方式查询它，我们在 9 个月的时间里不断更新它，而且更新缓慢而笨拙.

标签： sql-server performance oracle sap-iq

【解决方案1】：

使用合适大小的硬件和 I/O 子系统来满足您的需求，两者都足够了 - 如果您有很多列，那么行数确实非常低 - 我们经常使用以十亿而不是数百万表示的数据集。（只是不要在 SQL 2000 上尝试 :)）

如果您了解自己的用途和 I/O 要求，大多数 I/O 供应商都会为您将其转化为硬件规格。内存、处理器等再次取决于只有您可以建模的工作负载。

【讨论】：

谢谢，我认为工作量有点主观，但还是把它扔在那里......以防万一！

【解决方案2】：

是的，两者都应该能够处理您的表格（如果您的服务器适合它）。但是，我会考虑重新设计您的数据库。即使在您对数据进行非规范化的数据仓库中，具有 453 列的表也不正常。

【讨论】：

信不信由你数据被标准化！这是人口普查数据，例如，表示人的表格有很多关于人的变量。我们确实会根据特定主题（在其他表格中）进一步细分数据，但这对我们来说并不总是一目了然。不过感谢您的建议！
对于像 Sybase IQ 这样的面向列的数据库，这不是问题。
这是一个“经验法则”（因此：总是有例外，例如可能是 Cameron 的情况），如果您的表有这么多列（例如 >30），那么它可能代表不止一种类型的实体.例如，在人口普查数据中，我想知道是否所有这些列对于每个人来说都是非空的？也许有一些列不适用的人的子集？如果是这样，这些可以移动到单独的表中。我不是说这必须发生，只是一个建议。
@JeffreyKemp：我们确实区分了获得长表和短表并为此拥有两个“人”数据库（453 和 172 列表）的人，并对家庭做同样的事情（其余两张表）。这可以防止所有值出现空值。不管你信不信，在处理结束时，这些细胞中的每一个都有一些东西！

【解决方案3】：

Oracle 11g 对这样的数据和结构没有任何问题。

问候。

【讨论】：

【解决方案4】：

这实际上取决于列中的内容。如果有很多大的 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 个字符的 VARCHAR 列组成，那么您的大表在这方面不是问题，那么您可能会大大超出限制。这个 8k 限制曾经是 SQL Server 中的硬限制，但我认为现在它只是一个软限制和性能指南。

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

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

Oracle 有另一个潜在问题，即 ANSI 连接对连接中所有表的列总数有硬性限制。您可以通过避免使用 Oracle ANSI 连接语法来避免这种情况。（有些等价物不受此错误的影响。）我不记得限制是什么或它适用于哪个版本（我认为它尚未修复）。

假设你有足够的硬件，你所说的行数应该没有问题。

【讨论】：

非常有用的答案！谢谢

【解决方案5】：

Oracle limitations

SQL Server limitations

您可能接近 SQL Server，具体取决于您在该 453 列表中拥有的数据类型（注意每行的字节数限制，但也请阅读脚注）。我知道您说过这是标准化的，但我建议您查看您的工作流程并考虑减少列数的方法。

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

【讨论】：

【解决方案6】：

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

您可以考虑让数据集市（AKA 运营或在线数据存储）在白天更新，然后在晚上将新记录迁移到主仓库？我这样说是因为具有大量列的行插入和更新速度会更慢，因此您可能需要考虑根据应用程序的更新要求定制您的特定在线架构。

【讨论】：

如果是这种情况，那么用于更快更新的在线数据存储/数据集市可能是可行的方法，那么您的设计决策背后就有数据仓库理论的重要性，而且很长一段时间您可以阅读并应用于您的架构的 ETL 工具和数据建模技术的历史（其他人重新审视它会很熟悉）。我想说的是，在您对将采用的架构有一个粗略的了解之前，不应该决定选择数据库供应商。

【解决方案7】：

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

预计在操作方面会发生一些表重新设计和规范化，以适应基于行的存储的每页一行的限制。

如果您需要快速更新 DW，您可以考虑使用 EP for ETL 方法，而不是标准（预定）ETL。

考虑到您还处于早期阶段，请查看 Microsoft project Madison，这是一款可自动扩展的 DW 设备，最高可达 100s TB。他们已经运送了一些安装。

【讨论】：

【解决方案8】：

我会非常仔细地考虑从面向列的数据库切换到关系数据库。面向列的数据库确实不适合运营工作，因为更新速度非常慢，但它们对于报告和商业智能支持来说绰绰有余。

通常情况下，必须将运营工作拆分到一个 OLTP 数据库中，其中包含运营所需的当前活动（帐户、库存等），并使用 ETL 流程来填充数据仓库（历史、趋势）。几乎在任何情况下，面向列的 DW 都会击败关系型 DW，因此我不会轻易放弃 Sybase IQ。也许您可以使用您选择的关系产品（我会选择 SQL Server，但我有偏见）将您的系统设计为具有可操作的 OLTP 端，并保留您现在拥有的 OLAP 部分。

【讨论】：

这是个好主意，谢谢。我不认为使用面向列的数据库的速度提高会胜过使用更频繁使用的数据库的效率（仅在工具集中，更不用说更新速度更慢了！）。

【解决方案9】：

根据您在其他答案中的 cmets，我认为我建议的是：

1) 区分哪些数据实际更新与哪些数据或多或少只读（或不经常） 2）将更新的数据移动到以 id 连接到更大表的单独表（从大表中删除这些列） 3) 针对更小、更相关的表执行 OLTP 事务 4) 必要时使用内部连接连接到大表以检索数据。

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

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

【讨论】：

【解决方案10】：

Sybase 有一个名为 RAP 的产品，它将 IQ 与 ASE（他们的关系数据库）的内存实例相结合，旨在帮助解决此类情况。

您的数据不是很大，以至于您不能考虑迁移到面向行的数据库，但是，根据数据的结构，您最终可能会使用更多的磁盘空间并减慢多种查询的速度。

免责声明：我确实为 Sybase 工作，但目前不在 ASE/IQ/RAP 方面。

【讨论】：