[B! DB] frkw2004のブックマーク

Bulk insertでも20時間以上かかっていたMySQLへのインサート処理を1時間以内にする - エムスリーテックブログ

この記事はエムスリー Advent Calendar 2022の30日目の記事です。前日は id:kijuky によるチームメンバーのGoogleカレンダーの休暇予定一覧をスプレッドシート+GASで作ったでした。 AI・機械学習チームの北川(@kitagry)です。今回はMySQLへのインサートを20倍以上高速化した話について書きます。仕事をちゃんとしてるか見張る猫 TL; DR はじめに今回のテーブルバイナリログを無効化する追試 LOAD DATA INFILE 追試テーブルの正規化インデックスを一時的に剥がすまとめ We are hiring!! TL; DR バイナリログをオフにする LOAD DATA INFILEを使うインデックスを一時的に消すはじめに AI・機械学習チームではサイトトップからアプリに至るまで多くの推薦システムがあります。そこでは推薦ロ

frkw2004 2022/12/30

インデックスでselect処理が速くなる、って勉強した時に、その代わりinsertが遅くなる、って聞いてなかった？ ORACLEもsqlサーバーも大量インサートで一時的にインデックスを無効にする手法は覚えておいた方がいい。

リンク

SQLわかんねーーーーーーーー！！！！！！

学生時代に独学でVBAやってたのが零細企業でなぜか評価されてDB管理をやらされかけてるけど SQLマジでわかんねーーーーーーーーーーー！！！なんだこれーーーーーーーーーーーーー！！ああああああああああああああ！！！！わかんねーーーーーー！！！！

frkw2004 2022/10/07

千行を超えるSQLを使ったことあるけど、それはほぼ同じ副問い合わせを条件別にUNIONするようなやつだった。とりあえずLeft JoinとRight Joinを混合するのはやめろ。

リンク

決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ

エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DBの Transaction Processing を意味しません。本記事のポイントは残高を管理をするテーブルは作らず、ト

frkw2004 2021/06/30

残高見るのにビューを用意してたりするのかな？マテリアライズドビューで作っておけばよさそう。

リンク

SQLアンチパターン幻の第26章「とりあえず削除フラグ」

SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902Read less

frkw2004 2015/09/01

Where句必須、は別に悪いことではないような気がするけど。ＤＢが現実のモデルなら、現実とは常にWhere条件が付きまとう。暗黙か明示的かの違いはあるけど。

リンク

コンシューマサービスの運用に耐えるDB性能設計とは - レベルエンター山本大のブログ

JOIN 禁止の話に、いまだに絡んでくれる人がいた。 ■﹁艦これ﹂から、ソーシャル系のサーバ構成を考える - SQLer生島勘富の日記僕が以前に書いた本テーマに関するエントリは以下の3つ。 ■信じられないDB 文化﹁Join禁止﹂に﹁固定長DB﹂、、でも、合うんです。大規模コンシューマ向けサービスのRDB設 ■信じられないDB文化﹁固定長DB﹂でもあうんです。大規模コンシューマ向けサービスのRDB設計 ■ホント信じられないDB 文化だけど、統計情報固定化はマジでアリちょうど折よく、ウチの会社のオラクル女子が書いたエントリの続きも公開されました。 ■一緒にまなぼ！﹁hiromi と楽しむOracleパフォーマンスチューニング！﹂︻Vol.2 Statspackを見てみよう︼ということで僕の中でDB熱が盛り上がってきたので返答的なエントリを書きます。﹁とりあえずメモリだけ気にしておけ﹂

frkw2004 2013/09/02

元記事はメモリ管理を工夫してディスクI/Oをできるだけ起こさないように（ディスクI/Oが起きてはもう遅い）という趣旨じゃないのかな。

リンク

削除フラグのはなし

Query Optimization with MySQL 5.7 and MariaDB 10: Even newer tricksJaime Crespo

frkw2004 2011/08/10

画面とかのＵＩ上は削除フラグで、夜間バッチで退避テーブルへ移動とか。

DB

リンク

複合主キーを避けるべき理由 - 虎塚

データベース設計の話をしていて、﹁連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき﹂という意見を聞く機会がありました。脊髄反射で﹁ないわー﹂と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。その結果、次のような結論に至りました。単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避けるというわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。︵2011/07/25 追記︶複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、﹁避けるべき﹂というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

frkw2004 2011/07/14

サロゲートキーのデメリットにも言及しないと。ナチュラルキーにユニーク制約をつけないテーブルのせいでメンテナンスできないよ。あっちゃいけないデータ重複とかさ。

リンク

地獄のようによくわかるSQLテーブル結合 - こせきの技術日記

テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSSJOIN。こんなの使いません。ブクマ用画像。

frkw2004 2010/09/16

二つのテーブルなら難しくない。3つ以上のテーブルになると結合順の問題も出てくる。5つ以上のテーブルがLeft,Right,Cross入り混じって結合されているSQLを見たときは﹁何考えてんだ、コイツ？﹂と思いました。 ●DB ●sql

リンク

はてなブックマーク

タグ

関連タグで絞り込む (9)

DBに関するfrkw2004のブックマーク (8)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

今週のはてなブックマーク数ランキング（2024年7月第1週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス