『【研究課題レポート】MySQL ストレージエンジン性能比較』
１．３ 今回の検証に利用するサービス ブログ(mobile)のログイン管理用とスキン情報のデータベースを利用 １．４ 使用するDBの詳細情報 DB構成 Master：1台 Slave：3台 ブログモバイルで2台 その他サービスで1台 各データ件数 モバイル登録ユーザー及びログイン情報：役2,000,000件 総スキン数：155件 スキン適用ユーザ数：約1,100,000会員 ピークタイム時のSQL発行回数(Slave1台あたりの発行回数) ブログモバイルのみ Select：58,000/分程度 ブログモバイル以外のサービス Select：20,000/分程度 以下は共通 Insert：60/分程度 Update：900/分程度 Delete：10/分程度 １．５ 使用するベンチマークツール super-smack-1.3 ベンチマークで使用するSQLの内容ログイン状態チェックSQL 1件問
Solution Selling in EMEA
Building Spanner Better clocks → stronger semantics Alex Lloyd Senior Staff Software Engineer How to build a planet-scale serializable database Build clocks with bounded absolute error, and integrate them with timestamp assignment: • Ensure timestamp total order respects transaction partial order • Offer efficient serializable queries over everything Spanner • Descendant of Bigtable, successor to
Micro-Specialization in DBMSes
Overview Micro-Specialization uses relation- and query-specific information to specialize the DBMS code at runtime based on identifying runtime invariant. Runtime invariant is often of the form of variables in code that hold constant values during code execution. Micro-specialization is applied to eliminate from the original program unnecessary code such as branching statements that reference runt
FacebookがHBaseを大規模リアルタイム処理に利用している理由（後編）
Facebookは大規模なデータ処理の基盤としてHBaseを利用しています。なぜFacebookはHBaseを用いているのか、どのように利用しているのでしょうか？ 7月1日に都内で行われた勉強会で、Facebookのソフトウェアエンジニアであるジョナサン・グレイ（Jonathan Gray）氏による解説が行われました。 この記事は、「FacebookがHBaseを大規模リアルタイム処理に利用している理由（前編）」の続きです。 事例1 Titan（Facebookメッセージ） HBaseがFacebookでどのようなアプリケ－ションで使われているのかを紹介しよう。 Facebookの新メッセージ機能。
データベースのスケーラビリティをどうやって向上させるか
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
グーグル、データセンターの障害にも耐えるApp Engineの新データストアを発表。Paxosを採用
グーグルは1月6日、Google App EngineのデータストアとしてPaxos algorithmによるデータセンター間のデータ同期を採用し、可用性を大幅に向上させた新データストア「High Replication Datastore」を追加したと、ブログのエントリ「App Engine 1.4.1 をリリースしました - High Replication Datastore の紹介」で明らかにしました。 App Engine 1.4.1 をリリースしました - High Replication Datastore の紹介 - Google Japan Developer Relations Blog 複数のデータセンターにまたがったレプリケーションを行うことで、特定のデータセンターに障害が発生した場合でもほとんどの場合で問題なく動作するとのことです。 可用性は高まるが書き込みは遅く
Google Megastoreのお勉強メモ #appengine - スティルハウスの書庫の書庫
BrettさんのSTMに関する記事の中でGoogle Megastoreについて言及されていて、そのリンク先がハミルトン先生の2008年7月の記事（内で紹介されていたPhil Bernsteinさんのメモ）でした。つまりどうやらMegastoreに関する公開情報でGooglerのお墨付きなものはこれしかなさそうです。そこで改めて要点を写経しつつ、App Engineレベルから見た疑問点等をまとめてみました。なお、青色部分は私の訳注および感想です。同じ記事について解説したkuenishiさんの記事もありますので、合わせてご参照ください。 ところでここでは「BigTable」表記です。BigtableのTが大文字か小文字かについてguidoは「う〜ん論文ではtだったから小文字じゃないかな〜」と言ってました。つまりGoogle社内でも統一されてません。 Google Megastore What
Google Megastore - 3 Billion Writes and 20 Billion Read Transactions Daily - High Scalability -
A giant step into the fully distributed future has been taken by the Google App Engine team with the release of their High Replication Datastore. The HRD is targeted at mission critical applications that require data replicated to at least three datacenters, full ACID semantics for entity groups, and lower consistency guarantees across entity groups. This is a major accomplishment. Few organizatio
Cassandraデータモデル入門 - Arin Sarkissian - Digital Romanticism
この記事は、Arin Sarkissian氏のブログ記事「http://arin.me/blog/wtf-is-a-supercolumn-cassandra-data-model」を氏の許可を得て翻訳したものです。（原文公開日：2009年9月1日） ここ１、２ヶ月というもの、DiggのエンジニアリングチームはCassandraについて調べ、遊び、最終的にはプロダクションにデプロイするためにかなりの時間を費やしてきました。これは実に楽しいプロジェクトでしたが、楽しくなる前にCassandraのデータモデルについて理解するために相当の時間を費やしたのです。「'super column'って何だよ」というフレーズが何度も口にされました。 もしあなたのバックグラウンドがRDBMSならば（ほとんどみんながそうでしょうが）、Cassandraのデータモデルについて学ぶ際に、いくつかのネーミング規約で
2010 SIGMOD Best Paper Award — ACM SIGMOD Official Website
FAST: Fast Architecture Sensitive Tree Search on Modern CPUs and GPUs Changkyu Kim (Intel Corporation), Jatin Chhugani (Intel Corporation), Nadathur Satish (Intel Corporation), Eric Sedlar (Oracle Corporation), Anthony Nguyen (Intel Corporation), Tim Kaldewey (Oracle Corporation), Victor Lee (Intel Corporation), Scott Brandt (University of California, Santa Cruz), Pradeep Dubey (Intel Corporation)
データベース負荷テストツールまとめ(4) - SH2の日記
データベース負荷テストツールまとめの第4回です。 データベース負荷テストツールまとめ(1) TPC-B、TPC-Wベースのツールを6つ紹介 データベース負荷テストツールまとめ(2) TPC-Cベースのツールを6つ紹介 データベース負荷テストツールまとめ(3) TPC-Hベースのツールを2つ紹介 今回はTPC-Eベースのツールを見ていきたいと思います。 TPC-Eとは TPC-EはRDBMSベンチマーク仕様の一つで、オンライントランザクション(OLTP)の性能を測定するものです。証券会社の業務をモデルとして取引や市場の監視、メンテナンス処理を行い、1秒あたりに行った取引件数を性能の指標値とします。 OLTPのベンチマークとしてはこれまでTPC-Cがよく用いられてきました。しかしTPC-Cは1992年の策定から実に18年が経過しており、その間コンピュータのCPU性能はムーアの法則にしたがって伸
データベースにおけるデータ保護：ログの話 | 独り言v6
前回にも書いたとおりRDBMSの重要な部分にACIDのサポートがあるが、このうちAID、つまり原子性（トランザクションのロールバック・コミットは不可分）、分離性（他のトランザクションの影響を受けない）、耐久性（一旦commitしたトランザクションは意地でも消えない）の３つをサポートするためには重要な、ログの話をしよう。 まず、この３つをサポートすると言うことは以下の３つの機能を持つことに等しいと言える。 トランザクションを完全にロールバックするために、以前のバージョンに戻すことが出来ること。 トランザクション実行中のデータが見えないように工夫できること。 トランザクションのコミット時には、完全にデータが書き込みできるていること。 ただし、「ディスク書き込み途中にクラッシュしても」というのを満たすのは結構難しい。そこで、実現のためには実行前と実行後のデータをログとして残しておく、と言うのが有
独り言v6 » VoltDBは何故早いのかは問題ではない。何をするためのシステムなのかが問題だ
ちょっと小旅行に出ている間にアクセスが伸びていて、おかげさまで前回のVoltDBのエントリが大人気だったようだ。まだまだ書き足りない部分がいっぱいあったので、補足する意味も込めて書き足してみたい。それは、H-Storeが従来型RDBMSとどれほど異なったシステムか、ということだ。インターフェースの話や大まかな話はしたが、前提となる部分の話はずいぶん抜けてしまっていた。 NoSQLを超えるSQLデータベース「VoltDB」。Cassnadraとベンチマーク対決！ で、実際にCassandraと比べて検討している Key-Value Benchmarking という記事が紹介されていて興味深い。で、なおかつ勝っていると言うから痛快だ。まあ個人的にはこの勝負は高々３ノードしか使っていない時点でスケーラビリティに勝るKVSにずいぶん不利な内容だな、と言わざるを得ない。せいぜい12ノードぐらいでしか
Comparing VoltDB to Postgres
I've been asked a few times recently for my opinion on VoltDB, the new database server architected by the 'father' of Postgres, Dr Michael Stonebraker so rather than repeating myself over and over again it seems like a good idea to write it all down. VoltDB is an in-memory, lockless relational database that maintains ACID compliance, has a SQL interface and claims to offer massive performance incr
NoSQL at Twitter (NoSQL EU 2010)
2. Introduction ‣ How We Arrived at NoSQL: A Crash Course ‣ Collecting Data (Scribe) ‣ Storing and Analyzing Data (Hadoop) ‣ Rapid Learning over Big Data (Pig) ‣ And More: Cassandra, HBase, FlockDB 3. My Background ‣ Studied Mathematics and Physics at Harvard, Physics at Stanford ‣ Tropos Networks (city-wide wireless): mesh routing algorithms, GBs of data ‣ Cooliris (web media): Hadoop and Pig for
Errors in Database Systems, Eventual Consistency, and the CAP Theorem | blog@CACM | Communications of the ACM
CACM Web Account Membership in ACM includes a subscription to Communications of the ACM (CACM), the computing industry's most trusted source for staying connected to the world of advanced computing. Sign In Sign Up Recently, there has been considerable renewed interest in the CAP theorem [1] for database management system (DBMS) applications that span multiple processing sites. In brief, this theo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
F1 - The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business(PDF)
Index of /
http://1978th.net/tech/promenade.cgi?id=70
http://1978th.net/tech/promenade.cgi?id=71