最近、偶然、 FAL Labsの製品-Kyoto Tycoon （軽量のデータサーバー）が目を引きました。 この製品の基礎は、キーバリューデータウェアハウスであるQDBM （Quick Database Manager）です。 memcachedに似たプロトコルを介して、この「京都のタイクーン」と通信できることに夢中になりました。
MemcacheDBをしばらく使用しているので、それらの特性を比較したい（通信プロトコルは1つだけであり、NoSQLキー値ストレージがあります）。 最近、便利なケースが見つかりました-ある量のデータを1つの自作ストレージからMemcacheDBにエクスポートしました。 テストでは、同じサーバーにKyoto Tycoonを展開するだけです。
ここに私が得たものがあります：
テストしたサーバーは、 Opteron-2218、2.6GHz、8G OP、HDD 73G + 143G sasでした。
73ギガバイトのディスクにはインポートされたデータを含むファイルがあり、143ギガバイトのデータベースにはMemcacheDBとKyoto Tycoonがありました。
初期データ-10226086レコード、合計ボリューム（キー+値）1.4G。
データサーバーは次のコマンドで起動します：
$ ktserver -port 11114 -tout 10 -log /var/db_tests/kyoto/ktserver.log -ls -dmn -pid /var/db_tests/kyoto/ktserver.pid -plsv /usr/local/libexec/ktplugservmemc.so -plexポート= 11115 '/var/db_tests/kyoto/data.kch#opts=l#bnum=20000000#msiz=2g#dfunit=8'
$ memcachedb -p11117 -d -r -u sen -H / var / db_tests / mcdb / db / -N -v -P /var/db_tests/mcdb/mcdb_tests.pid
結果 ：
1.データのインポート：
-京都タイクーン-18分52秒
-MemcacheDB-32分39秒
2.データの読み取り（ログのキーのリストによると、データは対応するデータベースから選択され、チェックサムは検証のために考慮されました）：
-京都タイクーン-9分46秒 （キャッシュをリセットするためにデーモンを再起動し、結果は4秒悪化しました）
-MemcacheDB-19分35秒
3.「レーシング」（両方のデータインポートスクリプトを同時に起動）：
-京都タイクーン-1時間。
-MemcacheDB-1時間38分
日本語が終わる頃には、MemcacheDBはエントリの総数の3分の1をアップロードしていました。
どうやら、サーバー上の毎日の負荷の増加は、このような長い「一般的な」競争のせいでした。 残念ながら、完全にクリーンなサーバーはありませんでした。 しかし、私はこのプロセスに加えて、プロセスへの余分な影響を少なくともわずかに滑らかにするために、より自由な時間と2回で他のテストを開始しました。
さらにいくつかの特徴 ：
1.データファイルサイズ：
-Kyoto Tycoon-2.15G（データ損失なしで1.87Gに「縮小」し、明らかに空のブロックを解放した）。
-MemcacheDB-4.56G
2.占有RAMのサイズ：
-京都タイクーン-2.45G。 彼が許可された金額に加えて、コードと個人的なニーズを正直に借りました。
-MemcacheDB-208Mb。
この3回のテストで、2つの製品の比較を終了し、設定を変更するKyoto Tycoonを少し苦しめました。 使用されるデータストレージスキームはハッシュであるため（バイナリツリーを使用したバリアントも可能）、ハッシュテーブルの基本サイズがパフォーマンスに影響を与えると説明されており、格納されているレコード数の約2倍に設定することが推奨されています。 私のタスクではレコードの数が絶えず増加しているため、この数がベースハッシュの指定サイズを大幅に超える場合、速度の低下がどれほど深刻かが重要です。
さまざまなパラメーターを使用したKyoto Tycoonのテスト結果（上記のコマンドで変更したもののみを示します）：
1. bnum = 5,000,000（4倍に削減、レコード数の2倍）-17分28秒
2.bnum = 2,000,000-17分45秒
3.bnum = 5,000,000＃msiz = 1g（キャプチャされたRAMのサイズを半分にした）-18分23秒
4. bnum = 5,000,000＃msiz = 500m（半分）-19分15秒
5.データファイルのパラメーターなし（オプション、ユーザーがチューニングを行わない場合、サーバーはマニュアルからコマンドをコピーして起動します）：
-データのインポート-22分 4秒
-データの読み取り-11分 47秒
このテストパッケージを1回実行しました。 結果の違いは小さく、誤差の範囲内です。 おそらく、データファイルパラメーター（既定で設定）がない場合、結果は少しノックアウトされます。 どうやら、デフォルトの設定はかなり控えめです-メモリ内のサーバーは約400メガバイトしか占有しません。
もう制限を気にしませんでした。 電話をかけ、設定を試して、どの段階で店が窒息し始めるかを見てみましょう。 私にとっては、Kyoto TycoonはMemcacheDBよりも負荷を保持していると結論付けました。 おそらく次のプロジェクトでそれを使用します。
さらに、Kyoto TycoonはMemcachedなどの純粋なメモリキャッシュとしても使用できます。 開発者は、場合によっては勝つことさえあると主張しますが、比較テストはありませんので、ドライブチェックするのはいいことだと主張しています。
この説明で特に気に入ったのは、「堅牢性の向上：壊滅的な状況でもデータベースファイルが破損しない」ことです。開発者は、この根拠のないことは考えにくいため、確認したい人がいるでしょう。
PS。 実際、MemcacheDBとKyoto Tycoonの表面的な比較、およびもう少し詳細なテスト-Kyoto Tycoonを入手しました。 いずれにせよ、私は耳から結果を引き付けませんでした、私は私が支援したプロジェクトの1つからの実際のデータで働きました。
PPS。 京都タイクーンに加えて、FAL Labsにはいくつかの興味深いプロジェクトがあります。 たとえば、 Estraierは個人用の全文検索エンジンであり、 Hyper Estraierはコミュニティ検索エンジン（違いですが、私は理解していませんでした）、 Tokyo Promenadeは軽量CMSです。 これらの製品がどれほど優れているかを理解することは興味深いでしょう。
UPDT 最後のテストの結果を分析すると、Kyoto Tycoonサーバーを起動した後、保存のためにデータを送信する前に5〜10秒待機することをお勧めします。 テスト中に、新しいパラメーターでサーバーを再起動し、すぐにデータの送信を開始すると、約16,000の最初のレコードが失われました。 つまり 最初の2秒間、データローダーは頭を壁にぶつけました。 すでに実行中のサーバーで作業する場合、損失はありませんでした。 このような遅延は正常です-データフィールドのマークアップ、作業の準備。
UPDT2。MemcacheDBのデフォルトのキャッシュサイズは64 Mbであるため、msiz = 64mでテストを実行し、キャッシュサイズを均等化しました。
結果：
-記録-25分43秒
-読書-12分26秒
つまり とにかく、速度は速いです。 しかし、彼は同時に400 MbでRAMを使い果たしました-MemcacheDBの2倍です。
したがって、RAM-損失、ディスク上のデータベースの速度とサイズ-ゲイン（データベースのサイズは約2.5倍です）。
確かに速度の向上は、よりコンパクトなストレージ-ディスク操作の削減によるものです。
UPDT3（2011年3月1日から） 。 上記のテスト中に取得したデータベースのファイルサイズが著しく小さいことに大喜びし、BerkeleyDB（フロントエンドにMemcacheDBを含む）が32ギガのサイズに達した別のプロジェクトにKyoto Tycoonを置きました。 現在、Kyoto Tycoonデータベースファイルは30 Gigの「重量」です。 数ギガバイトしか保存しませんでしたが、違いは何度もありません。 節約は、データのタイプに大きく依存します。 テストでは、十分に圧縮されたテキストデータを使用し、新しいプロジェクトではバイナリデータのブロックを使用しました。 この場合の作業速度については何も言えません。 データベースにデータを入力すると、データが処理されるため、データベース自体よりも時間がかかります
。
MemcacheDBとKyoto Tycoon-エクスプレステスト
All Articles