どのデータベースが何十億レコードのストレージを処理できますか？

私たちは、膨大な量を収集するnetflowデータをキャプチャして分析するツールの開発を検討しています。毎日約14億のフローレコードをキャプチャします。これは、json形式では次のようになります。

{
   "tcp_flags": "0",
   "src_as": "54321",
   "nexthop": "1.2.3.4",
   "unix_secs": "1352234521",
   "src_mask": "23",
   "tos": "0",
   "prot": "6",
   "input": "105",
   "doctets": "186",
   "engine_type": "0",
   "exaddr": "2.3.4.5",
   "engine_id": "2",
   "srcaddr": "9.8.7.6",
   "dst_as": "12345",
   "unix_nsecs": "752265174",
   "sysuptime": "2943529544",
   "dst_mask": "24",
   "dstport": "80",
   "last": "2943523241",
   "srcport": "52672",
   "dpkts": "4",
   "output": "111",
   "dstaddr": "6.5.4.3",
   "first": "2943517993"
}

データセットの高速検索（10秒未満）を実行できるようにしたいと考えています。ほとんどの場合、時間の短いスライス（10〜30分間隔）で実行できます。また、データポイントの大部分にインデックスを付けて、各ポイントをすばやく検索できるようにします。また、検索が実行されたときにデータの最新のビューを取得したいと思います。オープンソースの世界にとどまることは素晴らしいことですが、このプロジェクトのプロプライエタリなソリューションを検討することに反対するわけではありません。

アイデアは、約1か月分のデータを保持することです。これは、約432億レコードになります。各レコードに約480バイトのデータが含まれるというおおよその見積もりは、1か月で最大18.7テラバイトのデータに相当し、インデックスを使用した場合の3倍になります。最終的には、このシステムの容量を増やして、何兆ものレコードを保存したいと考えています。

このプロジェクトの候補として、Couchbase、cassandra、mongodbを（非常に基本的に）評価しましたが、それぞれが独自の課題を提案しています。couchbaseでは、データの挿入中ではなく間隔でインデックス付けが行われるため、ビューは最新ではありません。結果を返すには、cassandraのセカンダリインデックスはあまり効率的ではありません。マスター/スレーブ/シャードであるため、スケーリングがはるかに難しいようです。評価を予定している他の候補には、elasticsearch、mysql（これが適用可能かどうかわからない）、およびいくつかの列指向のリレーショナルデータベースがあります。任意の提案や現実世界の経験をいただければ幸いです。

私が働いている会社では、同量のデータ（約10 TBのリアルタイム検索可能データ）を扱っています。Cassandraを使用してこれを解決します。マルチTBデータベースでO（1）検索を実行できるようにするためのアイデアをいくつか紹介します。これはCassandra dbに固有のものではありませんが、他のdbでも使用できます。

理論

• データを分割します。単一のサーバーがそのような量のデータを確実かつ現実的に保持する方法はありません。
• ハードウェア障害とノード全体の障害に備えて、データを複製します。
• 最初から多くのバックエンドサーバーの使用を開始します。
• トップエンドの高性能サーバーと比較して、多くの安価なコモディティサーバーを使用します。
• データがシャード間で均等に分散されていることを確認してください。
• クエリの計画に多くの時間を費やしてください。クエリからAPIを導出し、テーブルを慎重に設計します。これは最も重要で長期にわたるタスクです。
• Cassandraでは、複合列キーを設計し、O（1）でそのキーにアクセスできます。それらに取り組む時間を費やしてください。これは、セカンダリインデックスの代わりに検索可能なレコードにアクセスするために使用されます。
• 幅の広い行を使用します。タイムスタンプ付きイベントを保存するのに便利です。
• そのようなボリュームでフルスキャンまたは実際にはO（Log N）以上の操作を実行しないでください。O（Log N）以外のものが必要な場合は、そのような操作をMap-Reduceアルゴリズムにオフロードします。

練習

