kintoneの検索高速化への取り組み

kintoneの
検索高速化への取り組み
サイボウズ大阪開発部
三苫亮
2017/03/26
CAMPHOR-

自己紹介
三苫亮（みとまりょう）
• @mitomasan
• サーバーサイドエンジニア
• Java, DB周りが好き

✋注意✋
本日のお話は、開発中のものです。
弊社サービス kintone に
(まだ)反映されていません。

今日のお話
kintoneであつかっている
スキーマ不定なデータを
Elasticsearch にのせて
検索を高速化するお話

お話のながれ
• データの格納のしかたや検索の方式について
• kintone で発生したパフォーマンスの問題について
• Elasticsearch の概要
• 対策の概要と結果・トレードオフ
• まとめ

データをデータベースに格納する

同級生の名簿？
名前
性別
学年
つながり
共通の趣味

ラーメン屋のリスト？
店名
住所ジャンル
評価

売上伝票？
伝票番号
売上額
品名単価
品名単価
品名単価
…

データの形はさまざま

スキーマというスキーマ＝構造
データはそれぞれ構造を持っている

構造が事前にわかっているとシステムは処理しやすい
スキーマを定義して固定する
店名が天一で評価の高い
ラーメン屋が知りたいな
店名住所評価 …
天一 S

RDBMSの基本はスキーマ固定
友達テーブル
名前
連絡先
地元
構造を先に決めちゃう（＝テーブルを定義する）
バイト先
エピソードテーブル
友達名
日時
エピソード

スキーマレスって知ってる？
• スキーマレスDBという言葉をよく聞くね
• つまり構造が無い
• ベースラインとする構造は
あるだろうけれど
それを逸脱するデータも許容する🙆

スキーマ不定なデータというのもある
• 構造が一定のままではないデータ
• 構造はあるけど、変わる
• その時点の構造に合わないデータは許容しない🙅
• スキーマレスとは似て非なる言葉
名前
性別
名前
性別
学年
名前
性別
職業
収入

イメージとしては… あくまでイメージね
• スキーマレス
• ぜ～んぶ連想配列/Map/Hashでやっちゃうよ～☺
• カウボーイっぽい世界観
• スキーマ不定
• 型定義はするんだけど、実行時に途中で型変えちゃうよ
• Rubyっぽい世界観
• スキーマ固定
• 実装時に型定義して、実行時に変更は許さないよ
• Javaっぽい世界観

スキーマ不定
どんな時に使われる？
• 構造をあらかじめ決められないとき
• 答えが決まっていなくてもとにかく始めたい
• とはいえ、決定している項目は系統だって検索・集計したい
• その時の必要に合わせて構造を変更したい

話は変わってkintone
• スキーマを自由に設計できるWebデータベース
（＝システムの稼働中にテーブルにあたるものを定義する）
• スキーマ不定データが扱える
ドラッグ＆ドロップで
データベースの項目を
設計・変更できる

でもkintoneのバックエンドはRDBMS
えっ！？
スキーマ不定のシステムなのに、
バックエンドはスキーマ固定の
RDBMSなんですか？？？
RDBMS

RDBMSでスキーマ不定データを扱う
RDBMSでスキーマ不定データを扱うアプローチは大きく４つ
• 構造写像アプローチ
• モデル写像アプローチ
• friendfeedアプローチ
• salesforceアプローチ
参考：http://dev.ariel-networks.com/Members/inoue/schemaless/

構造写像アプローチ
• データの構造を、RDBMS上に構築する
• つまり普通のデータベースと同じ
• メリット
• RDBMSの機能がそのまま使える
• パフォーマンス
• デメリット
• 構造を変更するとき(DDL発行時)に
トランザクションで保護できない場合がある
• インデックス戦略がアドホックになりがち
• データ種別の数だけテーブルが増える
ラーメン屋リスト

モデル写像アプローチ
• データのモデルをRDBMS上に構築する
• メタプログラミング的
• メリット
• RDBMSのテーブル定義変更が不要
• ロックの粒度を小さくできる
• デメリット
• パフォーマンスはあまりよくない
• レコード数が縦に爆発
• よいインデックスを張るのが難しい
データテーブル
テーブルカラム番号データ
ラーメン屋リスト店名
ラーメン屋リスト住所
ラーメン屋リスト評価
ラーメン屋リスト …
1
1
1
1
ラーメン屋リスト店名
ラーメン屋リスト住所
ラーメン屋リスト評価
ラーメン屋リスト …
2
2
2
2

salesforceアプローチ
• 汎用的で巨大な構造を最初に定義
• 最初に100カラムとか用意しておく
• 検索用にインデックステーブル
• メリット
• わかりやすい
• デメリット
• 空間効率（ディスク消費）が良くない
• 項目数に上限がある
テーブル番号 C1 C2 C3 C4 C5 …
…
インデックステーブル
テーブル番号インデックス値
× データ型の数だけ
1
2
3
ラーメン屋リスト 1

friendfeedアプローチ
• データをシリアライズして
1カラムに放り込む
• JSONみたいなイメージ
• 検索用にインデックステーブル
• メリット
• Salesforceアプローチに比べて項目数
の制限が無い
• デメリット
• データ更新やシリアライズ・デシリアラ
イズのコストが大きい
テーブル番号データ
…
｛ …｝
｛ …｝
｛ …｝
1
2
3
× データ型の数だけ

kintoneはどのアプローチ？
friendfeedアプローチ
ちなみに命名元のfriendfeedというサービスは、今はもうない

こんな形の普通のテーブルだったら
どうやってデータを検索するの？
天一 S
…

SQLで書くとこんな感じ
SELECT *
FROM ラーメン屋リスト
WHERE 店名='天一' AND 評価='S'

