Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説
Transcript of Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説
![Page 1: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/1.jpg)
Neo4j 高可用性クラスタ― vs 大規模分散クラスタ―の解説
李 昌桓(LEE CHANGHWAN)
![Page 2: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/2.jpg)
自己紹介
• 李 昌桓 (LEE CHANGHWAN, @awk256), DBが大好きなサーバーサイドのエンジニア Informix, Oracle, Red Brick, SQL Server, Amaozn Elastic Map Redeuce,
,Apache hadoop, MySQL, Neo4j, MongoDB, AWS全般…etc
• クリエーションライン株式会社(クラウドSI, MSP, ビックデータ分析)
CloudStack, OpenStack, Azure, Softlayer, AWS, Elastic Serarch, Spark,
HahsCorp, Chef, MongoDB, Neo4j…etc
• 著書
Amazon Cloudテクニカルガイド(インプレス, 2010)
Amazon Elastic MapReduceテクニカルガイド(インプレス, 2012)
Cypherクエリー言語の事例で学ぶグラフデータベースNeo4j(インプレスR&D, 2015)
グラフ型データベース入門(共著:リックテレコム, 2016)
RDB技術者のためのNoSQLガイド(共著:秀和システム, 2016)
1
![Page 3: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/3.jpg)
本日のテーマはNeo4jの高可用性&拡張性に関する話しです
2
![Page 4: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/4.jpg)
• 高可用性(High Availbility)とは
• Neo4jのHAクラスタ―(High Availbility Cluster)とは
• Neo4jの大規模分散クラスタ―(Causal Cluster)とは
• まとめ
3
![Page 5: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/5.jpg)
高可用性(High Availbility)とは
簡単に言えば、スペアタイヤーを装備している構成が原型です。タイヤ―がパンクしたら、さっさと
交換して走る続けることを想定しています。
4
![Page 6: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/6.jpg)
コールドスタンバイ構成 (予備機)
Neo4jユーザ―グループ 5
予備機 稼働機 稼働機
バックアップ リストア
![Page 7: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/7.jpg)
通常、このタイプは、色んなん意味で安く済むかも知れませんが、タイヤ―の交換作業はかなり面倒そうですね
6
![Page 8: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/8.jpg)
ホットスタンバイ構成 (アクティブスタンバイ)
Neo4jユーザ―グループ 7
スレーブ マスター ↑マスター
データだよ
病気?! さよなら
元気かい
![Page 9: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/9.jpg)
このタイプの構成だと、1本なら
パンクしても、タイヤー交換なしで、安全な場所まで移動することができます
8
![Page 10: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/10.jpg)
負荷分散構成 (HAクラスタ―)
9
• 基本的に3台以上の奇数で構成する(3~9台) • SLA応じて障害時の稼働台数を調整し、サービス停止は0近く保つ
• writeリクエストとreadリクエストを区別して分散できる
• クロスで死活監視を行う
プライマリー
セカンダリ セカンダリ データ同期
元気?
元気? 元気?
![Page 11: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/11.jpg)
このタイプは、かなりやばい状況でも走り続けることができます。
10
![Page 12: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/12.jpg)
ディザスターリカバリ構成
11
プライマリー
セカンダリ
セカンダリ
地震など広域災害時にもサービスを続けられるように地理的な離れたデータセンターにレプリカを配置する
東京リージョン シンガポールリージョン
![Page 13: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/13.jpg)
もう、タイヤ―の話しではなくなりました。核セルタを作りましょう
12
![Page 14: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/14.jpg)
HAクラスタ―の最大のメリットは、
許容範囲内の障害であれば、自律的にデータの安全性を確保しつつ、稼働を続けられ
るということです
13
![Page 15: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/15.jpg)
3台構成(1台死んでいいよ)
Neo4jユーザ―グループ 14
ノード1 ノード2 ノード3 サービス
◎ 〇 × 継続
◎ × 〇 継続
× ◎ 〇 継続
× 〇 ◎ 継続
◎⇒プライマリー(リーダー、マスター) 〇⇒セカンダリ(スレーブ、メンバー) × ⇒故障
![Page 16: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/16.jpg)
5台構成(2台死んでいいよ)
Neo4jユーザ―グループ 15
ノード1 ノード2 ノード3 ノード4 ノード5 サービス
◎ 〇 〇 × × 継続
◎ 〇 × 〇 × 継続
◎ × 〇 × 〇 継続
× 〇 ◎ 〇 × 継続
× × ◎ 〇 〇 継続
〇 〇 × ◎ 〇 継続
〇 × 〇 × ◎ 継続
◎⇒プライマリー(リーダー、マスター) 〇⇒セカンダリ(スレーブ、メンバー) × ⇒故障
![Page 17: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/17.jpg)
7台構成(3台死んでいいよ)
Neo4jユーザ―グループ 16
ノード1 ノード2 ノード3 ノード4 ノード5 ノード6 ノード7 サービス
◎ 〇 〇 〇 × × × 継続
◎ 〇 〇 × × × 〇 継続
◎ 〇 × × × 〇 〇 継続
◎
× ×
×
〇 〇
〇
継続
・・・中略・・・ 継続
× 〇 × 〇 × ◎ 〇 継続
◎⇒プライマリー(リーダー、マスター) 〇⇒セカンダリ(スレーブ、メンバー) × ⇒故障
![Page 18: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/18.jpg)
9台構成(4台死んでいいよ)
Neo4jユーザ―グループ 17
ノード1
ノード2
ノード3
ノード4
ノード5
ノード6
ノード7
ード 8
ノード 9
サービス
◎ 〇 〇 〇 〇 × × × × 継続
× 〇 ◎ × × 〇 〇 × 〇 継続
× 〇 × × 〇 ◎ 〇 × 〇 継続
×
× 〇 ×
〇 ×
◎
〇 〇 継続
・・・中略・・・ 継続
× 〇 × 〇 × 〇
〇 × ◎ 継続
◎⇒プライマリー(リーダー、マスター) 〇⇒セカンダリ(スレーブ、メンバー) × ⇒故障
![Page 19: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/19.jpg)
Neo4jユーザ―グループ 18
如何なる壊れ型をしても、お互いに連絡が取れる者が過半数いれば、そのグループ
(クォーラム)のなかで、新しいマスターを選出し、正常な稼働を続けます
![Page 20: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/20.jpg)
なぜ、過半数なのか?
ネットワークを経由でデータのやり取りしている、という特性から過半数の連絡が取れるということは、データの信頼性が最も
高いグループだと認めます
19
![Page 21: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/21.jpg)
なぜ、マスター選出が重要なのか
何台のHAクラスタ―構成でも書き込みをコミットする権限は、1台のマスターのみが持ち、追加し
が出来ないログを記録することで
データの一貫性を守るためです
20
![Page 22: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/22.jpg)
複数のネットワーク分断が起きたとか、過半数以上のノードが死ん
だ場合はどうなるのか
21
![Page 23: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/23.jpg)
通常、残りのノードはReadOnly状態に
陥て書き込みはできません
人間が介在して復旧する必要があります
22
![Page 24: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/24.jpg)
このような「からくり」は「Raftプロトコール(分散合意アルゴリズム)」を参考に作られています。興味ある方は、下記を参照してください。
CONSENSUS: BRIDGING THEORY AND PRACTICE
https://ramcloud.stanford.edu/~ongaro/thesis.pdf
Raftについて(日本語)
https://gist.github.com/sile/ad435262c17eb79f133d
23
![Page 25: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/25.jpg)
さて、どのような「からくり」なんでしょうか。マスター選出に関
する真実を簡略に紹介します
24
![Page 26: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/26.jpg)
マスターは、
生き残った過半数以上の人達による投票(Vote)で決めるんだから民主的でいいね
25
![Page 27: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/27.jpg)
実は、Raftプロトコールによるマスター選出は、どうみても、王権
争いに近いです
26
![Page 28: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/28.jpg)
• 神様 人間 • 法律 Raftプロトコール • 王様 マスター or プライマリ or リーダー • 王位継承者達 メンバー全員が条件さえ満たせば、誰でも王に なれる
このような世界観の王国です
27
![Page 29: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/29.jpg)
初代の王の擁立は、
神様(人間)の意思が強く働きます。
例えば、神様が与えた順位とか
結構、いい加減かも・・・
28
![Page 30: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/30.jpg)
王様は、王国で起きた重大な事柄を追加のみが許される「王の巻物」に記録します。これ
は、王の使命であり、王権の象徴です
29
トランザクション・ログ
![Page 31: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/31.jpg)
王は、「王の巻物」の記録追加を次々と
王継承者達に伝えることで、自分が健在であることをアピールします
30
![Page 32: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/32.jpg)
王位継承者達は「王の巻物」を必死に筆写してきます。もしも、王権争いの際には、最新の記録をもっている者が王になる可能
性が高いからです。
31
![Page 33: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/33.jpg)
これで、何もなければ、
平和が続きます
32
![Page 34: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/34.jpg)
ただし、王継承者達は、虎視眈眈、王位を狙っています。お互いを監視しながら、王
様の隙を狙い続けます(ping)
33
![Page 35: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/35.jpg)
王位継承者達は王国に分裂が起きると、連絡が取れる、遠慮なく、我先に自分
が王に相応しいと、宣言します
34
![Page 36: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/36.jpg)
こうなると「王様が生存していて災害でたまたま孤立」していたとしても、王国が始まった時の勇者達の過半数が集まったグループで「新王」を擁立します
35
![Page 37: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/37.jpg)
王になれる権利とは
通常、「王の巻物」の最新記録を持っていることです。
同等の場合は、既定の神様からの
優先順位で決まります
36
![Page 38: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/38.jpg)
ここまで、高可用性(High Availbility)構成の
説明と、背景にある設計思想の説明でした
37
![Page 39: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/39.jpg)
• 高可用性クラスタ―
• 負荷分散クラスタ―
• トランザクションの伝播(今のところNeo4jのみ)
• シンプルなコンフィグレーション
Neo4jのHAクラスタとは
38
![Page 40: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/40.jpg)
Neo4jのHAクラスタ―の基本構成
39
HAプロクシ
[現在のマスター]
トランザクションの伝播
クラスタ―を起動するとマスターを自律的に選出します
トランザクションの伝播
HAプロクシは、リクエストを 各ノードに均等に割り当てます
GET/PUT/POST/DELETE
クライアント側ではクラスタ―へ接続するた
めに何もしなくても良いです
マスター
セカンダリ
セカンダリ
xxx.xxx.xxx.xxx
セカンダリが「書き込みリクエストを受けたら、マスターに引き渡します
![Page 41: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/41.jpg)
トランザクションの伝播とは
40
HAプロクシ
[現在のマスター]
マスターのみがコミット権限をもっています
トランザクションの伝播
更新系のリクエスト PUT/POST/DELETE
①更新系のリクエストです
③差分データコピーします
②コミットしたよ
検索処理は、普通に行われます(GET)
[セカンダリ] [セカンダリ]
![Page 42: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/42.jpg)
• トランザクションのコミットがセカンダリに伝播されている場合
データ流失は起きません
データを受け取ったセカンダリがマスターに昇格し、セカンダリが同期を取ります
• トランザクションのコミットがセカンダリに伝播されていない場合
データ流失のが起きます
新マスターが誕生し、新しいトランザクションをコミットしたら、セカンダリは同期を取りはじめ、ブランチしている旧マスターのデータはリカバリできません
トランザクション伝播と障害: リクエストを受け取ったマスター壊れた場合
41
ただし、これは理論的な可能性を言っているものであり、現実的に、このような事故が起きる確率はどのぐらいなのでしょうか 一瞬にしてDBが全然機能しなくなるような障害が起きる確率は?
なお、障害が起きた瞬間、ミリ秒の間をすり抜けて受け渡しができなくなるような不運なデータが発生する確率は?
![Page 43: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/43.jpg)
• トランザクションのリクエストがマスターに伝播されている場合
データ流失は起きません
マスターがコミットし、セカンダリが同期を取ります
• トランザクションのリクエストがマスターに伝播されていない場合
データ流失が起きます
マスターが他のトランザクションをコミットすると、セカンダリが同期を取りはじめ、ブランチしているデータはリカバリできません
トランザクション伝播と障害: リクエストを受け取ったセカンダリが壊れた場合
42
ただし、これは理論的な可能性を言っているものであり、現実的に、このような事故が起きる確率はどのぐらいなのでしょうか 一瞬にしてDBが全然機能しなくなるような障害が起きる確率は?
なお、障害が起きた瞬間、ミリ秒の間をすり抜けて受け渡しができなくなるような不運なデータが発生する確率は?
![Page 44: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/44.jpg)
conf/neo4j.conf
ha.server_id = 1
ha.initial_hosts = server1:5001,server2:5001, server3:5001
dbms.mode=HA
HAクラスタ―の設定::1台目
43
![Page 45: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/45.jpg)
conf/neo4j.conf
ha.server_id = 2
ha.initial_hosts = server1:5001,server2:5001, server3:5001
dbms.mode=HA
HAクラスタ―の設定::2台目
44
![Page 46: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/46.jpg)
conf/neo4j.conf
ha.server_id = 3
ha.initial_hosts = server1:5001,server2:5001, server3:5001
dbms.mode=HA
HAクラスタ―の設定::3台目
45
![Page 47: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/47.jpg)
ここまで、Neo4j HAクラスタ―の説明でした。
46
![Page 48: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/48.jpg)
Causalという言葉は、コンピューターサイエンス
から取ってきた言葉であり、既にCausal system, Causal consistency, Causal clusteringとかというふうに使われています。とちらも、分散処理に関わるある種の概念を表す言葉で、Neo4jの発明品ではありません。
Causal Cluster(大規模分散クラスタ―)
47
![Page 49: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/49.jpg)
• 大規模のHAクラスタ―
• 大規模のリードレプリカ
• ディザスターリカバリ
Causal Clusterとは
48
より少ないリソースで
![Page 50: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/50.jpg)
• コアは、HAクラスタ―を踏襲しています
• リードレプリカは、コアから同期を取ります
• マスター争奪争いには参加しません
Causal Clusterのアーキテクチャー
49
更新系
コア
リードレプリカ
アプリケーション
差分コピー
![Page 51: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/51.jpg)
更新系のクエリーのみを受け入れる構成で
より少ないパワーで大量のスループットを処理することができます
コアサーバー群
50
PUT/POST/DELETE
コア
![Page 52: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/52.jpg)
コアから独立しており、
一定間隔でコアから最新のトランザクションログを
コピーして来て同期を取ります
コアに殆ど負荷をかけません
レプリカサーバー群
51
コア
ログの差分コピー
![Page 53: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/53.jpg)
まとめると、こんなイメージになります
Causal Clusterのユースケース データウェアハウス?!
52
HAプロクシ
アプリケーションサーバ コア
リードレプリカ
オペレーション系DB レポート系DB
HAプロクシ
分析サーバー
![Page 54: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/54.jpg)
neo4j.conf
dbms.mode=CORE
causal_clustering.expected_core_cluster_size=3
causal_clustering.initial_discovery_members=
server1:5000, server2:5000, server3:5000
コアの設定
53
![Page 55: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/55.jpg)
neo4j.conf
dbms.mode=READ_REPLICA
causal_clustering.initial_discovery_members=rserver1:5000, server2:5000, server3:5000
リードレプリカ構成
54
リードレプリカ構成で重要なことは、自分のミッションを認識し、コアサーバーの誰からデータを持って来るのかを教えることです。 リードレプリカの他の仲間を意識する必要は全くありません。
![Page 56: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/56.jpg)
まとめ
55
区分 HAクラスター Causal Cluster
高可用性 • 同等 • 同等
拡張性 • 小規模 • 9ノードぐらい
• 中・大規模 • 数十台規模のリードレプリカ ただし、用途に応じては、小規模でも・・・
DR構成 • 現実的ではない • リードレプリカをデータセンター間で分散
![Page 57: Neo4j高可用性クラスタ― vs 大規模分散クラスタ―の解説](https://reader033.fdocuments.net/reader033/viewer/2022051101/58ed6ae91a28ab9c248b458d/html5/thumbnails/57.jpg)
THE END
56