超高速クエリ用データベース
可能な限り高速にクエリを実行する300 Gb +データ配列があります。従来のSQLデータベース（具体的には、SQL Server）では、このボリュームを必要なだけ効率的に処理できません（たとえば、select句で10〜20の条件でwhereを10秒未満で実行するなど）。この問題の他の解決策を調査しています。
私は NoSQL について読んでいましたが、この全体は有望に見えますが、実際にそれを使用したことがある人から聞いてみたいと思います。
ここで何を提案できますか？
[〜＃〜]編集[〜＃〜]して、目的を明確にします。
私たちは、ユーザーがツアーを検索してそのツアーの予約を行い、プラスチックカードで支払うアプリを開発している会社です。このすべては確かにロシア固有である可能性があるので、我慢してください。
ユーザーがサイトにログオンすると、次のようなフォームが表示されます。
代替テキストhttp://queenbee.alponline.ru/searchform.png
ここで、ユーザーはどこから出発し、どこへ行くか、日付、期間、その他すべてを選択します。
「検索」をクリックした後、DBサーバーにリクエストが送信されますが、DBサーバーはそのような負荷を処理できません。クエリにはさまざまな種類のパラメーターが含まれています。シャーディングもうまくいきません。
だから私が求めているのは、ある種の疑似データベースです。
レポートまたは分析のためにアドホッククエリを実行する場合は、市販のレポートツールでうまく機能するものを使用した方がよいでしょう。そうしないと、データを照会するための小さなレポートプログラムを作成するために、いつも自分自身が引きずられることに気付くでしょう。これはNoSQLタイプのデータベースに対するストライキですが、状況によっては問題となる場合とそうでない場合があります。
300 GBは、MS SQL Serverであっても、最新のRDBMSプラットフォームの機能を超えてはなりません。このタイプの大規模なデータベースクエリのその他のオプションは次のとおりです。
SSASキューブと集計を使用してクエリのパフォーマンスの問題を軽減できるかどうかを確認します。使用法に基づく最適化により、別のデータベースシステムを用意しなくても、十分なパフォーマンスが得られる場合があります。 SSASはシェアードナッシング構成でも使用できるため、直接接続ディスクを備えた比較的安価なサーバーのクラスター全体にクエリをストライプ化できます。このようにする場合は、フロントエンドのProClarityを参照してください。
Sybase IQは、レポートクエリ用に最適化された基盤となるデータ構造を使用するRDBMSプラットフォームです。これには、従来のさまざまなレポートツールと適切に連携できるという利点があります。 Red Brick、Teradata、またはGreenplum（変更されたバージョンのPostgreSQLを使用）など、このタイプのシステムは他にもいくつかあります。これらのシステムに対する主なストライキは、それらが正確に大衆市場のアイテムではなく、かなり高価になる可能性があることです。
マイクロソフトでは、パイプラインにシェアードナッシングバージョンのSQL Serverがあり、使用できる可能性があります。ただし、サードパーティのハードウェアメーカーに関連付けられているため、専用の（したがって高価な）ハードウェアでしか入手できません。
一部のクエリの量を減らすために、集約データを使用してデータマートを構築する機会を探します。
ハードウェアの調整を見てください。直接接続SASアレイおよびRAIDコントローラーは、テーブルスキャンで使用される種類のストリーミングI/Oを非常に迅速に実行できます。多数のミラーリングされたペアでテーブルをパーティション化すると、非常に高速にできますストリーミングパフォーマンス-SASチャネルを簡単に飽和させることができます。
実際には、記述したパフォーマンス目標が必要な場合は、I/Oサブシステムから10〜20 GB /秒を取得することを検討しており、実際にエキゾチックなハードウェアに頼ることなくこれを実行できます。
従来のSQLデータベースがこれらのボリュームを処理できないことに同意するかどうかはわかりません。これらの時間枠内ではるかに大きなデータセットを照会できますが、そのような作業を処理するように特別に設計され、適切なハードウェア、特にIO大規模なデータ要求を処理するように設計されたサブシステム。
適切に設定されたSQLサーバーは、パフォーマンスの問題なしにテラバイト単位のデータを処理できる必要があります。パフォーマンスの問題がないサイズのSQl Serverデータベースを管理している友人が何人かいます。
問題は次の1つ以上の可能性があります。
- 不十分なサーバー仕様
- 適切なパーティション分割の欠如
- 不十分なインデックス作成
- 貧弱なデータベース設計
- LINQのようなツールを使用するなど、クエリの設計が不十分であり、そのサイズのデータベースに対してパフォーマンスの低いコードを作成する可能性があります。
SQL Serverがこれらの負荷を処理する機能ではありません。そのサイズのデータベースがある場合は、大規模システムの最適化の経験を持つ専門のdbaを雇う必要があります。
実行しているクエリに合わせてデータを適切に構造化すれば、「従来の」データベースで期待どおりの結果が得られると思います。
レポートを適切に生成するには、データが生成（またはロード、変換など）されたときにデータを要約し、要約データから報告する必要がある場合があります。
SELECTの速度はWHERE句の条件の数（通常は直接）とは関係ありませんが、EXPLAIN PLANと検査される行の数に関係します。これを分析するツールがあります。
最終的には、300G（それほど大きくありません）では、少なくとも一部の時間にデータをディスク（=低速）に保持する必要があるため、IO操作の数を減らし始める必要があります。必須。 IO操作を減らすことは、カバーするインデックス、サマリーテーブル、異なるクラスター化インデックスを持つデータのコピーを作成することを意味する場合があります。これにより300Gが大きくなりますが、誰も気にかけません。
IO opsは王様です:)
明らかにこれらのことを行うことは開発者の時間の点で非常に費用がかかるので、問題に多くのハードウェアを投入することから始め、それが不十分になった場合にのみソフトウェアで修正することを試みるべきです。たくさんのRAMが出発点です（しかし、現在の費用対効果の高いレベルで一度に10〜20％を超えるデータセットを格納することはできません）SSDでさえ、最近はそれほど高価ではありません。
私がほとんど理解していないことから、従来のRDBMSは行ベースであり、挿入速度を最適化します。ただし、検索速度の最適化は、列ベースのストレージシステムで行うのが最適です。
私が与えることができるより完全な説明については 列指向のDBMS を参照してください
これは、WHERE句にある句と、データに必要なプロジェクションの種類によって異なります。
テーブルに適切なインデックスを作成するのに十分かもしれません。
また、クエリごとに100GBを読み取る必要がある場合、時間がかかるため、最適なデータ構造を使用しても意味がありません。
ご覧のとおり、NoSQLはリレーショナルデータベースではありません。
これは、独自のAPIを使用してトラバースできるキーと値のペアを格納するデータベースです。
つまり、データの物理レイアウトを自分で定義し、コードの最適化を行う必要があります。
私はこれでかなり時代遅れですが、数年前、少しだけではあるがまだ大量のデータ（約100Gb）を扱う BerkeleyDB プロジェクトに参加しました。
私たちのニーズは完全に問題ありませんでした。
当然のことながら、クエリを最適化できることにも注意してください。ここで使用するクエリを投稿していただけませんか？
Clickhouse を試してください ベンチマーク結果 があり、ほとんどの場合、MemSQLからでも高速ですが、レコードを更新することはできず、挿入/削除のみが可能です