データベースを遅くするための８つの方法

はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原

[ifttt]

ちょうど遅くしたいところだったので助かった

[electrolite]

一周回ってこういうかつて当たり前の知識の念押しが必要になっている時代。正規化しすぎというのも入れておいて。/ RDBは凝りすぎるとダメになるという意味で盆栽に似ていると思っている。

[Rinta]

“これは単純にインサート時にINDEXの再構築がたくさん走り、書き込み性能の劣化を招くからです。” すごく違和感。INDEXの更新ならわかるけど、再構築ってすごいことだと思うんだけど。RDBMSによって言葉が違うのかな。

[moto_motosaka]

あんまりデータベースの仕組み自体に詳しくない人がやりがちなやつ。ただDB性能だけに拘りすぎると、生産性や保守性が下がるケースもあるから、デメリットを理解した上であえてやる分には問題ないこともあるっちゃ

[lacucaracha]

この辺はDB全体の構造が分かってないとよく分からんところもあるのよね。ありがちなものとしては、アーカイブログ使わないのにREDOログをデフォルトのままにしてREDOスイッチ頻発させまくってた例とかあったね。

[vanbraam]

余り体系的/理論的でない記事,という印象.最初の例は典型的throughput/latency tradeoffなので,まずそれを説明してから,RDBMSでの具体例を示す方が良いと思う; 8つめはRDBMSを遅くする方法ではないので,無理に入れる必要を感じない

[infobloga]

「クライアントサイドJOIN」は時代遅れ。WebStorageが普及する前の話をしていると思われる。WebStorageが普及した現在、キャッシングを考慮するとクライアントサイドJOINのの方がネットワークトラフィックを減らせる。

[rti7743]

RDBみたいなものを作るとしたらどう設計するかというのを、実際に作らなくても良いから、脳内で考えてみると理解しやすいと思うんだよな。設計者の気持ちになって考えて、彼らに忖度したコードを書くと早くなる。

[taruhachi]

大量Deleteも付け加えたいが、Oracleだとそんなにしんどく無いのかな、、、。

[daichirata]

カーディナリティが低いカラムにインデックスはケースバイケースだし、遅くなるとかそう言う話では無い気はした

[ryosuke-fujii]

スケーラビリティを高くするためには、並列処理を妨げるUPDATE処理をいかになくすかだなぁ

[syque]

“基本的にインデックスはカーディナリティが高いカラムに指定しないと遅くなると言うか効果がありません”

[y_maeyama]

"シーケンスナンバーをPKにする"は、大量にデータをインサートしたりしたい場合はアンチパターになるとは知らなかった。勉強になる。

[efcl]

DBの削除、Indexなどのボトルネックの話

[jun6428]

相変わらず役に立つ記事は無言ブクマが多い

[uva]

はてブの攻撃的なコメントでげんなりする

[sweetestsavage]

目次では遅くするための方法書いてるのに説明文が遅くしないための方法書いてるからちょっと読み解きにくい

[surume000]

いつも“シーケンスナンバーをPK”にしとった

[buhoho]

なるほど〜と思いながら読んだところで、真に受けるとマズイみたいなブコメちょくちょくあって困惑。100文字じゃ表現できないだろうしアンサー記事待ってます♡

[kuroko_otomo]

助かる

[rawwell]

query optimizerを作ろうとすると自然に考える内容

[hachiking]

"シーケンスナンバーをPKにする" この辺りとか、構成によるよなぁ。分散環境ならわかるけど、シングルノードのMySQLとかでUUIDをインデックスにすると、リーフノードの分割が発生してコスト高かった記憶がある。

[hiby]

insertにせよupdateにせよindexにせよまあだいたいI/O絡みは遅くなるって肌感

[nonsugertan]

DB速度遅延方法

[Rishatang]

ここまでDiscussionゼロ

[NOV1975]

こういう奴はちゃんと本とか読んだ方が良いと思う。入門編ねこれ。

[rgfx]

連番PK遅いとか、本当に大規模環境が当たり前の温度感なんだなあと雲の上を見上げる気持ちになるVPS単鯖おじさんの気持ち。（やりたきゃ転職しような

[sjn]

人間フレンドリーに作ると遅くなるというリッチコンピューティングの基本を人間どもはまず知るべき

[engisuke]

失敗しながら学んできたけど、最初にこういうアンチパターンを知りたかった。

[daishi_n]

Auroraは書き込みインスタンスが1台しかない仕様で並列クエリはできるけどストレージレイヤでやってるからOracle RACとは微妙に違うけどね

[wosamu]

なんかもう少し前提としてRDBMSの仕組みあたりを説明した方がよさそうな気がする。つうかこのレベルだといまはもうメモリの量とかでだいたい力押しできてしまうのでは。

[matarillo]

インデックスが平衡木なら回転ぐらいは起きると思うがそれを再構築と言うかは、どうかな

[nmcli]

PostgreSQL勢だけど、PKにナチュラルキーの件はINSERT時の衝突可能性を排除しようと思うとserialカラムのほうが安全で好き

[koKekkoh]

アプリからしかDBを見ていない奴のあるあるじゃないかな？

[fashi]

具体例がなく専門用語だらけで読む前から知ってないと理解できないtipsな気がするけどついついブクマ

[tettekete37564]

前任者が書いたコードが1クエリ数十KBのSQLクエリをDBに何回も送りつける設計だったおっお。あるテーブルのレコード数が1増えるとクエリの要素が4増える設計だったおっお。DB側のクエリパースがボトルネックになってお

[murasuke]

シーケンスナンバーと、UUIDどちらがいいかはケースバイケース。UUIDだとキャッシュ利用率が下がるので、局所性を考えるとシーケンスNoの方が早い場合もあるし。

[convivial]

結局すべてはケースバイケースで。こういうケースもあるよと言う意味ではとても有用だと思いました。