｛天一 S
friendfeedアプローチだとこうなる
…
｛ …｝
｛ …｝
…｝
1
2
3
天一
S

｛天一 S
店名が '天一'
…
｛ …｝
｛ …｝
…｝
1
2
3
天一
S

｛天一 S
店名が '天一' かつ評価が 'S'
…
｛ …｝
｛ …｝
…｝
1
2
3
天一
S

｛天一 S
…
｛ …｝
｛ …｝
…｝
1
2
3
天一
S
番号=3のレコードが
目的のレコードであることがわかる

｛天一 S
…
｛ …｝
｛ …｝
…｝
1
2
3
天一
S
番号=3のレコードを取得する

SQLで書くとこんな感じ
SELECT データ FROM データテーブル
JOIN ●インデックステーブル
ON データテーブル.テーブル=●インデックステーブル.テーブル
AND データテーブル.番号=●インデックステーブル.番号
JOIN ●インデックステーブル
ON データテーブル.テーブル=●インデックステーブル.テーブル
AND データテーブル.番号=●インデックステーブル.番号
WHERE
データテーブル.テーブル = 'ラーメン屋リスト'
AND ●.インデックス値 = '天一'
AND ●.インデックス値 = 'S'

それって結構大変じゃない？
そう、大変。（SQLもパフォーマンスも…）
けど大丈夫！
kintoneは業務システムなのでデータ量は
多くとも数万件のオーダーで済むという前提があった☺
＜我々は非機能要件で保護されている！

前提の崩壊
うわー！
増
大
す
る
デ
ー
タ

湧き上がる問題
• データを検索するのに、何分も帰ってこない
• 検索のためのSQLが読みにくく、チューニングが大変
• チューニングのためにさらにSQLが膨れ上がったり
パフォーマンスと保守性の低下。

インデックス
テーブル
インデックス
テーブル
どこを直せばいい？
いままではこう。
②+③が遅く複雑なSQLになっている。
インデックス
テーブル①
④ ③
②
検索するぞ！

インデックス
テーブル
インデックス
テーブル
ボトルネックを潰すしかない
②に当たる部分を高速化するんだ！
インデックス
テーブル①
④ ③
②
遅いぞ！
なにくそ！

どうやればいいだろう？
問題点はJOINが大量にあるのが辛い・遅い
• JOINしないようにまとめたい
• まとめるとインデックスがうまく張れない
• ≒構造写像アプローチのデメリット
• データ量が膨大だとRDBMSでは
全項目のインデクシングは困難

Elasticsearch
• Elasticsearchとはなに？
• 様々なユースケースを解決する、
分散型RESTful検索/分析エンジンです。（本家サイトより）

Elasticsearchのいいところ
• 分散型
• 複数のノードからクラスターを構成する
• ノードを増やして性能を上げることが出来る
Cluster
Node Node Node Node
…

• スキーマ(Mapping)を定義することができる
• スキーマをもとにした検索ができる
Index
Type
番号
店名
住所
評価
…
Type
名前
性別
年齢
趣味
地域
…
…

• 全文検索ができる
• キーワード検索をおこなうことができる
• 'トンドル' で検索して '㌧㌦' も候補にあげることもできる
• すでにkintoneは全文検索エンジンのSolrも組み合わせて
使っており、それの置き換えにもElasticsearchを検討していた

• 安定運用やセキュリティに力を入れている
• Java Security Manager
• 一部のモジュールだけに特権を制限している
• JarHell対策
• ライブラリやクラスの衝突により、実行時に誤動作すること
• Elasticsearchは起動時に衝突していないか検証している
• 起動時チェック
• ヒープサイズ・ファイルデスクリプタ・仮想メモリが十分か確認
• などなど、詳細はここをチェック！
• https://www.elastic.co/jp/blog/elasticsearch-the-server

でてきた解決策
• 検索はElasticsearchにまかせてRDBMSは
オリジナルデータの保存場所とする
• 堅牢さはRDBMSに一日の長がある
• ID指定によるデータ取得は
現状RDBMSでも遅くない

新しいアーキテクチャ
①
④
③
インデックス
②
同
期

発生するトレードオフ
• インデックスの更新が非同期
• RDBMS上のデータをもとにインデックスを更新するため
トランザクションが同一ではない。
なのでElasticsearchが検索で返した値と
RDBMSに入っているデータにズレが
発生する時間がある
①
④
③
インデックス
②
同
期

対策
• 同期が遅延しているかどうかを管理し、
遅延が発生している状況下では、
間違った検索結果を返してないか
プログラム側で再フィルタリングを行う
①
④
③
インデックス
②
同
期
遅延が発生してるな？
俺もフィルタリングや

ベンチマーク結果
• 2,000万件のレコードを
絞り込む時間がいまの実装に
比べて大幅に短縮できた！
※ kintoneの検索が改善できるかどうかという
観点で行ったベンチマークなので
RDBMSとElasticsearchの機材スペック差
などは公平ではありません

まとめ
• スキーマ不定なデータをRDBMSで扱う際の
主要なアーキテクチャを４つ紹介！
• kintoneではfriendfeedアプローチを採用してるよ
• このアプローチは大量データに向かない☹
• Elasticsearchという分析エンジンを活用して
検索を速くするアーキテクチャに置き換えたよ☺
• トレードオフがあり、それについては受け入れられる
レベルまでアプリケーションでフォローをしたよ

おしまい
やってやれないことはない
増
大
す
る
デ
ー
タ

kintoneの検索高速化への取り組み

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

More from Ryo Mitoma

More from Ryo Mitoma (9)

Recently uploaded

Recently uploaded (10)

kintoneの検索高速化への取り組み