グローバルに分散化されたデータを扱い、データの一貫性を維持しながら高可用性をも実現するシステムを構築しようとしたら、それは簡単なことではありません。クラウドの良いところは、誰かがそれを構築して、誰にでも使えるようにしてくれることです。 CAP 定理によると、データベースは以下の 3 つの望まれる特性のうち、2 つまでしか持てないとあります。 C（Consistency）: 一貫性、共有されているデータが唯一の値を持つ A（Availability）: 可用性、読み込みと書き込みの両方で 100% の可用性が確保されている P（Partition Tolerance）: 分断耐性、ネットワークの分断に対する耐性があるここから導かれるシステムは 3 種類で、除く文字に応じて CA、CP、AP となります。これは、システムの設計者に 3 つから 2 つを選ぶことを強いるものではなく、実際多くのシ
最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
本日、qpstudyで「データベースとは」という内容について、そして「リレーショナルモデルとは」という内容について話す機会を頂いた。リレーショナルモデルという硬い内容であったにも関わらず、出席者の皆さんには最後まで良い反応をして頂けたように思う。実はリレーショナルモデルについて誤解している、あるいは知らない人が本当に多い、そして良い解説書がないということを普段問題として感じており、そういった背景から今回qpstudyの話を引き受けさせて貰った。今回発表した内容が皆さんのお役に立てば幸いである。 発表の内容はほぼ現在WEB+DB PRESSで連載している「理論で学ぶSQL再入門」のいくつかの回のものを要約したものになっている。連載ではさらに詳しい内容について説明しているので、興味のある人はぜひWEB+DB PRESSのバックナンバー（連載はVol.68〜）を購入して頂きたい。 本日発表したス
エンタープライズシステムのエンジニアをやって１０年以上。思うところを書いていきます。その他趣味を少々。。。 DBの世界に起きた大きな波 現在、どの製品を使ったとしてもRDBの性能問題は必ずといっていいほど発生する。理由は簡単で、CPU、ネットワークが高速化（CPUはマルチコア化、ネットワークは10G-Ethernetの一般化やInfiniBandなど）するのにディスク（ストレージ）が高速化に追いついていないからだ。その差を埋める役割として、RDBが担っているケースが多く、性能問題になるケースが散見される。 だが、そういう時代の流れに対して大きな変革が起きようとしている。SSDはかなりコモディティ化してきたので言うに及ばずといった感じだが、個人的には速いもののディスクの置き換えにすぎないと思っている。つまり、SSDは速いがDBのアーキテクチャに大きな変革をもたらすものではない。が、ここにきて
この内容は個人的な考察なので、間違っている箇所もあると思います。そういう部分を見つけた際はぜひ教えて下さい。 RDBMSの検索を早くするためにIndexって使いますよね。例えばこんなテーブル 1 2 3 4 5 CREATE TABLE user ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, name VARCHAR(255) NOT NULL, PRIMARY KEY (id) )ENGINE=InnoDB; idカラムにIndex(PRIMARY KEY)を張っています。これはidでの検索を高速にするためです。ここでidカラムにIndexが貼っていない場合と比べると検索時間が大幅に変わってきてしまいます（特にレコードが多くなった時) ではなぜIndexを貼ると検索が早くなるんでしょう？？ Indexとはその名の通り索引を意味します。特定のカラム
2018.12.11OSS-DB Silver出題範囲「運用管理 - インストール方法（initdbコマンドの使い方）」に関する例題解説を追加しました。 2018.12.10年末年始休業のご案内 Holiday Closing Notice 2018.12.08ビジネスパートナー制度説明会開催のお知らせ（12/11、12/18、1/8、1／15、1／22、1／29、2/5、2／12、2／19、2/26） 2018.12.07アカデミック認定校制度説明会開催のお知らせ（12/13、12/20、1/10、1/17、1/24、1／31、2/7、2／14、2／21、2／28） 2018.12.05『OSS-DB Exam Gold 技術解説無料セミナー』＠東京 12/2（日）開催結果のご報告 2018.11.27OSS-DB Silver出題範囲「開発/SQL - SQLコマンド（SELECT文）
■ 三菱図書館システムMELIL旧型の欠陥、アニメ化 - 岡崎図書館事件(7) 21日の日記で示したMELIL/CS（旧型）の構造上の欠陥について、その仕組みをアニメーションで表現してみる。 まず、Webアクセスの仕組み。ブラウザとWebサーバはHTTPで通信するが、アクセスごとにHTTP接続は切断される*1。以下のアニメ1はその様子を表している。 このように、アクセスが終わると接続が切断されて、次のアクセスで再び接続するのであるが、ブラウザごとに毎回同じ「セッションオブジェクト」に繋がるよう、「セッションID」と呼ばれる受付番号を用いて制御されている。 なお、赤い線は、その接続が使用中であることを表している。 次に、「3層アーキテクチャ」と呼ばれる、データベースと連携したWebアプリケーションの実現方式について。3層アーキテクチャでは、Webアプリケーションが、Webサーバからデータベー
2006-09-11 近況 今月は貧乏なので慎しく暮らしている. 週末もひきこもりとしてオンラインの記事を読んで過ごすことに. ウェブを眺めているといいタイミングで Google の新作論文が出ていた. ありがとう, Google の中の人. これ. GFS, MapReduce, Sawzall とつづく Google インフラ N 部作の 4 章が幕をあげた. 実はデータベースも作ってるんだぜ, という話. BigTable という名前だけは以前から O'Reilly Radar などに登場していた. ようやく公式な文書があらわれた. BigTable は GFS をはじめとする Google インフラの上に作られた分散データベース. 少し変わったデータモデルと, 運用までワンセットのヘビーな実装を持つ. 実装の話もまあ面白いんだけれど, それよりデータモデルが印象的だった. 先にその
A5:SQL Mk-2は複雑化するデータベース開発を支援するために開発されたフリーのSQL開発ツールです。 高機能かつ軽量で、使い方が分かりやすいことを目標に開発されています。 SQLを実行したり、テーブルを編集するほかに、SQLの実行計画を取得したり、ER図を作成したりすることが出来ます。 特徴・機能 OCI接続・直接接続・ADOまたはODBCを介したDBへの接続 Oracle DatabaseはOCI経由の接続・直接接続が出来ます。 PostgreSQLとMySQLは直接接続が出来ます。 Microsoft SQL Serverは、OLE DBプロバイダを直接呼び出した接続ができます。 IBM DB2は、ODBCドライバを直接呼び出した接続ができます。 その他のデータベースは、ADOまたはODBCを利用して接続します。 Oracle, PostgreSQL, MySQLは、A5:SQL
ここでは、リレーショナル型データベースを操作するために必須となる世界標準言語 SQL について、基礎から応用まで詳しく説明しています。 また、SQL のみにとどまらず、リレーショナルデータベースマネージメントシステム (RDBMS) の持つ様々な機能について詳しく説明しています。 最後には、データベースの設計に関する非常に重要な考え方についても触れていますので、これらを全て学習すると、データベースの操作から設計まで幅広い知識を身につけることができるでしょう。 SQL INDEX 1. データベースの概要 1.1. データベースとは 1.2. データベースシステムの特徴 1.3. データベースとファイルの違い 1.4. 代表的なデータモデル 1.5. リレーショナル型データベース 1.6. まとめ 2. SQL 2.1. SQL の歴史 2.2. SQL とは 2.3. SQL の機能 2.
Works Index Last Updated. 05-Apr-2007 What's New ? 2007/04/05 翔泳社さんのCodeZineに記事を書きました 逆引きSQL比較 基本的な機能（主にSQLについて）の概要を、逆引きで、かつ平易な言葉で閲覧する事を目的に作っています。 RDBMS Reverse Reference コラム [CodeZine] GUIのダイアログを使ったエンドユーザ向け対話バッチの実現 DOSのバッチから、VBScriptやCで作成した簡易なプログラムを呼び出して対話型の処理を行う方法を紹介します。 2007/04/05 オプティマイザヒントを使用したパフォーマンスチューニング−２ オプティマイザヒントを使用したSQLチューニングについて再度。 2005/11/23 テキストファイルやExcelシートをSELECT文で見てみる−２ Exc
人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ！！人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから
●既存のDB技術と一線を画すデータ検索技術を生み出す ●ゼロベースで発想しOSの基本機能に着目 ●ストップウオッチ片手に高速化を追求 ソフト開発ベンチャーのHOWSが、これまでにないデータ管理・検索技術「ISSEI」を開発した。HOWSは現在、ISSEIを次世代Web基盤技術として特許を出願している。 「ユーザー企業がデータを有効活用するためには、既存のリレーショナルデータベース（RDB）と一線を画す技術を編み出すほかないと考えた」。HOWSのCTO（最高技術責任者）である庄司渉副社長は、ISSEIを開発した思いを語る。 ユーザー企業の多くは現在、社内システムを整備し、テキストや画像、音声などさまざまな種類のデータを大量に蓄積している。その一方で「データを業務に有効活用できていない」と嘆くCIO（最高情報責任者）が多いのも事実だ。 その理由について庄司副社長は、「現在主流のRDBが限界に近
リレーショナルデータベースはクライアント/サーバモデルに適合するものの、サービスの世界では新しいソリューションが必要である(source)。RDBMSはスケーラビリティの問題に陥りやすい。冗長性や並列性をどのようにして実現すればいいのか(source)？ （リレーショナルデータベースは）単一故障点となります。特に複製はささいな事ではありません。疑問に思うのであれば、全く同じデータを必要とする2つのデータベースサーバがあることによって起こる問題を考えて見てください。データを読んだり書いたりするために両方のサーバがあると、同時に変更するのが困難になります。マスターサーバとスレーブサーバがあっても、良くありません。なぜなら、マスターはユーザが情報を書き込む際、沢山の熱を帯びるからです。 また、Assaf Arkin氏も整合性を書くこと(source)はRDBMSが自身の重さで内破してしまう理由で
＞＞前編 ハッシュ利用で比較を減らす 後編ではまず，オプティマイザが選択する最短経路を紹介する。 複数のテーブルを共通のキーを用いて結合する「ジョイン」はいくつかの方式がある。その一つであるハッシュ・ジョインは，ハッシュ関数を使って，一つのテーブルのキーからハッシュ値を計算する（図4）。さらに，ハッシュ値と該当するデータで構成する「ハッシュ・テーブル」を作成する。同様に二つ目のテーブルからハッシュ値を計算し，その値を基に検索するハッシュ・テーブルのレコードを特定する。ハッシュ値を計算するだけで比較対象のデータが絞り込めるので，ほかのジョイン方式よりも高速になる場合がある。ただし，「各テーブルを展開できるだけのメモリー容量が必要になる。メモリーが足りないと逆に遅くなる」（伊藤忠テクノソリューションズ プラットフォーム技術部 部長代行 宮田武氏）といった注意点がある。 図4●ハッシュ・ジョイン
ポイント ・高度なインデックスやジョインを利用し，最短経路でデータにアクセス ・メモリー不足を自律的に解消し，キャッシュのヒット率を高める ・インメモリーDBは全データをメモリーで処理し，高速化を図る 目的地に早く到着したいなら，最短の経路を最速で行けばよい。これはデータベース（DB）でも同様だ（図1）。インデックスなどを使ってデータへの最短経路を見つけ，メモリー・アクセスを増やして，最速でたどり着く。DBにはそんな技術が詰まっている。 図1●データベース高速化技術のポイント ビットマップ・インデックスなどを使い、データにたどり着く最短の道を選ぶ。また、できるだけメモリーにデータをキャッシュさせておくことで、アクセスのスピードを上げる、という二つのポイントがある [画像のクリックで拡大表示] 以下では，（1）データにたどり着く最短の道を選ぶ仕組みと，（2）アクセスのスピードを上げる仕組みの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く