• OSイメージの構築やサーバーの物理マシンへのインストールに時間を費やさないでください。迅速なプロトタイピングのためにクラウドベースのプロバイダーを使用します。私はAmazon EC2を使用しましたが、そのシンプルさ、信頼性、プロトタイピングの速度から非常に推奨できます。
• Windowsマシンは、ブート時に低速になる傾向があり、アイドル状態にあるかなり多くのリソースを使用します。UnixベースのOSの使用を検討してください。個人的には、Ubuntuサーバーは信頼できるOSであることがわかりましたが、さらにaskubuntuにはかなり良いコミュニティがあります
• ネットワークについて考えてみましょう。ノードは理想的には互いに近くにあり、高速のゴシップとメタデータ交換を可能にします。
• 極端な場合には入り込まないでください。列の幅が非常に広い場合や、列ファミリー（テーブル）が非常に長い場合です。最高のパフォーマンスは、適切な境界で達成されます-db が設計によりその多くのN行をサポートする場合、それがうまく機能することを意味しません。
• 検索には約3〜5秒かかります。これは、UIとデータベースの間の中間ノードが原因です。リクエストをデータベースに近づける方法を検討してください。
• ネットワークロードバランサーを使用します。確立されたものを選択してください。HAProxyを使用します。これはシンプルですが、高速です。それに問題はなかった。
• 複雑なソリューションよりも単純さを優先します。
• 企業の規模の予算に支えられていない限り、無料のオープンソースソリューションを探してください。複数のサーバーを超えると、インフラストラクチャのコストが非常に高くなる可能性があります。

私はAmazonで働いていませんし、HAProxyやUbuntuチームとは関係がありません。これは、あらゆる種類のプロモーションではなく、個人的な意見です。

これをSQL Serverに配置する場合、次のようなテーブルを提案します。

CREATE TABLE tcp_traffic
(
    tcp_traffic_id bigint constraint PK_tcp_traffic primary key clustered IDENTITY(1,1)
    , tcp_flags smallint    /* at most 9 bits in TCP, so use SMALLINT */
    , src_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , netxhop bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , unix_secs bigint  
    , src_mask int      /* an assumption */
    , tos tinyint       /* values are 0-255, see RFC 791 */
    , prot tinyint      /* values are 0-255, see RFC 790 */
    , input int         /* an assumption */
    , doctets int       /* an assumption */
    , engine_type int   /* an assumption */
    , exaddr bigint     /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , engine_id int     /* an assumption */
    , srcaddr bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , dst_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , unix_nsecs bigint /* an assumption */
    , sysuptime bigint  /* an assumption */
    , dst_mask int      /* an assumption */
    , dstport smallint  /* ports can be in the range of 0 - 32767 */
    , [last] bigint     /* an assumption */
    , srcport smallint  /* ports can be in the range of 0 - 32767 */
    , dpkts int         /* an assumption */
    , output int        /* an assumption */
    , dstaddr bigint    /* use a big integer for the IP address instead of storing
                            it as dotted-decimal */
    , [first] bigint    /* an assumption */
);

これにより、単一テーブルの合計推定ストレージ要件が得られ、43.2 beeellionレコードの5.5 TBのインデックスは追加されません（指定要件）。これは、データ自体の130バイトに、オーバーヘッドの行ごとに7バイト、オーバーヘッドのページごとに96バイトを加えて計算されます。SQL Serverはデータを8KBページに保存し、ページあたり59行を許可します。これは、1か月のデータで732,203,390ページに相当します。

SQL Serverは、8ページのチャンク（64KB）でディスクに書き込むことを好みます。これは、物理I / Oあたり472行に相当します。毎秒16,203のフローレコードが生成されるため、毎秒保証される34 IOpsの最小I / Oレートが必要になります。これ自体はそれほど大きなものではありませんが、システム内の他のI / O（SQL Serverなど）がこの必要なIOpsレートを決して侵害する必要はありません。したがって、少なくとも10桁以上のIOps、または340の持続IOpsが可能なシステムを設計する必要があります。スループットを保証するには、2桁以上の持続可能なIOpsが必要だと見積もる傾向があります。

