6

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

背景

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

问题

  1. 鉴于这些表的尺寸，有人会认为 SQL Server 或 Oracle 是可行的替代方案吗？

    • 表 1：172 列 * 3200 万行
    • 表 2：453 列 * 700 万行
    • 表 3：112 列 * 1300 万行
    • 表 4：147 列 * 250 万行

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

4

10 回答 10

7

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

于 2009-11-26T15:42:21.597 回答
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 个字符的 VARCHAR 列组成，那么您的大表在这方面不是问题，那么您可能会大大超出限制。这个 8k 限制曾经是 SQL Server 中的硬限制，但我认为现在它只是一个软限制和性能指南。

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

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

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

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

于 2009-11-26T16:02:35.373 回答
2

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

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

于 2009-11-26T15:40:42.920 回答
1

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

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

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

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

于 2009-11-26T19:02:37.037 回答
1

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

更多信息请访问： http: //neworacledba.blogspot.com/2008/05/database-limits.html

问候。

于 2009-11-26T15:44:55.007 回答
1

Oracle 限制

SQL Server 限制

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

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

于 2009-11-26T16:16:03.400 回答
0

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

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

于 2009-11-26T16:37:20.887 回答
0

Sybase have a product called RAP that combines IQ with an in-memory instance of ASE (their relational database) which is designed to help in situations such as this.

Your data isn't so vast that you couldn't consider moving to a row-oriented database but, depending on the structure of the data, you could end up using considerably more disk space and slowing down many kinds of queries.

Disclaimer: I do work for Sybase but not currently on the ASE/IQ/RAP side.

于 2010-04-18T11:48:36.870 回答
0

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

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

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

考虑到您处于此阶段的早期阶段，请查看 Microsoft项目 Madison，它是高达 100s TB 的自动可扩展 DW 设备。他们已经运送了一些装置。

于 2009-11-26T17:13:34.530 回答
0

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

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

于 2009-11-26T18:48:45.290 回答