大規模なデータセットに対するきめの細かい検索

1日あたり約400万件のレコードがあり、オンラインで7年間の価値を維持する必要があるため、検索できるようにする必要がある102億件のレコードを調べています。ユーザーは、検索がUIに十分な速さで、3〜5秒になることを期待しています

私の制御が及ばないため、既製のデータベースソリューションを使用することはできません。これは、データベースを別のチームに渡して管理する必要があるためです（質問しないでください）。つまり、ハードウェアを最適化する機能を失い、彼らはデータベースのための万能サービスを提供し、GBによって（内部で）課金されるソフトウェア。私は私がポイントを作ることを示唆するコメントを受け取るつもりだと確信しています、私はすでに持っており、経営陣は彼らが私に何をするように求めているかはばかげています。

私はソリューションの要としてLuceneを使用することを検討してきました。タイプ別および日別にパーティション化された実際のデータをフラットファイルに保存します。次に、Luceneドキュメントを使用して、検索対象のいくつかのフィールドにインデックスを付けます。唯一の「Stored」フィールドはレコードのIDです（そのため、フラットファイルから読み取ることができます）。

私は正確にLuceneまたはハードドライブにこだわっていませんが、私の理解によれば、インデックスを検索するための最初のIO /シーク時間があります。その後、すべてのLuceneドキュメントIDがあるとき、さらにIOが発生するドキュメントを読みます/ seeking時間、それから私はフラットフラットから実際のレコードを読みます...データセットのサイズを考えると、これは非常に速くなるとは想像できませんが、これは少し心配ですか？

Luceneの最大ドキュメントサイズはインデックスあたり21億です。そのため、ここでは複数のインデックスが必要になります。

このアプローチは、一見すると、うまくいくように見えますか？

保存しているデータはイベントアクションデータです。ほとんどのクエリは、イベントIDでグループ化し、特定のイベントの最後のイベントアクションの詳細を取得します。一部のクエリは、大規模なセットイベントとそれらの個々のイベントアクションを分析します。

データの大きさ、個々のフィールドの大きさ、または取得した予算については、まだ述べていません。

どのインデックスシステムを選択するかに関係なく、問題にハードウェアを投入することを検討してください。ディスクを検索する必要はありません。走査が非常に速いスキーム（おそらくソートされたリストまたはツリー）を使用して、すべてのデータにインデックスを付けます。インデックスをディスクに保存しますが、インデックス全体をRAMにキャッシュします。これを行うには、数十、または数百ギガバイトのRAMが必要になる場合があります。

個々のフィールドが大きい場合やサイズが可変の場合は、それらのインデックスハッシュを検討してください。

サーバーがそれを行うための価格は恐ろしいかもしれません。

技術的な詳細をすべて無視すると、これは組織/管理の問題であり、組織の管理者が解決する必要があります。

上司は問題を2階に蹴り上げたり、ユーザーに問題を高いレベルで提起させたりする必要があります。

あなたのレベルで、OracleとOracleハードウェアでこれを行うためにまとめるか、見積もりを要求してください。次に、Hadoopクラスターの現実的な見積もりをまとめます。

誇大宣伝にもかかわらず、これらのクラスターは安くはありません（64 GBのメモリを備えた18個の8プロセッサノードと4つの2 TBディスクが3つのラックに分散し、さらにカタログ用に4つのノードなどが必要になるなど）。過小評価しないでください。勝った場合は、実装する必要があります。

したがって、まず、要件の観点から問題を明確に述べましょう。

1. システムは、1日あたり最低4Mのレコードを保存します。
2. システムはユーザーに検索インターフェースを提供します
   2.1検索機能は最大3秒で結果を返します
3. システムは、最低102億件のレコードを検索できる必要があります。
4. システムは、カスタム設計
   されたデータベースを使用するものとします。

おそらく、追加の非機能要件、および個々のレコードの大きさの詳細があり、これらはおそらく状況に関連しています。

