信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
ソーシャルゲームのためのMySQL入門その２ | BLOG - DeNA Engineering
こんにちはこんにちは。11インチMacBook Airが欲しくてたまらないiwanagaです。 前回の記事 が幸いにもご好評を頂けた様で非常にうれしいです。嬉しくなって、ついがんばって第２弾を書いてしまいました。引き続き、ソーシャルゲームでよく使われるテーブルタイプ毎にちょっとしたテクニックを紹介していきます。 今回はちょっとライトな感じ＆読み物になってしまっていますが「ユーザID単位で1つだけ持つデータ」と「パラメータなどのマスターデータ」についてご説明したいと思います。ちなみに次回はInnoDBのデータ構造の簡単な説明と複合プライマリーキーのデータについて、その次で紹介し損ねたちょっとマニアックなテクニックや性能管理のための手法を紹介することを予定しています。 その前に。。。 先日行われた JAPAN INNOVATION LEADERS SUMMIT で弊社松信が「ソーシャルゲームの
ソーシャルゲームのためのデータベース設計 まとめ - お笑いプログラマの技術メモ
ソーシャルゲームを作る時に参考になるデータベースやKVSの選定、設計などの記事やスライドのまとめ 2013-02-03追記 スライド ソーシャルゲームのためのデータベース設計 http://www.slideshare.net/matsunobu/ss-6584540 とあるアプリの開発運用(トラブルシュート) http://www.slideshare.net/takafumionaka/ss-5852561 PHPで大規模ブラウザゲームを開発してわかったこと http://www.slideshare.net/ketaiorg/php-4638298 Lampで作るソーシャルアプリの負荷対策〜アプリとインフラの調和のテクニック〜 (Klabさん) http://www.slideshare.net/klab/4-d6963726f736f667420506f776572506f696e
[ThinkIT] 第5回：教科書的ではなく、現場にあったデータベース設計のコツ (1/3)
前回はデータベース設計をする際に誰もがぶつかる問題である、「列名に日本語を使うか？」「どのデータ型を使うか？」ということをテーマに取りあげました。今回も引き続き、データベース設計をする際に迷いやすい点をいくつか取りあげてみようと思います。 今回は前回と同様、SQL Serverのサンプルデータベース「Northwind」を元にして、データベース設計で迷いやすい点について考えてみましょう。図1は「Northwind」をER図にリバースした中から、エンティティ「商品」「商品カテゴリ」をサブウィンドウで表示したものです。 図1のように商品を分類するためにカテゴリコードをつけるエンティティ構造はよくあります。しかし実際の販売管理システムにおいては、このようなフラットなカテゴリ構造は不便です。なぜかというと、一般に商品カテゴリなどは表1のように階層構造で分類する必要があるからです。 01 ハードウェ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
