#leveldb

[seniordba]

LevelDB and Chromium Browsers

LevelDB is a fast and lightweight key-value storage library that is used by many applications, including web browsers. In this blog post, we will briefly explain how LevelDB is used with Chrome and Edge browsers in Windows 10, and what benefits it provides to locating user data. How it Works Chrome browsers, including the Microsoft Edge browser, is based on Chromium. Chromium is the open-source…

View On WordPress

[sage-t]

caffeのデータ操作

CaffeはデータをProtobufの形で管理します。 各種ツールを使えばほとんど気にすることなくCaffeを使えますが、せっかくなので少し詳しく見てみます。

なお、この記事はCaffeについてのように見えますが、その実はLevelDBのpythonでの使い方です。 実際の例として、Caffeを当たっている感じです。 根気よく読んでくだされば、caffeを知らなくてもprotobufメッセージを保存したLevelDBのpythonのアクセス方法としても使えるかと思います。その場合は、目次の2番目から参照してください。

目次

普通の方法でDBを作る

DBの中を見てみる

自分の力でDBを作る

普通にツールを使ったとき

まず、学習させたい画像ファイルをまとめたフォルダを用意します。

data_root -+- label_1 -+- a1.png | +- b1.png | +- c1.png | : +- label_2 -+- a2.png | +- b2.png | +- c2.png | : : :

というフォルダ構造を考えます。これらをリストアップしたファイルを作ります。

file_list.txt

label_1/a1.png 1 label_1/b1.png 1 label_1/c1.png 1 label_2/a2.png 2 label_2/b2.png 2 label_2/c2.png 2

フォーマットは

data_rootからのファイルパス label

となります。ファイルパスはスペースを含まないように。

端末（シェルかコマンドプロンプト）から、

convert_imageset.exe -backend leveldb path/to/data_root/ file_list.txt test_leveldb

としますとこのフォルダにtest_leveldbができ、この中にlevelDBの形でデータが保存されています。

なお、path/to/data_root/とfile_list.txtに記載するファイルパスは、これらの文字列をつなげたらその画像に尋ね当たれば大丈夫です。

pythonでの読み出し

PythonのLevelDBモジュールを用意しましょう。前回の記事を参照。

参考までに、Caffeが管理するメッセージの構造を見てみます。

https://github.com/BVLC/caffe/blob/master/src/caffe/proto/caffe.proto

Caffeがプログラム中で使っているDatum(入力や状態ベクトルの管理のための構造体)などがProtocol bufferの文法で定義されています。

このcaffe.protoファイルをどこかローカルに用意して、protocol bufferのコンパイラprotocに対して

protoc.exe caffe.proto --python_out=.

とすると、このフォルダにcaffe_pb2.pyができます。pythonからこれをimportすれば、caffeが定義しているprotobufのメッセージの構造を見ることができます。

caffeのprotobufだけならすでにコンパイルしたものがpycaffeに含まれています。

data = caffe.proto.caffe_pb2.Datum()

これでcaffeが入力データに使っている構造体を作れます。

protobufのpythonパッケージはpip install protobufで大丈夫かと。

では、データベース名を渡されたら順番に読み込み、OpenCVで表示する関数を定義してみます。

import numpy as np import leveldb import caffe import cv2 def read_db(db_name): db = leveldb.LevelDB(db_name) it = db.RangeIter() # db.Get(key) for key, val in it: print key data = caffe.proto.caffe_pb2.Datum() data.ParseFromString(val) img = caffe.io.datum_to_array(data) img = np.rollaxis(img, 0, 3) cv2.imshow("test", img) cv2.waitKey() cv2.destroyAllWindows()

rollaxisは、Datum中（色、 縦、横）とOpenCV中（縦、横、色）では配列の順番が異なるためです。 14行目のcaffe.io.datum_to_arrayを使わない場合、この行を

c = data.channels w = data.width h = data.height img = np.fromstring(data.data, dtype=np.uint8).reshape((c, h, w))

と変えても大丈夫です。reshapeの引数を(h, w, c)とすれば、rollaxisもいりません。

RangeIterはleveldbのkeyを順番に見ていくイテレータです。forループを回すことで、すべての保存データを見ています。 もし、keyが何か分かっている場合は

key, val = db.Get(key)

でもlevelDBから読みだせます。

pythonでの書き出し

Caffeのツールで作ったLevelDBと同じものを作ることを目指してみましょう。

方針としては、画像を読み込み、caffe用のビット配列にし、Messageを構築して、 ビット列にエンコードしてleveldbに書き込み。

