Kobe Digital Labo, Inc.

岩瀬 高博

Twitter: @okuyamaoo

Mail: ta.okuyamaoo@gmail.com

http://d.hatena.ne.jp/okuyamaoo/

Distributed Key-Value Store

1.自己紹介

2.okuyamaについて

3.新機能のご紹介

4.利用事例のご紹介

アジェンダ

・株式会社 神戸デジタル・ラボ

>神戸を基盤にＩＣＴソリューションを展開

・岩瀬 高博 (Twitter: @okuyamaoo)

>okuyama、ECサイト関係、研究系の案件

>車とか好き. okuyamaの由来もそこから

>活動

>OSS分散キーバリューストア #okuyama を開発

自己紹介

okuyamaとは？

・概要

・全体イメージ

・基本機能

・okuyamaは全てJavaで作られています。

>2009年の12月から開発をはじめ、

現在 Version 0.8.7.2

・全て一からの実装になります。

>開発動機は自身の勉強目的

永続化の仕組み, ネットワークI/O周りの仕組み,

レプリケーションの仕組み全てオリジナルとなります

okuyamaとは?

okuyamaはKey-Value Store

Key-1

Key-2

Key-3

Value-1

Value-2

Value-3

“Key-1”でValueを取得 Key-1 Value-1

“Value-1”が取得できる

Key-4 Value-4

Key-Value Store

>KeyとValueの関係で値を保持できる仕組み

okuyamaはKey-Value Store

データ格納部分を複数に分散できる。

>分散Key-Value Store

Key-1

Key-2

Value-11

Value-22

“Key-1”を“Value-11”へ更新

Key-1 Value-11

Key-3 Value-3

Key-4 Value-44

“Key-4”を“Value-44”へ更新

Key-4 Value-44

複数のノードで

データを管理

・全体イメージ

・Client → Master Node → Data Node(×3)

Master Node

Data Node

Data Node

Client

Client

Master Node Client

Data Node

Data Node

Data Node Data Node

Data Node Data Node

全体イメージ

Data Node

Data Node

Data Node

Data Node

・機能一覧

okuyamaに出来ること

Storage Type

冗長性

データメンテナンス

永続化・非永続化の選択、一貫性レベルの選択 保存先の選択(Memory, Disk, Disk + Memory)

複数台のサーバで構成されており、 サーバ追加も無停止で可能(アルゴリズム分散)

全てのデータは多重化されて保存され 全ての構成要素が多重化可能となっている single point of failureが存在しない

サーバ追加時や、障害時、復旧時の

データ再配置は全て自動で行われる。

Support Protocol Original, memcached, HTTP

可用性

データTag付加機能

JavaScript実行機能

Keyを束ねるTagを設定可能。取得時はKeyの集合、

又はKeyとValueを選択可能。Tagの数は制限なし。

JavaScriptをDataNodeで実行可能。

データの更新も同時に実行可能。

最近追加した機能

・パーティション機能

・ストレージ機能の強化

・全文検索機能

・Key-Value Storeを利用するアプリが

増えてきた場合に発生する問題

パーティション機能

・アプリ単位で環境を用意

・1つのKVSを共有利用

・Key-Value Storeを利用するアプリが

増えてきた場合に発生する問題

パーティション機能

・アプリ単位で環境を用意

・1つのKVSを共有利用

1つのサーバ上に複数のKVS

複数のサーバを用意

管理コストの増大

アプリ側でなんだかの工夫

ロジックに環境依存が発生する

操作ミスなどで他のデータに影響

・okuyamaのクラスター内に領域を作成 ・1つのokuyamaクラスターを複数の用途で共有利用

パーティション機能

・パーティションの容量は可変

>初期設定は不要

・パーティション数の限度はなし

>追加、削除の制限なし

・利用側はMasterNodeのポート単位

>memcachedクライアント等でも意識

せずに利用可能

・内部的にはパーティション単位での

プレフィックス付加での分離

・暗号化などは今後の検討課題

・仮想メモリ機構 ・完全ディスクモード以外の場合にメモリ使用量が

上限に達した場合に自動的にディスクをメモリとして利用

ストレージ機能強化

・Value圧縮機構 ・Valueを保存する際に圧縮し保存する(zipアルゴリズム)

圧縮しても意味がないデータは自動判定

・Valueがメモリモードの場合のみ利用可能

・データファイル遅延書き込み機構 ・トランザクション、データ両ファイルのディスクへの書き込みを

遅延させることが可能

・データ保全性の面ではトレードオフ

全文検索機能 ・標準機能として全文検索機能を搭載

>機能特徴

1.N-Gramを利用した検索Index作成

次のリリースで辞書方式のMixに変更

全文検索機能 ・標準機能として全文検索機能を搭載

>機能特徴

1.N-Gramを利用した検索Index作成

次のリリースで辞書方式のMixに変更

N-Gramを使った方式？

全文検索機能 ・N-Gramを利用した検索Indexの作成

>N-Gramは対象の文字列をN文字で

切り出だす方式。

それを見出しに、文字列への索引を管理

全文検索機能 ・Index作成

N文字の部分を決定して分解

