4

また、SQL Server(2008 R2 Developer Edition)には、パフォーマンスの問題がある非常に大きなテーブルがあります。

大きなテーブルを処理するには、別のDBMSの方が適しているのではないかと思いました。私は主に次のシステムのみを検討しています:SQL Server 2008、MySQL、およびPostgreSQL9.0。

または、上記の参照された質問が理解できないように、テーブルのサイズとパフォーマンスは主にインデックスとキャッシュの要因ですか?

また、正規化を大きくすると、パフォーマンスが向上しますか、それとも妨げになりますか?

編集:

以下のコメントの1つは、私が漠然としていたと主張しています。私は2000万行(20年の株式データと2年のオプションデータ)を持っており、パフォーマンスを桁違いに向上させる方法を見つけようとしています。私は読み取り/計算のパフォーマンスのみを気にします。書き込みパフォーマンスは気にしません。書き込みはデータの更新中のみであり、それらはBulkCopyです。

私はすでにいくつかのインデックスを持っていますが、物事を大幅にスピードアップする必要があるため、うまくいけば何か間違ったことをしています。私も自分のクエリを見始める必要があります。

提供されたコメントと回答は、データベースのプロファイリングを開始する方法を理解するのにすでに役立ちました。私はプログラマーであり、DBAではありません(したがって、Marcoの本の推奨事項は完璧です)。私はデータベースの経験があまりなく、データベースのプロファイルを作成したことはありません。これらの提案を試し、必要に応じて報告します。ありがとうございました!

4

6 に答える 6

11

8000万行は大きくありません。そのサイズのデータ​​を設計および照会する方法を学ぶ必要があります。これには、正規化、非正規化、クラスタリング、インデックス作成が含まれる場合がありますが、多くの場合、トレードオフは見た目よりも深くなります。インデックスを追加すると、たとえば、オプティマイザが十分に機能しない場合や間違った統計を決定した場合など、読み取りの場合でも実際にパフォーマンスが低下する可能性があります。

「DBチューナー」からではなく、開発者の観点から問題にアプローチするため、SQLアプリケーションのリファクタリングを読むことをお勧めします。

この本はTheArtof SQLの著者によるもので、多くのシナリオでOracle、SQL Server、MySQLを比較しています。それは実用的であり、いくつかの便利なグラフが付属しています。

強制されない限り、MySQLには近づかないでしょう。Postgres 9.0は、「ロック」のいくつかの定義に従ってロックしますが、私はまだ数か月間、本番環境で8.4を使用します。

また、このテーブルを手伝ってもらいたい場合は、スキーマ、インデックス、データ分散、使用パターンなど、できるだけ多くの詳細を提供してください。

于 2010-07-13T21:37:01.507 に答える
4

DBMSの切り替えは解決策ではありません。

どれくらい大きいですか?どのようなインデックスがありますか?

それが本当に大きい場合、それを分割できますか?

于 2010-07-13T21:16:05.573 に答える
4

SQLServerを最大限に活用するまでには長い道のりがあります。パフォーマンスの問題の原因となる設計とインデックス作成の問題に対処しないと、それらを別のプラットフォームに移植することになります。

「データベースを高速化する」という特効薬の解決策はありません。さもないと、多くのDBAが機能しなくなります。要件に沿ったパフォーマンスを得るには、パフォーマンスプロファイリングを実行し、データベース設計とインデックス作成戦略を微調整する必要があります。

申し訳ありませんが、実際にはショートカットはありません。

パフォーマンスと基礎となるテーブル構造/インデックス作成の点で問題のあるクエリについて詳しく説明すると、SOの賢い人がいくつかのガイダンスを提供できると思います。

于 2010-07-13T21:25:02.043 に答える
1

simpledbが選択だと思います。アマゾンが彼らのプラットフォームにそれを使用していることを考えると。

于 2010-07-13T21:18:49.490 に答える
1

これを見ただけです。infobright.orgをチェックする必要があります。数の計算については、それは素晴らしいです。mysql用のデータベースエンジンを提供しますが、トランザクションの更新ではなく、分析用に構築されています。

発生する唯一の問題は、データセットがinfobrightにとって少し小さいことですが、正常に機能するはずです。

于 2010-10-12T18:16:06.933 に答える
0

本当に大企業、銀行、軍隊、政府の大多数が大量のデータを委託している2つのDB製品は、OracleDB2です。どちらも適切に太い値札が付いています。どちらの製品にも、何十年にもわたる集中的な専門家による調整がありますが、多くの場合、そのメリットは、強力なコンサルタントの費用を負担する人だけが利用できます。私にはそのようなDB2コンサルタントである友人がいます。彼は腕と脚を充電しますが、他の人が考えないような手段で驚くべきパフォーマンスの向上を達成します。

これらはどちらもショートリストに含まれていないため、考慮されない可能性があります。私はマイクロソフト製品に不信感を抱いていますが、他の製品でもあなたの負荷を処理できると思います。だから...これは情報のための単なる情報だと考えてください。

于 2010-07-13T21:26:53.630 に答える