Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 3000社の業務データ絞り込みを支える技術
Similar to 3000社の業務データ絞り込みを支える技術 (20)
More from Ryo Mitoma
Recently uploaded
Recently uploaded (9)
3000社の業務データ絞り込みを支える技術
- 1. 3000社の業務データ 絞り込みを支える技術 kintoneの アーキテクチャと高速化 サイボウズ大阪開発部 三苫 亮 2017/09/08 Developers Summit 2017 KANSAI
- 2. 自己紹介 三苫 亮（みとま りょう） • @mitomasan • サーバーサイドエンジニア • Java, DB周りが好き • サイボウズ大阪開発部で kintone という製品の開発をしています。
- 4. お話のながれ • スキーマ不定データの格納・絞り込み • kintone の絞り込み • パフォーマンスの問題 • Elasticsearch の概要 • 対策の概要と結果・トレードオフ • まとめ
- 7. どんなデータを？
- 10. 売上伝票？ 伝票番号 売上額 品名 単価 品名 単価 品名 単価 …
- 11. データの形はさまざま
- 15. スキーマレスって知ってる？ • スキーマレスDBという言葉をよく聞くね • つまり構造が無い • ベースラインとする構造は あるだろうけれど それを逸脱するデータも許容する🙆
- 16. スキーマ不定なデータというのもある • 構造が一定のままではないデータ • 構造はあるけど、変わる • その時点の構造に合わないデータは許容しない🙅 • スキーマレスとは似て非なる言葉 名前 性別 名前 性別 学年 名前 性別 職業 収入
- 17. イメージとしては… あくまでイメージね • スキーマレス • ぜ～んぶ連想配列/Map/Hashでやっちゃうよ～☺ • カウボーイっぽい世界観 • スキーマ不定 • 型定義はするんだけど、実行時に途中で型変えちゃうよ • Rubyっぽい世界観 • スキーマ固定 • 実装時に型定義して、実行時に変更は許さないよ • Javaっぽい世界観
- 18. スキーマ不定 どんな時に使われる？ • 構造をあらかじめ決められないとき • 答えが決まっていなくてもとにかく始めたい • 決定している項目は系統立てて格納・絞り込み・集計したい • その時の必要に合わせて構造を変更したい ビジネスの現場でありがちな要求 また話が 変わったようだな
- 21. RDBMSでスキーマ不定データを扱う RDBMSでスキーマ不定データを扱うアプローチは大きく４つ • 構造写像アプローチ • モデル写像アプローチ • friendfeedアプローチ • salesforceアプローチ 参考：http://dev.ariel-networks.com/Members/inoue/schemaless/
- 22. 構造写像アプローチ • データの構造を、RDBMS上に構築する • つまり普通のデータベースと同じ • メリット • RDBMSの機能がそのまま使える • パフォーマンス • デメリット • 構造を変更するとき(DDL発行時)に トランザクションで保護できない場合がある • インデックス戦略がアドホックになりがち • データ種別の数だけテーブルが増える ラーメン屋リスト 店名 住所 評価 …
- 23. モデル写像アプローチ • データのモデルをRDBMS上に構築する • メタプログラミング的 • メリット • RDBMSのテーブル定義変更が不要 • ロックの粒度を小さくできる • デメリット • パフォーマンスはあまりよくない • レコード数が非常に多くなる • よいインデックスを張るのが難しい データテーブル テーブル カラム 番号 データ ラーメン屋リスト 店名 ラーメン屋リスト 住所 ラーメン屋リスト 評価 ラーメン屋リスト … 1 1 1 1 ラーメン屋リスト 店名 ラーメン屋リスト 住所 ラーメン屋リスト 評価 ラーメン屋リスト … 2 2 2 2
- 24. salesforceアプローチ • 汎用的で巨大な構造を最初に定義 • 最初に100カラムとか用意しておく • 検索用にインデックステーブル • メリット • RDBMSのテーブル定義変更が不要 • わかりやすい • デメリット • 項目数に上限がある データテーブル テーブル 番号 C1 C2 C3 C4 C5 … ラーメン屋リスト ラーメン屋リスト ラーメン屋リスト … インデックステーブル テーブル 番号 インデックス値 × データ型の数だけ 1 2 3 ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3
- 25. friendfeedアプローチ • データをシリアライズして 1カラムに放り込む • JSONみたいなイメージ • 検索用にインデックステーブル • メリット • RDBMSのテーブル定義変更が不要 • Salesforceアプローチに比べて項目数 の制限が無い • デメリット • データ更新やシリアライズ・デシリアラ イズのコストが大きい データテーブル テーブル 番号 データ ラーメン屋リスト ラーメン屋リスト ラーメン屋リスト … ｛ …｝ ｛ …｝ ｛ …｝ 1 2 3 インデックステーブル テーブル 番号 インデックス値 × データ型の数だけ ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3
- 27. こんな形の普通のテーブルだったら どうやってデータを絞り込むの？ ラーメン屋リスト 店名 住所 評価 … 天一 S …
- 28. SQLで書くとこんな感じ SELECT * FROM ラーメン屋リスト WHERE 店名='天一' AND 評価='S'
- 29. ｛天一 S friendfeedアプローチだとこうなる データテーブル テーブル 番号 データ ラーメン屋リスト ラーメン屋リスト ラーメン屋リスト … ｛ …｝ ｛ …｝ …｝ 1 2 3 インデックステーブル テーブル 番号 インデックス値 ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3 インデックステーブル テーブル 番号 インデックス値 ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3 天一 S
- 30. ｛天一 S 店名が '天一' データテーブル テーブル 番号 データ ラーメン屋リスト ラーメン屋リスト ラーメン屋リスト … ｛ …｝ ｛ …｝ …｝ 1 2 3 インデックステーブル テーブル 番号 インデックス値 ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3 インデックステーブル テーブル 番号 インデックス値 ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3 天一 S
- 31. ｛天一 S 店名が '天一' かつ評価が 'S' データテーブル テーブル 番号 データ ラーメン屋リスト ラーメン屋リスト ラーメン屋リスト … ｛ …｝ ｛ …｝ …｝ 1 2 3 インデックステーブル テーブル 番号 インデックス値 ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3 インデックステーブル テーブル 番号 インデックス値 ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3 天一 S
- 32. ｛天一 S 店名が '天一' かつ評価が 'S' データテーブル テーブル 番号 データ ラーメン屋リスト ラーメン屋リスト ラーメン屋リスト … ｛ …｝ ｛ …｝ …｝ 1 2 3 インデックステーブル テーブル 番号 インデックス値 ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3 インデックステーブル テーブル 番号 インデックス値 ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3 天一 S 番号=3のレコードが 目的のレコードであることがわかる
- 33. ｛天一 S 店名が '天一' かつ評価が 'S' データテーブル テーブル 番号 データ ラーメン屋リスト ラーメン屋リスト ラーメン屋リスト … ｛ …｝ ｛ …｝ …｝ 1 2 3 インデックステーブル テーブル 番号 インデックス値 ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3 インデックステーブル テーブル 番号 インデックス値 ラーメン屋リスト 1 ラーメン屋リスト 2 ラーメン屋リスト 3 天一 S 番号=3のレコードを取得する
- 34. SQLで書くとこんな感じ SELECT データ FROM データテーブル JOIN ●インデックステーブル ON データテーブル.テーブル=●インデックステーブル.テーブル AND データテーブル.番号=●インデックステーブル.番号 JOIN ●インデックステーブル ON データテーブル.テーブル=●インデックステーブル.テーブル AND データテーブル.番号=●インデックステーブル.番号 WHERE データテーブル.テーブル = 'ラーメン屋リスト' AND ●.インデックス値 = '天一' AND ●.インデックス値 = 'S'
- 37. kintone の絞り込み
- 39. UI : 絞り込み画面
- 40. UI : REST API SQLライクな独自クエリで条件指定して問い合わせる。 （絞り込み画面もブラウザ側で独自クエリを組み立てて送信） GET /k/v1/records.json ?app=1 &query=部署 in ("営業", "マーケティング") and 営業内容 like "引き合い"
- 41. kintone の絞り込みの仕組み 送信 AST （抽象構文木） 変換独自クエリ SQL変換 実行 結果セット （生データ） 結果セット （オブジェクト） 変換変換 返却返却 JSON
- 42. kintone の絞り込みの仕組み 送信 AST （抽象構文木） 変換独自クエリ SQL変換 実行 結果セット （生データ） 結果セット （オブジェクト） 変換変換 返却返却 JSON • 構文解析
- 43. kintone の絞り込みの仕組み 送信 AST （抽象構文木） 変換独自クエリ SQL変換 実行 • 暗黙的な条件追加 • 条件式最適化 結果セット （生データ） 結果セット （オブジェクト） 変換変換 返却返却 JSON
- 44. kintone の絞り込みの仕組み 送信 AST （抽象構文木） 変換独自クエリ SQL変換 実行 • SQLに変換する • さっきのJOINおばけを作る 結果セット （生データ） 結果セット （オブジェクト） 変換変換 返却返却 JSON
- 45. kintone の絞り込みの仕組み 送信 AST （抽象構文木） 変換独自クエリ SQL変換 実行 結果セット （生データ） 結果セット （オブジェクト） 変換変換 返却返却 JSON • 条件に合う レコードのIDを取得 • レコードのデータを取得
- 46. kintone の絞り込みの仕組み 送信 AST （抽象構文木） 変換独自クエリ SQL変換 実行 結果セット （生データ） 結果セット （オブジェクト） 変換変換 返却返却 JSON • オブジェクト変換
- 47. kintone の絞り込みの仕組み 送信 AST （抽象構文木） 変換独自クエリ SQL変換 実行 結果セット （生データ） 結果セット （オブジェクト） 変換変換 返却返却 JSON • アクセス権評価
- 48. kintone の絞り込みの仕組み 送信 AST （抽象構文木） 変換独自クエリ SQL変換 実行 結果セット （生データ） 結果セット （オブジェクト） 変換変換 返却返却 JSON • JSON変換
- 49. 補足：AST（抽象構文木）とは？ • プログラム（ここでは独自クエリ）を木構造に変換したもの。 AND IN LIKE 部署 営業内容 営業 引き合い マーケティング 部署 in ("営業", "マーケティング") and 営業内容 like "引き合い"
- 50. ASTに変換するメリット • 不正な入力を構文エラーとして検出できる。 • 安全に書き換えやすい。 • 文字列置換で内部でクエリを書き換え→キビシイ🙅 • SQLから独立しているため ASTからほかの問い合わせ言語に置き換えることも。 • これは後半の伏線
- 51. パフォーマンス問題
- 54. 湧き上がる問題 • データを絞り込んでも、何分も結果が返ってこない • 絞り込みのためのSQLが読みにくく、チューニングが大変 • チューニングのためにさらにSQLが膨れ上がったり パフォーマンスと保守性の低下。
- 55. インデックス テーブル インデックス テーブル どこを直せばいい？ いままではこう。 ②+③が遅く複雑なSQLになっている。 データテーブル インデックス テーブル① ④ ③ ② 検索するぞ！
- 57. どうやればいいだろう？ 問題点はJOINが大量にあること • JOINしないように検索対象のテーブルをまとめたい • まとめるとインデックスがうまく張れない • ≒構造写像アプローチのデメリット • データ量が膨大だとRDBMSでは 全項目のインデクシングは困難
- 59. Elasticsearchのいいところ • 分散型 • 複数のノードからクラスターを構成する • ノードを増やして性能を上げることが出来る Cluster Node Node Node Node …
- 61. Elasticsearchのいいところ • 全文検索ができる • キーワード検索をおこなうことができる • 'トンドル' で検索して '㌧㌦' も候補にあげることもできる • すでにkintoneは全文検索エンジンのSolrも組み合わせて 使っており、それの置き換えにもElasticsearchを検討していた
- 62. Elasticsearchのいいところ • 安定運用やセキュリティに力を入れている • Java Security Manager • 一部のモジュールだけに特権を制限している • JarHell対策 • ライブラリやクラスの衝突により、実行時に誤動作すること • Elasticsearchは起動時に衝突していないか検証している • 起動時チェック • ヒープサイズ・ファイルデスクリプタ・仮想メモリが十分か確認 • などなど、詳細はここをチェック！ • https://www.elastic.co/jp/blog/elasticsearch-the-server
- 63. でてきた解決策 • 絞り込みはElasticsearchにまかせて RDBMSはオリジナルデータの保存場所とする • 堅牢さはRDBMSに一日の長がある • ID指定によるデータ取得は 現状RDBMSでも遅くない
- 65. 新しいアーキテクチャ 送信 変換独自クエリ IDリスト • QueryDSL(Elasticsearchのクエリ言語) に変換する。 結果セット （生データ） 結果セット （オブジェクト） 変換変換返却 JSON QueryDSL AST （抽象構文木） 実行 返却
- 66. 新しいアーキテクチャ 送信 変換独自クエリ IDリスト • 条件に合う レコードのIDを取得 結果セット （生データ） 結果セット （オブジェクト） 変換変換返却 JSON QueryDSL AST （抽象構文木） 実行 返却
- 67. 新しいアーキテクチャ 送信 変換独自クエリ IDリスト • レコードのデータを取得 結果セット （生データ） 結果セット （オブジェクト） 変換変換返却 JSON QueryDSL AST （抽象構文木） 実行 返却
- 71. まとめ • スキーマ不定なデータをRDBMSで扱う際の 主要なアーキテクチャを４つ紹介！ • kintoneではfriendfeedアプローチを採用してるよ • このアプローチは大量データに向かない☹ • kintoneの絞り込みのアーキテクチャ紹介 • 独自クエリとRDBMSとの橋渡し • Elasticsearchという分析エンジンを活用して 絞り込みを速くするアーキテクチャに置き換えたよ☺ • トレードオフがあり、それについては受け入れられる レベルまでアプリケーションでフォローをしたよ