タグ

designとdbに関するMakotsのブックマーク (26)

  • コンシューマサービスの運用に耐えるDB性能設計とは - レベルエンター山本大のブログ

    JOIN 禁止の話に、いまだに絡んでくれる人がいた。 ■「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 の日記 僕が以前に書いたテーマに関するエントリは以下の3つ。 ■信じられないDB文化Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設 ■信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 ■ホント信じられないDB文化だけど、統計情報固定化はマジでアリ ちょうど折よく、ウチの会社のオラクル女子が書いたエントリの続きも公開されました。 ■一緒にまなぼ!「hiromi と楽しむOracleパフォーマンスチューニング!」【Vol.2 Statspackを見てみよう】 ということで僕の中でDB熱が盛り上がってきたので返答的なエントリを書きます。 「とりあえずメモリだけ気にしておけ」

  • 信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ

    ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止

    信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
  • いきあたりばったりのアーキテクチャと教訓

    スライドの作者であるGleicon Moraesは、これらの図を示した上で、リレーショナルデータベースはガムテープのようにつぎはぎで使えるような万能薬ではない。シャーディングや非正規化などは検討すべきよい選択肢であり、またリレーショナル以外のデータベースも選択肢としていれるとよいだろうと説いています。 そして次のような「リレーショナルデータベースの間違った使い方10項目」を示しているのです(訳は前述の記事「データベースの間違った使い方10項目」から)。 Dynamic table creation(動的なテーブルの作成) Table as cache(テーブルをキャッシュとして使う) Table as queue(テーブルをキューとして使う) Table as log file(テーブルをログとして使う) Distributed Global Locking(分散したグローバルなロック)

    いきあたりばったりのアーキテクチャと教訓
  • グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering

    はじめに はじめまして、グリー株式会社でエンジニアをしておりますkgwsと申します。今回は、グリー内で写真データの保存を行っている分散ストレージ(nanofs)を紹介させていただければと思います。 背景 弊社で運営させていただいている "GREE" ではユーザの写真や動画データを保存することができます。1億ユーザを目指すグリーは、ユーザの増加とともに写真や動画データは上限なしに増加していきます。またユーザの皆様の大切なデータを失うことは許されませんし、サービスを止めることも許されません。そんな状況の中、様々な技術や仕組みを使いサービスを運営してまいりました。 グリーのストレージの歴史は大きく分けて3世代がありました。 第一世代 第一世代ではアプリケーションサーバからNFSサーバをマウントし画像データを保存しておりました。簡単に導入できることと高価なサーバを使用すれば信頼性や安定性も保たれる

    グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering
  • 物理データモデル作成のポイントは“森→木→森”

    前回まで、システム企画段階における「概念データモデル」、基設計段階における「論理データモデル」についてお話をしてきました。この2つの共通点は、企業のビジネス活動をデータモデルで可視化することでした。今回は、詳細設計フェイズにおける「物理データモデル」を解説します。 物理データモデリングとは 第4回「データベース設計はいつ、何をポイントに行うか」でも触れましたが、物理データモデリングは、システムを動かすことを目的に作ります。概念モデル、論理モデルとビジネスの視点を中心に設計をしていましたが、物理モデルは「システムの視点」による設計となります。 ここでは、リレーショナルデータベースへの実装を前提として、論理データモデルとの乖離(かいり)を最小限に抑えながら、アクセス方式と格納方式を考慮した設計を行うことで、システム要件を満たした「動くシステム」の設計を行います。 2つの方式で“複眼的な視点”

    物理データモデル作成のポイントは“森→木→森”
  • Tags: Database schemas

    An online tech community is the most exciting place for a software developer to spend their time. It not only offers the chance to work and interact remotely, but also helps in honing one’s own skills and becoming a well-rounded programmer. Whether you are a budding software developer or simply passionate about technology, here are the best online software development communities you can join. The