Datastoreのtips - スティルハウスの書庫の書庫
Datastoreのパフォーマンス Datastoreのパフォーマンスは、エンティティの数とは無関係 保存されているエンティティが1件でも、1000件でも、1000万件でも、パフォーマンスに変化はない Datastore performance doesn't depend on how many entities you have 個々のエンティティに対する更新処理のスピードは、1〜10回／秒程度 個々のエンティティの更新処理は遅い アプリケーションのパフォーマンスを決めるのは、更新処理の実装方法。参照処理は桁違いに速い low-level APIを使えば少し速くなるが、ドキュメントがあまりない http://groups.google.com/group/google-appengine-java/browse_thread/thread/e717f7ba37749ea4/0b37a3
Erlang による Skip Graph の実装 - kyeeva blog!
参考： Skip Graph の論文 http://www.cs.yale.edu/homes/aspnes/skip-graphs-journal.pdf ソースコードはこちら Skip Graph in Erlang · GitHub 特徴 ・Erlangによる完全なSkip Graphの実装 ・複数マシンを利用してスケールアウト可能 ・boot/4関数内のLevel_Maxの値を大きくすることにより、Levelの階層を増やすことができる ＝＞ スケールアウトしてエントリ数が増えても、検索効率が落ちない ・keyにatomを指定することもできるので、柔軟な範囲検索を行うことができる ・コードの行数は200行未満 実際の動作（Erlangを知っている人向け） 起動(分散) <ノードjohn@asus> $ erl -sname john Eshell V5.7 (abort with ^
Beyond Filesystems
Historically, I’ve been a bit of a filesystem purist. If somebody called something a filesystem that wasn’t fully integrated into the kernel so that any application could transparently read, write and even map files within a familiar hierarchical directory/file structure, or if it didn’t support consistency at least as good as NFS (preferably better) I’d be quick to correct them. I’d say that what
Kazuho@Cybozu Labs: Pacific という名前の分散ストレージを作り始めた件
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名：アプリケーションレベルパーティショニング／レベル２分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加（とそれにともなう負荷の再分散）が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
Some Notes on Distributed Key Stores
random($foo) is the occassionally still updated blog of Leonard Lin. My pics are on Flickr, code is on Github. @lhl on Twitter. More » Last week I ended up building a distributed keystore for a client. That wasn’t my original intention, but after doing testing on just about every project out there, it turned out to be the best (only?) solution for our needs. Specifically, a production environmen
Initial Release of Moneta: Unified Key/Value Store API
I'm happy to announce the (very) initial release of a new library called moneta, which aims to provide a unified interface for key/value stores. The interface mirrors the key/value API of hash, but not the iteration API, since iteration is not possible across all key/value stores. It is likely that a future release will add support for enumeration by keeping a list of keys in a key (very meta :P )
第1回 Kaiとは？ ─Kaiのコンセプトとメカニズム | gihyo.jp
今回から数回にわたり、Kaiという分散Key/Valueストアについて解説させていただきます。 まず、第1回では井上がKaiのコンセプトをご紹介します。次回以降は、Kai開発者の一人である幾田さんがKaiの利用方法について解説します。最終回では、gooホームでKaiを運用している橋本さんから、Kaiの運用方法について紹介していただく予定です。なお、本連載が対象とするKaiのバージョンは0.4です。 Kaiとは Kaiとは、分散型のKey/Valueストアです。Amazon.comが2007年に発表したDynamoというシステムに触発されて、そのオープンソース版として開発されています。Kaiをバックエンドに据えてWebサイトを構築することで、高いスケーラビリティやアベイラビリティを実現できます。2009年5月には、gooホームのバックエンドに導入され、運用実績も高まってきました。 Kaiは多
Cloudera Blog
In an era where artificial intelligence (AI) is reshaping enterprises across the globe—be it in healthcare, finance, or manufacturing—it’s hard to overstate the transformation that AI has had on businesses, regardless of industry or size. At Cloudera, we recognize the urgent need for bold steps to harness this potential and dramatically accelerate the time to […] Read blog post
知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey
セールスフォースが採用しているマルチテナントアーキテクチャでは、すべてのユーザーが同一データベース、同一スキーマを共有しています。 では、個別に入力項目を増やすようなスキーマの変更を伴うアプリケーションのカスタマイズや、新たなテーブルを作成してそこに独自データを保存するようなアプリケーションの新規作成はできないのか？ といえば、そんなことはなく、セールスフォースが提供するプラットフォームの上で、自由に項目の追加や新しいテーブルの作成が可能です。 全ユーザーでスキーマを共有しながら、しかし個別のカスタマイズを許容する。この一見矛盾する要件を、セールスフォースはどのように実現しているのでしょうか？ （本エントリは「知られざる『マルチテナントアーキテクチャ』（2）～スケーラビリティのカギは組織ID」からの続きです。） 公開されているスキーマを見てみる ユーザーがスキーマを変更したり、新規テーブル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Chimera, a Structured Peer-to-Peer Overlay
『はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知』へのコメント
moved
GREE Engineering