インメモリーデータグリッドの選択肢

ULSCopyright © 2011-2017 UL Systems, Inc. All rights reserved.

Proprietary & Confidential Powered by

Apache GEODE Meetup Tokyo #3

インメモリーデータグリッドの選択肢

2017/2/16

ウルシステムズ株式会社http://www.ulsystems.co.jp

mailto:[email protected]

Tel: 03-6220-1420 Fax: 03-6220-1402


Proprietary & Confidential Powered by 1

About Me

山河征紀

Business

Private

• GEODE歴：9年（Since 2008）• GEODEバグ報告数：nnn 件

• マラソン• 横浜マラソン2016：4h17m• 目標は2017年度中のサブ4

• 登山• 目標はココ



おしらせ

Apache Geodeのハンズオンやります！

3/14（火）19：00～六本木ヒルズ森タワー20F

Pivotal Japan

• 一緒に運営していただける方

• スピーカーをお願いできる方

大募集中



2007年

2017年

データグリッドの昔と今

（ex-GemFire）

（ex-GridGain）



たくさんあるのはありがたい

でも・・・

どれを使えばいいんだろう？



今日、お話したいこと

In-Memory DataGrid



おことわり

本日、お話する内容は、あくまで個人の見解です

ただし、Geode MeetupだからといってApache Geodeに有利になるような見方はしておりません



サーバ

サーバ

サーバ

アプリケーションのスケールアウトは容易になったが、RDBがボトルネックに

マイクロサービス時代では、ここがスケールしないときつい

良くあるシステムの課題

JVM

JVM

JVM

アプリケーション



RDB

スループットだけでなくレイテンシーも

重要



そんなときに…

インメモリーデータグリッド



インメモリーデータグリッドに必要な3大要素＋1

複数ノードのメモリーにデータを分散して保持していること

メモリー中のデータと外部データストアとの連携がシームレスにできること

メモリー中のデータへトランザクション処理ができること

①

②

③

メモリー中のデータに関するイベントが容易にハンドリングできること



ということで…

3つの観点で、どれが良いのかを比較してみます！



ラウンド1

データの分散



データ分散？



データ分散とは…

クラスター全体を論理的に1つのまとまりとして見たとき、データをどのノードのメモリーにもつか、ということ

データの特性によって分散スタイルを選ぶ必要があるため、この選択肢が充足していることは重要

パーティションレプリケーション

すべてのマシンで同一のデータを保持する

何れかのマシンにデータが存在する



データの分散：比較結果（1）

呼び方は違えど、主要な分散スタイルに差はない

レプリケーションパーティション

Geode ○ Replicated ○ Partitioned

Ignite ○ REPLICATED ○ PARTITIONED

Hazelcast ○ ReplicatedMap ○ Map

Infinispan ○ Replicated-cache ○ Distributed-cache

Coherence ○ Replicated Cache ○ Partitioned Cache



データの分散：比較結果（2）

細かい部分では特色がある

ただし、これらは「あったら嬉しい」というレベルのものその他の分散スタイル補足

GeodeLocalPreloadedDistributed non-replicated

レプリケーションでは、書き込み時のオプションが選べる（distributed-ack,distributed-no-ack,global）

IgniteLOCALNear Cache

パーティションのバックアップを全ノードで保持したものがレプリケーション、というコンセプト

Hazelcast Near Cache

レプリケーションでの書き込みは結果整合性KeyValue以外のデータ構造も選択できる

InfinispanLocal mode cacheNear Caching

機能やAPIは非常に多い

CoherenceLocal CacheNear CacheOptimistic Cache

各種Schemeを組み合わせてキャッシュを構成できる



パーティションのデータ分散（1）

パーティションに関しては、こんな風にデータを保持したい時もある（カスタムパーティショニング）

ノード#1

Order-1 User-A

Order-3 User-B

Order-5 User-A

Order-7 User-A

ノード#2

Order-2 User-B

Order-4 User-A

Order-6 User-A

Key Value

Key Value

ノード#1

Order-1 User-A

Order-5 User-A

Order-7 User-A

ノード#2

Order-2 User-B

Order-4 User-A

Order-6 User-A

Key Value

Key Value

Order-3 User-B

データは均等に分散しいているが…

処理内容によってはUser毎にまとまっていた方がノード間通信がなく、都合が良

い場合もある



加えて、異なるデータの種類も同一ノードに配置したい時もある（コロケーション）

Ord

er

Use

rパーティションのデータ分散（2）

ノード#1

Order-1 User-A

Order-4 User-A

User-B User-B属性

Key Value

Ord

er

Use

r

