もう1つの、DBのかたち、分散Key-Valueストアとは
もう1つの、DBのかたち、分散Key-Valueストアとは：分散Key-Valueストアの本命「Bigtable」（1）（1/3 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 クラウド時代のデータベース「分散Key-Valueストア」 グーグルがインターネットの世界をここまで席けんできた最大の理由は何でしょうか。実は、それは同社の優れた検索技術ではありません。グーグルが成し遂げた最も大きなブレークスルーの1つは、同社が生み出した巨大な分散データストア、「Bigtable」にあります。 Bigtableは、Google検索をはじめ、YouTubeやGoogle Map、Google Earth、Google Analytics、Goog
［次世代DB編］異なる分散KVS間でデータ移行してはいけない
分散型のキーバリューストア（分散KVS）には、オープンソースソフトや商用のもの、サービスとして提供されるものなど、さまざまな種類がある。これらをすべて同じだと思ってはいけない。その構造や特徴はバラバラであり、ある分散KVSのデータは別の分散KVSに移行するのは困難だ。 既存のRDBMSの資産を分散KVSに移行するのが容易ではないことはよく知られている。同様に分散KVS間の移行もかなり難しい。安易に移行できると考えていると、苦労することになる。 大きく異なるテーブル構造 現在、分散KVSと呼ばれるデータベースには、以下のようなものがある。 ・Amazon SimpleDB（Amazon） ・Apache Cassandra（Apache） ・BigTable（Google） ・Flare（GREE） ・kumofs（えとらぼ） ・memcached（Danga Interactive） ・R
［次世代DB編］分散KVSで正規化をしてはいけない
クラウド上のデータベースとして、分散型のキーバリューストア（分散KVS）を用いることが多くなった。分散KVSは、スケーラビリティーに優れており、特にユーザー数が多いシステムでは利用価値が高い。 ただし、分散KVSにはいくつかの制約があり、システム開発に利用する際には、これまでの“RDBMS脳”をいったんリセットする必要がある。中でも、RDBMSでは真っ先に考慮していた「正規化」については、分散KVSでは原則として行ってはいけない。 分散KVSの四つの特徴 なぜ分散KVSでは正規化をしてはいけないのか。これを理解するには分散KVSの特徴を押さえる必要がある。分散KVSには、大きく四つの特徴がある（図1）。 一つは、分散KVSでは問い合わせにキーを使って、バリュー（値）を取得することだ。データ構造が単純なので、データの取り出し時間が短くて済む。PerlやPHPの連想配列や、JavaのMap、C
［次世代DB編］分散KVSに重要なデータを置いてはいけない
分散KVS（キーバリューストア）は、RDBMSの代わりになると思ってはいけない。RDBMSでは当たり前だった機能の一部は、あきらめる必要がある。このため、重要なデータをむやみやたらと分散KVS上に置くのはやめた方がよい。 分散KVSであきらめなければならない機能には、次の四つがある、 ・トランザクション機能 ・排他制御機能 ・読み取り一貫性を保証する機能 ・スプリットブレイン対策機能 逆にいえば、これらを取り込まないことで、分散KVSはRDBMSではかなわなかった、無尽蔵なスケーラビリティーや、極端に短いレイテンシー（要求が返ってくるまでの遅延時間）による高パフォーマンスを実現できたわけだ。 ところが、使い方を間違えれば、たちまち問題が生じてしまう。とりわけ、業務システムにおける重要なデータを分散KVS上に置く場合は注意が必要だ。 トランザクション処理に支障 重要なデータとは、不整合や損失
［データ設計］マスター系と更新系を明確に分ける
福士有二 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 データ設計の肝になるのは，データの最小単位であるデータ項目と，データ項目のまとまりと関連を示した論理データ・モデルである。画面設計や業務プロセス設計より先に設計作業を進め，追加や変更がある場合は速やかに対処することが肝心である。 図6に示したのが，データ設計で作成する設計書とその関係である。大きく分けて「(1)設計基準作成」「(2)データ項目設計」「(3)データベース論理設計」という三つのステップがあり，全部で8種類の設計書を作成する。要件定義で作成した「業務用語集」「概念データ・モデル」「データフロー図（DFD）」を用意しておこう。図7と照らし合わせて読んでほしい。
［データベース設計編］参照整合性制約機能を多用してはいけない
参照整合性（Referential Integrity）とは，テーブル間のデータの整合性を保つための仕組みである。例えば，「受注テーブルの商品番号カラムには，商品テーブルの商品番号カラムに同じ値がなければならない」といった制約を維持するための仕組みである（図1）。RDBMSはこの整合性を維持するための機能として，「参照整合性制約」といった機能を持つことが多い。これは，定義された参照整合性をチェックし，整合性を逸脱するような値がテーブル内に存在しないようにする機能である。この機能を使用する場合は，テーブル定義の際に「Constraint句」を用いることが多い。 参照整合性制約機能は，誤ったデータがテーブルに含まれないようにするには効果的な機能である。だが，むやみに使うと問題を引き起こすことがあるので，注意が必要だ。 データ移行時にエラー 最も問題が起こりやすいのは，データを移行する際だ。先の
［データベース設計編］レコード長×件数でデータ容量を決めてはいけない：ITpro
データベース設計の一つに，ディスク容量の見積もりがある。概算として，そのデータベースに格納する「テーブルのレコード長×件数」で見積もることがあるだろう。だが，こうして求めた値の容量を確保していると，後々ディスク容量不足になることが多いので注意が必要だ。 その原因として，大きく二つの理由がある。一つは「論理レコード長」と「物理レコード長」の違い，もう一つは「ブロック」の考え方が入っていない点である。論理レコード長とは，簡単に説明すればディスクへの格納形式を考慮しないレコード長，物理レコード長とはディスクへの格納形式に基づいたレコード長である。ブロックとは，RDBMSがディスク入出力を行う際のデータ単位である。 物理サイズはRDBMSに依存 レコード長は，テーブルを構成するカラム・サイズの合計で考えるのが基本である。カラムの定義は，例えば「カラム01 char(10)」（10バイトの文字列）や
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベースソフトってなんであるの？ : はれぞう
accessclub.jp - このウェブサイトは販売用です！ - アクセスクラブ リソースおよび情報