タグ

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

  • 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機械学習チームではサイトトップからアプリに至るまで多くの推薦システムがあります。 そこでは推薦ロ

    Bulk insertでも20時間以上かかっていたMySQLへのインサート処理を1時間以内にする - エムスリーテックブログ
    frkw2004
    frkw2004 2022/12/30
    インデックスでselect処理が速くなる、って勉強した時に、その代わりinsertが遅くなる、って聞いてなかった? ORACLEもsqlサーバーも大量インサートで一時的にインデックスを無効にする手法は覚えておいた方がいい。
  • SQLわかんねーーーーーーーー!!!!!!

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

    SQLわかんねーーーーーーーー!!!!!!
    frkw2004
    frkw2004 2022/10/07
    千行を超えるSQLを使ったことあるけど、それはほぼ同じ副問い合わせを条件別にUNIONするようなやつだった。とりあえずLeft JoinとRight Joinを混合するのはやめろ。
  • 決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ

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

    決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
    frkw2004
    frkw2004 2021/06/30
    残高見るのにビューを用意してたりするのかな?マテリアライズドビューで作っておけばよさそう。
  • SQLアンチパターン 幻の第26章「とりあえず削除フラグ」

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

    SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
    frkw2004
    frkw2004 2015/09/01
    Where句必須、は別に悪いことではないような気がするけど。DBが現実のモデルなら、現実とは常にWhere条件が付きまとう。暗黙か明示的かの違いはあるけど。
  • コンシューマサービスの運用に耐えるDB性能設計とは - レベルエンター山本大のブログ

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

    frkw2004
    frkw2004 2013/09/02
    元記事はメモリ管理を工夫してディスクI/Oをできるだけ起こさないように(ディスクI/Oが起きてはもう遅い)という趣旨じゃないのかな。
  • 削除フラグのはなし

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

    削除フラグのはなし
    frkw2004
    frkw2004 2011/08/10
    画面とかのUI上は削除フラグで、夜間バッチで退避テーブルへ移動とか。
  • 複合主キーを避けるべき理由 - 虎塚

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

    複合主キーを避けるべき理由 - 虎塚
    frkw2004
    frkw2004 2011/07/14
    サロゲートキーのデメリットにも言及しないと。ナチュラルキーにユニーク制約をつけないテーブルのせいでメンテナンスできないよ。あっちゃいけないデータ重複とかさ。
  • 地獄のようによくわかるSQLテーブル結合 - こせきの技術日記

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

    地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
    frkw2004
    frkw2004 2010/09/16
    二つのテーブルなら難しくない。3つ以上のテーブルになると結合順の問題も出てくる。5つ以上のテーブルがLeft,Right,Cross入り混じって結合されているSQLを見たときは「何考えてんだ、コイツ?」と思いました。
  • 1