27

可能な限り高速にクエリを実行したい 300 Gb 以上のデータ配列があります。従来の SQL データベース (具体的には SQL Server) では、このボリュームを必要なほど効率的に処理できないため (たとえば、 selectwith 10-20 の条件をwhere10 秒未満で実行するなど)、この問題に対する他の解決策を調査しています。

私はNoSQLについて読んでいて、これはすべて有望に見えますが、実際に NoSQL を使用したことのある人の意見を聞きたいです。

ここで何を提案できますか？

編集して、私たちが求めているものを明確にします。

私たちは、ユーザーがツアーを検索し、そのツアーの予約を行い、プラスチックカードで支払うことができるアプリを開発している会社です. このすべては確かにロシア固有のものである可能性があるので、我慢してください.

ユーザーがサイトにログオンすると、次のようなフォームが表示されます。

代替テキスト http://queenbee.alponline.ru/searchform.png

ここで、ユーザーは出発地と目的地、日付、期間などを選択します。

「検索」をクリックすると、リクエストがDBサーバーに送られますが、そのような負荷を処理できません。クエリにはさまざまな種類のパラメーターが含まれます。シャーディングもうまくいきません。

だから私が求めているのは、超高速のクエリを実行できるある種の疑似データベースです。

4

8 に答える 8

19

レポートや分析のためにアドホック クエリを実行したい場合は、既製のレポート ツールとうまく連携するものを使用した方がよいでしょう。そうしないと、データを照会するための小さなレポート プログラムを作成するために、常に頭を悩ませていることに気付くでしょう。これは NoSQL タイプのデータベースに対するストライキですが、状況によっては問題になる場合とそうでない場合があります。

300GB は、最新の RDBMS プラットフォーム (MS SQL Server でさえも) の能力を超えてはなりません。このタイプの大規模なデータベース クエリのその他のオプションは次のとおりです。

  • SSAS キューブと集計を使用して、クエリのパフォーマンスの問題を軽減できるかどうかを確認してください。使用量に基づく最適化により、別のデータベース システムを取得しなくても十分なパフォーマンスが得られる場合があります。SSAS はシェアード ナッシング構成でも使用できるため、直接接続ディスクを備えた比較的安価なサーバーのクラスター全体でクエリをストライピングできます。この方法を使用する場合は、フロントエンドの ProClarity を検討してください。

  • Sybase IQ は、クエリのレポート用に最適化された基本的なデータ構造を使用する RDBMS プラットフォームです。これには、さまざまな従来のレポート ツールとうまく連携できるという利点があります。Red Brick、Teradata、Greenplum (変更されたバージョンの PostgreSQL を使用) など、このタイプのシステムは他にもいくつか存在します。これらのシステムに対する主なストライキは、それらが大衆市場向けのアイテムではなく、非常に高価になる可能性があるということです.

  • Microsoft は、パイプラインに共有なしバージョンの SQL Server を用意しており、これを使用できる可能性があります。ただし、サードパーティのハードウェア メーカーと提携しているため、専用の (したがって高価な) ハードウェアでしか入手できません。

  • 一部のクエリのボリュームを削減するために、集約されたデータを使用してデータ マートを構築する機会を探します。

  • ハードウェアのチューニングを見てください。直接接続の SAS アレイと RAID コントローラは、テーブル スキャンで使用される種類のストリーミング I/O を非常に迅速に処理できます。多数のミラー ペアでテーブルを分割すると、非常に高速なストリーミング パフォーマンスを得ることができ、SAS チャネルを簡単に飽和させることができます。

    実際には、説明したパフォーマンス目標が必要な場合は、I/O サブシステムから 10 ～ 20 GB/秒を取得することを検討しており、本当にエキゾチックなハードウェアに頼ることなくこれを行うことは確かに可能です。

于 2010-02-09T13:55:14.363 に答える
16

従来の SQL データベースがこれらのボリュームを処理できないことに同意するかどうかはわかりませんが、それらの時間枠内ではるかに大きなデータセットを照会できますが、そのような作業を処理するように特別に設計されており、適切なハードウェアに配置されています。大規模なデータ要求を処理するように設計された IO サブシステム。

于 2010-02-09T13:46:52.610 に答える
14

適切にセットアップされた SQL サーバーは、パフォーマンスの問題を発生させることなく、テラバイト単位のデータを処理できるはずです。パフォーマンスに問題のないサイズの SQl Server データベースを管理している友人が何人かいます。

問題は次の 1 つまたは複数である可能性があります。

  • サーバーのスペック不足
  • 適切なパーティショニングの欠如
  • 索引付けが不十分
  • データベースの設計が不十分
  • そのサイズのデータ​​ベースに対してパフォーマンスの低いコードを作成する可能性がある LINQ などのツールの使用を含む、不適切なクエリ設計。

これらの負荷を処理するのは、SQL Server の能力ではありません。そのサイズのデータ​​ベースがある場合は、大規模システムの最適化の経験を持つ専門のデータベース管理者を雇う必要があります。

于 2010-02-09T14:46:08.847 に答える
6

実行しているクエリに合わせてデータを適切に構成すれば、「従来の」データベースで目的のことができると思います。

レポートを適切に生成するには、データが生成される (またはロード、変換されるなど) ときにデータを要約し、要約データからレポートする必要があることに気付く場合があります。

SELECT の速度は、(通常は) WHERE 句の条件の数とは (ほとんどの場合、直接的に) 関係ありませんが、実行計画と検査される行の数に関係しています。これを分析するツールがあります。

最終的に、300G (それほど大きくない) では、データの一部をディスク (= 低速) に保持する必要がある場合があるため、必要な IO 操作の数を減らし始める必要があります。IO 操作を減らすということは、カバーするインデックス、集計テーブル、およびデータのコピーを異なるクラスター化インデックスで作成することを意味する場合があります。これにより 300G が大きくなりますが、気にする必要はありません。

IO opsは王様です:)

明らかに、これらのことを行うことは開発者の時間の点で非常に高くつくため、問題に多くのハードウェアを投入することから始めて、不十分になったときにソフトウェアで修正するようにしてください。大量の RAM から始めます (ただし、現在の費用対効果の高いレベルでは、一度に 10 ～ 20% を超えるデータ セットを保存することはできません)。SSD でさえ、最近ではそれほど高価ではありません。

于 2010-02-10T07:50:36.117 に答える
3

私がほとんど理解していないことから、従来のRDBMSは行ベースであり、挿入速度を最適化します。ただし、検索速度の最適化は、列ベースのストレージシステムで最もよく達成されます。

私が説明できるよりも詳細な説明については、列指向DBMSを参照してください。

于 2010-02-09T14:00:08.340 に答える
3

それは、WHERE に含まれる句と、データに必要なプロジェクションの種類によって大きく異なります。

テーブルに適切なインデックスを作成するだけで十分な場合があります。

また、最適なデータ構造を持っていても、クエリごとに 100 GB を読み取らなければならない場合、それにも時間がかかるため役に立ちません。

于 2010-02-09T13:47:21.533 に答える
2

NoSQL、お読みになったかもしれませんが、リレーショナルデータベースではありません。

これは、独自のを使用してトラバースできるキーと値のペアを格納するデータベースですAPI。

これは、データの物理的なレイアウトを自分で定義し、コードの最適化を行う必要があることを意味します。

私はこれについてはかなり時代遅れですが、数年前、私はBerkeleyDBわずかに少ないがまだ大量のデータ（約100Gb）を扱うプロジェクトに参加しました。

それは私たちのニーズには完全にOKでした。

当たり前のように思われるかもしれませんが、クエリを最適化できることにも注意してください。ここで使用するクエリを投稿していただけますか？

于 2010-02-09T13:48:23.813 に答える