粘れば速くなるかもしれない。2015Consulを使ったHA化の構築を行ったが、様々な問題があって結局Consulは使わずに本番運用を開始した、という話。HAは仮想IPを用いて構築する方が一般的かと思いますが、Consulを使ってDNSベースのHAを構築していました。個別の話はDNSベースならではの話、あるいはインフラ構築あるある話など様々な苦難を乗り越え(乗り越えてない?)たエピソードが満載。得られたポイント(教訓)はどんなに炎上してても負荷試験はやろう使うパッケージはきちんと理解・検証が重要とのこと。マシンで2億件のシリアルデータ(シリアルコードを含むレコード)を扱うという無理ゲーの話。Insert/Updateしたら案外早かったので、実データを使ったら所要時間が全く違っていてお客さんの前で辛いことになったそうで。オンライン処理じゃない大きなデータ投入の際はアーカイブログ切ったり、インデックスやFKの作成は後でやったりと別のアプローチが効果的なことが多いです。(個人的な経験則)元々ハードウェア的にもきつい案件ですが、DBで頑張るよりアプリやスキーマレベルでどうにかすべき部分も多かったようです。TLで流れていましたが、これが参考になりそうです。(監視)、探索的な解析などデータ解析は重要なビジネスファクタになっています。その中で最近はどのようなデータ分析基盤が作られているかをRDBから巨大データのリアルタイム処理まで順を追った解説がなされたセッションでした。Write:RDBMSはこれ。書き出す時にスキーマに合わせて書く。クエリ処理を速くするため。Read:データを書く時はスキーマを考慮せずにシンプルに置く。読み込む時に最適な型に変換する。Lake:一つの巨大なストレージにデータに置く。ベンダーによってそれ以降の解決法が異なる。Tez:タイムスライスではなく、DAGベースの処理で最適化されたクエリで処理Hadoopにはもう単一障害点はもう無い!!!Hadoopを自社で持ちたい→やめたほうがいい。しても使いたい!→ディストリビューションを使ったほうがいい。Readを行うクエリエンジン。Storm:分散リアルタイム計算を実行するエンジン。twitterが使っていたことで有名。コードのデプロイが必要。Norikra:コードではなくSQLで処理。分散しない!キューシステムデータ送信をプッシュ型からプル型にすることができ、送り先のリソース都合に合わせたデータ送信が可能。