00:01
こんにちは。今日は、久しぶりに部屋の中で録音したいと思います。
つい先日、Londonは、積雪が久しぶりにありましたね。
去年は、こんなに雪が積もったかなっていうぐらいで、外で子供たちが雪だるまを作ったりして遊んでて、
とても綺麗な雪が降ってて、雪国出身の自分としても懐かしい気持ちになりましたね。
じゃあ、今日もやっていきたいと思います。Ken WagatsumaのLondon Tech Talk。
今日は、技術ネタでやっていきたいと思います。
グラフデータベースとは何かについてお話ししていきたいと思います。
そもそも、グラフデータベースとは何かについて、どういったところで使われているかについてお話ししていきたいと思うんですけれども、
なんでグラフデータベースを選んだかというと、
自分が
2021年から2022年、つい先月まで、グラフデータベースを作っている企業で働いていたんですね。
そこで得た知見や経験をもとに、もっとグラフデータベースっていろんな人に知られてもいいかなと思ったので、
Podcastで伝えることにしました。現在はその企業に勤めていないので、
全く利益関係とかはないです。もちろん、話すことで広告料をもらっているとか、そういうのもないので、純粋に技術の話として聞いてもらえればなと思います。
こうした技術の話をするときって、一般的には動画とか、あとはブログ記事を書いたりするってことも多いと思います。
この音声のみで、どこまで技術の話をうまく伝えられるかっていうところに、個人的にチャレンジしていきたいなと思っています。
新しい技術を学んだりするときに、いきなり社教とかするより、自分で大事だなと思っているのは、
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
いかにコンセプトをメンタルモデルみたいな形に落とし込んでいくか。
伝えるために音声というメディア でどこまでできるかっていうのも
03:02
チャレンジしていきたいと思って いきます では グラフデータベース
とはそもそも何かについて そもそも データベースとは何か どんなもの
があるかということなんですけども ウェブエンジニアであれば MySQL
とかPosgreSQLとかなどのいわゆる RDBMS リレーショナルデータベース
をよく利用することが多いかもし れません ここにはキーバリュー
ストアですね メモキャストとか Redisのようなものを使ったりする
ことも多いと思います ニュースケース とかによっては MongoDBとか あと
AWSから出しているDynamoDBのような ドキュメント思考データベース
と呼ばれるものであったり カラム 思考データベースと呼ばれる
別の種類のデータベースとか いろいろあると思います データベース
って言っても別に特別なソフトウェア ではなくて ただのプロセスですね
一言で言うと データを保存 管理 分析するのに優れたソフトウェア
もしくは実行プロセスです データベース の入力としては 基本的にデータベース
がサポートするあらゆる型のデータ ですよね 文字列
であったり 数値であったり JSON型とか ブログとかをサポートしている
データベースもありますし ただ 基本的にはそのバイト文字列を
ディスク上に保存しているに すきません なので 基本的にどの
データベースもやることは一緒 なんですよ データをバイト文字列
にしてディスクに保存する じゃ なんでこんなにたくさんのデータ
があるか データベースがあるか というところがあるんですけど
これも何かというと じゃあ まず このデータを保存するところ
とか データを管理するところとか データを読み出して分析するっていう
ところに いろいろなインターフェース が考えられるからなんですよね
例えば 保存しちゃうデータを読み込む ときに そのままバイトだけを読み
出してもほぼ分析できないので クエリ言語というものを作って
今だとSQLがほぼ 何を言っても 毎回 間違いなくしてもうちに
スキルを計算していくために 系統を整えた形式というものが
あるんですけれども このデータを保存するところや データを
ほぼメジャーですけれどもSQLというものを使ってデータを読み出して
それをビジュアライズしたりアプリケーションから使って計算したりすると思いますし
そのデータの保存方法もどういうふうに保存するかによって
アプリケーションの適正というのが異なってきます
例えば1行ずつ読み出すようなことが求められる要件のビジネス要件のアプリケーションもありますし
あとは非構造データをまるっとJSONのような形に入れて
まるっとキーで取り出すみたいなハッシュみたいな
06:04
ディスビューティッドハッシュみたいな形で使ったほうがいいこともありますし
あとは
データ分析をするときに大量の同じカラムのデータを
まるっと複数の列から取ってくるほうが優れているような要件もあったりします
なので基本的にどのデータベースでやることと一緒なんですけれども
どう保存するかどう管理するか
それをどう読み出すかというところのインターフェースが
違うことによっていろいろなアプリケーションで使われる
なので例えばMySQLのようなRDBMSがあれば
例えばMySQLのようなRDBMSがあれば
十分かというと全然そうではなくて
複合的なポリグロットなデータベースマネジメントシステムを
基本的には使っていくことになると思います
サービスが成長するにあたって
この部分はバチカフカを使ってみたり
この部分はキーバリューストアを使って
この部分はRDBMSを使ってみたいな形です
今回お話しするグラフデータベースで
メジャーなものとして例えばNeo4jとかあったりするんですけれども
そのグラフデータベースというのも
RDBMSとかキーバリューストアみたいな他のデータベースにとって
変わるものではなくて
それらと同じようにグラフデータを扱うのに適した
ユースケースで使うためのデータベースと
考えてもらえれば問題ないかと思います
基本的にそのデータベースに求められるということは
大量のデータを効率的に検索し作成できる
というところなんですよね
そのデータ構造とアルゴリズムを
ビジネス用に使うことで
条件に合った形で最適化をして
ここら辺の過程というのは本当にデータベースが長年研究されているので
コンピュータサイエンスの中でも
その研究の積み重ねと努力
再緻密なコーディングの積み重ねによって実現されているんですよね
インデックスと呼ばれる副次的なデータ構造を作ったりだとか
ちょっと変わった機構造で表現してみたりだとか
ディスクだけでなくメモリをうまく活用したりだとか
ハードウェアレイヤーで最適化を図ったりだとか
そのビッグデータ時代が到来して
大量のデータを保存するとなると
それだけデータの保存場所が必要となってくるんですけども
保存場所が増えるほどお金もかかってくるので
データをただ保存すればいいだけじゃなくて
いかに少ないサイズで同じことを表現しつつ
コストを最適化できる形で保存していくかということも大事なんですね
コストの最適化やパフォーマンスの最適化だけじゃなくて
データベースを使うのは開発者ですので
開発効率
データベースのも重要となってきます
例えばSQLのような確率化というか
ほとんどのデータベースで使える
クエリ言語があれば学習コストが1回かかれば
ほとんどのデータベースで使えるので
09:01
あとはデバッグツールですとか可視化ツールというのもないと
データベースというのはうまく使っていけないと思います
じゃあグラフデータベースがどういった
グラフにデータに適しているかというところがポイントになってきますね
まず例えばリレーショナルデータベースモデルというのは
これ1970年代でしたかね
もともと理論としてのデータモデルが提唱されて
開発され始めた一番古いデータベースで
リレーションと呼ばれるタプルの集合体
表現されているんですよね
他にノーシークエルというキャッチーなフレーズで
話題になったモンゴDBとかダイナモDBのような
ドキュメント思考データベースというのもあったりしますが
グラフデータベースというのは一言で言うと
グラフ理論で表現できる問題を解くのに最適化されたデータベースです
このグラフ理論というのがポイントですね
このグラフ理論というのはレオンハルト・オイラーという
数学者の人が18世紀に大気化した数学理論なんですよ
これもしかしたら小学校の時の数学の教科書とかで
ストーリーを聞いたことがあるかもしれないんですが
ケイニヒスペルクの7つの橋問題という有名な証明があります
ストーリーとしては18世紀の初め頃に
昔のプロイセンという王国があったんですけども
今のロシアの連邦の中かな
そこの東部の
プロイセンの使徒であるケイニヒスペルクという大きな町がありました
この町の中央にはプレーゲルという大きな川が流れていて
7つの橋が架けられていたんですね
その7つの橋と川によって町のエリアがいくつかに分かれていた
その時に王様が
本当に王様だったかちょっと分からないですけど
偉い人がきっと何かしら偉い人が
このプレーゲル川に架かっている7つの橋というのを
2度通らずに
全て渡って元のところに帰ってくることができるか
これを証明してほしいと頼まれた
それによって証明するために考えた数学の理論というのが
グラフ理論であり
この問題をケイニヒスペルクの7つの橋問題と言います
要するに太筆描きみたいな形ですね
抽象化すると
ここで川が流れている町の
この川が流れている町の
地域をイメージしてほしいんですけど
橋によって2つの地域が
つながっているとします
12:00
2つのそれぞれの地域を丸を描いて
橋を線のような形で表現すると
その7つの橋があるので
7つの線とそれによってつながれた複数の地域というのが
丸と線で表現できると思います
このグラフ理論の中では
この丸のことをノード
説と言ったり
この線のことをエッジ編と呼ぶんですけども
このノードとエッジで抽象化したんですよね
この7つの橋モデル
このノードとエッジと呼ばれる丸と点で
解くことができる問題のこと
というのがいわゆるグラフ理論で表現できる問題
なので面倒くさいので
デジタルモデルとしてはすごい簡単で
線と点で表現できるもの全てってなります
じゃあプラクティカルな例でいくと
どういうものがあるかというと
まず1つは皆さんが使っているウェブページですね
セマンティックウェブです
それぞれのウェブページをノード
ハイパーリンク
Aタグで作るリンクですね
クリックすると飛ぶやつ
ハイパーリンクをエッジとして表現すると
例えばどのページからどのページに
どれぐらいリンクが
貼られているかっていう
ものを作ることが
関連性を表現できますよね
例えばいろんなウェブサイトから
たくさんリンクされている
つまりたくさんのノードから
エッジが集中しているノードっていうのは
人気サイトだろうということで
これは初期のGoogleのサーチ
アルゴリズムとかにも使われたりしますし
今は多分もっともっと複雑な
アルゴリズムだと思うんですけども
ベースとしては
ある考えとしては
いろんなウェブサイトから
エッジが伸びているということは
人気だろう
もしくは権威があるだろう
という形で表現されていますね
ウェブ以外の例としては
例えばソーシャルネットワークですね
TwitterとかFacebookで代表される
ソーシャルネットワークには
それぞれのユーザーアカウントをノード
フォロワーの関係をエッジとして表現すると
人間関係っていうのが見えてきますよね
例えばいろんなユーザーアカウントから
エッジが伸びている
たくさん集まっている人は
例えば人気Twitterアカウントとか
有名人のTwitterアカウントですとか
あとそのエッジを辿っていくと
誰と誰が友達かっていうのが分かってくるとか
でこれを利用して
例えばFacebookとかTwitterを使ってると
こんな人知りませんかみたいな
レコメンデーションとして
こんな人フォローしてみませんか
っていうことが出てくると思うんですけども
これはグラフ理論において言うと
エッジがなるべく少ないHOPで
15:00
繋がることのできるクラスターとしては
関連の近い人だよねということで
ここらへん多分推薦アルゴリズムにも
Twitter Facebookの内部実装は知りませんが
グラフ理論で解くことができます
その二つのノード間どれぐらい近いか
みたいな近接性とかですね
他に面白い例でいくと
金融のトランザクションですかね
銀行とか個人の口座とか
ノードでお金の流れ
トランザクションをエッジとして表現すると
どこからどこにどれぐらいお金が流れたか
っていうのが分かります
例えば僕の日本の銀行口座から
例えばとある銀行を通して
イギリスにある僕の銀行に送金する
みたいな形でやると
どこからどこにどれぐらいの金額が
どのようなHOPで流れたか
っていうのが分かるんですけど
これが
どういう風に利用されるかって
例えばクレジットカードとか
オンライン決済とかをしたときに
不正送金とかマネードロンダリングされていないかどうかの
検出ができるんですよね
あとはこう
あのパンドラ文書とか
多分聞いたことある方がいるかと思うんですけど
そういった不正文書が公開されたときに
政治献金がいかにこう
裏金に回ってしまっていたりだとか
あとはこうリアルタイムの
クレジットカードの不正検知だとか
そういったシステム使われたりします
あともう二つぐらいイメージとしてあげると
あとは推薦エンジンですね
レコメンデーションエンジン
例えばECサイトにおける商品とか
カテゴリーをノードとして
購入履歴のトランザクション
エッジとして表現すると
誰がもしくはユーザーをノードとして表現すると
どのユーザーがどんな商品を買ったか
っていうのが分かってきますね
で同じような商品を買ってる人は
別の商品を買うこともあるだろうということで
グラフ理論を利用して
ユーザーに対してこんな商品
似たような人が買ってますよと
提案することができたりします
相関性の分析ですね
あと最後の例として
これすごい分かりやすいと思うんですが
地図のアプリケーションですかね
地図上の店舗とか住居をノード
それらをつなぐ道をエッジとして表現すると
例えばデリバリーサービスにおける最短経路を
最短経路を導き出したりとか
あと地域間の人工動態分析したりだとか
そういったことに利用できたりします
なので意外とノードとエッジで表現できる
実用世界の例っていうのは多くて
それらにメンダルモデルとしては
綺麗にはまる形なんですね
グラフデータベースをそういった例に使うと
何が嬉しいのかっていうことなんですけども
Twitterをちょっと考えてみましょう
ソーシャルネットワーク
18:00
ユーザー同士のフォロワーフォローみたいな関係性で
割といろんなウェブアプリケーションの要件として
あると思うんですよね
ユーザーアカウントが入ってくる
そういったときに
僕の日本のスタートアップの経験で
いろんなとこでグラフデータベースが使われてるか
全然そんなことなくて
普通にリレーショナルデータベースで
外部キーとかを使って
関連テーブルを入れて
表現したりするんですね
ここがポイントとしては
グラフデータベースでできることは
他のリレーショナルデータベースでもできますし
逆もまたしっかりで
もちろんドキュメント思考のデータベースでもできます
じゃあ
MySQLでも
モデリングして
正規化して表現できるものなので
わざわざ
グラフデータベースで
使うのかっていうのが
ポイントなんですけども
大きな理由が二つあります
まず一つなんですけど
Twitterのような規模の
フォロワーフォローイーの関連のアプリケーション
実際に運用したことがある方がいれば
イメージつくんですけど
スケールしないんですよね
なんでかっていうと
じゃあTwitterを想像したときに
ユーザー同士のフォロワーフォローイーの関係を
外部キーのような形でつなげたときに
例えば
有名アカウント
有名人のアカウントみたいな
ホットノードみたいなアカウントの
データを引っ張ってくるときに
かなり
ジョインが結合ですね
ジョインが発生するんですよね
ジョインが発生するのは悪くないんですけど
ジョインってなかなかスケールしないものなので
実際のアプリケーションを運用してくるときに
パフォーマンスのボトルネックになってくるんです
単純にその二つのテーブルを
ジョインするような
シンプルな例だったらいいんですけど
例えばユーザーテーブルから
フォローしているユーザーの一例を
フォローテーブルからジョインさせて
次にツイートテーブルとジョインして
フォロワーのアカウントのIDとか
最近のレイティストの
最近のツイートも一緒に表示させて
それらがどれくらいお気に入りされているか
みたいな件数を取るために
ライクテーブルともジョインさせてみたいな
ジョインの嵐になってきますと
ジョインの嵐になってくると
開発効率だけとか実装効率だけではなくて
普通に実アプリケーションの運用として
全然スケールしない
例えばウェブサイトを表示するのにも
数秒かかってしまうみたいな感じになってくるんですよね
スケール性能に乏しい
あとはやっぱりエッジとノードで表現しやすい
メンタルモデルだと思うんですよ
誰かが誰かをフォローしているみたいな
そういうのが
ホワイトボードにそのまま落とし込めるんですけど
それをわざわざテーブルというものを使って
21:01
正規化をして落とし込まなきゃいけないので
ここでコンテキストがスイッチみたいなものが
発生してしまうんですよね
開発者の中で
そういった開発効率っていうのも難がある
グラフデータベースは
それをどう解決するかというと
グラフ理論で解けるような
エッジとノードで表現できるデータっていうのは
を保存してクエリを
実行するのとっても早いんですよ
別にこれは全然魔法ではなくて
ディスク上に保存している
データのレイアウトを工夫しているからなんですけども
ソーシャルネットワークのような
エッジとノードで表現できるものを
ディスク上で連結リストのような形で
関連するデータを
ポインターのように探索できるようにしているんですね
クエリもそれに伴って
例えば
userA is following userBみたいな感じで
SQLではなく
例えばNeo4jですと
Neo4jの専用のクエリラングレージを
Cypherというものがあるんですけども
Cypherを使って
割と直感的に
データを保存することができると
ディスク上のレイアウトが
工夫されていることによって
userAのフォローしている
userBのフォローしている
userCの最近の
お気に入りみたいなのが
本当にポインターを
3HP、4HP辿っていくような形で
かなり高速に探索できます
大量のテーブルをジョインして
インデックスとかを駆使して
取るというものではなくて
本当にかなり高速に探索できます
さらに
グラフのエッジとノードで
表現していることによって
数々のグラフ理論における
数学的ファンクションを実行できます
例えば最短経路の実行ですとか
あとはいろいろアルゴリズムがあるんですけども
それももちろん
RDBMSで表現したものを
一旦メモリに持ってきて
アプリケーションレイヤーで
実行というのもあるんですけども
データベースレイヤーで
実行できちゃうんですよね
そのグラフ理論の関数が
なのでめちゃくちゃ早いし
データベースを使う側からすると
そのグラフ理論を適用した結果で
返ってきてするので
本当にありがたいっていうか
アプリケーションレイヤーで
実装する必要がない
っていうのが一番のポイントになってきます
なので
グラフデータベースは
地上最強のデータベースかって言うと
全然そんなことはないんですが
グラフ理論を使いたくて
グラフ理論で表現できる
アプリケーションであれば
選択の余地はかなりあるかなと思っています
もちろんディスク上のレイアウトを工夫して
いるだけじゃなくて
クエリを最適化させるような
地道なクエリ実行計画の作成であったりとか
24:01
あとはもちろんメモリを活用した
そのデータベース内部での
副次的データ構造の補助とか
などをすることによって
グラフデータベースなりの
ハイパフォーマンスを担保しているので
普通にRDBMSで
そういったフォロワーとか
フォローインの関係とか
関連性があるような
データモデルを表現するより
実務用上のデータモデルを表現するより
実務用上において
かなりのメリットがあるということになっています
なのでここはトレードオフですね
SQLにすごい詳しい人
RDBMSの運用にすごい詳しい人であれば
ある程度スケールもさせて
マイグレーションとかの知識もあって
SQLで表現できて正規化もすることのほうが
新しくグラフデータベースの
インスタンスを立てて
Cypherのような別のクエリ言語を学んで
新しくグラフデータベースの
それをライブラリとして
入れるよりは
学習コストが低いかもしれません
というか多分それが今の現状だと思います
ほとんどのスタートアップとか
RDBMSで全部やろうとしているところ
ただ
やっぱりクラウドの時代が来て
例えばそのグラフ
Neo4jでもクラウドで
提供されている
グラフデータベースが出てきました
マネージドデータベースですね
AWSの
とかでもNeptuneとか使えますし
なのでクラスターを運用するみたいなところは
だいぶオフロードできますよね
そのクラウド運用側に
となってくると
そのクエリ言語を学ぶとか
そのアプリケーションレイヤーだけ
最低限覚えておけば
ある程度実に
頼るような利用ができてくる
ということになるので
5、6年前にグラフデータベースをやってます
自分たちでも運用してますってよりは
かなりとっつきやすくなってきたんじゃないかと
思いますね
ということなのでまとめると
グラフデータベースっていうのは
グラフ理論を適用できるデータモデルに対して
かなり使えると
なのでこのポイントとしては
要件とかを実装
設計して落とし込む時に
これってわざわざRDBMSで表現するように
グラフ理論で一瞬で解けるよね
一瞬とは言わずに
グラフ理論でネイティブに解けるよね
っていうのが分かれば
これはかなり最高の余地があるかなと
思っています
今日はこんなところですかね
グラフデータベースについて
お話ししてみましたが
声でどれぐらい
Podcastというメディアで
どれぐらいうまく伝えるのか
っていうのが今回気になるところなので
もしフィードバックとかあれば
ぜひぜひ教えてください
ロンドンテックトークでは
ご意見ご感想を募集しています
スタンドFMのレター機能
使ってぜひご意見やご感想を聞かせてください
27:01
質問でも構いません
その場合は番組内で取り上げて答えていきます
それではまた来週
