Talk on the underlying implementation details of InfluxDB. Talk given in SF the week of 04/04/14.
![The Internals of InfluxDB](https://cdn-ak-scissors.b.st-hatena.com/image/square/527e29f4200e010f6fd97b9866115a4c19ecc5a0/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fee2774a0a08c0131f6cc2abc05ca10ad%2Fslide_0.jpg%3F2819162)
Your application has gotten big, you know you need to start scaling horizontally. You can't afford downtime because competition is tight and users will jump ship if they have a bad experience, but you also can't sacrifice the rapid development process you're used to. You're looking at scalable NoSQL databases like Riak, but the key-value model is too difficult, especially when you have to deal wit
本コンテンツは、2014年1月30~31日に筑波大学で開講された「情報システム特別講義D」における講義「Inside PostgreSQL Kernel」の内容を再構成、加筆・修正したものです。 はじめに 本コンテンツについて 本コンテンツへのフィードバックについて アーキテクチャ概要 PostgreSQLの構成要素 PostgreSQLの基本的なアーキテクチャ SQL文の処理される流れ トランザクション管理 トランザクション処理におけるACID特性 各レコードの可視性の管理 Atomicity(原子性)の実装 Consistency(一貫性)の実装 Isolation(分離性)の実装 トランザクション分離レベルの定義 Durability(永続性)の実装 チェックポイント メタデータ管理 pg_controlファイル OID/XID/TID システムカタログ MVCCとストレージ構造 テ
riakのhandoffについて調べたこと¶ source code readingに向けて、riakのhandoffについて詳細を調べることとし ました。 というか、処理の流れをだいたい把握するために、自分のためにまとめたもの ですので、たぶん他の人には役に立たないと思います。 handoffについて¶ ring_updateが呼び出され、ringが更新されるとnodeの再配置が起こりますので、 各vnodeが担当しているringの範囲も変わってくるわけです。それに伴い、各 vnodeが持っている実際のデータを新しい担当vnodeに対して送る必要がありま す。これをhandoffと言います。 処理の流れ¶ riak_core_vnode_manager:schedule_management_timer/0 send_afterでタイマーがセットされ、management_tickごとに
Apache Phoenix enables OLTP and operational analytics in Hadoop for low latency applications by combining the best of both worlds: the power of standard SQL and JDBC APIs with full ACID transaction capabilities and the flexibility of late-bound, schema-on-read capabilities from the NoSQL world by leveraging HBase as its backing store Apache Phoenix is fully integrated with other Hadoop products su
敬称略的な 1日め 永安 悟史 (アップタイム・テクノロジーズ) Inside PostgreSQL Kernel 星野 喬 (サイボウズ・ラボ) 10分で分かるデータストレージ 10分で分かるLinuxブロックレイヤ 10分で分かるバックアップとレプリケーション WalBの紹介 油井 誠 (産業技術総合研究所) 並列データベースシステムの概念と原理 佐藤一憲 (Google) Googleクラウドが実現する大規模並列クエリサービス (資料?) 2日目 小沢健史 (NTT) 分散処理基盤 Hadoop/MapReduce 中川 真宏 (Treasure Data. Inc) Treasure Data Technologies 田籠 聡 (LINE) Retrospection / prospection and schema Norikra in Action 上西 康太 (Basho
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
One of the notable features of Amazon's 2007 Dynamo paper was the use of vector clocks for conflict resolution. However, the two most prominent systems designed by engineers who worked on Dynamo -- Cassandra and DynamoDB -- both avoid the use of vector clocks in favor of finer-grained updates. To understand why, let's first look at the problem that vector clocks solve. Resolving conflicts with vec
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
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い!!絶対にだ!!」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く