UUIDとULIDを理解していない方は見た方がいい記事
Auto increment（自動採番）型を採用したくない場合 Auto Incrementは、データベースにおいて自動的に一意の識別子を生成するメカニズムです。通常、数値型の列が対象となり、新しいレコードが挿入されるたびにその列の値が自動的にインクリメントされます。典型的なIDですかね。 ここでは一意性の確保の話や、データ移行やバックアップのデメリットには言及せず、セキュリティとプライバシーの懸念にフォーカスして考えます。 予測可能性 Auto Increment型のIDは連番であるため、次に生成されるIDが容易に予測可能です。これにより、攻撃者がシステムの内部構造を推測し、不正アクセスを試みるリスクが高まります。 情報漏洩のリスク 連番のIDはデータベースの挿入順序を反映しているため、公開されることで企業の活動パターンやデータ生成の頻度が漏洩する可能性があります。 例） 競合他社は、公
後輩エンジニアを絶望させるDB設計方法4選 - Qiita
エンジニアの格闘 エンジニアのみなさんはかつてひどいコードや設計と直面し、それと格闘したことでレベルアップした経験はあるでしょう。 つまり、先輩エンジニアたるものクソコードやクソ設計を残して、後輩エンジニアのレベルアップに寄与するのは義務だと言っても過言ではありません(?) 今回はDB設計に焦点をあてて、そのように絶望させる設計の残し方を記しておきます。 初めての投稿なのでレベル的にはかなり初歩になっています。 ↑きっと彼も立派なエンジニアになった時感謝してくれるでしょう 1) 必要な正規化を行わない エンジニアという不思議な不思議な生き物は処理の共通化等なにかと処理をまとめたがる習性があります。 以下のように著者テーブルと書籍テーブルがあるとします。 書籍 書籍ID 書籍名 著者ID
MySQLのutf8mb4と戦った話 - Uzabase for Engineers
皆様こんにちは、NewsPicksエンジニアの米澤です。 先日 2023/03/30は、こちらでアナウンスしていた通り、サービスの停止を伴うシステムメンテナンスを実施させて頂きました。 NewsPicksをご利用頂いている皆様には、ご迷惑おかけいたしました。 今回はこのメンテナンスの中で行われたDBテーブルのmigrationについてお話ししたいと思います。 ことの始まり やったこと 方針決め utf8mb4に対応していないテーブルを調べる migrationを作成する 影響範囲を調べる 開発環境でリハーサルを行う メンテナンスの日 最後に ことの始まり NewsPicksではバグの検知にBugSnagを利用しています。 ある時、BugSnagにこんなエラーが通知されてきました。 org.springframework.orm.hibernate4.HibernateJdbcExcepti
100億レコード超のDBを“障害ゼロ”でマイグレーション 新卒1年目が考えた2つのアプローチと3つの工夫
インターネットやAIを駆使しながら、領域に捉われずにさらなる挑戦を行うDeNAの取り組みを紹介する「DeNA TechCon 2023」。ここで成田氏が登壇。PocochaのDBをマイグレーションしたことについて話します。 新卒1年目が100億レコード超のDBマイグレーションをした話 成田篤基氏：発表を始めます。みなさんはじめまして。成田と申します。私は2021年にディー・エヌ・エーに新卒で入社して、現在入社から2年が経とうとしています。 私は新卒1年目で、大規模なデータベースマイグレーションを行う貴重な経験ができました。本日はそのマイグレーションプロジェクトについて、体験から得た学びをみなさんにお伝えします。題して「新卒1年目が100億レコード超のDBマイグレーションをした話」です。どうぞよろしくお願いいたします。 目次です。本日はこちらの目次に沿って発表を進めていきます。 まずは私たち
勘でリレーションを張っていないか？ - Qiita
はじめに 今回は外部キーを張るときに最低限意識したいことについて書きました。 何か間違えがあったり、もっとこういうところも意識してますという人がいたらコメントお願いします。 この記事で伝えたいこと ①リレーションシップ先のデータを消したときに同時にリレーションシップ元のデータが消えても自然な状態を作る ON DELETE CASCADEをうまく利用できる状態を作る つまり親子関係を正確に表現する。 リレーションシップ先は親テーブル、リレーションシップ元は子テーブルを意味しています。 ②データを作成するときのことを考えてデータの生成順序がおかしくならないように外部キーを張る ③関連を表現するときに中間テーブルを利用したほうが良い場面がある 注意 下記【例を交えながら説明】の説明に出てくるテーブル設計に関しては、上記の【この記事で伝えたいこと】の①と②と③の項目に対して想像しやすいように、理解
DBのロックについてあまり意識したことがない人に向けた実は覚えておきたいロックについての知識 - CARTA TECH BLOG
みなさん、おはようございます！ CARTA fluct エンジニア の なっかー@konsent_nakka です。 CARTA TECH BLOG アドベントカレンダー 12/14ということで、普段DBのロックについてあまり意識したことがない人に向けた実は覚えておきたいロックについての知識をざっとまとめてみました。 とりあえずこれだけ読んでおけば最低限は困らない、もし何か困った時にはあそこで出てきた内容をもう少し深く調べて見るか、というきっかけになれば良いなと思います。 厳密な定義よりも普段DBを扱う中でロックについてあまり意識したことがないような人にもすっと入ってくるように簡単な表現を優先して書いていますがご了承ください。 目次 留意事項 排他ロックと共有ロック トランザクション分離レベル SELECTのロックレベルを変更する 共有ロック: LOCK IN SHARE MODE 排他ロ
「SQLite3 WASM/JS」パブリックベータ公開。SQLite 3.40でサポート開始、WebブラウザなどでSQLiteが実行可能に
「SQLite3 WASM/JS」パブリックベータ公開。SQLite 3.40でサポート開始、WebブラウザなどでSQLiteが実行可能に SQLiteの最新版となるバージョン3.40がリリースされました。本バージョンからSQLiteのソースコードがWebAssembly版の「SQLite3 WASM/JS」へのコンパイルをサポートし、配布される公式のバイナリにLinux版、Windows版、Mac OS X版、Android版などと共に「SQLite3 WASM/JS」が含まれるようになりました。 SQLiteはオープンソースの代表的なリレーショナルデータベースの1つ。軽量かつコンパクトな実装で、クライアント／サーバ形式ではなくアプリケーションに組み込んで利用できる点が最大の特徴です。 先月（2022年10月）に予告なくSQLite3 WASM/JSのページが公式Webサイトで公開され、
EmbulkでPostgreSQLをMySQLに移行した話 - LIVESENSE ENGINEER BLOG
こんにちは。マッハバイトを運営するアルバイト事業部エンジニアの mnmandahalf です。 先日、マッハバイトの販売管理システムで使っているデータベースをオンプレPostgreSQLからAmazon Aurora MySQLに移行しました。 本記事では移行に至った背景、吸収する必要があった差分や苦労した点についてお話しします。 環境 移行前のバージョン: PostgreSQL 9.4 ※ドキュメントはバージョン14のものを添付しています 移行後のバージョン: Aurora MySQL 3.02.0 (compatible with MySQL 8.0.23) 環境 MySQL移行の背景 データ移行方法の検討 Embulkの実行で考慮したポイント Embulkの設定 scram-sha-256認証への対応 タイムスタンプが9時間巻き戻る FK制約を無効化できない PostgreSQLとM
ER図の自動生成について、dbdiagram.io, DBeaver, A5M2 を比較してみる。 - Qiita
はじめに データベース設計のER図について、自動で生成する以下３つのツールを比較した記事です。 dbdiagram.io DBeaver A5:SQL Mk-2（A5M2） 先日、こちらの記事をQiitaに投稿したところ、多くの方に記事を見ていただき、コメントも多数いただきました。 ER図に関するお勧めのツールをコメントいただく方が多くいらっしゃいました。 今回はその中から、無料でも利用できる3つのツールの「ER図の自動生成」の機能を試します。 比較の結論としては、〇〇が一番良いという感想ではなく、どのツールも多機能で、できることは違うので、今後使うときは用途や業務の環境によって使い分けていけたらと思っています。 目次 それぞれのツールについて、下記の内容を書いていきます。 1. dbdiagram.io 1-1. 始める 1-2. 使う 1-3. 感想 2. DBeaver 2-1. 始
組み込みシステム向けDBであるSQLite入門 - MyEnigma
Using SQLite: Small. Fast. Reliable. Choose Any Three. (English Edition) 目次 目次 はじめに SQLiteの歴史 特徴 トランザクションがある 設定がない 様々なSQL機能が利用可能 クロスプラットの単一ファイルで管理 高速にデータにアクセスできる 大規模なデータを管理できる ソフトウェアが小さい ソフトウェアやファイルフォーマットが安定している ソースコードがPublic domainで公開されている。 ソフトウェアとしての品質が高い 使い方 公式のCLIツールを使う Pythonの公式モジュールsqlite3を使う PandasのDataFrameとSQLiteをやり取りする 参考資料 MyEnigma Supporters はじめに 世界で最も使われているOSSってなんだろうと考えた時に、 真っ先に思いつくのが
ドキュメントDBかリレーショナルDBどっち使う？ - Qiita
はじめに ドキュメントデータベースかリレーショナルデータベース、どちらを選ぶか。 この選択で、アプリケーションのパフォーマンス、コスト、コードの可読性など幅広い影響が出るため、慎重な判断が必要です。この記事では、自分が思う「考慮すべきポイント」を解説したいと思います。 考慮すべきポイント 1. どのデータモデルがアプリケーションコードに最適か スキーマ制約を課さずに、データレコードをドキュメント（つまりJSONオブジェクト）として保存すべきか？それともスキーマを正規化してデータをいくつかのテーブルに分けるべきか？ このような判断をするために、開発しているアプリケーションのモデルの関係性（例: UserとTaskの関係が1:N）と、一度に読み込むデータの種類を見た方がいいです。 ドキュメントDBがおすすめの時 アプリケーションのデータは、以下のような木構造で表現できますか？普段そのデータを一
Cloudflare D1 がヤバい
まだ検証足りないけど、マジで想像通りのブツなら魂震えるかもしれん…。 Announcing D1: our first SQL database Cloudflare D1 = Edge SQLite Cloudflare D1 は Cloudflare Worker で、つまり CDN Network 上で sqlite が動きます。これだけなら普通の sqlite ホスティングなんですが、もちろん Cloudflare が出すからにはそれだけではなく、CDN Edge 上に Read Replica がバラ撒かれた sqlite になります。ヤバくないですか？ 僕はヤバいと思いました。 このヤバさを知るために、Cloudflare が開発した基盤についていくつか抑えておく必要があります。 Durable Objects は CDN 上の Actor モデルを構築できます。この Acto
idをautoincrementして何が悪いの？
idをautoincrementしない方が良い理由 こんにちは。株式会社プラハCEOの松原です。 最近プラハチャレンジの参加者とお話している際に 「PKのidはautoincrementするとして...」 とナチュラルにid=autoincrementするものという前提が見えたので、「本当にidをautoincrementしても良いものだろうか？」と気になったことを書いてみようと思います。もしフレームワークが自動的にautoincrementでテーブルを作るからなんとなく使っているという方がいたらご一読いただいた後、それでも連番を使いたい理由があれば教えて欲しいです・・！ 不必要に情報を晒すことになる スクレイピングされたり もしも僕が某大手に勤めているエンジニアで「競合サービスAにのってる物件情報、全部コピーして新しいサービス作ろうぜ」と指示されたらですよ？「人としてそれはやっちゃダメで
DBスキーマ変更管理ツール sqldef を試してみた - Qiita
1. sqldef とは sqldef は "The easiest idempotent MySQL/PostgreSQL/SQLite3/SQL Server schema management by SQL." と謳っているDBスキーマ変更管理ツールです。 通常の開発において DDL 文を管理する場合、環境を１から作るように CREATE TABLE 文など新規作成 DDL 文を準備すると共に、既に作成済みの環境でテーブルを変更するために ALTER TABLE 文など差分適用 DDL 文を準備する必要があります。この２種類の DDL 文を二重管理しないといけないというのは DBA にとっては頭の悩ましい問題でした。（差分適用 DDL 文のみ準備し、１から環境を作る場合も全ての変更を適用するという手もありますが…） sqldef を利用すると、変更適用先 DB の現在の状況と新規作成
本当にtransactionは必要なのか？ - 急がば回れ、選ぶなら近道
前提 前提ですが。 transaction=Consistency/Isolationを担保する仕組みの話とする。 一般にtransactionが持つべき属性はACIDと言われる。C/Iに比べて、A/Dが“わかりやすい”のでAtomic/Durableの属性の方が人口に膾炙しているが、現在のtransactionではA/Dネタはあまり話題にならない。A/Dネタはローカルだけで見るのであれば普通にfile system /storageの話になる。元来Atomic/Durableはtransactionのコンテクストでは専らlogging / recoveryの話だった。そして、これは非同期のepoch-basedになるとそれ自体の取り扱い優先度が下がる。現代的なtransactionでは、「現時点ではread committedが保証されているFS/storageでA/Dの問題は(ある程度
自作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 を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はじめに｜図解 DB インデックス
DBアーキテクチャの比較と選択
