UUIDとULIDを理解していない方は見た方がいい記事
Auto increment（自動採番）型を採用したくない場合 Auto Incrementは、データベースにおいて自動的に一意の識別子を生成するメカニズムです。通常、数値型の列が対象となり、新しいレコードが挿入されるたびにその列の値が自動的にインクリメントされます。典型的なIDですかね。 ここでは一意性の確保の話や、データ移行やバックアップのデメリットには言及せず、セキュリティとプライバシーの懸念にフォーカスして考えます。 予測可能性 Auto Increment型のIDは連番であるため、次に生成されるIDが容易に予測可能です。これにより、攻撃者がシステムの内部構造を推測し、不正アクセスを試みるリスクが高まります。 情報漏洩のリスク 連番のIDはデータベースの挿入順序を反映しているため、公開されることで企業の活動パターンやデータ生成の頻度が漏洩する可能性があります。 例） 競合他社は、公
MySQLとOracleの実行計画を比較してみた - ASMのきもち
まいえすきゅーえりたい ぽすぐれない おらくるってる（狂ってる）tomoです。 今日はいつものMySQLリファレンスを読むではなく、夏休みの宿題にしていたこれをやってみます。 MySQLとOracleDBの実行計画を比較してみた さて同じようなテーブルで同じデータを載せて。 実行計画を取ってみた時、どのくらい情報量が違うのか簡単に違いを見てみましょう。 前提として、以下をご認識ください。 一方はOSSのDBエンジン、もう一方はガチガチ商用DBエンジンです。情報量が違うのは当たり前であって、良し悪しを比較したいのではありません。そして製品比較をしたいのではありません。いつも商用DBメインで使っているエンジニアが、OSSのDBにこうゆう情報も出してほしいな！というのをお願いしたいと思っていて、それを考える元ネタメモだと思ってください。 OSSでこれだけの情報出せるMySQLや、今回紹介しません
『WEB+DB PRESS』 休刊のお知らせ：WEB+DB PRESS
WEB+DB PRESSは，2023年8月発売のVol.136をもって隔月刊誌としては休刊させていただきます。物価上昇による製作費の高騰など諸般の事情により，今回の決定に至った次第です。 突然の休刊案内にてたいへん恐縮ではございますが，何卒ご理解を賜りますよう，お願い申し上げます。 22年以上の長きにわたり，絶大なご支援をいただきましたことを，厚く御礼申し上げます。 弊誌で扱っていた分野のコンテンツは，今後も弊社刊行のSoftware Designやgihyo.jp，書籍などで提供させていただきます。また，必要な場合には「特別号」の編集・刊行なども検討してまいります。 最後に，皆様の一層のご活躍を心より祈念しております。
TSQL JOIN Types Poster (Version 3) - Steve Stedman
So many times I have been asked for help with a query, where the question really comes down to the understanding of the difference between INNER and LEFT or RIGHT JOINs. >>> Try my JOIN types course! I created this poster a few years ago and I keep it posted on the wall at the office. This way when I am trying to explain JOIN types, I just refer to the poster. I have created the poster below to he
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
SELECT ... FOR UPDATE同士でデッドロックさせる - かみぽわーる
最近SELECT ... FOR UPDATEでデッドロックする話を何度かしたので。 前職のときにUPDATE同士がデッドロックしてたときに、SELECT ... FOR UPDATEで排他ロックを取ってからUPDATEしてデッドロックを防ぎますってPRをレビューしてたときのことで、複数レコードの排他ロックは一瞬ですべてのレコードのロックを取れるわけではなく、ロックを取る順番が揃っていないと簡単にデッドロックしますよという話です。 https://gist.github.com/kamipo/0bb4e37d58ba18a8cefb8aa02f778231 # frozen_string_literal: true require "mysql2" def client Mysql2::Client.new( host: "localhost", username: "root", dat
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
ID生成方法についてあれこれ
ID生成について聞かれることが多いので、独自の観点でまとめてみます。タイトルは適当です…。 DBはMySQL(InnoDB)を想定しています。あしからず。 ID生成を知りたいなら ID生成に関しては以下の記事がよくまとまっているので参考にしてみてください。値形式など詳しく書かれています。 ID生成大全 Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ ID生成方法 以下のID生成方法は、お手軽に採用しやすいもの順で列挙します。 DB採番/連番型 AUTO_INCREMENT DBのAUTO_INCREMENTで採番する方法。 Pros 数値型で扱える 普通は64ビットの整数型を採用することが多い 単調増加する連番ですので、ソート可能でかつインデックスの空間効率がよい 単調増加するので、キャパシティを予測しやすい 64ビットあればあまり気に
Gormが本番テーブルの数億件のデータを消そうとした話 - keroxpのScrapbox
MySQLの場合、--safe-updatesオプションを利用することでこういった不慮のUPDATE/DELETEを防げるようです
postgresのデータを盗まれた話 - のんびりやの日記
はじめに さっぶ。どうも、だーやまんです。 この記事は、本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiitaの11日目の記事です。 これは、中途半端な知識でサービスを運用していた結果、タイトル通りの大失敗をしてしまったお話です。個人開発での出来事なので、業務で起きたことかと胃薬を握られていた方はご安心ください。 語るのもすごい恥ずかしいレベルですが、戒めのために晒しておきます。 この記事を読んでほしい人 初めてインターネット上にサービスを公開しようとしている人 喋太郎の利用者様(この場をお借りして、改めてお詫び申し上げます。本当に申し訳ございませんでした。) 背景とか Discord読み上げBot 「喋太郎」にてやらかしました www.dayaman.work 利用者が約10万人 さくらのVPSにてAppサーバ2台、DBサーバ1台で運用 各サーバの死活監視
crontab database ～君がしでかしてくれたもの～ - Qiita
この記事は本番環境でやらかしちゃった人のアドベントカレンダー２日目の記事です。 内容的にそろそろ時効だと思うので供養のために書きました。 追記。そういえば時期をちゃんと書いてなかったけど事件が起きたのは去年2018年、つまり仕込み（ヲイ）は2017年の話です ぶっちゃけネタ記事ですｗ （たまたま見つけて参加してみただけなのに昨日の記事の伸びっぷりを見て戦々恐々としてる TL;DR DB移行作業において、テスト期間中は常に最新のデータで処理できるように書いておいたプログラムをcrontabで実行していた。最終的に本番に合わせて日時を調整していたが、そのことを失念し１年後に再実行されてしまい、本番データが１年前に巻き戻る事故発生。 crontab は分、時、日、月、曜日を指定できるが、１年後に帰ってくるから気をつけてね。という話。 惨劇はなぜおこってしまったのか 結論から言えばcrontabの
「脱Oracle」の背景にある、Oracle Databaseの価値を改めて考える | フューチャー技術ブログ
はじめに2019年10月15日、Amazonは自社サービスにおける実質的な”脱Oracle”を発表しました。75PBに及ぶデータを、傘下のAWSが提供するDatabase Service（AuroraやDynamoDB、Redshiftなど）へと移行したとの事。 この一報は、Amazonというグローバル規模のECの巨人、クラウド・プラットフォーマーのリーダーの一角が、大規模基幹システム領域におけるRDBMSのデファクト・スタンダードと決別したという点で、業界関係者に対して非常に大きなインパクトを残したものかと思います。 大人の色々な側面が垣間見えるものの、非常に難易度の移行PJであった事はを想像に難くありません。 “Oracleもいよいよ賞味期限を迎える” 果たしてそうなのか。ここで今一度、**”脱Oracle”とは何を脱する事なのか**、を考えてみます。 “脱Oracle”とは？第1は高
ユーザー企業のOracle技術者が足りない、高まる技術的負債のリスク
20年以上前に構築した古い基幹系システムを使い続けるユーザー企業が5社に1社の割合で存在するとされるなか、「枯れた技術」の維持管理に危機が迫っている。枯れた技術としてはCOBOLが有名だが、今回取り上げるのは別の技術だ。 リレーショナルデータベース（RDB）である。とりわけ最大シェアを誇る米オラクル（Oracle）の「Oracle Database（Oracle DB）」を扱える技術者が足りないとささやかれ始めている。 クラウドシフトとAI人気が原因？ 「今まで1度も取引のないユーザー企業からOracle DBに障害が発生したといきなり連絡を受け、復旧作業を頼まれるケースが増えている」。こう証言するのはDBの導入や運用保守を専門とする、日本エクセムの後藤大介CEO（最高経営責任者）だ。 こうした依頼が増えた理由について、後藤CEOは「ユーザー企業が自社システムのクラウド移行を進めた結果、社
Docker でロードバランサ・アプリケーションサーバ・DBサーバの環境構築 - A Memorandum
はじめに Nginx でロードバランサを構成する Webサーバ1号機の作成 Webサーバ2号機の作成 ロードバランサの作成 ロードバランサとWebサーバの起動 Web アプリケーションの準備 Docker でアプリケーションをビルドする DBサーバの準備 ロードバランサとアプリケーションサーバの起動 まとめ はじめに 前回は Docker のインストールからイメージビルド・コンテナ起動・Compose までの流れをみてきました。 blog1.mammb.com 今回は以下のような、一般的な Web アプリケーションの開発環境を構築していきます。 前回の記事とあわせて、Docker の活用方法を理解いただければと思います。 Nginx でロードバランサを構成する 最初に、単純な Web サーバを Nginx でロードバランシングする環境を作成して動作を見てみます。 このような構成となります。
Oracle DBの「非公開バグ」が表面化、大阪市基幹システム障害の真相
大阪市で住民票などの証明書発行業務を担う基幹システムが停止。復旧まで21時間を要し、8000件近い証明書発行業務に影響が及んだ。原因はOracle Databaseのクラスタ機能に潜むバグだった。ネットワークの不調をきっかけにシステムが停止し、再起動もできなくなった。米オラクルはバグの存在を把握しながら対外開示をしていなかったとみられる。 2019年6月7日午後0時5分頃。大阪市内の24の区役所や出張所、梅田・難波・天王寺のサービスカウンターで、住民票の写しや記載事項証明書、国民健康保険や税務関連の証明書などが印刷できなくなった。金曜日の昼休みということもあり、週内に書類を発行してもらおうと区役所など窓口に来ていた住民からは悲鳴と怒号が上がった。 同じ頃、大阪市西区の阿波座にある大阪市ICT戦略室も騒然としていた。システム障害を知らせる警報が鳴り、各区役所からトラブル発生を知らせる電話が相
【旧版・説明欄参照ください】 サーバーレスアプリケーション向きの DB 設計ベストプラクティス
【2019/09/12 追記】 この資料は旧版であり、最新版が存在します。 2019/09/12 にアップロードしたものをご参照ください 最新版 → https://www.slideshare.net/AmazonWebServicesJapan/db-20190905 --------（元の文）------------------- 2019/05/09 に #AWSLoft Tokyo で開催されたイベント、「イチから理解するサーバーレスアプリ開発」における講演資料の一つです。 ・サーバーレスアプリケーションにおいて Amazon DynamoDB が利用しやすい理由 ・RDB と DynamoDB の設計プロセス・考え方の対比・明文化 ・実例に沿った DynamoDB の設計プロセス解説とサンプル例題 などを含みます。 イベント: https://understandingbasi
Aurora - クラウド時代のDBアーキテクチャ - 発明のための再発明
はじめに Amazon Auroraは、AWSを触る人ならほとんどの人が利用を検討したことがあるでしょう。 Amazon社内ではOracleを止めたというtweetもありました SHUTDOWN ABORT the last Oracle database running Amazon Fulfillment! pic.twitter.com/DorqTua2Lt— John Darrow (@jdarrow) 2019年3月29日 そんなAuroraは、従来のRDBとは違いクラウド上で動くことを念頭に設計されています。 また、ログが中心的な役割を持つことから「The log is the database」と表現されることもあります。 そんなAuroraの仕組みについての論文を読んだので紹介します。 読んだ論文は以下の２つです。 Amazon Aurora: Design Conside
ZOZOTOWNで最大級のトラフィックを記録する福袋発売イベントで実施した負荷対策 - ZOZO TECH BLOG
こんにちは。開発部の廣瀬です。 本記事では、昨年障害が発生してしまったZOZOTOWNの福袋発売イベントについて負荷対策を実施し、今年の福袋イベント期間を無傷で乗り切った話をご紹介したいと思います。 大規模サイトの障害に関する生々しい話はあまり公開されていないように思いますので、長くなってしまいましたが詳細に書いてみました。尚、今回のお話は弊社のサービスで使用しているDBMSの1つである、SQL Serverに関する話題がメインです。 福袋イベント「ZOZO福袋2019」とは 年に1度、多数のブランドの福袋が一斉に発売される、ZOZOTOWNの年末の風物詩的イベントです。今年は450以上のブランド様にご参加いただきました。お客様からも毎年大変ご好評いただいており、年間を通して最も多くのトラフィックを記録するイベントの1つです。 アクセスが殺到するが故に、昨年は福袋の発売直後からエラーが多発
「エリソン会長は間違っている」、AWSがオラクルに反撃 | 日経 xTECH（クロステック）
米アマゾン・ウェブ・サービス（AWS）が、同社への批判を繰り返す米オラクル（Oracle）に反撃した。2018年11月に開催した「AWS re:Invent 2018」の基調講演では、米アマゾン・ドット・コム（Amazon.com）で過去に起こったシステム障害が「Oracle RAC」のバグに起因していたことまで公表し、脱Oracleの歴史を解説した。両社の仁義なき戦いは過熱している。 「2004年12月12日はアマゾンにとって史上最悪の1日だった。クリスマスを前に注文が非常に多くなるはずだったこの日、Oracle RACのバグが原因で顧客データベース（DB）が12時間ダウンし、それによってアマゾン全サービスも12時間ダウンしたからだ」――。 AWS re:Invent 2018の11月29日の基調講演。アマゾンのヴァーナー・ボーガス（Werner Vogels）CTO（最高技術責任者）は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アンチパターンから学ぶ RDBの正しい設計 / learn-from-failure-2