ID=1 Value=“今日は勉強会です”

ID=2 Value=“今日は晴れです”

今日:1

日は:1

は勉:1

勉強:1

強会:1

会で:1

です：1

す:1

今日:2

日は:2

は晴:2

晴れ:2

れで:２

です:２

す:2

2つの表をマージ

今日:1,2

日は:1,2

は勉:1

は晴:2

勉強:1

晴れ:2

強会:1

れで:2

会で:1

です：1,2

す:1,2

N=2

全文検索機能 ・Index検索

検索ワード = “今日 勉強会” Nに合わせて検索ワードも分解

“今日” “勉強” “強会”

全文検索機能 ・Index検索

分解したワードを先ほどのリストから探す

“今日”

“勉強”

“強会”

今日:1,2

日は:1,2

は勉:1

は晴:2

勉強:1

晴れ:2

強会:1

れで:2

会で:1

です：1,2

す:1,2

全文検索機能 ・Index検索

分解したワードを先ほどのリストから探す

“今日”

“勉強”

“強会”

今日:1,2

日は:1,2

は勉:1

は晴:2

勉強:1

晴れ:2

強会:1

れで:2

会で:1

です：1,2

す:1,2

ID:1,2

ID:1

ID:1

取得ID

全文検索機能 ・Index検索

分解したワードを先ほどのリストから探す

“今日”

“勉強”

“強会”

今日:1,2

日は:1,2

は勉:1

は晴:2

勉強:1

晴れ:2

強会:1

れで:2

会で:1

です：1,2

す:1,2

ID:1,2

ID:1

ID:1

取得ID

全てに含まれるID

ID=1

ID=1の文章 “今日は勉強会です”

全文検索機能 ・このN-Gramを利用してIndexを作成

>もう少し特徴を出してみようと

1.辞書方式とのMix

2.N-GramのNの部分はIndex作成、検索時に

設定できるように(デフォルトはN=1, 2, 3で作成)

3.作成Indexのグルーピングが可能

全文検索機能 ・検索Indexをグループ別で作成、検索

データ登録時に任意のグループを指定することで

検索時の範囲を限定することが可能

>今日の勉強会の内容を

グループを決めて検索

とかも可能

twitterのグループから

“今日の勉強会”を検索

他のグループは対象から外せる

blog

twitter

ATND

利用事例

・共有キャッシュサーバ

・データ集約ストレージ

・ソーシャルアプリ向けホスティングサービスの

“アプリプラットフォーム”で利用

>アプリプラットフォームを利用されている

ユーザにネットワーク越しに利用できる

memcachedサーバとして提供

okuyamaは冗長構成で構築し、サーバメンテナス

などは全てプラットフォーム側で実施

共有キャッシュサーバ ~リンク様

・構成図

MasterNode

DataNode DataNode

DataNode DataNode

MasterNode

DataNode DataNode

トランザクションログ

okuyamaクラスター

ＬＶＳ MasterNodeへの

バランシングと

フェイルオーバー

アプリプラットフォーム利用者

Heartbeatにて監視

障害時はＶＩＰを移行して切り替え

待機系

ＬＶＳサーバ

メモリーのみ

ポート番号単位でユーザに提供

利用ユーザにはmemcachedに見える

memcachedクライアントには

フェイルオーバーの考え方は

ないので、ユーザとokuyamaとの

間にLVSを挟んで、バランシング&

冗長化。LVSはHeartbeatを使って

冗長化構成としている

共有キャッシュサーバ ~リンク様

・複数のシステムで利用するデータを

集中管理するストレージ基盤に利用

データ集約ストレージ

>商品販売時に利用するマスター情報などを

システム単位で管理していたところを1箇所で

管理して各システムは集約ストレージ経由で

データ参照するよう変更

・構成図

データ集約ストレージ

MasterNode

DataNode DataNode

DataNode DataNode

MasterNode

DataNode

DataNode

DataNode DataNode DataNode

+ トランザクションログ + Value=Disk

WebAPIサーバ群

データ種類に応じた

ＡＰＩ実装

データ種類に応じた

ＡＰＩ実装

データ種類に応じた

ＡＰＩ実装

okuyamaの前にWebAPIサーバを

配置してそちらにデータに合わせた

処理を実装し、アプリケーションは

RESTでデータ処理を実行

okuyamaはデータに合わせて

パーティションでデータを分離

データ例)

商品マスタ

在庫マスタ

ユーザマスタ

etc…

ユーザ情報

問い合わせ

商品マスタデータ検索

在庫マスタ

更新、問い合わせ

・okuyamaだけで全てを完結させるのは厳しい

今後

>その他の要素との融合

それを行うためのインターフェース整備など

・検索だけを受け持つプラグイン的なAPIサーバ

>コア部分だけ隠蔽して、I/Fだけ公開

・管理用のアプリケーション(cse、zabbix…?)

>データ入れたら簡単に見たい！！

テスト、運用作業の効率化などに必須

最後に

・Information

UserGroup

http://groups.google.com/group/kvs_okuyama/

Development

http://sourceforge.jp/projects/okuyama/

Facebook

http://www.facebook.com/okuyama.jp

Thank you!