画像を保持するディレクトリパスを与えたらその中の画像を読み込んで順番にdb_nameに押し込んでいく関数です。 フォルダ内に画像ファイル以外のものがあるとエラー出ます。

import numpy as np import leveldb import caffe import os import cv2 def write_db(img_dir, db_name): imgs_fns = os.listdir(img_dir) db = leveldb.LevelDB(db_name) idx = 0 for fn in imgs_fns: abs_fn = img_dir + "/" + fn img = cv2.imread(abs_fn) # OpenCVで画像読み込み key = "{0:0>8}_{1}".format(idx, fn) data = caffe.proto.caffe_pb2.Datum() # 構造体生成 data.height, data.width, data.channels = img.shape # 画像サイズセット data.encoded = False # 生データ保存 img = np.rollaxis(img, 2, 0) # 添字の順番変更 data.data = str(bytearray(img)) # データをバイト列に db.Put(key, data.SerializeToString()) # Datumインスタンス全体をバイト列にしつつデータベースに送信 idx += 1

"{0:0>8}_{1}".format(idx, fn) というのは、Caffeでのkeyのフォーマットは{id 8桁}_{file名}ですので、それに合わせています。

data.data = str(bytearray(img)) はもうちょっと簡単なのがあるかもしれません。

これを実行すれば、db_nameのフォルダができて、Caffe用のLevelDBができていて、caffe学習に使える、かもしれません。

なお、Caffeのioを使って画像を読み込むこともできます。その場合、13行目を

img = caffe.io.load_image(abs_fn) img[:, :, :] = img[:, :, -1::-1]

とすればよいです。後ろの1行は何しているかというと、load_imageで普通に読み込むとチャンネルがRGB順ですが、OpenCVやデータベース中ではBGR順になっているので、それに合わせるため、チャンネルの次元をひっくり返しています。

その他

なんでこんなめんどくさいことを調べたかというと、3nチャンネルの入力データのLevelDBを手作りしたかったからです。

まあおかげでpythonからpycaffeにデータを渡す方法が分かりましたが、それはまた今度気が向いたら。

[sage-t]

LevelDB python

pythonのモジュールにleveldbがあります。

Windowsの方で少々インストールに手間取ったのでメモしておきます。

LevelDB はGoogleによるNoSQLデータベース。

MySQLみたいなRDBMSとは違って、一つのアイテムにつき、Keyとvalueを紐づけてそのアイテムごとに管理するシステムを取っています。

まあ、ハッシュみたいな感じでとらえています。 すごいいっぱいのデータを扱えるように、メモリアクセスの効率をすごい頑張っているていう認識です。

メッセージとデータ

データベースのストレージに書き込むにあたって、おそらく文字列、数値いろんなデータ型を保存したいかもしれませんが、valueはただのバイト列しか取れません。 何等かのバイト列データをvalueに押し込め、一意なバイト列のKeyでタグ付けしてデータベースに保存します。

いろんなデータ型を扱えるようにするために、任意のオブジェクト型⇔バイト列の変換を実現するメッセージのフレームワークが役に立ちます。

そういったデータとバイト列の変換の関数を整えたりして、メッセージ授受を便利にしたライブラリとして、MessagePackやGoogleの開発したprotocol bufferがあります。StringifyしたJSONもメッセージとして使えますが、すこし重たいです。

極端な話、Cの構造体を思い出してみれば、どんな構造体でもメモリ上の配置は決まっていますので、そのメモリをそのままバイト列にして送受信してもヘッダさえあればデータをもとに戻せます。

メッセージ送受信についての話は馬鹿にできません。MPIによる並列計算も、プロセス同士でメッセージをやり取りして並列計算を実現しています。オブジェクト指向ではインスタンス同士がメッセージをやり取りするという描像も見たことがあります。つまり神羅万象はメッセージです。

閑話休題。

LevelDBとProtocol bufferの組み合わせは例えばCaffeが使っています。 というか僕はそれで知りました。

Python

やっぱりインタプリタ型言語から使えたら何かと便利です。 ということでpythonのモジュールを使ってみます。

Gentooでしたら

# pip install leveldb $ python >>> import leveldb >>> db = leveldb.LevelDB("test_levelDB") >>> db.Put("key1", "hogehoge") >>> x = db.Get("key1") >>> x 'hogehoge'

となり、実行したディレクトリに「test_levelDB」というディレクトリができています。 中は絶対パスの情報はないと思いますので、適当にmvしても大丈夫でしょう。

Windows

Windowsではインストールが少々めんどくさいです。というのも、