ノード#2

Order-2 User-B

Order-3 User-B

User-A User-A属性

Key Value

Ord

er

Use

r

ノード#1

Order-1 User-A

Order-4 User-A

User-A User-A属性

Key Value

Ord

er

Use

r

ノード#2

Order-2 User-B

Order-3 User-B

User-B User-B属性

Key Value

User-Aのデータがないのでノード#2にとりにいかないといけない

…

ノードを跨いでデータを取得しなくて良い



パーティションのデータ分散：比較結果

こちらも差はなし

カスタムパーティショニング

コロケーション

Geode ○ PartitionResolver ○ Co-Location

Ignite ○ AffinityCollocation ○ Affinity

Collocation

Hazelcast ○ PartitionAwareKey ○ Partition

AwareKey

Infinispan ○ Grouping APIKeyAffinityService ○ Grouping API

KeyAffinityService

Coherence ○ KeyPartitioningStrategy ○ Key

Association



ラウンド1：データの分散対決結果発表

過去バージョンではできないものがあったが、現時点では大きな差なし



ラウンド2

シームレスな外部データストア連携



シームレスな外部データストア連携とは…

全てのデータはメモリーにのりきらない

のりきらないデータは外部データストアとの連携が必要

外部データストアとの自動連携

データグリッド

RDB等

APPが意識するのはメモリー上のデータ

だけ

メモリー中のデータを参照して、データが存在しない場合（キャッシュミス）は自動的にメモリー上に読み込んでほしい

メモリー中のデータを追加・変更した場合は、自動的にデータストアに書き込んでほしい



キャッシュミスが発生した場合は、データストアよりデータを読み取りメモリーに保持する

リードスルー

RDB等



参照（Read A）

リードスル―

リードスル―

A B

C D

D

D

A

A

B

B参照

（Read B）

APP

APP



メモリー上のデータを更新した場合は、自動的にデータストアに書き込む

ライトスルー/ライトビハインド

RDB等



追加（Write A）

ライトスルーライトビハインド

（Insert）

A B

D

D

D

A

A

B

B更新

（Write B）

ライトスルーライトビハインド

（Update）

APP

APP



外部データストア連携：比較結果

出来ないものはなし

リードスルーライトスルーライトビハインド

Geode ○ CacheLoader ○ Cache

Writer ○AsyncEventListener

Ignite ○ CacheStore ○ Cache

Store ○ CacheStore

Hazelcast ○ CacheLoader ○ Map

Store ○ MapStore

Infinispan ○ CacheLoader ○ Cache


Coherence ○ CacheLoader ○ Cache




これも、過去バージョンではできないものがあったが、現時点では大きな差なし

あえていうなら、各種データストア用のデフォルト実装が揃っているInfinispanが使いやすいかもしれない

ラウンド2：外部データストア連携対決結果発表



ラウンド3

トランザクション



トランザクション

インメモリーデータグリッドを採用する場合、更新処理の高速性、スケーラビリティを求めて採用するケースがある

ベースは、トランザクション不要なように設計すべきであるが、少なからずトランザクション処理が必要となるケースがある



トランザクション：比較結果

Ignite、Infinispanが出来ることは多いトランザクション対象

分離レベルロック方式レプリケー

ションパーティション

MIX

Geode ○ △ △ READ_COMMITED 楽観

Ignite ○ ○ ○READ_COMMITEDREPEATABLE_READSERIALIZABLE

楽観悲観

Hazelcast ○ ○ ○ READ_COMMITED 楽観

Infinispan ○ ○ ○ READ_COMMITTEDREPEATABLE_READ

楽観悲観

Coherence ○ ○ ○ READ_COMMITED 楽観



トランザクション機能で選ぶなら、Ignite、Infinispanが出来ることは多い

高速性を目指すときに必要かどうかは微妙なとこではあるが

ラウンド3：トランザクション対決結果発表



まとめ

インメモリーデータグリッド機能対決結果

–RDBと同じようなトランザクション機能が必要ならIgniteやInfinispanを選んだ方が良い

–GeodeとCoherenceは10年前から出来ないことがわかっているが対応していないので、おそらく今後も対応されない

–それ以外は以前は差があったが、現時点では大差なし

ラウンド結果

1. データ分散 DRAW（差なし）

2. 外部データストア連携 DRAW（差なし）

3. トランザクション1. Apache Ignite2. Infinispan



最後に

今回は、残念ながらGeodeだけ「出来ない」がでちゃいました！

それでも、今後もGeodeを使い続けます！

別の観点の比較はまた別の機会にでも…

インメモリーデータグリッドの選択肢

Technology