-
- いいね！9
mitomasan
@mitomasan
これから(15:45から)お話するデブサミ関西2017【C-4】の資料です！ 3000社の業務データ絞り込みを支える技術 #devsumiC slideshare.net/RyoMitoma/3000…
2017-09-08 15:31:35
鎌玉 大
@kamatamadai
#devsumiC 3000社の業務データ絞り込みを支える技術 〜kintoneのアーキテクチャと高速化〜 三苫 亮 [サイボウズ]さんの話へ。去年のセッション内容が興味深かったので
2017-09-08 15:41:41
鎌玉 大
@kamatamadai
#devsumiC スキーマ不定な業務データを扱うためのKindle現行アーキテクチャと現在進んでいるElasticserch利用の話
2017-09-08 15:47:22
鎌玉 大
@kamatamadai
#devsumiC RDBMSはスキーマ固定。スキーマ不定なデータは、構造はあるけど変わる。構造がないスキーマレスと異なる。
2017-09-08 15:53:56
鎌玉 大
@kamatamadai
#devsumiC スキーマレスは全部連想配列/Map/Hashでやるイメージ。スキーマ不定は実行時に型が変わる、Rubyぽい世界観。スキーマ固定は実行時に変更は許さないJavaぽい世界観。
2017-09-08 15:56:53
鎌玉 大
@kamatamadai
#devsumiC RDBMSでスキーマ不定データを扱う４つのアプローチ。1)構造写像アプローチ：型が変わる度にDDL発行。デメリット：インデックス戦略がアドホックになりがち
2017-09-08 16:01:04
鎌玉 大
@kamatamadai
#devsumiC 2)モデル写像アプローチ…DBアンチパターンのEntity Attivuteパターン(何でもテーブルですね)。デメリットはパフォーマンスが悪い、インデックスを張るのが難しい
2017-09-08 16:03:40
鎌玉 大
@kamatamadai
#devsumiC 3)salesforceアプローチ…リザーブ列を予め用意（それ、COBOLで見た）。検索用にインデックステーブルを使用。デメリット：項目数に上限がある
2017-09-08 16:05:25
鎌玉 大
@kamatamadai
#devsumiC 4)friendfeedアプローチ…データをシリアライズして１カラムに放り込む。JSONみたいなイメージ。検索用にインデックステーブル。デメリット：データ更新やシリアライズ・デシアライズのコストが大きい
2017-09-08 16:06:54
鎌玉 大
@kamatamadai
#devsumiC kin toneはfriendfeedアプローチ。命名元のfriendfeedというサービス今はもうない
2017-09-08 16:07:43
鎌玉 大
@kamatamadai
#devsumiC SQLで書くとこんな感じ SELECT データ FROM データテーブル JOIN ●インデックステーブル ON データテーブル.テーブル=●インデックステーブル.テーブル AND データテーブル.番号=●インデックステーブル.番号 JOIN ●インデックス…
2017-09-08 16:09:47
鎌玉 大
@kamatamadai
#devsumiC kintoneは業務システムなのでデータ量は 多くとも数万件のオーダーで済むという前提があった☺ ＜ 我々は非機能要件で保護されている！続きは後半で…(あああああ、)
2017-09-08 16:10:37
鎌玉 大
@kamatamadai
#devsumiC kintoneでのデータ絞り込みは、UIやREST APIから独自クエリを発行して、AST(抽象構文木)に変換後、SQLに変換している。ASTに変換するメリット：構文エラーを検出できる、安全に書き換えやすい、SQL以外に置換も可能
2017-09-08 16:15:46
鎌玉 大
@kamatamadai
#devsumiC ここからはkintoneにまだ反映されていない処理について。パフォーマンス問題をどうするか？インデックステーブル、データテーブルを引っ張るSQLが遅く複雑。大量のJOINをどうする。そこでElasticsearch
2017-09-08 16:18:54
近藤佑子
@kondoyuko
サイボウズ三苫さんのセッション。kintoneのアーキテクチャの解説です。 #devsumiC pic.twitter.com/dskQm1wO8C
2017-09-08 16:21:11
拡大