ジョインが70倍高速で、Memcached API搭載の「MySQL Cluster 7.2」正式版が登場
米オラクルは、オープンソースのデータベースとして普及しているMySQLをクラスタ化して利用するためのソフトウェア「MySQL Cluster 7.2」の正式版を公開しました。 GPLに準拠したオープンソース版と同時に、管理ツールを同梱し、24時間365日のサポートも行う商用版の「MySQL Cluster Carrier Grade Edition」も同時に公開しています。 ジョインが70倍高速に MySQL Cluster 7.2の最大のポイントは、ジョインが高速になったことです。これまでクラスタでのジョインは、ジョインするテーブルのデータがクラスタ内のノード間をいちいち飛び交っていたため、複雑なジョインになるほど遅いものになっていました。 MySQL Cluster 7.2で採用されたAdaptive Query Localization（あるいはPush Down Joins）と呼ば
4億個・70TB保存実績ありの分散オブジェクトストレージシステム「STF」無料のオープンソースとして公開
livedoor Blogなどのサービスで実際に大量の画像データ管理・保存に使用され、「高価な専用ストレージを使用することなく安全、高速に大量のデータを保存・参照することが可能になります。またSTFは既存のオープンソース技術で作られているため専用ストレージに比べ運用に際して新たなノウハウを学習する必要がありませんので、運用にかかるコストが低くなります」というなかなかよさそうなストレージシステム「STF」が公開されました。ライセンスは「Artistic License2.0」です。 livedoor ラボ「EDGE」 開発日誌 : 分散オブジェクトストレージシステム「STF」公開のお知らせ - livedoor Blog（ブログ） http://blog.livedoor.jp/edge_labs/archives/1609981.html 開発までの経緯は以下のようになっています。 以前
NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ／秒を実現
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか？ それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範（まつのぶよしのり）氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」（英語）をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
最速KVS研究第一弾（memcached/Tokyo Tyrant/Kyoto Tycoon） - なぜか数学者にはワイン好きが多い
TokyoとKyotoについては，オンメモリ・ディスクベースの両方を測定しましたが，memchacedが最速でした．強し！ memcachedとTokyo Tyrantについては，いわゆるmemcachedプロトコルが使えるので，memcachedプロトコルでsetとgetをしました． プログラムはやはりC言語バインディングが最速だろうということで，こんな感じです． #include <libmemcached/memcached.h> #include <stdio.h> #include <string.h> #include <stdlib.h> #include <time.h> #include <sys/types.h> #include <md5.h> #include <omp.h> void set_key_val(MD5_CTX *con, int seed, char
開発メモ
前回の記事にて、Kyoto Tycoonでメッセージキューを実現する方法について述べた。今回は、それを実運用にて使いやすくするための諸機能について説明する。みんな大好きなmemcachedプロトコルでメッセージキューを実現してみよう。 ジョブキューとメッセージキュー どうでもいい話ではあるが、ジョブキューおよびメッセージキューという用語はよく混同して使ってしまう。俺定義では、ジョブキューは「ジョブ管理機能」という目的をたまたまキュー構造に基づいて実装しているものであり、メッセージキューはキュー構造に基づく非同期メッセージング機構であって用途は特に限定しない。つまりメッセージキューをジョブキューを実装するのに使うこともあるが、それ以外の用途にもメッセージキューは使われる。またジョブキューをメッセージキューに基づかないで同期的に実装することもできる。 きっと偉い学者さんがどこかでちゃんとした定
memcachedプロトコルCAS操作について
カテゴリー DX (2) 一般 (58) 研究会 (6) 働き方 (4) 技術 (349) Edge AI (2) Edge Computing (12) Erlang (1) FIWARE (2) Fog Computing (9) Infiniband (31) Internet of Things (32) Key Value Store (17) Linux (3) Linux KVM (10) Machine Learning (2) RealTime Web (14) Webサービス (42) インフラ (7) コンテナ (3) ストレージ (92) データセンター (7) データベース (47) データ流通 (6) テレプレゼンス (2) ネットワーク (214) 仮想化 (110) 災害コミュニケーション (26) 空間情報 (30) 量子コンピューティング (3) 教育
第4回 memcachedのCASとmixiでの運用動向 | gihyo.jp
今まで簡単に触れてきたmemcachedのCAS（Compare and Swap）機能ですが、今回はその具体的な使用例や、プロトコルの違いによる特徴を紹介します。また、mixiでの今後のmemcached運用動向を紹介します。 CASの概要 memcachedには特定のデータに対してアトミックな更新を試みる機能が存在します。この機能の仕組みは単純で、クライアントは特定のコマンド（テキストプロトコルの場合は“gets”）を実行することにより、サーバから特定のレコードとその状態を表すユニークな識別子を与えられます。 この識別子はレコードが何らかの手段によって更新されると変更され、クライアントが保持している識別子とは別の値になります。したがって、クライアントは与えられた識別子を更新命令と一緒に送信することで、サーバはレコードをアトミックに更新できるかを確認することができます。もし識別子が
ウノウラボ Unoh Labs: リビドーに赴くままlibmemcachedをPHPから使ってみる
Keita です。 浴衣姿の女性は人類の宝だと思います。 さて、phpのpeclのmemcache'd'ってご存知でしょうか。 長い歴史をもつpecl memcache(名前近過ぎだ）はその拡張の中でmemcachedプロトコルの実装をしていますが、pecl memcachedはlibmemcahcedにその実装を依存を任せています。 利用するときの違いとしては memcache: インストール時に他のライブラリに依存しない 長いこと使われてるライブラリなので安定性はある memcached memcacheよりも利用できる機能が多い 今後もプロトコルの拡張があったときにlibmemcachedに追従するだけなので対応が早いことが予測される という点が挙げられます。(まだまだ一杯ありますが・・） memcacheよりも利用できる機能が多いというのはかなり大きく、具体的に言うと、set時に
memcachedを知り尽くす 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
libMemcached
libMemcached is an open source C/C++ client library and tools for the memcached server (http://danga.com/memcached). It has been designed to be light on memory usage, thread safe, and provide full access to server side methods. libMemcached is designed to provide the greatest number of options to use Memcached. Some of the features provided: Asynchronous and Synchronous Transport Support. Consiste
Memcacheでスピンロックを実装してTask Queue処理結果を集約してみるテスト - スティルハウスの書庫の書庫
TaskQueueで分散処理した結果をまとめるときは、排他を考慮する必要があります。Datastoreを使う場合なら、単に結果を新規エンティティとして追加したり、エンティティグループの楽観排他を使ったりすればOKです。一方、やっぱりMemcacheでスピーディーに集約したいよ、という場合は、Memcache上で排他を実装する必要があります。以前のエントリにちょろっと書いたMemcacheService#incrementでスピンロックという方法について説明してほしいというコメントをid:miztakaさんよりいただいたので、ここに改めて書きたいと思います。 Memcacheでは排他制御が必要 ご存じのとおり、App Engineはデフォルトで複数のApp Serverによるクラスタが構成されており、またMemcacheサービスはクラスタ全体で共有されるグローバルなキャッシュとして機能します
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Membase.org
livebookmark.net
libmemcached in Launchpad