dbに関するsigwygのブックマーク (8)
-
MySQLで、レプリケーションベースのHAな構成について考えたメモです。3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、﹁こうしたほうがいいと思う！﹂﹁ここがおかしい！﹂などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
-
-
ケータイ大規模サービスの開発・運用に関する資料のまとめ Tweet 2009/2/18 水曜日 matsui Posted in 記事紹介・リンク | 5 Comments » 先月末に﹁満足せる豚。眠たげなポチ。大規模サービスの運用事例まとめ﹂という大変素晴らしいブログエントリーがあり、ブックマークしていたのですが、なかなか時間を作れずに目を通せずにいました。 本日読んでみると、とてもためになる情報が多かったため、まとめのまとめという形ですが、資料の中からケータイ関係の事例を抽出して、簡単にコメントをつけてみました。 まず、大元の記事はこちらです。 → 満足せる豚。眠たげなポチ。 大規模サービスの運用事例まとめ [blog.hacklife.net] → 満足せる豚。眠たげなポチ。 ﹁大規模サービスの運用事例まとめ﹂に補記 [blog.hacklife.net] → livedoor 開
-
ちょっと技術的な話。oracle分かる人にしか分からないかも。 最近取引先のシステムを見る機会が何度かあったのだが、昨日すんごいとこ見た。 DBが重くて業務にならないというから、ちょっと中を覗かせてもらったらもうエラいこっちゃ。 ・業務ロジックの殆どをファンクション・プロシージャで構成している。なのに、キャッシュヒット率が妙に低い。 ・調べてみようと思ったら一回もstatspackが取得されていない。(担当者には、﹁statspack?syslogならとってあるんですが…﹂と言われた) ・各テーブルのindexがどういう訳か全列に貼られている。ちなみにindexは全テーブル例外なくその一個だけ(プライマリキーを除けばだが)。 ・と思ったら、PKが文字列だったりするテーブルがあちらこちらにある。 ・試しにファンクションを一つ二つ見てみたら、なんか普通にクロス結合されまくっていてちょっとくらっ
-
ちょっと技術的な話になる。 私の知人に、かつてはアルファベット三文字の某有名SI会社に在籍していて、今はどういう訳か某ネットゲームの会社に勤めている変り種がいる。 彼はネットワークとDBの専門家である。ゲーム業界には元来DB周りに詳しい人があまり多くなかったらしく、しかしネットゲームの開発にはDBやネットワークのアーキテクチャに関する知識が必須で、要は引き抜かれたらしいのだが、当人それ程ゲーム好きでもないのに面白いルートに行くなーと思っていた。 機会があったら金融業界とネットゲーム業界のシステム周りの違いについて聞いてみたいなーと思ってたんだが、この前久々に会ったら色んな話が聞けた。特定されない程度においおい書いてみよう。ぼかして書く為、ところどころいー加減だが勘弁して頂きたい。 今日はサーバとかデータのやり取りとか、技術的な話。 まず、前提。オンラインシステムの肝の一つに、﹁誰がデータを
-
« MySQL のクエリ最適化における、もうひとつの検証方法 | メイン | MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話 » 2008年06月09日 フレンド・タイムライン処理の原理と実践 MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話に続きます。 Twitter が注目されるようになって久しい今日この頃ですが、友人の投稿を時系列に並べて表示する、というのは、Twitter に限らず Mixi の﹁マイミクシィ最新日記﹂やはてなブックマークの﹁お気に入り﹂等、ソーシャルなウェブサービスにおいては一般的な手法です。ですが、この処理 (以下﹁フレンド・タイムライン﹂と呼ぶ) は、一見簡単そうに見えて、実装には様々な困難が伴います。本記事では、﹁フレンド・タイムライン﹂を実現する、プッシュ型とプル型の二種類の手法について、その原
-
DSのスターフォックスというゲームにはまりまくりのmikioです。最近社内外で﹁俺ストレージサーバ﹂を作るのが流行っているようなので私も参戦してみました。今回はDBMのネットワーク層をほぼスクラッチで作った話をします。 Tokyo Tyrant Tokyo Tyrant︵以下TT︶はTokyo Cabinet︵以下TC︶をラップしてネットワーク越しに操作できるようにするツールです。キャビネット︵内閣︶を傀儡にするタイラント︵僭主︶ということで名付けました。ダウンロードはこちら。TCは高性能なDBMで、マルチスレッドモデルで高い並列性を実現していますが、逆にマルチプロセスモデルだとファイルロックがかかるので並列性が低くなってしまいます。つまり、書き込みモードでデータベースにアクセスしているプロセスがいると、その間は他のプロセスがデータベースに接続しようとするとブロックされることになります。
-
今回のテーマはデータベースエンジニアの必須知識の1つである﹁正規化﹂です。正規化は、リレーショナル・データベースのテーブル設計を行ううえで非常に重要なテクニックであり、データベースを設計、実装したことのある方なら一度は正規化に触れているのではないでしょうか。 それほど基本的な知識であるにもかかわらず、正規化を説明できる人はなかなかいません。多く聞かれるのが﹁何となくテーブルを作ると自然に第3正規形になる﹂とか﹁実務上は第3正規化まで行えば問題ない﹂というものです。 ではなぜ﹁第3正規化まで行えば問題ない﹂のでしょうか。本稿ではひととおり正規化について確認しながら、あまり触れられることのない第3正規化より先の正規化を紹介して、この疑問に答えていきたいと思います。 正規化の位置付け 正規化は、データベース設計全般にかかわる基礎知識ですが、特に論理データモデリングの作業の中で必要になります。本稿
-
1
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
設定を変更しましたx
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
memoranda redballis
ke-tai.org > Blog Archive > ケータイ大規模サービスの開発・運用に関する資料のまとめ
どうも世間では、思ったよりDBエンジニアが不足している様だ: 不倒城
不倒城: SI業界からネットゲーム業界に移った知人に色々話を聞いてきた。
Kazuho@Cybozu Labs: フレンド・タイムライン処理の原理と実践
DBMによるデータベースサーバ - mixi engineer blog
素早く正規形を見抜く実践テクニック（1/4） － ＠IT
