kiyoka.2011_08_04 RSSPLAIN

Related pages: !kiyoka.blog.list !kiyoka.blog.2011_08
55555555555555555555555555555555555555555555555555555555555
5

[アイデア][KVS] SQLiteをKVSのストレージに使う(アイデアのみ)

5
 nosql-logo
5

SQLiteのテストスイート項目数の多さは有名だ。項目数の多さが欠陥の少なさを示しているわけではないが相関はあるだろう。

5

こいつをKVSのストレージとして使えば、ソフトウェアのバグによるデータ破損が発生しにくいKVSが実現できるのではないかというアイデア。

5

 

5

KVSは星の数ほどあるが、コードの信頼性の評価は難しい。

5

普及率も把握できないし、参考にできるのは、どこそこのサイトで実運用しているという情報だけというのが正直なところ。

5

そこで、SQLiteをバックエンドに持つKVSを使えばSQLiteの枯れたコードを利用して信頼性を確保できる。

5

SQLiteはiPhoneやAndroid、ThunderBirdにも入っているため、コードはななり枯れていると推測できる。

5

 

5

そのようなソフトウェアをちゃっちゃとでっち上げるとすれば、きっとNoSQLiteという名前になるだろうなー。

5

と思ってGoogleで検索してみると… もう既にあった。

5

 

5
 DBIx::NoSQL - search.cpan.orgEXT
5
  DBIx::NoSQL - NoSQL-ish overlay for an SQL database
5
 
5
 DESCRIPTION
5
  DBIx::NoSQL is a layer over DBI that presents a NoSQLish way to
5
  store and retrieve data. It does this by using a table called
5
  __Store__. Once connected to a database, it will detect if this
5
  table is missing and create it if necessary
5
  
5
  When writing data to the store, the data (a HASH reference) is first
5
  serialized using JSON and then inserted/updated via DBIx::Class to
5
  (currently) an SQLite backend
5
  
5
  Retrieving data from the store is done by key lookup or by searching
5
  an SQL-based index. Once found, the data is deserialized via JSON
5
  and returned
5
  
5
  The API is fairly sane, though still beta
5

 

5

同じ作者のgithubを見に行ってみると。

5

過去の作品だと思われる、同様のものがあった。

5

 

5
 robertkrimen/FutonDb - GitHubEXT
5
  FutonDb - A NoSQL-ish overlay for an SQL database
5

 

5

作った動機はわからないけれども、作品はあるわけで、同じことを考える人はいるんだなぁと思った。

5

 

5

ついでにPythonにも同様のものがあったり。これはオブジェクトをシリアライズして保存するやつだけど。

5
 y_serial – warehouse compressed Python objects with SQLite — y_serial v0.60 documentationEXT
5
  y_serial = serialization + persistance. In a few lines of code,
5
  compress and annotate Python objects into SQLite; then later
5
  retrieve them chronologically by keywords without any SQL. Highly
5
  useful NoSQL “standard” module for a database to store schema-less
5
  data.
5

 

5

さて、SQLiteをバックエンドストレージにした場合、パフォーマンスは出ないだろうからKVSである必要性が無いんだよなーという、やはり本質的なところに戻ってきてしまった。

5

きっと、超高速なKVSの裏方でレプリケーションスレーブにしてバックアップ専用に使うとかが現実的なのかな。

5

例えば、次のような構成かな。

5
 Tokyo Tyrant => レプリケーション => NoSQLite(SQLite内蔵)
5
 または
5
 Kyoto Tycoon => レプリケーション => NoSQLite(SQLite内蔵)
5

 

5

なんか、KVSのインタフェースを持つ必要性がうぃんあらなくなってきたぞ。あれれアイデアが破綻した…(笑)

5

 

5

 

5

...comment disabled...