IPアドレスをドット付き10進数形式で保存していないことに気付くでしょう。これにより、ストレージ（アドレスごとに7バイト）が大幅に節約され、IPアドレスのインデックス作成、取得、並べ替え、比較がはるかに効率的になります。ここでの欠点は、ドットで区切られた10進数のIPを8バイト整数に変換してから保存し、表示のためにドットで区切られた10進数のIPに戻す必要があることです。そのためのコードは簡単ですが、行レートを変更すると、処理される各フロー行にかなりの処理オーバーヘッドが追加されます。この変換プロセスは、SQL Serverとは物理的に異なるマシンで行うことができます。

特定の要件をリストしていないため、必要なインデックスの議論はまったく別の問題です。このテーブルの設計は、SQL Serverが受信した物理的な順序でフロー行を格納します。tcp_traffic_idフィールドは各レコードで一意であり、記録された順序で行を並べ替えることができます（この場合は、ほとんどの場合1対1フローイベントの時間まで）。

HBaseをお勧めします。クエリの対象に応じて、すべての生データを1つ以上のHBaseテーブルに保存できます。HBaseは大規模なデータセットを処理でき、領域分割による自動シャーディングを実行します。

また、行キーを適切に設計すると、O（1）クエリでも非常に高速に取得できます。大規模なデータセットを取得する場合、データの取得はO（n）操作であるため、依然として低速になることに注意してください。

各フィールドでクエリを実行するため、各フィールドに一意のテーブルを作成することをお勧めします。src_addressデータの例には、次のようなテーブルがあります。

1.2.3.4_timestamp1 : { data }
1.2.3.4_timestamp2 : { data }

したがって、3月27日12:00 AMから3月27日12:01 AMまでの1.2.3.4全体のすべてのデータを照会する場合は、開始行と停止行を指定して範囲スキャンを実行できます。

私見、行キーの設計は、HBaseを使用する上で最も重要な部分です。適切に設計すれば、高速なクエリを実行し、大量のデータを保存できます。

これは言った：

...このプロジェクトの独自のソリューションを検討することに反対していません

IBM Informixデータベース + TimeSeries データブレードを検討することをお勧めします。一部の人々が言うこととは反対に、Informixは生きており、非常にうまくいっています。最後のバージョンは先月リリースされました（2013年3月、バージョン12.10）。

TimeSeriesは、あなたのような状況に対処できる「プラグイン」（無料）のようなものです。
また、無料バージョンのInformixデータベース（エディションInnovator-C）を使用して本番環境で使用できます。（もちろん、無料版には多くの限られたリソースがあるため、技術的な部分を評価するためだけです）

ここで、リファレンスとして使用できるベンチマークのPDFを確認できます。ここでは、より技術的な例を含む2つのプレゼンテーション：ダミーガイドとその他のヒント

私はTimeSeriesの個人的な経験がないので、評価するための単なる提案である「ソリューション」になることに同意することはできません。

次に、Informix TimeSeriesを確認することをお勧めします。IBMの文献によれば、TimeSeriesはこの種の情報を1/5のスペースに保存でき、従来のリレーショナルテーブルの5倍の速度で実行できます。

その他の利点は、エンドユーザーにTimeSeriesデータを従来のリレーショナルテーブルのように見せることができる仮想テーブルインターフェイス（アプリケーション開発を簡素化すると同時にTimeSeriesの利点を活用できる）、バージョン12.1のTimeSeriesデータをサポートするHDRノードを備えたシンプルなHA複雑なデータウェアハウスレポートを高速化するために使用できるInformix Warehouse AcceleratorへのTimeSeriesデータの統合と、無料のInformix DeveloperまたはInnovator-Cエディションを使用してInformixでTimeSeriesソリューションをプロトタイプ化する機能。