20200521

基本情報

開催日	開催時間	開催場所
2020-05-21	19:00-20:30	オンライン

発表者

メインセッション：yahonda さん

参加者

Connpassページを参照のこと。

司会（管理者）

こば

アジェンダ

No	時間	議題	説明
1	19:00-19:10	自己紹介	各自
2	19:10-19:40	（発表）1. Introduction and Overview	サマリの発表を想定、都度質問もOK
3	19:40-20:10	（議論）1. Introduction and Overview	本文内容にこだわらず自由に、適宜休憩
4	20:10-20:30	次回以降の進め方を議論、発表者の決定	5回目ぐらいまでは決めたい

当日出た質問と回答（サマリ）

質問：DBを選ぶ時の基準は？
　- 元Oracleなので。昔はそんなに選択肢もなかった。
　- 技術者がいるか、みたいな観点や顧客の要望もあると思う。
　- 業務要件がまずある。

質問：IoTだとRDBが難しい。ひたすらセンサーデータを入れておけというユースケースなど。ただCassandraだけもきつい。
　- その通りで1種類のDBというのはきつい。使い分けになると思う。
　- WriteヘビーなゲームなどはRDBだときつい。
　- 時系列DBもあるよ。
※VictoriaMetricsは結構参加者の興味を引いた様子。

質問：最近のOLAPのバックエンドって単一DBなのか？それとも複数種のデータソースか。
　- DWHつくることも。
　- どこのレイヤでデータを抽象化するかが重要。TablaeuとPrestoでそのあたりの考えに違いがある。
　- 今は選択肢が色々ある。

質問：ヒープという用語が出てくるが、この言葉の意図は？
　- 挿入順など一切の順序を保証しない、空いてる箇所に突っ込むだけなのがヒープ。
　- ヒープってpostgres用語？MySQLはWebexのチャットにあったようにインデックス構成表。
　- Oracleでもヒープはマニュアルにある。

当日のチャットログ

- 著者はAlex Petrovさん twitterのbioだとApache Cassandra Committer
- https://github.com/ifesdjeen
- 「オペレーションの実行」は，CC と RW を実行することでしょうかね・・・
- バイト列の解釈は上位レイヤーがやるということでしょうかね
- 自分もそういう風にとらえました
- ストレージとDBとの比較の一環でデータの持ち方に触れてる感じですかね > For flexibility ~
- データベースのディシジョンツリーって皆さまどうされてますか？(アプリエンジニア的には詳しいDBAいるかどうか、トランザクションをどこまで強固なものを必要とするかぐらいで大体決まっちゃいますが...)
- ここでのあらかじめ定義はPrepared Statementというより、一度書いたクエリを何回も実行するような用途という意味だと僕は解釈しました。
- Time-Series DBではタイムスタンプを差分でもつのがよくありますね
- SIMD のことですね
- SIMDだ
- https://dl.acm.org/doi/pdf/10.14778/2824032.2824078 最近の時系列データベースではほとんどのOSSはこちらの論文の差分符号化アルゴリズムを採用していますね。
- SIMDはたしか90年代からあるので意外と歴史ありますね。
- SAP HANA なんかはカラムでメモリ上にデータを保持して，HTAP 的なワークロードに耐えられるような実装になっています．
- Primary Index as indirectionはMySQLかな
- "Primary Index as an Indirection"　の話を伺っているとディスクという物理的要素がアルゴリズムに与えている影響が大きいのですね(だからNVMeだとまた違ってくるのか)
- ですね。Secondary key(not PK) はleaf nodeにPKのidを持ってます
- MySQLだと
- Indirection，インメモリ DB ではパフォーマンスのボトルネックになるという話が最近の DB 分野の話題ですね．
-ランキングとかリアルタイム集計にはRedisが扱いやすいですね
- InfluxDBはクラスタリングや分散がイマイチ弱かったですね
- クラスタリング機構がそもそも商用エディションのみで試しづらいというのもありますね。 > influxdb
- インメモリ DB の性能はディスクベースの DB でバッファ管理を工夫すれば実現できるという研究: https://umbra-db.com/
- 他にOpenTSDBとかも試しましたが、TSDBはどれも一癖ありました
- ですね>InfluxDBのクラスタリングは商用版のみ
- TSDBはまだ枯れてない感が
- Facebook gorillaっていうのもありましたね。
- NoSQL系はどれも運用ノウハウが確立されてなくて大変、というのもありました・・・
- TSDBはこれ使っておけばいいというのはなかなかないですね...
- 強いて言うならPrometheusが無難かな・・・データ欠損許容するので商用サービスとかではつかいづらいですが・・・
- 最近だとVictoriaMetricsが勢いがありますね。 https://victoriametrics.com/ Prometheusのリモートストレージとしても利用できます。
- なるほどVIctoriaMetrics
- コロプラさんが使ってるやつですね。>  victoria metrics Prometheus 専用と思ってましたが時系列DBだったのですね
- 関係あるかなぞですが、"MEMORY ストレージエンジン (従来は HEAP と呼ばれていました) は、メモリーに格納された内容で特定用途のテーブルを作成します。".. だそうです。 https://dev.mysql.com/doc/refman/5.6/ja/memory-storage-engine.html
- bi-weeklyでよいと思います
- 2週間ごと良い気がします
- 2週間でよさそうです！
- 2週間毎に賛成です

次回以降の進め方

トピック（１）開催ペース、1回あたりのボリュームについて

月1回か、ボリュームを減らして2回開催かなど間隔の調整を行う。開催日は変動があってよいが、発表者優先で調整する。
どの程度の期間で輪読会完了を目指すか。半年？1年？
上記ペースに合わせて、各回のボリュームをどのように調整するか。各章のボリュームや難易度を参考に。

当日のコメント等

オンラインのメリットを活かして、月2回、2週間に1回ぐらいでも良い。
ボリューム的には後半は1章でも1人で発表するのが厳しいと思う。

トピック（２）次回以降の発表者について

第2回から第5回目までの発表者を大まかに決める。当然後日調整は可能。
開催場所は発表者が探す必要はない。もちろん発表者が行きやすい場所（自社等）、使いやすいツール等を調整することは可能。
各回1人ではなく、2人発表の方が良いかも知れない。

当日のコメント等

2章から6章、10章の発表者について立候補があったので、それを全体スケジュールに反映する。
開催日は発表者のスケジュールを最優先で調整する。
5章の担当は今日分けておいた方が良さそう、ということで話し合い、fujiiさんが前半の1.Buffer Managementと2.Recoveryを担当、ゆで卵さんが3.Concurrency Controlを担当する。