私はデータベースの第一人者ではないので、アドバイスをお願いします。
バックグラウンド
現在SybaseIQに保存されているテーブルは4つあります。現在、これを選択することはできません。基本的に、他の誰かが私たちのために決定したことに固執しています。Sybase IQは、データウェアハウスに最適な列指向データベースです。残念ながら、私のプロジェクトでは多くのトランザクション更新を行う必要があるため（私たちはより運用データベースです）、より主流の代替手段を探しています。
質問
これらのテーブルのディメンションを考えると、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
経験則では、行サイズはディスクブロックサイズ（通常は8k）を超えてはなりません。ご覧のとおり、大きなテーブルが完全に4バイトの整数で構成されている場合はこの点で問題はありませんが、255文字のVARCHAR列で構成されている場合は制限を大幅に超える可能性があります。この8kの制限は、SQL Serverでは厳しい制限でしたが、最近では、ソフトな制限とパフォーマンスのガイドラインにすぎないと思います。
VARCHAR列は、指定したサイズに見合ったメモリを消費するとは限らないことに注意してください。これが最大サイズですが、必要なだけ消費します。VARCHAR列の実際のデータが常に3〜4文字の長さである場合、サイズは、VARCHAR（4）またはVARCHAR（255）のどちらとして作成したかに関係なく、整数列のサイズと同様になります。
一般的なルールは、ディスクブロックごとに多くの行が存在するように行サイズを小さくすることです。これにより、テーブルのスキャンに必要なディスク読み取りの数が減ります。8kを超えると、行ごとに2つの読み取りがあります。
Oracleには、ANSI結合には、結合内のすべてのテーブルの列の総数に厳しい制限があるという別の潜在的な問題があります。これは、OracleANSI結合構文を回避することで回避できます。（このバグに悩まされていない同等のものがあります。）制限が何であるか、またはそれがどのバージョンに適用されるかを思い出せません（まだ修正されていないと思います）。
適切なハードウェアがあれば、話している行の数はまったく問題ありません。
適切なサイズのハードウェアとI/Oサブシステムを使用すれば、どちらも非常に適切です。列がたくさんある場合、行数は非常に少なくなります。通常、数百万ではなく数十億で表されるデータセットを使用します。（SQL2000では試さないでください:)）
使用法とI/O要件を知っている場合、ほとんどのI/Oベンダーはそれをハードウェア仕様に変換します。メモリ、プロセッサなども、モデル化できるのは自分だけのワークロードに依存しています。
Oracle 11gは、このようなデータと構造に問題はありません。
詳細については、http：//neworacledba.blogspot.com/2008/05/database-limits.htmlをご覧ください。
よろしく。
その453列のテーブルにあるデータ型によっては、SQL Serverに近い場合があります（行あたりのバイト数の制限に注意してください。ただし、脚注も読んでください）。これは正規化されているとおっしゃっていましたが、ワークフローを確認し、列数を減らす方法を検討することをお勧めします。
また、これらのテーブルは十分に大きいため、ハードウェアの考慮事項がパフォーマンスの大きな問題になります。いずれかのRDBMSを使用してサーバーを指定およびセットアップするには、経験豊富なDBAが必要です。ディスクサブシステムを適切に構成することが重要になります。パフォーマンスを向上させるために、とりわけテーブルのパーティション分割も検討することをお勧めしますが、これはすべて、データがどのように使用されているかによって異なります。
他の回答のコメントに基づいて、私がお勧めするのは次のとおりです。
1）実際に更新されるデータと読み取り専用（またはまれに）になるデータを分離します。2）更新されたデータをIDで結合された別のテーブルに移動して大きなテーブルに移動します（大きなテーブルからそれらの列を削除します）。より小さく、よりリレーショナルなテーブルに対してOLTPトランザクションを実行します。4）必要に応じて、内部結合を使用して大きなテーブルに接続し、データを取得します。
他の人が指摘しているように、DBにOLTPとOLAPの両方を同時に実行させようとしているのですが、それは困難です。サーバー設定は、どちらのシナリオでも異なる方法で調整する必要があります。
SQLServerまたはOracleのいずれかが機能するはずです。国勢調査データも使用しており、gigantoテーブルには約300以上の列があります。SQL Server 2005を使用していますが、すべての列がその容量までいっぱいになると、レコードの可能な最大サイズを超えると文句を言います。国勢調査データはOLAP方式で使用されるため、列がそれほど多くあることはそれほど大きな問題ではありません。
Sybaseには、このような状況で役立つように設計されたASE（リレーショナルデータベース）のインメモリインスタンスとIQを組み合わせたRAPと呼ばれる製品があります。
データはそれほど大きくないため、行指向のデータベースへの移行を検討することはできませんが、データの構造によっては、かなり多くのディスクスペースを使用し、さまざまな種類のクエリの速度を低下させる可能性があります。
免責事項：私はSybaseで働いていますが、現在ASE / IQ/RAP側では働いていません。
これらすべてのテーブルのすべての列は、アプリケーションによって更新されていますか？
日中に更新されるデータマート（別名、運用データストアまたはオンラインデータストア）を用意し、新しいレコードを夜間にメインウェアハウスに移行することを検討できますか？これは、大量の列を含む行の挿入と更新が遅くなるためです。そのため、特定のオンラインアーキテクチャをアプリケーションの更新要件に合わせて調整することを検討することをお勧めします。
1つのDBに、運用システムとウェアハウスシステムとして同時に機能するように依頼することは、依然として少し難しい作業です。運用システムにはSQLサーバーまたはOracleを使用し、レポートと分析には別のDWを使用して、おそらくシステムを維持することを検討します。
行ベースのストレージのページごとに1行の制限に適合するように、運用側でテーブルの再設計と正規化が行われることを期待してください。
DWを高速に更新する必要がある場合は、標準の（スケジュールされた）ETLではなく、EPforETLアプローチを検討してください。
これの初期段階にあることを考慮して、最大100TBの自動スケーラブルなDWアプライアンスであるMicrosoftプロジェクトMadisonを見てください。彼らはすでにいくつかのインストールを出荷しています。
列指向データベースからリレーショナルデータベースへの切り替えを慎重に検討します。列指向データベースは、更新が非常に遅いため、運用作業には実際には不十分ですが、レポートおよびビジネスインテリジェンスのサポートには十分すぎるほどです。
多くの場合、運用作業を運用に必要な現在のアクティビティ（アカウント、在庫など）を含むOLTPデータベースに分割し、ETLプロセスを使用してデータウェアハウス（履歴、傾向）にデータを入力する必要があります。列指向のDWは、ほとんどすべての状況でリレーショナルDWを打ち負かすので、SybaseIQを簡単に諦めることはありません。おそらく、選択したリレーショナル製品を使用して運用可能なOLTP側を持つようにシステムを設計し（SQL Serverを選択しますが、偏見があります）、現在のOLAP部分を維持できます。