Create new page · t-matsuo/resource-agents Wiki
Attach files by dragging & dropping, selecting or pasting them. Loading Uploading your files… We don’t support that file type. Try again with a GIF, JPEG, JPG, MOV, MP4, PNG, SVG or WEBM. Attaching documents requires write permission to this repository. Try again with a GIF, JPEG, JPG, MOV, MP4, PNG, SVG or WEBM. We don’t support that file type. Try again with a GIF, JPEG, JPG, MOV, MP4, PNG, SVG
「強制されたサロゲートキー」の事例を眺める - 設計者の発言
Ruby on Rails上で実装されているプロジェクト管理ツール「Redmine」をインストールした。実務で使うためではなく、前回記事で言う「サロゲートキーを強制する開発基盤」のひとつであるRails上のＤＢ設計事例を眺めてみたかったからだ。 サロゲートキーが強制される基盤上で作られるテーブル構造の特徴は、複合主キーが許されないために「親子関係」が出現しない点である。たとえば図１において、membersはuser-idとproject-idの組み合わせをユニーク制約としているが、それらは一次識別子に含まれていないので、usersやprojectsとは「参照関係」をとっている。つまりＥＲ図だけ眺めたら、memberレコードを追加した後で、user-idやproject-idの値が変更可能であるように見える。 図１ [users] id, firstname, lastname, ... ＋
バリデーションの双方向性問題を解く - 設計者の発言
何回かにわたって「動的参照関係」における整合性に関する問題をとりあげた。とくに、「参照先」が更新された場合に起こり得る不整合について説明した。ただしそれらは「静的参照関係（通常の外部キー制約）」を含め、あくまでも「参照レコードが存在するかどうか」の問題である。 しかし、「参照レコードが存在するかどうか」は多彩な制約の一部でしかない。それ以外にもさまざまな制約があって、それらすべてについて「参照先レコードが更新された場合の不整合問題」がつきまとう。「参照元」におけるバリデーション（制約にもとづく整合性の検証）はこれまでまともに対処されてきたが、何度か書いたように、「参照先」をバリデーションの起点とする不整合問題は見過ごされがちだった。これを、参照元と参照先の双方で対処すべき問題という意味で「バリデーションの双方向性問題」と呼ぶことにしよう。 具体例を見よう。たとえば次のモデルのテーブルＣにお
Execute Query
Execute Query now on Google Groups We have set up Execute Query on Google Groups to consolidate queries and issues as well as provide an indexed support forum and mailing list. Please visit us at http://groups.google.com/group/executequery. You can also continue to log your issues and requests directly here or from the feedback option in the application help menu. Latest Version Execute Query v4.4
HDDをSSDにしたらデータベースはどれだけ速くなるか？ オラクルと富士通が実験
リレーショナルデータベースを利用する際には、高い性能を引き出すために物理設計をし、スキーマを工夫し、パラメータのチューニングを行うことがつねに行われてきました。 性能のボトルネックはたいがいHDDにあり、いかにそのボトルネックを回避するかがチューニングのポイントですが、最近では性能向上のための武器として、HDDよりもずっとアクセス性能の高いSSDが注目されています。SSDはHDDと置き換えるだけで、アプリケーションにまったく手を加えずに性能向上を可能にする手段として非常に魅力的です。 HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか？ オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました（参考「日本オラクルと富士通 フラッシュ技術活用によるデータベース高速化を共同検証」）。 ホワイトペーパーでは、HDDの代わり
Kazuho@Cybozu Labs: Pacific という名前の分散ストレージを作り始めた件
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名：アプリケーションレベルパーティショニング／レベル２分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加（とそれにともなう負荷の再分散）が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
RDBMSの時代の終わりが見えてきた - きしだのはてな
クラウドと一緒にやってきたもの 最近、クラウドが流行ってます。 GoogleのMapResuceから始まって、MicrosoftのAzureまで、大手のクラウド製品が出揃った感じ。 で、そこで、こんなクラウド製品が出ましたというときに、必ずといっていいほどそのクラウド用のデータベースの説明があります。そして、それはRDBMSではありません。 GoogleだとBigTable、MicrosoftだとSQL Data Services、あとはAmazonのSimpleDB。どれも、基本的にはひとつのテーブルにハッシュコードでアクセスするようになっています。 ほかのクラウド製品も、Oracle Coherenceだったり、楽天のRomaだったり、非RDBMSのデータストレージを提供します。 クラウドというわけではないけど、mixiのTokyo TyrantやApache CouchDBも、RDB
ホーム | Let's POSTGRES
メインコンテンツに移動 お知らせ Let’s Postgres 運営管理についてのお知らせ コンテンツメニュー 導入検討 と 入門 インストール 運用管理 チューニング 新機能: 16 / 15/ 14 / 13 / 12 / 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 トラブルシュート サポートとFAQ 事例紹介 イベントレポート リンク集 レプリケーション / クラスタ構成 XML / PostGIS / 拡張モジュール パーティショニング / テキスト検索 Window関数 / 再帰SQL / 外部データ連携 文書: 15 / 14 / 13 / 12 / 11 / 10 / 9.6 / 9.5 Let's PostgreSQL は特定非営利活動法人日本PostgreSQLユーザ会が運営しています。 RSS feed
「はてな流大規模データ処理」を見てきた - もぎゃろぐ
KOF2008：関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 ＃ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量：五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク
SSDとSATAのベンチマーク比較 第2ラウンド: サーバーアプリケーション | OSDN Magazine
昨日はBonnie++を用いてクライアントマシンにおけるソリッドステートドライブ（SSD：Solid State Drive）のベンチマーク評価を行い（翻訳記事）、同じ予算で複数台のハードディスクを購入するのに比べて1台のSSDを購入することにどれだけメリットがあるかを論じた。今日はSSDのシークタイムが極めて短いことがサーバーにおいてどれだけ有利に働くかを見てみよう。 SSDの応用例は専らモバイル志向でノートPCのハードディスクをSSDに置き換えることに関心が向けられており、そうした利用形態ではSSDの最大のメリットであるシークタイムの高速性が活かされることはない。シークタイムの短さに関して特にどん欲なサーバーアプリケーションのひとつにリレーショナルデータベースがある。今回テストに用いたSSDはサイズが非常に小さく、データベースのタプルそのものを格納することは多分できないが、インデックス
[ThinkIT] 第1回：共有バッファでどれだけ変わる？ (1/4)
PostgreSQLとは、リレーショナルデータベース管理システム（RDBMS）です。誰でもどのような目的にも無料で使えるオープンソースのソフトウェアです。最近ではすっかり知名度も上がり、非常に多くの方がPostgreSQLを利用されるようになりました。 これほど普及してくると利用される方の技術レベルも様々で、長らく商用RDBMSでシステム開発をされてきた方もいれば、RDBMSを扱うのはPostgreSQLがはじめてという方もいます。当然PostgreSQLの使われ方も様々で、PostgreSQLの性能を限界まで引き出すようにチューニングを施している方もいれば、インストールしたままのデフォルト設定のままで使っている方もいます。 ソフトウェアのデフォルト設定を「開発者の推奨設定」と捉える方がいらっしゃいます。しかし残念ながらPostgreSQLにおいては成り立ちません。それではPostgreS
SqlSyncによるデータベースの同期化 | OSDN Magazine
SqlSync では2つのデータベースを比較して、どのタプルが追加され、除かれ、変更されたかを知ることができる。また、一方のデータベースを他方のクローンにし、必要な変更を加えながらその状態を保つことができる。同期化にSqlSyncを用いることには、異種エンジン間（たとえば、MySQLからPostgreSQLへ）の同期化ができるというメリットがある。 Ubuntu、Fedora、openSUSEの標準リポジトリにはSqlSyncパッケージがない。そこで、本稿ではバージョン1.0.0-rc1を使い、64ビットのFedora 8マシンでソースからビルドすることにした。プロジェクトのfreshmeatページにもホームページにも書かれていないが、SqlSyncはデータベースへのアクセスにODBCを使う。したがって、unixODBC開発パッケージがインストールされていないと、ビルドは成功しない。 Sq
再帰クエリ
再帰クエリとは、木構造のような再帰的なデータ構造を 1 つのクエリで再帰 的に結果を取得する機能です。例えば、部品展開や、経路探索などができるよ うになります。 例えば、以下のような組織構造を表現するテーブルがあるとします。 CREATE TABLE department ( id INT PRIMARY KEY, -- 部署 ID parent_department INT REFERENCES department, -- 上位部署の ID name TEXT -- 部署名 ); INSERT INTO department VALUES (0, NULL, 'ROOT'); INSERT INTO department VALUES (1, 0, 'A'); INSERT INTO department VALUES (2, 1, 'B'); INSERT INTO departme
DBDesigner 4
General Information - What is DBDesigner 4? DBDesigner 4 is a visual database design system that integrates database design, modeling, creation and maintenance into a single, seamless environment. It combines professional features and a clear and simple user interface to offer the most efficient way to handle your databases. DBDesigner 4 compares to products like Oracle's Designer�, IBM's Rational
画像もDBに格納して管理する －扱いがめんどうなLOB(ラージオブジェクト)は使わない方法も含め
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Health Insurance High Speed Internet Work from Home Healthy Weight Loss Best Penny Stocks Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
CodeZine：DeNAの人気サイトに学ぶ LAMPによるWeb-DBシステム構築/運用の極意（前編）（モバオク, モバゲー）
シングルマスタの非同期レプリケーション機能では、マスタサーバーが1台に限定され、マスタからスレーブへの複製は非同期で行なわれるため遅延が生じ、短時間のスケールで見ると全スレーブとの同期が保証されない。しかし、その反面スレーブの台数を増加させていってもマスタサーバーの更新負荷は大きくならず、スケーラビリティを維持できるという利点がある。DeNAによる運用実績でも、マスタとスレーブ間の遅延は通常数秒程度以内に収まる。 このレプリケーションを利用する場合、アプリケーション側ではデータ更新時にはマスタサーバーへ接続し、データ参照のみを行なう場合はスレーブサーバーへ接続するように作成する必要がある。 Webや携帯電話向けサービスの場合、小さな規模で始めてユーザー規模、データ規模、ページビュー数を徐々に増加させていくことが多い。小さな規模のためDBの負荷分散が不要な場合でも、マスタサーバー1台、スレー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://cloud.google.com/products/cloud-sql/
Google Code Archive - Long-term storage for Google Code Project Hosting.
IBM Developer
株式会社スタイルズ
