タグ

designとoracleに関するMakotsのブックマーク (3)

  • DB 設計時のサイズ見積り[最新版] - Qiita

    こんにちは、すっかり秋ですね!@yone098 です。 みなさんDBの設計してますか? DB設計時のサイズ見積り 以前はてなダイアリーで書いた記事は5年前のものであり、リンクが切れているものがあるので最新版として MySQL, PostgreSQL, Oracle, SQLServer におけるDB設計時のサイズ見積りをまとめ直しました。 URL内のバージョン表記を変えると以前のバージョンの情報になります。 MySQLは、あまり情報に変化は無かったので Excel でマクロなどを作成して自社で自動算出出来るようにするのが良いと思います。 データタイプごとに必要な要求ストレージが決まっているのでレコードサイズが決まり、あとは要件次第で何レコードになるかを予測します。 データタイプごとに必要な記憶容量 テーブルの最大サイズ関連 http://dev.mysql.com/doc/refman/5

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

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

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

    データベースの運用に当たって、効率のよいバッチアプリケーションが作成できるかどうか、は大きな課題です。連載では、Oracle Databaseの管理運用を前提に、効率のよいバッチアプリケーション作成のためのテクニックを紹介していきます。 バッチ処理の抱える問題 オープン系技術の導入によって、企業システムのフロントエンド(画面周り)は大きく進化を遂げました。しかし、バックエンド(サーバ周り)でのバッチ処理は、今日でもさまざまな問題を抱えています。 最も深刻な問題は、バッチの処理性能が著しく低下してしまうことでしょう。業務のIT化が進むにつれて、データベースに蓄積されるデータ量はどんどん増加する傾向にあります。また、Webなどで多様なサービスを展開するには、データをさまざまな形式に加工/集計する必要があります。 この2つのマイナス要因によって、既存のバッチアプリケーションにかかる負荷はますま

    バッチアプリケーション設計のポイント
  • 1