Database Lounge Tokyo #5 ツイートまとめ

3tつのお題。論理と物理の戦い、共有地をめぐるトレードオフ、リソースはすべてを解決するか #dbltokyo

2017-09-19 19:15:55

今日も #dbltokyo の聴衆の面々が強い（確信

2017-09-19 19:16:27

豚子玉川 @ButakoTamagawa

ミックさん、トークがめっちゃ流暢 #dbltokyo

2017-09-19 19:16:35

Tomoo Takahashi @tjtakahashi

「論理と物理の戦い。論理は物理から独立可能か？」#dbltokyo

2017-09-19 19:16:49

論理は物理から独立可能か？ #dbltokyo

2017-09-19 19:16:53

論理設計と物理（ストレージ、ファイルシステム等々）は独立できるのかという話。 #dbltokyo

2017-09-19 19:17:03

𝗻𝘂𝗹𝗹 | 𝘂𝗻𝗱𝗲𝗳𝗶𝗻𝗲𝗱 | @cheezenaan

論理設計と物理設計のギャップから、性能問題が発生する #dbltokyo

2017-09-19 19:17:11

パフォーマンス問題の多くが論理/物理のギャップに起因 #dbltokyo

2017-09-19 19:17:34

パフォーマンス観点では、物理から独立していない論。 #dbltokyo

2017-09-19 19:18:17

RDBは物理的概念を抽象化することにかなり早い段階で成功した事例。だからこんなに流行った。ファイル→テーブルデータのアドレス→データの値列→属性データの位置など全く気にしなくても使えるからすごい。　#dbltokyo

2017-09-19 19:18:36

Tomoo Takahashi @tjtakahashi

「配列型という黒歴史。みんな優しいからなかったことにしている」ww #dbltokyo

2017-09-19 19:18:43

配列型はオールスルーw #dbltokyo

2017-09-19 19:18:44

「PostgreSQLやOracleは配列型を実装してしまった」「みんな優しいのでスルーしている」 #dbltokyo

2017-09-19 19:18:56

しかし完全に分離はできず隠蔽は出来ていない #dbltokyo

2017-09-19 19:19:04

𝗻𝘂𝗹𝗹 | 𝘂𝗻𝗱𝗲𝗳𝗶𝗻𝗲𝗱 | @cheezenaan

ファイルとかデータのアドレス等の物理的な概念を抽象化して隠蔽化できたのはRDBの大きなポイントだった #dbltokyo

2017-09-19 19:19:23

物理層の抽象化はうまくいったが、物理/論理の隔離は駄目だった #dbltokyo

2017-09-19 19:19:57

atsuizo @atsuizo

「ぐえー、多すぎるンゴ」#dbltokyo

2017-09-19 19:20:00

改善出来ないSQL → ヒット件数が単純に多すぎる #dbltokyo

2017-09-19 19:20:18

Blacknon @blacknon_

SQLがなぜ遅いか→ヒット件数が多すぎる #dbltokyo

2017-09-19 19:20:24

Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp @Guutara

論理と物理の分離。というわけかたでいうと、アプリ（開発者）とDBA（人間なんだよ）の分離も雄ねじ気がするし、多分、原理的には、抱える問題も、似ている。隠蔽はできたけど、隔離までは行かない。。。 #dbltokyo

2017-09-19 19:20:46

改善できないSQL：ヒット件数が多すぎる。環境側で頑張るしかない？ #dbltokyo

2017-09-19 19:21:02