筑波大学でデータベースの話をしてきました - kuenishi's blog
筑波大学の川島先生に呼ばれて木、金と情報システム特別講義Dというやつに参加してきた。こんなことになるとは思っていなかったが、あろうことか講師側で呼ばれてしまい、思えば遠くへ来たものだと感慨深い。フリは「RiakとNoSQLの話をしてもらえたら」という非常に自由度の高い内容なので、せっかくなので僕の知っていることを全部詰め込んで話してやろうと思ったら10分延長してさらにスライド10枚分くらいを消化不良で終了という、みっともない感じになってしまった。かなり端折ってポイントだけ説明したので流れが分からず苦労した方も多いと思うが、まあ僕の性格なので許してほしい。データベースの講義をひと通り終えた院生レベルを想定してスライドを作ったので、もしかすると、わりと難しかったり分かりにくかったりするかもしれないので、わからないことがあったら適当に質問してください。 言いたかったことの流れを僕なりにまとめると
HAT, not CAP: Introducing Highly Available Transactions | Peter Bailis
Peter Bailis :: Highly Available, Seldom Consistent Data management, distributed systems, and beyond HAT, not CAP: Introducing Highly Available Transactions 05 Feb 2013 tl;dr: Highly Available Transactions show it’s possible to achieve many of the transactional guarantees of today’s databases without sacrificing high availability and low latency. CAP and ACID Distributed systems designers face har
高速なトランザクション処理をうたうSQLデータベース「VoltDB 3.0」リリース | OSDN Magazine
米VoltDBは1月22日、リレーショナルデータベースシステム「VoltDB 3.0」を公開した。クラスタ環境におけるトランザクション処理アーキテクチャの改善により、さらに低遅延を実現するという。 VoltDBは、「Postgres」や「Ingres」などのデータベースプロジェクトを手がけたMichael Stonebraker氏が設計したデータベース。高速なトランザクション処理を特徴とし、ACIDに遵守した次世代のリレーショナルデータベースを標榜している。GPLv3で公開するオープンソース版（Community Edition）と、サブスクリプション形式の商用版（Enterprise Edition）の2つがリリースされている。 バージョン3.0は2011年9月にリリースされたバージョン2.0以来のメジャーリリース。性能側では、トランザクションのアーキテクチャを再設計し、クラスタにおける
When is "ACID" ACID? Rarely. | Peter Bailis
RC: read committed, RR: repeatable read, S: serializability, SI: snapshot isolation, CS: cursor stability, CR: consistent read Instead of providing serializability, many these databases provide one of several weaker variants,2 often when marketing material and documentation claim otherwise.3 There is no fundamental reason why a database shouldn’t support serializability—we have the algorithms, and
FoundationDB | Home
FoundationDB gives you the power of ACID transactions in a distributed database.Get StartedDownload FoundationDBMulti-model data store. FoundationDB is multi-model, meaning you can store many types data in a single database. All data is safely stored, distributed, and replicated in the Key-Value Store component.Easily scalable and fault tolerant. FoundationDB is easy to install, grow, and manage.
12年後のCAP定理: "法則"はどのように変わったか
設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FoundationDBの共同創立者Nick Lavezzo氏へのインタビュー