毎日本番DBをダンプして、ローカルと開発環境で利用して生産性を上げてる話
シードデータで動作確認して大丈夫だったのに、本番反映してみたら想定してなかった挙動・エラーが出た😱そんな経験はありませんか。 恥ずかしながら私は今までに何回もありました。機能開発だけじゃなくバッチやマイグレーションなんかでも発生しがちなコレ。またはシードデータで動作確認できても、本番データでも通用するか検証ができないままプルリクを作る、なんていうこともあると思います。今回はこちらを無くす試みをしたお話です。 「もう本番DBで開発しちゃえばいいじゃない」の問題点 この課題を解決するには、極論すると本番DBで開発するしかないのですが、そうなると言うまでもなく以下の問題が出てきます。 レビュー通過してないコードが本番に影響を与える トライ＆エラーができない 個人情報をはじめとするセンシティブな情報が開発者の端末に漏れる データ量が多すぎてローカルに持ってこれない しかし言い換えると、これらをク
祖母が就寝するとDBインサートができなくなる - Qiita
世の中には、一見関係なさそうな物理現象がITシステムに不可思議な影響を及ぼすことがあります 例えば,500マイル以上離れた場所にメールが送れないという話だったり 中国人のAさんがお茶を入れると会社のネットが繋がらなくなる という話があります。 私の場合は、祖母が就寝するとDBインサートが失敗する、という状況でした 実家の見守りシステム 問題が起きているのは、離れた実家にいる一人暮らしの祖母の状態を見守るために作成した自作のシステムです。 気温や湿度、CO2濃度、明るさ、部屋のドアの開閉、冷蔵庫の開閉の状況をモニタリングできるようにしています。 Raspberry Piに各種センサが接続され、定期的にInfluxDBに送信し、Grafanaという可視化ツールでいつでも見られるようにしています。 これらの情報を見ることで、祖母の家の部屋の温度が適切か、活動しているか、部屋にいるかなどが分かりま
正規化の要点を理解する - Qiita
この場合営業部の部長は社員によって異なる人物となっており矛盾が発生しています。 つまりこのテーブルは更新の仕方によっては矛盾が発生しうる設計となっています。 上記で矛盾が起きたのは、複数のレコードが同じ部長名という情報を持っていたことが原因です。 RDBにおいて矛盾が発生しうる原因はこのようなデータの重複です。 正規化を正しく行うことで、データの重複を排除し、矛盾が発生しないテーブル設計とすることが出来ます。 正規化によって得られるもの 正規化を正しく行うことで、DB上での矛盾の発生を設計レべルで防ぎ管理が容易なテーブル構造とすることが出来ます。 容易になることで色々なメリットを享受できますが、ここではコスト削減という点を見てみます。 DBは必ずしも正規化を行わないと矛盾を防げないわけではありません。 データに矛盾があるDBはそもそも使い物にならないため、業務においては正規化していようがし
データベース アーカイブ | Enjoy IT Life
行ロックを利用してレコードを参照する方法をロッキングリードと呼びます。ロッキングリードを利用することで参照レコ…
【図解】B-treeを理解し、複合インデックスの順番を正しく作る | Enjoy IT Life
複合インデックス（結合インデックス）とは複数のカラムを組み合わせたインデックスのことをいいます。 検索やソート条件で一緒に利用されるカラムに対して複合インデックスを作成することでクエリの高速化が期待できます。 複合インデックスを正しく作成するにはB-treeインデックスの理解が必須です。 今回は複合インデックスを正しく作成するために必要な基礎知識について紹介します。 複合インデックスには順序がある ユーザーテーブルに存在するlast_name, first_name, ageのカラムに対して複合インデックスを作成する場合を考えてみます。 (last_name, first_name, age)の順で複合インデックスを作成した場合、インデックスの構造は以下のようになります。 (age, last_name, first_name)の順の場合は以下のようになります。 複合インデックスの構造は先
Building a Simple DB in Rust - Part 1 - Parsing
This article is part of the Building a Simple DB in Rust series. While I've used rust for a while and have had a few small projects in it, I felt like I was missing a truly "systems" project. So when I came across this series for making a simple DB in C, I figured why not try to make my basic DB in rust. I will roughly follow the structure of that series at first, but I will most likely deviate an
GoでDBを使ったアプリを書くときみんなどうしてる？ Tonamelはどうしているか晒してみます - KAYAC engineers' blog
こんにちは。ゲームコミュニティ事業部サーバサイドエンジニアの谷脇です。 この記事はTech KAYAC Advent Calendar 2022の2日目です。 私はTonamelというWebサービスを運営しています。Tonamelでは、GoとPerlを用いてサーバサイドアプリケーションを構築しています。 この記事ではTonamelでのパッケージ構成や、DBを使う際に用いているライブラリについて紹介します。 そもそもTonamelって何 パッケージ構成やは、アプリケーションの特性や、実装の複雑さなども考慮するため、前提として作っているものを説明します。 tonamel.com Tonamelとはeスポーツを始めとした競技の大会を開催するときに用いるプラットフォームです。大会主催者と参加者双方が利用します。 Tonamelの機能説明 この図に挙げているように、『参加者管理』と『トーナメント表』
idをautoincrementして何が悪いの？
idをautoincrementしない方が良い理由 こんにちは。株式会社プラハCEOの松原です。 最近プラハチャレンジの参加者とお話している際に 「PKのidはautoincrementするとして...」 とナチュラルにid=autoincrementするものという前提が見えたので、「本当にidをautoincrementしても良いものだろうか？」と気になったことを書いてみようと思います。もしフレームワークが自動的にautoincrementでテーブルを作るからなんとなく使っているという方がいたらご一読いただいた後、それでも連番を使いたい理由があれば教えて欲しいです・・！ 不必要に情報を晒すことになる スクレイピングされたり もしも僕が某大手に勤めているエンジニアで「競合サービスAにのってる物件情報、全部コピーして新しいサービス作ろうぜ」と指示されたらですよ？「人としてそれはやっちゃダメで
自作DBを始めたい人におすすめの本 - salachike:blog
この記事は、慶應理工アドベントカレンダー2021の20日目の記事です。 カレンダー全日埋まってすごい 🎉🎉 adventar.org 「Database Design and Implementation」という簡素なDBをスクラッチで作っていく本に取り組んだので、その読了エントリです。 Database Design and Implementation: Second Edition (Data-Centric Systems and Applications) (English Edition) 作者:Sciore, EdwardSpringerAmazon こんな人におすすめ MySQLやPostgreSQLを使った経験はあるが、DBの理論やその実装はあまり詳しくない人に特におすすめです。特に自作〇〇*1に興味がある人は間違いなく楽しめると思います。単純に本に紹介されている理論
よくあるオンプレOracleからRDSに移行したDBAの反省文 - ASMのきもち
この記事は JPOUG Advent Calendar 2021 - Adventar 17日目の記事です。 昨日はShinodaさんの「Oracle Database から PostgreSQL への接続を試す - Qiita」でしたね。 いやーOracle Database Gateway for ODBC全然使ったことがなかったので、これはぜひやってみよ…あれ、RDSでできるの？明日AWSサポートに早速連絡してみよう… 最近ブログを書く頻度がアドベントカレンダー以外書く頻度がない感じになってきております…コレハ、マズイ、ゾ！！笑 さて弱気な内容はおいておいて…ここ最近、ろくに活動もできなかったのはこれをやっていたからなのです。 そうよくある、(꜆꜄•ω•)꜆꜄꜆オンプレOracleからRDSに移行した話。 今更感あるのですが、私と同じミスを減らすきっかけになれば。と思い、書いてみます
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
DBMの設計と実装 その0 全体の計画 - 豪鬼メモ
DBMの設計と実装について20回くらいに分けて書いてみる。まずは全体の計画と意気込みから。 諸君 私はDBMが好きだ 諸君 私はDBMが好きだ 諸君 私はDBMが大好きだ ハッシュ表が好きだ 開番地法が好きだ 連鎖法が好きだ 赤黒木が好きだ B+木が好きだ スプレー木が好きだ トライ木が好きだ スキップリストが好きだ ブルームフィルタが好きだ 統計で 会計で 辞書検索で 文書検索で 言語処理で 画像処理で アカウント管理で 機械学習で シミュレーションで ゲームで ローカルで クラウドで この地上で使われるありとあらゆるデータベースが大好きだ 数値を並べただけのテーブルから一瞬で所望のレコードが探せるのが好きだ ノードの分割操作を繰り返していくと根にたどり着いて木の高さが上がった時など心が踊る 単一プロセスの操るライブラリだけでデータ管理が完結するのが好きだ メモリとスレッドに物を言わせて
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ アプリケーションの寿命よりも長く、データの追加やテーブルの変更で成長し続ける「データベース」と、どのように付き合っていけばよいのでしょうか？ 曽根壮大（soudai）さんによる寄稿です。 こんにちは。そーだい（@soudai1025）です。 新しいサービスを始めるとき、必ずと言っていいほどデータベースは利用されています。また今稼働しているサービスの多くでも、RDBMSをはじめ、いろいろなデータベースが利用されています。そんなに広く利用されているデータベースだからこそ、多くの問題の元になるのもまた事実です。 そこで今回は、Webサービスを中心にデータベースの選び方、設計についてお話していきたいと思います。そして私もまさに今、2011年から続くWebサービス「オミカレ」のRDBMSのリファクタリングに携わ
DBマイグレーションを行う技術 - 発明のための再発明
データベースのスキーマを変更するということはデータをいじる行為であり、最悪の場合データが消えます。 最悪の事態にはならなくとも、思わぬ場所に影響が起きたり、データの不整合が発生する恐怖と戦う必要が有ります。 テストや切り戻しを含めて計画し、大きな変更の場合にはダウンタイムまで考慮する必要があります。 そこで、RDBを対象にデータベースの変更を行う方法について書いていきます。 スキーマ変更 まずは、スキーマ変更について、 カラムを追加する 一番簡単で、影響も少ない変更です。 気をつけるのは、 ソースコードの変更よりも前にスキーマ変更を完了させる (長時間)ロックがかからない方法を選ぶ といったところでしょうか。 大抵の場合は、スキーマの変更とソースコードの変更の順番にさえ気をつければ問題は発生しません。 カラム名を変更する 「ALTER」でさくっと変えたくなりますが、ソースコードの変更が同時
初心者でもDB設計やデータモデリングについて学べる7つのサイトと本 - paiza times
Photo by Samuel Mann こんにちは。谷口です。 「SQLは何となく書けるけど、DB設計はしたことない…」「DB設計について一度ちゃんと学んでおきたい…」という人は多いですよね。 DB設計とは、DBのデータモデル（DBの構成など）を作成する作業です。 DBを一から作ったり、テーブルを追加したりする際は、当然ですが「今あるデータが何となく格納できればそれでOK」ではありません。 テーブルは正規化できていないといけませんし、データの整合性も取れないといけません。また、効率よくデータが取れる構造になっているかどうかも重要です。 一から設計に取りかかるようなケースは少ないかもしれませんが、DBを取り扱うことがあるなら、こうしたDB設計の基本は知っておいて損はありません。むしろ自分が扱うDBの構造はきちんと知っておかないと、「なんか適当にSQL投げたらデータ取れたけど、正しく取れてる
ゲーム/アプリ/WEBシステム開発のマイティークラフト » FuelPHPでのDB水平分割対応
札幌オフィスのKです。 従来は、サーバシステム（LAMP環境）の制作は自社製フレームワークでの開発が中心でしたが、近日はオープンソースのフレームワークを使うことが増えてきています。 自社製フレームワークも悪くないのですが、オープンソースのフレームワークだと、他社から運用を引き継ぐ場合、あるいは逆に開発していて運用は他社に引き継ぐ場合にやりやすいかとも思います。 そこで、今回はソーシャルゲームなどの開発でも広く使われるようになってきていると聞いている FuelPHP について、必要なのにケアされていないDBのTipsを書いてみたいと思います。 ※FuelPHPがどのようなもものかにつきましては、日本語ドキュメントをご参照ください。 （FuelPHP 日本語Document）http://fuelphp.jp/ ■今回制作した環境 今回は、下記の環境で検証を行いました。 Apache 2.2.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
高負荷を捌くDBチューニングノウハウを公開！PHPとMySQLの TCP TIME-WAIT チューニング(後編) | さくらのナレッジ
実践イミュータブルデータモデル — NEWTポイント機能の設計
DB外の副作用をトランザクションから分離しよう / Isolate out-of-DB side effects from transactions
実行計画の話