> pip install leveldb Collecting leveldb Downloading leveldb-0.193.tar.gz (224kB) 100% |################################| 225kB 1.3MB/s No files/directories in c:\users\sage\appdata\local\temp\pip-build-2gw0js\leveldb\pip-egg-info (from PKG-INFO)

というエラーが出てインストールできません。 ソースコードをcloneしても同じです。

ちょうどいいリポジトリを提供してくれている人がいました。

https://github.com/happynear/py-leveldb-windows

これをgit cloneします。 そして、leveldb_ext.slnをVisual Studio 2013以上で開き、設定を更新。2015だったので、なんとなくtoolsetを2013にしました。

Pythonのライブラリのパスが、なぜかD:\Python27にインストールされていること前提の設定ですので、Python.h not foundとか言われるかもしれません。その場合、プロジェクトのプロパティから、追加のインクルードディレクトリと追加のリンク依存ディレクトリのパスでpythonのものを修正しましょう。大丈夫、先頭にあるのですぐ分かります。

できたx64\Releaseフォルダ中のleveldb.pydを、python_root\Lib\site-packagesに移動。

pythonを立ち上げ、

import leveldb >>> db = leveldb.LevelDB("test_levelDB") 以下略

という感じで、同様にできます。

しかし、pythonの本体がVS2008ビルドなのに、これはVS2013で文句言われないのなんでなんだろう。

とっぴんぱらりのぷぅ

[klaas-loclet-blog]

Using SnappyDB for Caching

Tried out SnappyDB today. SnappyDB is a fast key value store for Android, which uses Google’s native LevelDB along with the Snappy compression algorithm, also from Google.

Setup and usage is dead simple. Add these two lines to your build.gradle:

compile 'com.snappydb:snappydb-lib:0.5.0' compile 'com.esotericsoftware.kryo:kryo:2.24.0'

The first dependency is SnappyDB itself, the second one is Kryo, a framework which is used for object serialization underneath. Call .open to open a database (or create it on first access):

private DB cache; ... // Create/open the cache try {    cache = DBFactory.open(context, CACHE_DB_NAME); } catch (SnappydbException e) {    Log.e(getClass().getSimpleName(), e.getMessage()); }

Inserting an object is as simple as

// Put the region in the cache cache.put(region.getId(), region);

where region is a POJO I want to cache and the first argument is a unique String identifier used as the key. To retrieve an object from the cache, use .getObject:

Region r = cache.getObject(id, Region.class);

You may check for existence with .exists:

if (cache.exists(id))    ...

The cool thing is that you can store and retrieve any POJO as long as Kryo can figure out how to serialize it. You do not need to implement Serializable, nor do you need to modify your model classes in any way.

Well, that’s almost true. You must make sure your model classes obey the following three rules:

The class must have a default (no-arg) constructor.

The class must not have any (non-static) inner classes.

Any classes referenced in fields of your model class must also obey 1. and 2.

The third one took me a while to figure out, as the exception thrown by Snappy (or rather by Kryo) will tell you 

com.snappydb.SnappydbException: Maybe you tried to retrieve an array using this method ? please use getObjectArray instead Class cannot be created (missing no-arg constructor): com.[...]

and you need to carefully read which class is causing the problem. At first, you may find yourself staring in confusion at your model class with its beautiful no-arg constructor, when the problem is really a class referenced in a field of your model that doesn’t have one.

The same goes for inner classes: Kryo may complain that

com.snappydb.SnappydbException: Maybe you tried to retrieve an array using this method ? please use getObjectArray instead Class cannot be created (non-static member class): com.[...]

which means you may need to refactor your model class (and/or its child classes), moving any private inner classes to their own file, making them public and giving them a no-arg constructor. I had to do this for an optimized spatial data structure I was attempting to cache and it was kind of tedious. However, Kryo has its reasons for not storing inner classes and for most of your POJOs this will likely never be an issue.

So the first impression is actually pretty awesome: SnappyDB feels - well - snappy. Cache retrieval for region data in the LOCLET app is on the order of a few milliseconds and there’s virtually no coding overhead for storing stuff (apart from the potential need to refactor some of your model classes). Conceptually, it feels like the right choice for saving simple data in a lightweight fashion.

As a final caveat, beware that SnappyDB itself is not thread-safe (LevelDB underneath is, though). So if your app requires concurrent access, be sure to synchronize your writes/reads manually:

synchronized (cache) {    cache.put(region.getId(), region); }

[txgruppi]

[openbooth]

LevelDB Benchmarks

via Pocket http://ift.tt/pRjywR

[ctnt]

A framework for easily creating beautiful presentations using HTML

[truedat101-blog-blog-blog]

A must read on leveldb