こんにちは。開発部の廣瀬です。 本記事では、昨年障害が発生してしまったZOZOTOWNの福袋発売イベントについて負荷対策を実施し、今年の福袋イベント期間を無傷で乗り切った話をご紹介したいと思います。 大規模サイトの障害に関する生々しい話はあまり公開されていないように思いますので、長くなってしまいましたが詳細に書いてみました。尚、今回のお話は弊社のサービスで使用しているDBMSの1つである、SQL Serverに関する話題がメインです。 福袋イベント「ZOZO福袋2019」とは 年に1度、多数のブランドの福袋が一斉に発売される、ZOZOTOWNの年末の風物詩的イベントです。今年は450以上のブランド様にご参加いただきました。お客様からも毎年大変ご好評いただいており、年間を通して最も多くのトラフィックを記録するイベントの1つです。 アクセスが殺到するが故に、昨年は福袋の発売直後からエラーが多発
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
ベクトルの違うデータ まあ、それは事実。 ただ、履歴をそのまま残したいということも事実。 いちいち削除履歴テーブルなんて作ってられないのも事実。 ※ここでの論理削除は、復活する論理削除じゃなく、物理削除の代わりとして履歴のための論理削除を指します。(復活する論理削除って、そもそも削除とは言えないって気も...) 本来、論理削除されたデータって... そのテーブルの定義するデータとはベクトルの違うデータ である考えます。 でも、わざわざ削除されたデータを保持するテーブルを作ると、それはそれで面倒なのでそのまま同じテーブルに持ったままにする。その方が扱いが簡単なことが多いから。削除フラグを true にするだけで済むから。 個人的には、業務上重要なテーブルに関しては、しっかりと「削除履歴テーブル」を用意して、本体のテーブルには常に有効なデータだけがある状態の方が、データメンテもプログラムも遥か
PostgreSQLデータベースのスキーマやインデックスの管理、SQLの実行などをWebブラウザから行えるツール「PostgreSQL Studio」が、オープンソースで公開されました。 PostgreSQL Studioは、データベース内のテーブルのスキーマを参照し、また列やインデックス、ビューや制約、トリガーなどの作成や変更、SQL文の実行などを行う機能としてSchema Brwoser、Detail Browser、SQL Worksheet、Object Wizardsなどを備えています。 Webブラウザから利用できるため、PostgreSQL StudioをPostgreSQLと同じファイアウォールの背後に置いておき、HTTP経由でアクセスすることにより、安全にデータベースを管理できると説明されています。 Javaで記述され、複数のPostgreSQLバージョンに対応 対応するP
3. シナリオ A「ブログに、共同編集機能付けたいんよ」 B「はい」 A「今一人しか編集できないじゃん？」 B「ですね」 A「複数人がいじれるように出来ない？」 B「考えてみます」
RDBMSに関する典型的な誤解が絶えないという現実
新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの？：ITproという記事に対するブクマで次のようなIDコールが来た。（現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。） "リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。 さて、この疑問に対する正解は如何なるものだろうか？ つい先日「7つのデータベース 7つの世界」の書評で書いたばかりだが・・・ 言うまでもなくその通りである。 リレーションが2次元的な構造を持っているというのは典型的な誤解だ。（ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。）リレーショナルモデルについてちゃんと学習してい
「業務ロジックをデータモデリングはどこまで表現できるか？」について考えたことをラフなメモ書き。 業務システムでは、データが命。 データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。 すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。 顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。 でも、DOAの方が現代は重要性を増していると考えている。 例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。 日本におけるデータモデリングの歴史は意外に古い。 TH法、T字型ER、渡辺さんのXEAD Model
最近MySQLの勉強をしていました。実践ハイパフォーマンスMySQLを読むべきという話を聞いていたのですが、かなり網羅的に書かれていて、今の知識ではどれが重要なのかわからない状態でした。そこで色々調べてみて、参考になる記事をいくつか見つけたので、少しまとめてみようと思います。 今回まとめた記事を読んで、大体以下のことが理解できました。 インデックスの使われ方とその構造(MyISAMとInnoDB) EXPLAINの詳しい使い方、見方 InnoDBの特性 ALTER TABLEの特性 レプリ遅延 まず最初に Webエンジニアのための データベース技術[実践]入門 (Software Design plus)posted with amazlet at 12.06.02松信 嘉範 技術評論社 売り上げランキング: 9767 Amazon.co.jp で詳細を見る 松信さんの書いた「Webエンジ
1. <Insert Picture Here> MySQL 日本語利用徹底入門 日本オラクル株式会社 MySQL Global Business Unit テクニカルアナリスト 奥野幹也 2012 年 5 月 29 日 Copyright© 2012, Oracle. All rights reserved. 2. 2 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。ま た、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはでき ません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確 約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オ ラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊 社の裁量により決定されます。 Oracle と Java は、 Oracle Cor
分散システムでは、バックエンドのデータストアにリレーショナルDBを使用することが一般的です。しかし巨大な分散システムとなるクラウドシステムにおいては、RDBでは限界があります。今日は、クラウドシステムにおけるリレーショナルDBの限界について、おさらいしたいと思います。 1.RDBをデータ種別によって分割した場合 クラウドのように分散システムが巨大化した場合、データボリュームの増加と、アクセス数の増加から、単一のリレーショナルDBでは対応しきれなくなります。よって、リレーショナルDBを分割して対処することになるのですが、まずはデータ種別で分割した場合についてみてみます。 たとえばマスタデータ系、トランジションデータ系など、データの種別で分割した場合、ある程度の負荷分散はできるものの、とてもクラウドのボリュームには対応できません。なぜならば、マスタデータ系は運用時の登録・更新の頻度が少ないのに
2011年8月のkazeburoさんのエントリに対する解説記事です。結論から言うとkazeburoさんの案に賛成なのですが、本日はどうしてそうなったのかというところを確認していきたいと思います。本記事はMySQL Casual Advent Calendar 2011の17日目のエントリです。16日目はakira1908jpさんでした。 当時の内容を覚えていない方は、先にkazeburoさんのエントリをご一読ください。また、テストケースがGitHubに公開されていますのでカジュアルに再現試験をすることも可能です。 Covering Index と self-join と MySQL - blog.nomadscafe.jp kazeburo's gist: 1150842 - Gist 問題のSQLをチューニングするには、MySQLがインデックスに対してどのようにアクセスするかという点につ
かじゅあるしてますか？（挨拶） この記事はMySQL Casual Advent Calendar 2011の20日目の記事です。 19日目は @n0ts さんでした。 たいていの方ははじめまして。sohgohといいます。守備範囲は主にサーバー＆DB管理ですが、歴史的背景から（？）アプリ開発も一部兼任してたりしてます。...といいつつ最近はチーム全体のマネージメント業務の割合が多くなってきていて、どうやって遊ぶ時間を捻出するか現場業務に携わり続けるかが悩みです＞＜ さて、今回はMySQLのUDF(UserDefinedFunction)でファイルのput/deleteをチーム内でカジュアルに実装した話です。 ソースは https://github.com/sohgoh/mysql/tree/master/file_functions にあります。 ■作ったきっかけ 数年前、とあるサービスで
しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
オープンソースDBMSのコミュニティが一堂に会し、それぞれの技術について発表し合う「オープンソースカンファレンス 2011.DB」。MySQLとPostgreSQLの2大DBMSの将来像を探った。（編集部） 2011年11月5日、オラクル青山センターにてオープンソースカンファレンス2011.DBが開催された。話題をデータベースに限定してオープンソースカンファレンスを開催したのは、2008年6月以来3年ぶり。イベントではコミュニティを代表するメンバーが各製品の近況や概要を解説した。商用製品のオフィシャルなセミナーと違い、聴衆が仲間であったり、関連コミュニティのメンバーであったりするので、勉強会のように打ち解けた雰囲気で進んでいく。本記事ではPostgreSQLとMySQLのセッションを中心に紹介する。 9.1では同期レプリケーションまで進化 最初のセッションで登壇したのは日本PostgreS
LPI-Japan（エルピーアイジャパン）は5日、PostgreSQLを体系的に学習するための教材「オープンソースデータベース標準教科書 -PostgreSQL-」の無償提供を開始した。オープンソースデータベース技術者認定試験のサイト、またはLPI-Japanのサイトよりダウンロードできる。 「オープンソースデータベース標準教科書 -PostgreSQL-」は、データベース初心者を対象とした教材。これからデータベースの学習をはじめるにあたり、SQL言語を使ったデータベースの操作やデータベースの作成・管理についての基礎を学習可能な教材が必要という教育機関からのニーズに対応して作成された。データベース初心者でもわかりやすく、実際にアプリケーションを操作しながら、データベースの基本を学ぶことができる。 なお、同書の解説範囲は、LPI-Japanが7月に発表した「OSS-DB技術者認定試験Silv
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
