数十億のレコード（1年間で約30億/月）の小さなデータ（約50〜75バイト）を保存できる必要があります。
唯一の要件は、同じGUIDを持つすべてのレコードの高速挿入と高速ルックアップ、および.netからデータストアにアクセスする機能です。
私はSQLサーバーの担当者であり、SQL Serverでこれを実行できると思いますが、BigTable、CouchDB、およびその他のnosqlソリューションについてのすべての話を踏まえると、分散クエリとスケーリング。私はcassandraを試しましたが、.netライブラリは現在コンパイルされていないか、すべて変更される可能性があります（cassandra自体と一緒に）。
利用可能な多くのnosqlデータストアを調べましたが、堅牢な本番環境対応プラットフォームとしてのニーズを満たすものが見つかりません。
.netからアクセスできるように、360億の小さくてフラットなレコードを保存する必要がある場合、何を選択し、その理由を教えてください。
回答:
最大3.5TBのデータを保存し、約1K /秒を24時間365日挿入し、指定されていないレートでクエリを実行することもSQL Serverで可能ですが、さらに質問があります。
私が強調したこれらすべての要件が必要な場合、提案する負荷は、どのようなギミック（シャーディング、パーティショニングなど）を試しても、リレーショナルシステム、任意のシステムで数百万のハードウェアとライセンスを必要とします。nosqlシステムは、その定義上、満たすことができません。これらすべての要件をいる。
したがって、明らかに、これらの要件のいくつかはすでに緩和されています。Visual Guide to NoSQL Systemsには、「3つのうち2つを選択」パラダイムに基づいてnosql製品を比較する優れたビジュアルガイドがあります。
OPコメント更新後
SQL Serverを使用すると、これは簡単な実装になります。
パーティショニングとページ圧縮にはそれぞれEnterpriseEdition SQL Serverが必要であり、Standard Editionでは機能せず、どちらも要件を満たすために非常に重要です。
ちなみに、レコードがフロントエンドWebサーバーファームからのものである場合は、各WebサーバーにExpressを配置し、バックエンドにINSERTを使用する代わりにSEND、ローカル接続/トランザクションを使用してバックエンドに情報を送信します。Webサーバーと同じ場所にあるExpress上。これにより、ソリューションの可用性に関するストーリーが大幅に向上します。
これがSQLServerでのやり方です。良いニュースは、直面する問題がよく理解されており、解決策がわかっていることです。これは、Cassandra、BigTable、Dynamoで達成できるものよりも優れているとは限りません。私は誰かに、彼らの主張を議論するために、SQLっぽくないことについてもっと知識があるようにします。
プログラミングモデル、.Netサポートなどについては触れなかったことに注意してください。正直なところ、大規模な展開では無関係だと思います。それらは開発プロセスに大きな違いをもたらしますが、一度展開されると、ORMオーバーヘッドがパフォーマンスを低下させる場合、開発がどれほど速くても問題ありません:)
一般に信じられていることとは異なり、NoSQLはパフォーマンスやスケーラビリティについてではありません。これは主に、いわゆるオブジェクトリレーショナルインピーダンスの不一致を最小限に抑えることですが、水平方向のスケーラビリティとRDBMSのより一般的な垂直方向のスケーラビリティについても説明します。
高速挿入と高速ルックアップの単純な要件については、ほとんどすべてのデータベース製品で十分です。リレーショナルデータや結合を追加したい場合、または強制する必要のある複雑なトランザクションロジックや制約がある場合は、リレーショナルデータベースが必要です。NoSQL製品は比較できません。
スキーマレスデータが必要な場合は、MongoDBやCouchDBなどのドキュメント指向データベースを使用することをお勧めします。緩いスキーマがこれらの主な魅力です。私は個人的にMongoDBが好きで、いくつかのカスタムレポートシステムで使用しています。データ要件が絶えず変化しているときに非常に便利だと思います。
他の主要なNoSQLオプションは、BigTableやCassandraなどの分散型Key-Valueストアです。これらは、コモディティハードウェアを実行している多くのマシン間でデータベースを拡張する場合に特に役立ちます。もちろん、サーバーでも問題なく動作しますが、ハイエンドのハードウェアや、SQL Server、Oracle、または垂直用に設計されたその他のデータベースを利用していません。スケーリングを利用していません。また、明らかに、リレーショナルではなく、正規化の実施には適していません。または制約。また、お気づきのように、.NETサポートはせいぜいむらがある傾向があります。
すべてのリレーショナルデータベース製品は、限定された種類のパーティショニングをサポートしています。BigTableや他のDKVSシステムほど柔軟性がなく、数百に簡単に分割できません。のサーバーにすることはできませんが、実際にはそれがあなたが探しているもののようには聞こえません。データのインデックス作成と正規化を行い、強力なハードウェア（特に、余裕がある場合はSSD）でデータベースを実行し、2、3、または5つの物理ディスクに分割する限り、数十億のレコード数を処理するのに非常に優れています。必要。
上記の基準を満たしている場合、企業環境で作業していて、適切なハードウェアとデータベースの最適化に費やすお金がある場合は、今のところSQLServerを使用します。ペニーをつまんでいて、これをローエンドのAmazon EC2クラウドコンピューティングハードウェアで実行する必要がある場合は、代わりにCassandraまたはVoldemortを選択することをお勧めします（.NETで動作するようになると仮定します）。
数十億の行セットサイズで作業する人はほとんどいません。スタックオーバーフローでこのようなリクエストが表示されることがほとんどですが、データは報告されているサイズに近いものではありません。
ダウンタイムがないと仮定すると、360億、1か月あたり30億、つまり1日あたり約1億、1時間あたり416万、1分あたり約7万行、1秒あたり11,000行が、12か月間持続的にシステムに流入します。
これらの数字は長いマージンで不可能ではありません。私はより大きなシステムを実行しましたが、それが実際に意味する量であることを再確認したいと思います。実際にこの量を持っているアプリはほとんどありません。
保存/取得に関して、あなたが言及していない非常に重要な側面は、古いデータのエージングです-削除は無料ではありません。
通常のテクノロジではパーティション化が行われていますが、GUIDベースのルックアップ/取得では、12か月全体で一致するすべての値を取得する必要があると仮定すると、パフォーマンスが低下します。GUID列にクラスター化インデックスを配置すると、関連付けられたデータが読み取り/書き込み用にクラスター化されますが、それらの量と挿入速度では、断片化が高すぎてサポートできず、フロアに落ちてしまいます。
また、これがOLTPタイプの応答速度を備えた深刻なアプリケーションである場合、つまり、インデックス作成のオーバーヘッドが非常に少ないと仮定すると、約2.7 TBのデータである場合、非常に適切なハードウェアバジェットが必要になることをお勧めします。
SQL Serverキャンプでは、データをシャーディングし、それに対して並列クエリを実行して大規模なデータマートに対して高速を提供するように設計された、新しい並列データウェアハウスエディション（マディソン）だけを確認する必要があります。
「数十億のレコード（年間で約30億/月）の小さなデータ（約50〜75バイト）を保存できる必要があります。
唯一の要件は、同じGUIDを持つすべてのレコードの高速挿入と高速ルックアップ、および.netからデータストアにアクセスする機能です。」
これはSQLServerで可能であることが経験からわかります。これは、2009年の初めに行ったためです...そして、今日でも非常に高速に動作しています。
テーブルは256のパーティションに分割されました。これは、2005 SQLバージョンであることに注意してください...そして、あなたが言っていることを正確に実行しました。つまり、情報のビットをGUIDで格納し、GUIDですばやく取得します。
私が去ったとき、約20〜30億のレコードがあり、データ保持ポリシーがインスタンス化されようとしていたにもかかわらず、データの取得は依然として非常に良好でした（UIを通過する場合は1〜2秒、RDBMSの場合はそれ以下）。
つまり、簡単に言うと、GUID文字列から8番目の文字（つまり、中間のどこか）を取得し、SHA1がそれをハッシュして、小さなint（0-255）としてキャストし、適切なパーティションに格納して、取得時に同じ関数呼び出しを使用しました。データを戻します。
さらに情報が必要な場合は私にpingしてください...
次の記事では輸入と使用について説明し16十億のMicrosoft SQLでの行のテーブルを。 http://sqlmag.com/t-sql/adventures-big-data-how-import-16-billion-rows-single-table。
記事から：
これが私の経験からのいくつかの蒸留されたヒントです：
- クラスター化インデックスが定義されたテーブルにあるデータが多いほど、ソートされていないレコードをテーブルにインポートするのが遅くなります。ある時点で、それは実用的であるには遅すぎます。
- テーブルを可能な限り小さいファイルにエクスポートする場合は、ネイティブ形式にします。これは、文字データよりもバイナリフィールドでよりコンパクトに表されるため、ほとんどが数値列を含むテーブルで最適に機能します。すべてのデータが英数字の場合、ネイティブ形式でエクスポートしてもあまりメリットはありません。数値フィールドにnullを許可しないと、データがさらに圧縮される可能性があります。フィールドをNULL可能にすることを許可すると、フィールドのバイナリ表現には、続くデータのバイト数を示す1バイトのプレフィックスが含まれます。
- BCPカウンター変数は4バイト整数であるため、2,147,483,647レコードを超えるBCPを使用することはできません。MSDNまたはインターネットでこれへの参照を見つけることができませんでした。テーブル
が2,147,483,647を超えるレコードで構成されている場合は、テーブルをチャンクでエクスポートする
か、独自のエクスポートルーチンを作成する必要があります。- 事前入力されたテーブルでクラスター化インデックスを定義すると、多くのディスク領域が必要になります。私のテストでは、ログが
完了する前に元のテーブルサイズの10倍に爆発しました。- BULK INSERTステートメントを使用して多数のレコードをインポートする場合は、BATCHSIZEパラメーターを含めて、一度
にコミットするレコードの数を指定します。このパラメーターを含めない場合
、ファイル全体が単一のトランザクションとしてインポートされます。
ため、多くのログスペースが必要になります。- クラスター化インデックスを使用してデータをテーブルに取り込む最も速い方法は、最初にデータを事前に並べ替えることです。次に、BULKINSERT
ステートメントとORDERパラメーターを使用してインポートできます。
見落とされているように見える珍しい事実があります。
「基本的に、1日に3,000万行を挿入した後、同じGUID（おそらく20行）ですべての行をフェッチする必要があり、すべてを取り戻すことが合理的に確実です。」
20列のみが必要なため、GUIDの非クラスター化インデックスは問題なく機能します。パーティション間でデータを分散させるために、別の列にクラスター化することができます。
データ挿入に関して質問があります：どのように挿入されますか？
方程式の片側を理解するために、これらに答える必要があると思います。
AmazonRedshiftは素晴らしいサービスです。質問が2010年に最初に投稿されたときには利用できませんでしたが、2017年には主要なプレーヤーになりました。これはPostgresからフォークされた列ベースのデータベースであるため、標準のSQLおよびPostgresコネクタライブラリで動作します。
レポートの目的、特に集計に最適です。単一のテーブルからのデータは、Amazonのクラウド内の異なるサーバーに保存され、定義されたテーブルdistkeysによって分散されるため、分散CPUパワーに依存します。
そのため、SELECT、特に集約されたSELECTは非常に高速です。大きなデータの読み込みは、Amazon S3csvファイルからCOPYコマンドを使用して実行することをお勧めします。欠点は、DELETEとUPDATEが通常よりも遅いことですが、それが、Redshiftが主に多国籍データベースではなく、より多くのデータウェアハウスプラットフォームにある理由です。
CassandraまたはHBaseを使用してみることができますが、ユースケースに従って列ファミリーを設計する方法を読む必要があります。Cassandraは独自のクエリ言語を提供しますが、データに直接アクセスするにはHBaseのJavaAPIを使用する必要があります。Hbaseを使用する必要がある場合は、オープンソースプロジェクトであるMap-RのApacheDrillを使用してデータをクエリすることをお勧めします。ドリルのクエリ言語はSQL準拠です（ドリルのキーワードはSQLと同じ意味です）。
年間のレコード数が多いと、最終的にはスペースが不足します。2 ^ 64ファイルをサポートし、より小さなボックスを使用するxfsのようなファイルシステムストレージを使用してみませんか。いかに派手な人々が手に入れたいか、またはデータベースSQL NoSQLを使用してシステムを取得するために費やす金額に関係なく、これらの多くのレコードは通常、電力会社や気象観測所/環境省のような小規模な管理を行うプロバイダーによって作成されます。全国のステーション。圧力、温度、風速、湿度などを保存するようなことをしていて、GUIDが場所である場合でも、データを年/月/日/時間で割ることができます。ハードドライブごとに4年間のデータを保存するとします。次に、ミラー付きの小さなNasで実行して、読み取り速度を向上させ、複数のマウントポイントを設定できます。それが作成された年に基づいています。あなたは単に検索のためのウェブインターフェースを作ることができますそれで場所を捨てる1 / 2001/06/01/温度と場所1/2002/06/01 // Temperatureは、その2年間（24時間* 2）の夏の初日の1時間ごとの気温の内容のみをダンプします。これに対して、数十億のレコードと場合によっては数百万が費やされたデータベースを検索します。物事の簡単な見方..神のいる世界の15億のウェブサイトは、それぞれが何ページあるかを知っています。代わりに、彼らは電力料金を持っています...数百万台のがらくたコンピュータ。そしてカフェインの索引付け...将来性のある..さらに追加し続けます。そして、SQLから実行するインデックス作成が理にかなっている場合は、天気や統計などの固定されたタスクのためのスーパーコンピューターを構築して、技術者がシステムを自慢できるようにしますxtbをx秒でクランチします...お金の無駄になる可能性がありますどこかで過ごした。
レコードをプレーンなバイナリファイル（GUIDごとに1つのファイル）に保存しても、それより速くなることはありません。