Kazuho@Cybozu Labs: 高度に進化した分散データストアは RDBMS と見分けがつかない？ (shibuya.pm #12 スライド)
開発しているシャーディングミドルウェアである Incline と Pacific については YAPC::Asia 2009 を始めいろいろな所で話をする機会をいただいてきたので、今回は、なぜ RDBMS ベースのアプローチを採用したのかという背景を中心に説明させていただきました。概念的な話が多くて分かりにくかったと思います（すみません）が、細かな点についてはパフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)を参照いただければと思います。 また、中で出てきた「実体化ビュー」については、Materialized view - Wikipedia, the free encyclopediaが良くまとまっているかと思います。Incline は一言でいうと、RDBで構成されるshard群の上で read-only かつ eventually co
NOSQL Patterns、和訳 - @katzchang.contexts
http://horicky.blogspot.com/2009/11/nosql-patterns.html 11/30時点で、一通り翻訳のうち、正直ベースのざっくり感覚（業界用語）で75%完了です。 本人も理解が怪しいながら訳しているので、随所に間違いを仕込んでいます。ご指摘頂ければ幸いです。 NOSQL Patterns ここ数年、大規模データを扱うデータストレージ機構が発展している。これらの機構は従来のRDBMSモデルとは異なっており、NOSQLとも呼ばれている。キープレイヤーとしては： GoogleBigTable, HBase, Hypertable AmazonDynano, Voldemort, Cassendra, Riak Redis CouchDB, MongoDB これらは、次の共通点を持っている。 Key-Valueストア 多数台の一般的なPCで運用可能 複数サー
世界のトップ研究者がデータベースの未来を語る - Claremont Report on Database Research
５年に一度、データベースのトップ研究者が一か所に集まって、データベースの未来について語るThe Clearemont Report on Database Research 2008の記事がCACMに紹介されていました。 The Claremont Report on Database Research （各研究者のプレゼンテーションスライドはこちらから） 大規模データ処理、RDBMSエンジンの見直しの必要性、クラウド、MapReduce、開発者にとってのデータベースの使いやすさ、新しい言語は？、Uncertain data, プライバシーの管理などなど、DBの将来を見据えた意見が盛りだくさんです。 どの研究者がどの方向性を打ち出しているのかを記事から読み取れれば、もう立派なデータベース通。そして、錚々たるメンバーのなかになぜかTim O'Reillyが混じっている。。。 とにもかくにも、
列指向データベース管理システム - Wikipedia
列指向データベース管理システムは、データベース管理システム (DBMS) の内部構造において、列のデータをひとまとまりにして取り出すときに効率的であるように設計されたものである。これはデータウェアハウスや図書館のカタログのように、大量の類似のデータ項目に対し集計が行われるものに対して有用である。[1]このアプローチはvalue-basedなストレージ構造を使用する行指向データベースや相関データベースと対比される。 列指向データベース管理システムは、一般的に「カラムナデータベース」 (Columnar Database) とも呼ばれる。 詳細[編集] 通常のDBMSシステムはひとつの行を構成する列データをひとまとまりとして格納する。これに対し列指向DBMSでは、列の値をまとめてファイルシステム上の近い場所に（あるいはひとまとまりの論理構造として）置くというアプローチがある。 利点[編集] 行
Google Fusion Tables Tour
Look at public data. Get started with an interesting data set from the Table Gallery. Import your own. Upload data tables from speadsheets or csv files. During our labs release, we can support up to 100MB per table, and up to 250MB per user. You can export your data as csv too. Visualize it instantly. See the data on a map or as a chart immediately. Columns with locations are interpreted automat
IT news, careers, business technology, reviews
Heads on: Apple’s Vision Pro delivers a glimpse of the future
メールマガジン - バックナンバー
おら! オラ! Oracle - どっぷり検証生活 メールマガジン登録/解除 このメールマガジンを購読される方、または購読を解除される方は、画面左の登録/解除フォームにメールアドレスを入力して下さい。 ※このメールマガジンはまぐまぐからの配信となります。 バックナンバー
データベースコンサルタントのノウハウちょい見せ ACIDを超える概念か？ 新しいトランザクションの考え方 - BASE
各種インフラ技術(OS、ストレージ、ネットワーク)やオラクル製品といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります DB使いであれば、ACID(Atomicity、Consistency、Isolation、Durability)は当たり前の考えかと思います。実は、DBMSならACIDが当たり前というのは、思いこみと言っても良いのです。少なくとも、ACID以外の考え方が存在するのは事実です。 今回は、そんな考え方である、BASE(Basically Available、Soft state、Eventually consistent)を紹介します。クラウドなどの世界で徐々に広がりつつある、トランザクションの考え方です。 この記事は、「BASE: An A
「郵便番号データの落とし穴」に落ちてしまいました。 - 日記
いま、仕事で郵便番号のデータをデータベースのテーブルに登録するツールを作成している。登録するデータは日本郵便のサイトからダウンロードしてきたファイル(いわゆるKEN_ALL.CSV)を使用している。最初は 毎月1回、自動でダウンロード 圧縮ファイルを解凍 システムが必要とする項目だけを抜き出して別のCSVファイルに落としシェルか何かで適当にテーブルにインポートと思っていたが・・・。ダウンロードするのはいいが、ファイルのダウンロードが成功したか、途中で失敗したかどうやって判定したらいいのかわからない。md5のファイルなどが別途用意されていればいいが、当然、日本郵便はそんな細かい仕事はやってくれない。 圧縮の形式がLZHはいかがなものか。zipじゃだめなの？ データフォーマットがひどい。KEN_ALL.CSVのデータフォーマットのひどさについては、郵便番号データの落とし穴を参照なのだが、問題は
郵便番号データの落とし穴
概要 MS-Access 上で郵便番号を住所変換するためには、住所入力支援機能が提供されている。 しかし、元になっている辞書ファイルのアップデートが遅れたり、用途に応じてカスタマイズするには限界があるなどの理由から、日本郵政公社が配布している郵便番号データを利用して、オリジナルの郵便番号⇒住所変換機能を実装する方法も、広く知られている。 日本郵政公社（執筆当時。現・郵便事業株式会社）が配布している郵便番号データは単純な CSV 形式のため、加工がしやすく、初・中級クラスの VBA の知識があれば簡単に応用が効く、というのが、私が見聞きした範囲での一般的な認知のようだ。 しかし最近になって、ふとしたことから実際にその CSV データを見る機会が有り、いくつかの疑問点・問題点が浮かび上がってきた。 はたして日本郵政公社の CSV データは、本当に使いやすいのだろうか？ 仕様 まず、仕様を確認し
ネットワーク型データモデル - Wikipedia
ネットワーク型データモデル（ネットワークがたデータモデル）は、データベースモデルの一種であり、オブジェクト群とそれらの関係を表す柔軟な手法である。発明者はチャールズ・バックマン。1969年にCODASYLによって標準規格とされた。 概要[編集] 階層型データモデルではデータを木構造で構成し、あるレコードには1つの親レコードと複数の子レコードが関連している。一方、ネットワーク型データモデルでは各レコードは任意の個数の親レコードと子レコードを持つことができ、ラティス構造を形成する。 ネットワーク型データモデルの主要な利点は、階層型データモデルに比較して、各実体の関係をより自然に表現できる点であった。このモデルは広く実装され使用されたが、2つの理由により支配的手法とはならなかった。第一にIBMが IMS や DL/I といった既存の製品で階層型データモデルに固執したことが挙げられる。第二に関係モ
Archived MSDN and TechNet Blogs | Microsoft Docs
Archived MSDN and TechNet Blogs 2/7/2020 2 minutes to read MSDN and TechNet blog sites have been retired, and blog content has been migrated and archived here. Archived blogs are grouped alphabetically by the initial letter of the blog name. Blogs and blog posts can be searched by their names, using the Search box at the top of the page. Actively updated blogs have been moved to other blog sites,
DB移行の7つのステップ
データベース移行ではどのような作業を行わないといけないのか？全体的な流れを俯瞰的に見なければ、作業の見積もりなどが難しいことだろう。というわけで、今日はデータベース移行時に必要になる作業について7つのステップに分けて紹介しようと思う。言うまでもないことであるが、移行時には既存システムを直接いじるわけではない。（稼働中のシステムを直接いじるのは、走ってるクルマに乗り込むのと同じぐらい危険な行為である！！）開発用のシステムを別途用意して作業を進めるという前提で読んで欲しい。 1. データベース構築まずは何はともあれ新規データベースを構築することである。MySQLであれば典型的な構成にしておけばそれなりに高速に動作するので、細かいチューニングは後で問題が出てからやれば良い。my.cnfはインストールディレクトリの下のsupport-filesディレクトリにあるものを弄ってもいいし、MySQL P
いよいよSSD元年:Kenn's Clairvoyance
CNETのパネルディスカッションで「2009年のIT業界、注目株は何ですか？」というお題をもらったところ、長くなりそうだったのでこちらに。 今年はいよいよNANDフラッシュベースの記憶デバイスがブレイクしそうです。2008年はSSDがHDDに代替しうるというプルーフ・オブ・コンセプトが示された年でしたが、今年こそは価格性能比が接近・交差し、本格的な普及期に入るのではないかと見ています。 今までSSDといっても実効速度ではHDDとあまり変わらないイメージでしたが、今後ExtremeFFSなどの登場によってその差は10-20倍へと拡大し、ボトルネックはインターフェースへと移っていくでしょう。そのあたりの課題がクリアされてくれば、いずれ100-200倍の達成も夢ではなさそうです。ムーアの法則は健在ですね。 また、あっという間に32GBというSDHC規格の最大容量に達してしまったSDカードに、SD
データベースコンサルタントのノウハウちょい見せ クラウドやマルチコアでの将来のボトルネックはきっとロック処理でしょう。コーディングが変わるかもしれません！？
各種インフラ技術(OS、ストレージ、ネットワーク)やオラクル製品といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります 「私はOSとストレージとネットワークに興味がある」という割には、そういう話題を書いていませんでした。今日はOSをテーマとして、将来のボトルネックという話を書いてみたいと思います。今回は難しい内容を簡単に説明できていないので、「分からなかった」というコメントが届いたら、丁寧に書き直したいと思います。 さて、「分散メモリー」という技術があります。いいですよね。クラウドコンピューティングは将来バラ色に見えます。 マルチコア化(クアッドだけではなく、8コアとか)も、いいですね。どんどん性能が上がるように思えます。 ここで質問です。クラウドコンピュー
DBMによるテーブルデータベース - mixi engineer blog
正月早々インフルエンザにかかって寝込んだmikioです。電車に乗る時や繁華街などに出る時はマスク着用が必須ですね。さて今回は、Tokyo Cabinetで実装したテーブル方式のデータベースについて紹介します。意外にどうして強力な機能なので、このネタは連載することを予告します。 テーブルデータベースとは 簡単に言えば、リレーショナルデータベースのテーブルのように、複数の列からなるレコードを格納できるデータベースです。SQLや表結合などの複雑な機能はサポートしませんが、そのぶん高速に動作します。つまり、DBMの速度で動くリレーショナル風データベースです（厳密にはリレーショナルデータベースではありません）。 TCの基本となるハッシュデータベースは、単純なkey/value型のデータベースであり、つまりキーにも値にもスカラ（数値や文字列などの特に構造を持たない単一の値）しか格納することはできません
Top 5 Database Research Topics in 2008
岡野原君が自然言語処理関連で2008年に読んだ論文のベスト5を紹介しています。それに倣って、僕も個人的にインパクトのあった2008年のデータベース研究のベスト５を集めてみました。 Michael J. Cahill, Uwe Röhm and Alan D. Fekete. Serializable Isolation for Snapshot Databases. SIGMOD 2008. (ACM DOI) 真っ先に思い浮かんできたのがこの論文。SIGMOD2008のベストペーパーでもあります。僕自身、トランザクション処理を長く研究していた経験から、Serializability（ディスクのread/writeの順番をあるプロトコルに従って入れ替えても、データベースの検索・更新結果に影響を与えない）を保障しつつ、一秒間あたりに処理できるトランザクションの数（つまりスループット）を上げる
ローデバイスはもう（ほとんど）必要ない | Unofficial DB2 BLOG
(サマリ)最近のDB2を利用しているなら、ローデバイスを使用する必要はほとんどないですよ ※2008/09/16更新：デフォルトでファイルシステムキャッシュを使用しなくなったのは、正しくはv9.5からでしたので修正しました。またコメントで質問をいただいたので具体的な指定方法を追記しました。 もしあなたが比較的新しいバージョンのDB2を使用していて、ローデバイス(Raw Device)の利用を予定しているなら、再考される事をお勧めします。 まずローデバイスとは何でしょうか。通常、ディスク装置を使用する場合はNTFSやJFS、EXT3といったファイルシステムを作成した上で使用しますが、ローデバイスは、Raw(生の)という名前にあるようにファイルシステムを介さず、ダイレクトにデバイスにアクセスする方法です。Unix/LinuxやWindowsで利用可能です。 多くの商用RDBMSはローデバイスを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
cahill.net.au » Blog Archive » SIGMOD 2008 repeatability