簡単に言えば、要件に問題があるということです。これらの要件を見ると、そのうちの3つ（最初の3つ）がシステムに正しく適用され、その機能と動作が定義されています。最後の要件は、純粋主義的な観点からは有効な要件ではありませんが、私はこれらのタイプの要件が作業明細書に入れられるのを見てきました。

したがって、この問題を解決する方法は、他の3つを考慮して、4番目の要件のコストを見積もることです。それを行ったら、それをソリューションコストとして提示します。経営陣はパニックに陥り、すぐに問題をリーズナブルな価格で解決できない理由を尋ねます。これが、何が必要かについての議論の入り口です。手頃な価格の代替品を用意し、提示する準備をしてください。

これは、あなたが現在行っていることとは対照的です。これは、最後の1つが与えられた場合、他の3つは満たすことができないと想定しています。彼らが見るすべてはドル記号なので、経営者はそれを理解していません。

私があなたの立場にいるなら、アプリケーションに埋め込まれた通常のRDBMSだけを使用して、非常に合理的な本による実装から始めて、何かをサポートする必要があると感じさせないようにします。SQLite、H2、またはその他の組み込みデータベースは、次のことを行う必要があります。特別なフラットファイル、エキゾチックなインデックス、何もない：データの膨大さをほとんど無視して、当面の問題を解決するための標準的なプラクティスの単純なアプリケーション。 （もちろん、十分な大きさの整数をキーとして選択しますが、それだけです。）

エキゾチックなものに頼らずにそれをより速く動作させる方法に関して、それで作業している間、おそらくさらにいくつかのアイデアが思い浮かぶでしょう。

次に、これをテストして、それがどのように機能するかを確認し、結果を実際のソリューションと共に組織の「存在の力」に示します。

1. 必要な制約の範囲内で簡単な実装が実行される可能性があるため、そのままで問題ありません。他に何もする必要はなく、リソースの浪費もありません。

2. 単純な実装のパフォーマンスが必要な制約の外にあるが、それほど離れていない場合、「存在する力」は「まあ、これは十分に近いので、他のことはしたくないので」それがそれだ。」ここでも、無駄なリソースはありません。

3. 単純な実装のパフォーマンスが必要な制約の範囲外であるが、同じ桁の範囲内である場合は、より優れた、より大きく、より高速なハードウェアを購入するように指示します。ほとんどの場合、彼らはそれを行い、ケースをクローズします。

4. 彼らがより良く、より大きく、より高速なハードウェアを購入したくない場合は、大規模でスケーラブルなRDBMSの使用を控えるという要件を再考することをお勧めします。それらが妥当であり、あなたも妥当であることを示した場合、彼らはそれを再考する可能性があります。

5. ビーの力が合理的な道のいずれにも従うのではなく、代わりに魔術師の役割を果たすことを望んでいるのなら、それから私はエキゾチックな解決策について心配し始めます。多くの可能性があり、物事はそのポイントに到達しません。しかし、たとえそうであっても、その時点までに無駄に行っていた作業の量は比較的少なく、それで十分かもしれないギャンブルの価値は十分にあります。

フロントエンドから考えると......

UIでルックアップタイプを分離すると、より適切な制約を設定できる場合があります。

ルックアップタイプの1つは、イベントの最近のイベントアクションデータのようです。これにより、データ検索で時間で分離できます。これにより、データのセットがはるかに少なくなり、ユーザーがそれをすぐに取得することが期待される可能性があります。

大規模なデータセットまたは古い時間枠の検索を実行する必要がある他の種類のルックアップには、異なるUI（またはいくつかのUI）を指定できます。これは、ユーザーにとってより面倒な一連の要件であると理解できるため、忍耐が合理的に期待される場合があります。そしてもちろん、現実的に必要です。

フロントエンドのデザインに影響を与える能力があるかどうかはわかりませんが、使用している制約を伝えることができれば、ユーザーインタラクションを処理する担当者が理解して応答することを期待しています（少なくとも一部）。