300万件のレコードをキー値形式で格納する方法
300万個の商品の基本情報を保存しなければなりません。現在の情報は、四半期ごとに更新される1つの180 mb CSVです。
1日に約30,000のクエリがありますが、クエリは非常に単純なキー値ストアです。製品IDを検索して残りの情報（すべて1つのレコードに含まれる）を表示するだけです。
これはウェブ用なので、高速なパフォーマンスが重要です。
リレーショナルデータベースが本当に必要ない場合でも、MySQLを使用する必要がありますか？四半期ごとに300万の静的htmlファイルを生成するだけでよいでしょうか。各製品の1行のCSVをAmazon S3やRackspace Cloud Filesなどに保存する必要がありますか？これを行う最良の方法は何ですか？
MySQLは非常に広くサポートされており、これは本当に簡単なことなので、私はそれを使用することをお勧めします。サーバーに少なくとも数GBのメモリがない限り、インメモリシステムを使用するのではなく、MySQLを使用することをお勧めします。
MySQLであるかどうかに関係なく、データをデータベースに格納し始めると、さらに多くの用途があることに気付くでしょう。ここでは、キーと値のペアについてのみ説明していますが、製品に関連する残りのデータはどこかに保存する必要があります。それがデータベースにない場合、データストレージが非常に効率的であるとは思えません。
何をするにしても、しないでください 300万個のファイルを作成します。多くのファイルが作成する問題からすでにここにいくつかの質問が出てきました。
この種のタスクには、最適化であるNoSQLデータベースの専用のKey-Valueタイプを使用できます。見て：
- Redis -Redisはオープンソースの高度なKey-Valueストアです。キーには文字列、ハッシュ、リスト、セット、およびソート済みセットを含めることができるため、データ構造サーバーと呼ばれることがよくあります。
- MemcacheDB -MemcacheDBは、永続化のために設計された分散型Key-Valueストレージシステムです。
- その他（そのようなリストの1つはここにあります： http://nosql-database.org/ ）
もちろん、MySQLやその他のリレーショナルデータベースを使用することもできますが、ソリューション特により優れていると考えられるデータのキー値タイプ用に設計されています（それ以外の場合、おそらく（RAM and HDD）ソリューションに関して）はるかに小さくなるという事実。
そして今、完全に異なる何かのために：
与えられた：
- 180MB/3M製品=平均62バイト/製品。
- 1日あたり30,000クエリ= 1秒あたり0.34クエリ
- 四半期ごとに更新=本質的に静的なデータ
箱から出して解決策：
各製品をTXTリソースレコードとしてダンプし、DNSに保存します。例：
$Origin products.example.com.
product_1_name IN TXT "product 1 description"
product_2_name IN TXT "product 2 description"
...
product_3000000_name IN TXT "product 3000000 description"
利点：
- 非常に信頼性が高く、信頼されています（すでに毎日それに依存しています）
- ほぼすべてのプラットフォームで構築可能
- ほとんどすべての言語が何らかの形でDNSクエリをサポートしています
- オープンソースおよび商用サーバーは、さまざまな種類のバックエンドデータベースをサポートします
- 簡単に複製できる（複数のネームサーバーを指定するだけ）
- 12のサーバー間で複製された場合でも、アトミック更新を処理します
- データの整合性を確保するために暗号で署名できます
- 1秒あたりの桁数が高いクエリを処理できます（1秒あたり10,000クエリsecondは、市販のハードウェアで簡単に処理できます）
これが悪い考えかもしれない理由：
- データを検索する必要があります（DNSは純粋にキー/値のルックアップです）
- データを非表示にする必要があります（DNSには機密性はありません）
MyISAMといくつかの優れたインデックスを備えたMySQLは、これにぴったりです。もちろん、他にもたくさんのオプションがありますが、MySQLは、（普遍的ではないにしても）非常に広く、あらゆる商用Webホストでサポートされています。必要な速度によっては、 memcachedも検討に値するかもしれません ですが、各キー/値のペアのサイズがわからない場合、それらの300万個をメモリに格納することは、180Mbよりもさらに悪い考えです。 CSVファイル（まあ、それは180MbのCSVファイルなので、その大きさがわかります。かなり小さいペアでなければならないので、memcachedの方が優れている可能性があります）。
300万個の静的HTMLファイルを必要とするしないと、ファイルシステムに深刻な悪影響を及ぼします。 S3でも、1行のCSVで同じ問題が発生します。 1つのフォルダに300万個のファイルが必要な人は誰もいません。
Perl5の誕生以来流行っていなかったとしても、まさにこの種のことを行うBerkeley Databaseを使用できます。 Berkeleyはキーと値のペアのみをサポートし、db全体をハッシュに結び付けて、それにアクセスします。
Berkeleyの使用については、シェルフにある古いPerlリファレンスの多くで詳しく説明されています。または、 BerkeleyDB CPANモジュールのPerldoc を試してください。私は通常、バークレーDBの使用を避けます（私の雇用者は、コードが目立つように機能する非常に古いコードを使用していますが、一部のDBはあなたのサイズと同じです）。データが複雑になると面白くないので。
質問にAmazon S3のフラグを付けました。
Amazon SimpleDBと呼ばれる他の関連製品の1つに注意を向けたいと思います。
SimpleDBデータモデルは、ご使用のタイプのアプリケーションにうまく適合するようです。
これはプラグインではありませんが、Amazonクラウドサービスの使用を計画している場合は特に検討する価値があります。
SDBデータモデルはスプレッドシートに似ています。
詳細については、こちらをご覧ください： http://aws.Amazon.com/simpledb/ そしてデータモデル： http://docs.amazonwebservices.com/AmazonSimpleDB/latest/ DeveloperGuide /
180 MBのデータはどのリレーショナルデータベースでも簡単に処理できますが、MySQL、Redis、MemcacheDB、およびその他のより単純なKey-ValueよりもMongoDB（ http://www.mongodb.org/ ）を強くお勧めしますストアまたはリレーショナルデータベース。その理由は、この種の問題では、MongoDBが最も高速で表現力に優れたシステムであり、スキーマの制限なしに超高速の動的更新が可能であるため、必要に応じてドキュメントの形式を変えることができるためです。私は先日、guardian.co.ukからのプレゼンテーションに出席していましたが、すべてのリレーショナルデータベースを禁止し、MongoDBを排他的に使用してニュースを提供するという方針決定を下しました。あなたは彼らのウェブサイトがどれほど速く、1995年以来オンラインになっているのか（英国で最も古いオンライン新聞）の感触をつかむことができます。また、リレーショナルデータベースが原因で、過去にあらゆる種類のボトルネックが発生しています。 180mbの場合、MongoDBはインメモリからすべてを提供するため、サブmsの読み込み時間がかかる可能性があります。
これを行う最良の方法は、実際にはデータとクエリの品質と性質に依存します。手始めに、製品の単一のテーブルにある180MBのデータは、どのように見ても問題ではありません。また、1日あたり3万回のクエリでも問題は少なくなります。データベースが適切に構成されていれば、古いデスクトップはこの負荷を処理できます。
MySQLまたはnoSQLデータベースという2つの主要なオプションをすでに指摘している人もいます。
すべての単一の製品に存在する特定の数の属性（メーカー、価格、倉庫番号など）がある場合、これらの属性の列を用意し、キーと値のペアをフラットテーブル形式に変換することをお勧めします。そのテーブルの主キーとして製品IDを使用します。ほとんどの製品ではすべての属性を取得するために1つのクエリを実行するだけでよいため、一部の列が行の半分だけで使用されている場合でも、これは非常にうまく機能します。これは製品に関するデータです。これがデータの構造である可能性は非常に高いと思います。
属性の存在とデータ型が大きく異なる場合は、このシナリオを従来のSQLデータベースよりも効率的に処理するnoSQLデータベースを使用することをお勧めします。
パフォーマンスに関して：私は以前、eコマース企業で働いていました。長い間、WebサイトにはMySQLサーバーからのデータが提供されていました。このサーバーには2GBのRAMがあり、データベースの合計は約でした。サイズが5GBで負荷が高い状態で、サーバーは1秒あたり数千のクエリを処理しました。はい、多くのクエリ最適化を行いましたが、これは間違いなく実行可能です。
1日に約30,000のクエリがありますが、クエリは非常に単純なキー値ストアです。製品IDを検索して残りの情報（すべて1つのレコードに含まれる）を表示するだけです。
クエリは単純なキールックアップであり、バイナリ検索では最悪の場合21回の反復が必要であり、ハッシュキーを使用するとクエリがさらに高速になると述べました。 300万件のレコードは、結合（または他のデカルト積タイプの演算）および線形検索を回避する限り、小です。
だいたい何でもうまくいくと思います。負荷が30000クエリ/日であることは、（負荷が1日を通して一定であると仮定すると）20秒ごとに1つのクエリがあることを意味します。それは悪くないです。
まず、最もよく知っているテクノロジに実装してから、これが本当にシステムのボトルネックかどうかを測定することをお勧めします。