ドットインストール代表のライフハックブログ
DHTについては下記参照 DHTについて - WebLab.ota DHTのアルゴリズム - WebLab.ota DHTの比較図 - WebLab.ota Google File System pure p2pじゃない どっちかっていうと,winMX 単一のマスターノードがファイルの位置とかを知ってる クライアントは,検索したいときマスターノードにファイルの位置を聞く マスターノードがファイルの位置(チャンクサーバのアドレス)を返す クライアントがチャンクサーバが通信してファイルのやり取りをする データの一貫性は無視 dfltweb1.onamae.com – このドメインはお名前.comで取得されています。 世界中のWebのページを格納するには巨大な容量のファイルシステムが必要となりますが、彼らはそれを自分たちで、Scale-outする分散ファイルシステム Google File Sy
scale outの技術 首藤 一幸 Last-updated: January 5, 2010 注: このページの文章は以下の記事の元原稿です。 首藤一幸, "スケールアウトの技術", クラウドの技術, pp.88-101, (株)アスキー・メディアワークス, ISBN978-4-04-868064-6, 2009年 11月 6日 アスキー・メディアワークス社の 書籍紹介ページ Amazon.co.jp の ページ 首藤一幸, "スケールアウトの技術", UNIX magazine 2009年 4月号, pp.78-91, (株)アスキー・メディアワークス, 2009年 3月 18日 データベースに求められる性能を試算したところ、 十台、百台…数万台のサーバが必要になった。 クラウドを構築する側はこういう問題に直面し、解決しようとしてきた。 台数に比例した性能を引き出すこと、つまりsca
はじめに 本連載ではクラウドコンピューティングで利用される分散データベースの技術について紹介しています。第1回はクラウドコンピューティングの技術について概説し、その環境に対応するための新たな分散データベースの必要性について述べました。 今回はクラウド向け分散データベースの具体的な事例として、Googleの「BigTable」とAmazonの「Dynamo」について紹介したいと思います。少し耳慣れない言葉も出てくるかと思いますが、最後までお付き合いいただけると幸いです。 一般にハイスループット(高効率)とローレイテンシー(低遅延)がトレードオフの関係にあることはよく知られていますが、クラウドシステムもその例外ではありません。これらは最近でも、クラウド技術のシステム特性を理解する上で欠かせないトピックですが、分散データベースに関しては、ハイスループット重視のBigTableに対し、ローレイテン
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
SetsunaのVersion-0.0.2をリリースしました。 Github Sourceforge.jpダウンロードページ 今回のリリースで一番大きな追加機能はServerモードの追加です。 0.0.1の時は、Setsunaにデータを入れる方法はパイプ入力しかなかったので、 コマンドラインで何かの出力をパイプでSetsunaに繋ぐしかなかったので、 Setsunaが動いているサーバ以外からデータをSetsunaに流せなかった のが不便でした。そこでNetWork越しにデータを流せるようにこの機能を追加しました。 起動方法は簡単で"-server true"という表記を付けるだけです。ただServerモードの 場合はsetsuna.jar内に含まれないライブラリにも依存しているので従来の-jar指定での 起動は出来なくなっています。以下が起動サンプルです。 java -classpath
■Memcacheプロトコルに一部対応 KVSの標準プロトコルになりつつある、memcacheのプロトコルに対応するモードを追加 リリース物okuyama-0.5.2.zipないのclasses/MasterNode.propertiesの 14行目"MasterManagerJob.Option="を"MasterManagerJob.Option=memcache"とすると memcacheプロトコルでアクセス可能である。 classes/MasterNode2.propertiesがmemcache用の設定ファイルになっている。 execMasterNode2.batを実行するとmemcacheプロトコルで立ち上がる。 対応メソッドはsetとgetである。またset,getのflagは0のみ対応している。 今後対応範囲を増やす予定。
株式会社ミクシィの前坂です。第1回でmemcached 1.4の簡単な紹介をしました。今回は新しく正式導入されたバイナリプロトコルの扱い方をご紹介いたします。 バイナリプロトコルの扱い バイナリプロトコルを扱うには、アプリケーションのプログラミング言語に合ったバイナリプロトコル対応のクライアントライブラリが必要です。バイナリプロトコルは最近導入されたこともあり、ネイティブ対応していると報告されているクライアントライブラリはC言語のlibmemcachedとJavaのspymemcachedだけです(2009年8月時点)。ただし、世の中にはlibmemcachedをwrapした、さまざまの言語で記述されたクライアントライブラリがいくつかあり、それらを使ってバイナリプロトコルを扱うことが可能です。 今回の記事ではそれらのクライアントも含めて, C、Java、Python、PHPでのデモコー
※ memcachedプロトコルの仕様書は以下にあります。 http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt データの保存を行うコマンド(set,add,replace,append,prepend)は、以下のような文法となります。 <コマンド> <key> <flags> <exptime> <bytes> <data> <key>は保存するためのキー名を指定します。実装によっても異なりますが、最大長は250byteです。 <flags>はアプリケーション特有の32bitの値(0〜4294967295)を指定することができ、データの取得時に格納した時の値が返されます。 <exptime>はデータの有効期間を秒数で指定します。指定した時間経過すると、自動的にキーが削除されます。0を指定すると自動削除され
Cassandra Wiki Cassandraは、非常に高いスケーラビリティーを持ち、イベンチュアルコンシステントな分散システム構造のKVS(Key Value Store)です。 Cassandraは、主にBerkeley DBとMySQLから構成されるAmazon Dynamo (PDF)の分散ハッシュテーブル(DHT)と、Google BigTable (PDF)のデータモデルという分散システムのテクノロジーを併せ持っています。 Amazon Dynamoのように、Cassandraはイベンチュアルコンシステントであり、Google BigTableのようにCassandraは典型的なKVS(Key Value Store)より豊かなカラムファミリーベースのデータモデルを提供します。 Cassandraは、2008年7月にFacebookによってオープンソースとして公開されました。
Cassandra について - Presentation Transcript CyberAgent ND Tech Talk Cassandra Suguru Namura CyberAgent, Inc CyberAgent ND Tech Talk コンテンツ • Cassandra とは • Cassandraの技術 • パフォーマンステスト • まとめ • おまけ CyberAgent ND Tech Talk CASSANDRA とは Overview of Cassandra CyberAgent ND Tech Talk Cassandra • 悲劇の予言者 http://en.wikipedia.org/wiki/Cassandra_%28metaphor%29 CyberAgent ND Tech Talk 大規模かつ構造化されたデータの スケールゕウトが可能で 中央
Error message : Directory is not found or not writable (DATA_DIR) Directory is not found or not writable (DIFF_DIR) Directory is not found or not writable (BACKUP_DIR) Directory is not found or not writable (CACHE_DIR) Site admin: whitestar Copyright © 2006-2023 whitestar. All Rights Reserved. Icons powered by famfamfam. PukiWiki 1.5.0 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL
前回でCassandraへのアクセスするコードの基本をおさえました。今回解説するのは以下の2点です。 CassandraのAPIの全体像 Cassandraにデータを投入するコードの詳細 3つの分類からAPIの全体像をおさえる 第1回でもご紹介しましたが、CassandraのクライアントAPIはThriftによって自動生成されます。APIは非常にシンプルなものが幾つかあるだけで、覚えるのもさほど難しくはありません。本連載ではその中からよく使うものに特化してご紹介していきます。 以下にCassandraのAPIを、データ挿入系・データ検索系・認証/管理系の3つに分類してまとめてみました。まずはこれらにひと通り目を通してみてください。 データ挿入/更新/削除のAPI データ挿入、更新、削除のAPIは以下の表のとおりです。現実的によく使う中心的なAPIはbatch_mutate、removeの2
キースペース、カラムファミリの設定は以上です。 他にも、レプリケーション数やレプリケーションをどのように行うかなどの指定がありますが、今回は割愛します。 コミットログとデータディレクトリを設定する 次はコミットログとデータディレクトリの設定を行います。 Cassandraは、書き込み時には操作をすべてコミットログに追加で書き込んでいき、その実体(Memtableといいます)はメモリ上にカラムファミリごとに展開していく仕組みになっています。Memtableはサイズの閾値等をもっており、その閾値に達するとディスクに書き出します。この操作のことを「フラッシュ」といい、ディスクに書き出す構造のことを「SSTable」といいます。SSTableは一度書き出されるとその内容は不変で、実際の物理データとしては以下の3つがセットで書き出されます。 インデックス ブルームフィルタ データファイル インデック
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く