ウェルネスAIとグラフDB
FiNC CTO 南野充則
目次
1. 自己紹介/会社紹介
2. FiNC人工知能:ウェルネスAI
3. リレーショナルDBとグラフDB
4. ウェルネスAIの課題
5. 導入によるメリット
①自己紹介
・Swiftと画像解析
最近のブーム
大学時起業、受託開発と
コンサルティングの会社
を営み、FiNCへ。
南野 充則
取締役 CTO
経歴
・ダイエット実験
好きなAWS
・S3
①会社紹介
モバイルヘルスケアベンチャー / 科学×専門家
②FiNC人工知能:ウェルネスAI
=
管理栄養士とトレーナーの英知を集めた人工知能。
②FiNC人工知能:ウェルネスAI
個人の生体情報をインプットすることによって、その人
に最適なアドバイスを可能にする
③課題
UserとLifeLog、LifeLogとTag、TagとItem(食事、運
動、生活習慣改善行動)といった関連テーブルが多数
LifeLog Tag Item
join多すぎる。効率のいいクエリをなかなか書けない。
④グラフDB
出典:Learning Neo4j、Rik Van Bruggen
<リレーショナルDB>
・述語論理に基づいたリレーショナルモデルを採用
・強い整合性と表現力の豊かさが特徴
<グラフDB>
・ノードとエッジという2つの要素から構成されるグラ
フを扱うことに特化
・柔軟性と高速なグラフ演算が特徴
リレーショナルDBでもグラフ扱えるよ?
テーブル構造として表現することは可能。
・効率的なクエリを書くことは困難。
例1)リレーションの数だけ中間テーブルが必要でjoinが増える。
例2)経路を見つける時も1度見つかっても最短経路である保証はない
・そもそもSQLは宣言型、最短経路問題は手続き的な解法が必要
・整合性を保証するのが難しい(エッジの追加後にループや閉路がな
い、エッジを削除してもグラフが連結している、平面的)
参考) SQLアンチパターン(Naive Trees)
http://qiita.com/hirashunshun/items/06adf4f42f03a9f3b63d
⑤メリット
1. Joinを考えなくていい
2. 経路検索が容易
3. 複数条件も容易
⑤メリット
Join の手間がかからない
ex.) 「食事タグ」がついた生活習慣改善行動(タスク)
を取得
# 1-1. Cypher
MATCH (task:`Task`)<--(tag:`Tag`)
WHERE tag.name = ‘食事’ RETURN task;
# 1-2. SQL
SELECT * FROM tasks
INNER JOIN tags_tasks ON tasks.id = tags_tasks.tag_id
LEFT JOIN tags ON tags.id = task_sets.tag_id
WHERE tags.name = '食事'
⑤メリット
経路検索が容易
ex.) 自分のLv.4 のタスクで食事タグがついているもの
# 2-1. Cypher
MATCH (tag: `Tag`)-->(lv_up_task:`Task`)<-[r*3]-(task:`Task`)
WHERE tag.name = "食事"
RETURN lv_up_task;
# 2-2. SQL
SELECT * FROM tasks
LEFT JOIN level_up_paths as lv2_paths ON tasks.id = lv2_paths.task_id
LEFT JOIN level_up_paths ON lv3_paths ON
lv2_paths.next_task_id = lv3_paths.task_id
LEFT JOIN level_up_paths ON lv4_paths ON
lv3_paths.next_task_id = lv4_paths.task_id
INNER JOIN tags_tasks ON lv4_paths.next_task_id = tags_tasks.task_id
LEFT JOIN tags ON tags.id = tags_tasks.tag_id
WHERE tags.name = '食事'
⑤導入によるメリット
複数条件も容易
ex.) ビタミン, 夏, 間食タグのうち、2つ以上持つタスク
# 3-1. Cypher
MATCH (task:`Task`)<-[r]-(tag:`Tag`)
WHERE tag.name IN ['ビタミン', '夏', '間食']
WITH task, count(r) as tags_count
WHERE tags_count >= 2 RETURN task;
# 3-2. SQL
SELECT * FROM tasks
LEFT JOIN tasks.id = filter.id
( SELECT tasks.id, COUNT (*) as tags_count FROM tasks
INNER JOIN tags_tasks ON tasks.id = tags_tasks.tag_id
LEFT JOIN tags ON tags.id = task_sets.tag_id
WHERE tag.name IN ['ビタミン', '夏', '間食']
GROUP tasks.id
HAVING tags_count >= 2
) as filter
1. クエリ書くの簡単
2. データの可視化楽しい
3. 栄養士・ディレクターとのコミュニケーション
円滑化
4. データを実験的に試すのは⃝
5. 本番環境で試すのはもう少し検証必要
1. スケーラビリティ
2. パフォーマンス
グラフDBに詳しい方。是非教えてください。
現在はNeo4jを使用(Railsと相性いい?)
ご静聴ありがとうございました。

More Related Content

PDF
11:7@google
PDF
FiNCとマイクロサービス
PDF
20151204 遺伝子&健康アプリサービスの提案
PDF
Microserviceなんて最初からやるもんじゃ無かった
PPTX
上げよう!IoT女子力
PPTX
IoTガーデニング(IT農業)第一弾
PPTX
新卒自称IoT女子が社内でIT農業をやろうとがんばっています
PDF
Japan Anti-Abuse Working Group
11:7@google
FiNCとマイクロサービス
20151204 遺伝子&健康アプリサービスの提案
Microserviceなんて最初からやるもんじゃ無かった
上げよう!IoT女子力
IoTガーデニング(IT農業)第一弾
新卒自称IoT女子が社内でIT農業をやろうとがんばっています
Japan Anti-Abuse Working Group
Ad

ウェルネスAiとグラフDB