回答編集履歴
3
誤字を修正しました
test
CHANGED
|
@@ -18,20 +18,20 @@
|
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
なお、LevelDB に動画のような巨大なデーターを直接格納するのは無理です。なぜなら、API として、メモリー上にあるキーバリューを、まるごと put、または、get することしかできないからです。数GBあるデーターをアプリ側でメモリーに読み込んでから、DB に格納するのは非効率ですよね。また、動画の場合はデータの途中から少しずつ読みだすといった操作も必要ですが、LevelDB では、このような操作はできません。
|
|
21
|
+
なお、LevelDB に動画のような巨大なデーターを直接格納するのは無理です。なぜなら、API として、メモリー上にあるキーバリューを、まるごと put、または、get することしかできないからです。数GBあるデーターをアプリ側でメモリーに読み込んでから、DB に格納するのは非効率ですよね。また、動画の場合はデーターの途中から少しずつ読みだすといった操作も必要ですが、LevelDB では、このような操作はできません。
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
|
25
|
-
本当は C++ から呼びだせて、こういう目的に適した専用のデータストアがあればいいのですが、ちょっと思い当たりません。
|
|
25
|
+
本当は C++ から呼びだせて、こういう目的に適した専用のデーターストアがあればいいのですが、ちょっと思い当たりません。
|
|
26
26
|
|
|
27
27
|
|
|
28
28
|
|
|
29
|
-
大きなデーターを Level DB などに格納するためによく使われる手法の一つに、チャンキングがあります。これは、そのまま格納するには大きすぎるデータを、アプリ側で適当な大きさ（数KBくらい）に分割してから格納する方法です。以前、仕事で LevelDB を使って、
|
|
29
|
+
大きなデーターを Level DB などに格納するためによく使われる手法の一つに、チャンキングがあります。これは、そのまま格納するには大きすぎるデーターを、アプリ側で適当な大きさ（数KBくらい）に分割してから格納する方法です。以前、仕事で LevelDB を使って、QEMU（仮想マシン）の実験的なストレージドライバを開発したことがあるのですが、そのときは、まあ普通に使えるくらいには動いていました。ちなみに、その時、チャンキングのサイズは、ゲスト OS として使われる Linux のファイルシステムのブロックサイズに合わせて 4KB にしました。よく数MBでチャンキングしてるのを見かけるのですが、これだとあまり性能が出ないと思います。
|
|
30
30
|
|
|
31
31
|
|
|
32
32
|
|
|
33
|
-
もうひとつのよくある方法は、LevelDB はメタ情報（画像データのファイル名、作成者、アクセス権などの情報）だけの格納に使って、画像の本体は、ファイルシステムにファイルとして格納することです。ファイル数がよほど多くならない限りは、この方法のほうが、チャンキングよりも性能が出ます。ただ、ファイルシステムでは、１つのディレクトリーに数万というファイルを入れると動きが鈍くなるので、適当にディレクトリーを分けてあげる必要があります。
|
|
33
|
+
もうひとつのよくある方法は、LevelDB はメタ情報（画像データのファイル名、作成者、アクセス権などの情報）だけの格納に使って、画像の本体は、ファイルシステムにファイルとして格納することです。ファイル数がよほど多くならない限りは、この方法のほうが、チャンキングよりも性能が出ます。ただ、ファイルシステムでは、１つのディレクトリーに数万というファイルを入れると全体的な動きが鈍くなるので、適当にディレクトリーを分けてあげる必要があります。これは、例えば、親のディレクトリーの名前に、キーのハッシュ値の一部を使うといった方法で実現できます。あと、ファイルシステムも、inodeというファイルやディレクトリーを管理するためのデーター構造に B-Tree インデックスを使っているので、格納したファイルの数があまりにも大きくなると、性能が大きく落ちます。
|
|
34
34
|
|
|
35
35
|
|
|
36
36
|
|
|
37
|
-
どちらを選ぶかは、うーん、データー件数に依存するのですが、数億件程度でしたら、後者のほうが作るのも簡単で、性能も出るのでいいと思います。ただ、ハードドライブの容量はいまでも大きくなり続けていますし、サーバーだと30台以上搭載することもできますので、もし、そういうレベルの件数を想定しているなら、簡単なアプリを試作して、実際にテストしてみることをおすすめします。
|
|
37
|
+
どちらを選ぶかは、うーん、データー件数に依存するのですが、数億件程度でしたら、後者のほうが作るのも簡単で、性能も出るのでいいと思います。ただ、ハードドライブの容量はいまでも大きくなり続けていますし、サーバーだとハードドライブを30台以上搭載することもできますので、もし、そういうレベルの件数を想定しているなら、簡単なアプリを試作して、実際にテストしてみることをおすすめします。
|
2
日本語のおかしなところを修正しました
test
CHANGED
|
@@ -2,11 +2,11 @@
|
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
5
|
-
LevelDB は格納できるキーバリューのサイズに制限を設けていないので、画像データ（数百KBから数MB）を格納することは物理的には可能です。が、その用途に
|
|
5
|
+
LevelDB は格納できるキーバリューのサイズに制限を設けていないので、画像データ（数百KBから数MB）を格納することは物理的には可能です。が、その用途に向いているかというと、そうではありません。
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
9
|
-
理由は、LevelDB では、キーバリューをディスクに格納する際、数百から数十万というキーバリューを
|
|
9
|
+
理由は、LevelDB では、キーバリューをディスクに格納する際、数百から数十万というキーバリューを１つのファイル（SSTable と言います）にまとめないことには、性能を発揮できないからです。SSTable の中では、キーバリューをキー順でソートしておかなければならないのですが、LevelDB はそのソートをメモリー上で行います（キーバリューを MemTable というメモリー上のデーター構造にいったん蓄えます）。メモリーをあまり圧迫しないように、LevelDB は MemTable のサイズをできるだけ小さく保とうとします。すると、１つの SSTable に格納できる画像の数も減ってしまい、結局、画像を直接ファイルシステムに格納するのと、大差なくなってしまいます。
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
@@ -18,7 +18,7 @@
|
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
なお、LevelDB に動画のような巨大なデーターを直接格納するのは無理です。なぜなら、API として、メモリー上にあるキーバリューを、まるごと put、または、get することしかできないからです。数
|
|
21
|
+
なお、LevelDB に動画のような巨大なデーターを直接格納するのは無理です。なぜなら、API として、メモリー上にあるキーバリューを、まるごと put、または、get することしかできないからです。数GBあるデーターをアプリ側でメモリーに読み込んでから、DB に格納するのは非効率ですよね。また、動画の場合はデータの途中から少しずつ読みだすといった操作も必要ですが、LevelDB では、このような操作はできません。
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
1
文章の前後関係に不自然なところがあったので、修正しました
test
CHANGED
|
@@ -22,7 +22,7 @@
|
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
|
25
|
-
本当は C++ から呼びだせて、こういう
|
|
25
|
+
本当は C++ から呼びだせて、こういう目的に適した専用のデータストアがあればいいのですが、ちょっと思い当たりません。
|
|
26
26
|
|
|
27
27
|
|
|
28
28
|
|