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の検索高速化への取り組み

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Mais de Ryo Mitoma

Mais de Ryo Mitoma (9)

Último

Último (8)

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