HOWS「ISSEI（イッセイ）」
●既存のDB技術と一線を画すデータ検索技術を生み出す ●ゼロベースで発想しOSの基本機能に着目 ●ストップウオッチ片手に高速化を追求 ソフト開発ベンチャーのHOWSが、これまでにないデータ管理・検索技術「ISSEI」を開発した。HOWSは現在、ISSEIを次世代Web基盤技術として特許を出願している。 「ユーザー企業がデータを有効活用するためには、既存のリレーショナルデータベース（RDB）と一線を画す技術を編み出すほかないと考えた」。HOWSのCTO（最高技術責任者）である庄司渉副社長は、ISSEIを開発した思いを語る。 ユーザー企業の多くは現在、社内システムを整備し、テキストや画像、音声などさまざまな種類のデータを大量に蓄積している。その一方で「データを業務に有効活用できていない」と嘆くCIO（最高情報責任者）が多いのも事実だ。 その理由について庄司副社長は、「現在主流のRDBが限界に近
TUM Informatik III: HyPer: Hybrid OLTP&OLAP High-Performance Database System
TU München - Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Summary The HyPer prototype demonstrates that it is indeed possible to build a main-memory database system that achieves world-record transaction processing throughput and best-of-breed OLAP query response times in one system in parallel on the same database state. The two workloads of online transaction processing (OLTP) and onl
What we talk about when we talk about NewSQL — Too much information
Yesterday The 451 Group published a report asking “How will the database incumbents respond to NoSQL and NewSQL?” That prompted the pertinent question, “What do you mean by ‘NewSQL’?” Since we are about to publish a report describing our view of the emerging database landscape, including NoSQL, NewSQL and beyond (now available), it probably is a good time to define what we mean by NewSQL (I haven’
ランキングのつくりかた:Kenn's Clairvoyance
遅ればせながら、あけましておめでとうございます。 先週には、ベイエリアの友人たちがやっているEchofonがPostUpに買収されるなど、幸先のよい新年のスタートとなりました。 さて、最近ホットなマーケットといえばソーシャルゲームですが、ゲームといえばリーダーボード。ハイスコアのランキングで友人や見知らぬ人たちと競うのは、ビデオゲームが誕生した1970年代から欠かせない要素でした。 ところが、インターネット経由で100万人規模のプレイヤーがつながるようになってきた現在、その全体をランキングづけするのは、技術的にも大きなチャレンジとなってきました。 今回は、そのリーダーボードのつくりかたについて、ぼくらの作っているソーシャルゲーム・プラットフォームであるPankiaの運用で得られた知見を共有したいと思います。 自分の順位を知る方法 リーダーボードの基本的な考え方はシンプルで、それはつまり「ユ
ジム・グレイ - Wikipedia
ジェームズ・ニコラス・グレイ（James Nicholas Gray、1944年1月12日 - 2007年1月28日洋上で行方不明となり、2012年5月16日に死亡認定された[4]）は、アメリカ合衆国の計算機科学者。通称はジム・グレイ (Jim Gray)。1998年、「データベースおよびトランザクション処理に関する独創的な研究とシステム実装についての技術的リーダーシップに対して」チューリング賞を授与された[5]。 経歴[編集] カリフォルニア州サンフランシスコ生まれ。母は教師、父はアメリカ陸軍の軍人で、2番目の子である。生まれた直後に一家はローマに移り、3年間過ごしたため、グレイは英語の前にイタリア語を覚えた[2]。その後バージニア州に移り4年間過ごしたが、両親が離婚。母と共にサンフランシスコに戻った[2]。父はアマチュア発明家であり、タイプライターのインクリボン・カートリッジの特許を取
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Seth Gilbert∗ Nancy Lynch∗ Abstract When designing distributed web services, there are three properties that are commonly desired: consistency, avail-
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Seth Gilbert∗ Nancy Lynch∗ Abstract When designing distributed web services, there are three properties that are commonly desired: consistency, avail- ability, and partition tolerance. It is impossible to achieve all three. In this note, we prove this conjecture in the asyn- chronous network model, a
BrewersCapTheorem - ブリュワーの CAP 定理
BrewersCapTheorem - ブリュワーの CAP 定理 目次 この文書について ブリュワーの CAP 定理 - Amazon と eBay のクールエイド ブリュワーの(CAP)定理 一貫性 (Consistency) 可用性 (Availability) 分割耐性(Partition Tolerance) 定理の重要性 図解で証明 CAP と折り合う 1. 分割耐性を諦める 2. 可用性を諦める 3. 一貫性を諦める 4. BASE に跳ぶ 5. 問題をかわして設計する まとめ 参考文献 ブリュワーの CAP 定理 この文書について "Brewer's CAP Theorem - The kool aid Amazon and Ebay have been drinking" の日本語訳です. http://www.julianbrowne.com/article/view
スタースキーマ - Wikipedia
スタースキーマ または 星型スキーマ はデータウェアハウスに利用される最も単純なスキーマである。スタースキーマには唯1つもしくは少数のファクト表と複数のディメンション表が含まれる。スタースキーマはスノーフレークスキーマの一種であるが、多くの用途で利用されている。 モデル[編集] スタースキーマは多次元モデルを表す単純なスキーマである。 ファクト表はデータウェアハウスでの解析で利用され、複数の異なるディメンションに区分される。ファクト表は主要なデータを持つ一方、ディメンション表は相対的にサイズが小さくディメンションのそれぞれの値を表現する。必要に応じて、ディメンション表はファクト表と結合される。 ディメンション表は単純な主キーを持つ一方、ファクト表の主キーは関連するディメンション・キーを組み合わせた複合キーである場合もある。 ディメンション表に冗長なデータを含ませ、第2正規形に留めておくこと
CAP Theorem（定理）
QCon Tokyoでは色々なところで「CAP Theorem」という定理が出てきた。が、eBayの人をのぞけば（たぶん）正確な定義は提示されておらず、不明な点がいくつか残っている。これからのインフラを考える上でも、QConセッションの内容をより良く理解するためにも、このあたりをまずきちんと理解しておきたい。主な疑問点は以下のとおり。 C, A, Pの特性の正確な定義は何なのかCAP定理が前提にしているシステムのモデルはどのようなものなのか Theoremとなっているが、単なる経験則なのか、それとも数学的な定理なのか 頼みの綱？のWikipediaを調べてみたが、日本語版はおろか英語版にも載っていない。概観をまとめた海外の記事を結城さんが訳してくれているようなので、これを読んでみる。 CAP Theoremそのものは、Eric BrewerがPODCカンファレンスのキーノートで提唱したもの
EventuallyConsistent - 結果整合性
EventuallyConsistent - 結果整合性 目次 この文書について 結果整合性 歴史の話 クライアント側の整合性 サーバ側の整合性 まとめ 結果整合性 この文書について Werner Vogels "Eventually Consistent" の日本語訳です. http://www.allthingsdistributed.com/2007/12/eventually_consistent.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... 近年, データ複製の文脈で 結果整合性(eventual consistency) に関する議論が盛んだ. この記事では大規模データの複製における原則や抽象, 高可用性とデータ整合性のトレードオフに関する話題をいくつか集めてみたいと思う. 現在進行中の分野であり, 全ての定義が最初から明快であるとは思わないでほ
Kyoto Cabinet 1.0.0リリース！ - mixi engineer blog
夏が近づくとウキウキしてくるmikioです。昨日ついにリリースされたKyoto Cabinet 1.0について今回は報告します。 1.0の位置づけ コミュニティ毎や製品毎にバージョン番号割り当ての方針は異なるわけですが、私の個人的なポリシーでは、1.0には特別な意味があります。すなわち、0.xのバージョンはbeta版的な位置づけで、「実サービスに使うのはちょっと待った方がいいですよ」ということを意味します。一方で、1.xはstable版的な位置づけで、「よろしければ実サービスでも使ってみてください」ということを意味します。私がstable版に設定する原則を以下に列挙します。 安定稼働を至上命題とする（バグがあればその修正を最優先する） APIを変更しない（変更するとしても後方互換性を維持する） DBファイルのフォーマットを変更しない（変更するとしても後方互換性を維持する） なるべく機能追加
ETLとは - IT用語辞典
概要 ETL（Extract/Transform/Load）とは、データベースなどに蓄積されたデータから必要なものを抽出（Extract）し、目的に応じて変換（Transform）し、データを必要とするシステムに格納（Load）すること。また、ソフトウェアの持つそのような機能。 一般的にはデータウェアハウスを構築する際に外部のデータベースや何らかの情報源からデータを取り出して必要な形式に整えて保存することを指す。このような処理を行う専門のソフトウェアや拡張機能をETLツールという。 抽出元となるのは業務システムに日々蓄積されていく様々な種類や内容、形式のデータで、ETLツールは様々なシステムに対応できるよう、リレーショナルデータベース（RDB）やCSVファイル、表計算ソフトのデータファイル、XMLファイル、ログファイル、テキストファイルなど多様なデータ形式を読み込めるようになっている。 変
RRDtool - The Time Series Database
What RRDtool does RRDtool is the OpenSource industry standard, high performance data logging and graphing system for time series data. RRDtool can be easily integrated in shell scripts, perl, python, ruby, lua or tcl applications. News For the latest news regarding RRDtool, check the Announcements Mailinglist Archive. Or add our Facebook and Google+ pages. Download RRDtool is available for downloa
独り言v6 » SSD時代になってRDBMSの逆襲はあるか ー ReThinkDBの試みを読み解く
今日も突然TwitterでRDBMSとNoSQL周りの会話に若干巻き込まれたわけだけど、実際にどっちが勝つのかの帰結を予測するのは非常に難しい。 NoSQLのスケーラビリティと可用性は大変素晴らしいし、オブジェクト指向言語との相性もO/Rマッピングに比べれば抜群によい。しかし一方で、SQLと言う言語とその実装には癖があるとはいえ、RDBMSで実現できる柔軟性は捨てがたいし、ACIDが保証されているし、既存資産が流用できることも大きい。ポイントはそのACIDがどれだけ重要であるかということと、性能面だろうと思っている。つまりNoSQLでないとコストメリットが出ないほど大規模であればNoSQL優勢、そうでない部分はRDBMSで、ということだ。あまりに普通で失望した、と言われそうだが。 まあそれはおいておいて、最近RDBMSの性能を後押しするだろうと考えられている存在が、マルチコアCPUとSSD
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Concurrency Control and Recovery in Database Systems - Microsoft Research
ソーシャルゲームのためのデータベース設計
Amazon.co.jp: トランザクション処理 上: ジムグレイ, アンドレアスロイター: 本
GitHub - twitter-archive/gizzard: [Archived] A flexible sharding framework for creating eventually-consistent distributed datastores![GitHub - twitter-archive/gizzard: [Archived] A flexible sharding framework for creating eventually-consistent distributed datastores](https://cdn-ak-scissors.b.st-hatena.com/image/square/2db2051dcceeb069e3f99113b5c4df2bd582bd9f/height=288;version=1;width=512/https%3A%2F%2Fopengraph.githubassets.com%2Fa47bf8ff854e29b84d4885718b5bc0c9d061a6f5ae3f09346bd98dbadd3da437%2Ftwitter-archive%2Fgizzard)
Drizzle - A database for the cloud
Graph Databases, NOSQL and Neo4j