2021/7/16にCloud Native Database Meetup#1の発表資料です。
#CloudNativeDB NewSQLへの誘い
2021/7/16にCloud Native Database Meetup#1の発表資料です。
Geode hands-on
Apache Geode ハンズオン資料です。 ソースコードはこちら：https://github.com/masaki-yamakawa/GeodeHandsonRead less
RebornDB: the Next Generation Distributed Key-Value Store - High Scalability -
« Stuff The Internet Says On Scalability For July 10th, 2015 | Main | Sponsored Post: VoltDB, Datadog, Tumblr, Power Admin, Learninghouse, MongoDB, Internap, Aerospike, SignalFx, InMemory.Net, Couchbase, VividCortex, MemSQL, Scalyr, AiScaler, AppDynamics, ManageEngine, Site24x7 » There are many key-value stores in the world and they are widely used in many systems. E.g, we can use a Memcached to s
voldemortの技術 - Dynamoとの比較
5. DynamoとVoldemortの比較 問題 Dynamo Voldemort メリット データの割当 Consistent Hashing Consistent Hashing Incremental Scalability 書込みの高可用性 Vector Clocks & Vector Clocks & Read Repair Read Repair 一時的失敗 Sloppy Quorum & Sloppy Quorum & 可用性と 耐久性 Hinted Handoff Hinted Handoff 永続的失敗 Anti-entropy using Restore from 耐久性 Merkle trees Replica node メンバーシップと Gossip-based Gossip-based 失敗感知 membership membership protocol &
consul-templateのイベント発火トリガーについて調査した - Qiita
ざっくり説明するとconsul-templateとは consulの様々なイベントを検知して 「テンプレート更新」 ＞ 「任意のコマンド実行」 してくれるツールです。 今回実現したかったのは consul-kvsの変更をトリガーにしてほげほげする ことです。 最初はconsul-templateがどういう条件でイベント発火するのかよくわからなかったのですが、 ドキュメントをよく見たらその辺りの仕様が記載されていたのでメモしておきます。 どういう条件でwatchしているのか？ 何の事はない話で、基本的には 読み込むテンプレート内で利用している値が変更されたかどうか を見ているようです。 素晴らしいですね。（※一部例外あり） 例: kvsのキーの値を監視する場合 以下のようなテンプレートで key を参照するだけでよいです。
Consul KVSをバックエンドにしたリアルタイムダッシュボード #monitoringcasual - 酒日記 はてな支店
最近悩んでいることを解決する小さいアプリケーションを書いたので、monitoring casual talks #7 で発表してきました。 モニカジは毎回全員発表で濃い話がいろいろできて楽しいですね！ Consul KV Dashboard // Speaker Deck GitHub - fujiwara/consul-kv-dashboard: Consul KVS based dashboard web application. 概要はスライドにありますが、Consul KVS に保存された値をいい感じにまとめて(リアルタイム更新で)見せることのできる、Go + React.js でできた小さな Web application です。 ConsulのREST APIに値を送る(curlで十分)だけで、現在の各ホストで発生した値を画面でリアルタイムに更新しつつ閲覧できます。 Consu
HaskellのPersistentライブラリのZooKeeperバックエンドの開発 | GREE Engineering
こんにちは！インフラストラクチャ本部の橋本です。 このエントリは GREE Advent Calendar 2014 12日目の記事です。 読者のみなさまの一助となる知見が少しでも提供できれば幸いです。 はじめに HaskellのO/RマッパーであるPersistentのZooKeeperバックエンドを開発しました。 Persistentのいいところは以下のようになります。 HaskellのデータとDBのデータの変換が自動（O/Rマッパなので当たり前ですね。） 型安全に加えて、構造的に安定（DB["user"]とか文字列でDBから値をとってくることはできません。クエリでも同様です。) コネクションがプールされます SQLだけでなくNoSQLも扱えます よく使われています（Yesodのフレームワークに組み込まれていることが大きいと思います。) 開発の動機は、以下の通りです。 GreeではKV
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
wavelet行列で高速な「もしかして友だち？」検索 | 株式会社サイバーエージェント
業務経歴： Sierでのソフトウェア開発・大手メディアでのサービス運用を経て2012年サイバーエージェント入社。 アメーバ事業本部コミュニティサービスの開発責任者を経て、現在はアドテクスタジオで広告配信技術に注力。 好きな分野はグラフ探索とチューリングマシン。 ソーシャルサービスでは、ユーザ間のつながりやユーザ同士の類似性がとても重要です。 つながりの近いユーザや自分と似ているユーザを「もしかして友だち？」とサジェストすることでユーザ間のつながりを伸展させることができます。 そこで、ユーザの「つながり」具合が似ているユーザを「友だちかもしれないユーザ」としてサジェストを行うことを考えました。 しかし「つながり」のデータというのはユーザ数のベキ乗であるため、容量が大きくなりやすい性質があります。 即ち、「つながり」類似度の算出には時間がかかる、ということです。 この「つながり」類似度算出
『redis、それは危険なほどのスピード』
どうも、プラットフォームDivでエンジニアをやっている Wataru です。 最近３人目の子供が産まれて、産後自宅勤務をさせてくれた弊社はとてもいい会社だと思います。出産予定のあるエンジニアのかたは是非弊社に転職を。 さて、今回はRedisの紹介をさせて頂きたいと思います。 Redisってすごくマイナーなわけではないのですが、めちゃくちゃ便利なのにあまり注目されていないなーという印象があるので、これを機会に是非使ってみてもらえると嬉しいです。 Redisって何？Redisとは「remote dictionary server」から名前が付けられたオープンソースのkey-valueデータストアです。 MemcacheDB等のKVSとの最大の違いは、格納するバリューがデータ構造というところです。 つまり、リスト・セット・ハッシュなどのデータ構造で格納できるのでバリューに対してアトミックな操作が
InfluxDB をちょっとさわってみた - （ひ）メモ
InfluxDBとは http://influxdb.org メトリクスやイベントといった時系列データを格納するのに適したデータストアです。 ちなみに go で書かれています。 ちなみに 2013のOpen Source Rookiesに選ばれました。 InfluxDBの特徴 RRDやMySQLに時系列データを格納する場合と比較して、InfluxDBの特徴を紹介します。 バックエンドは LevelDB LevelDBとは、キーでソートされた状態で可能されたKVSです（Google製）。詳しくはこのへん参照のこと。 http://en.wikipedia.org/wiki/LevelDB https://code.google.com/p/leveldb/ https://speakerdeck.com/smly/influxdb-and-leveldb-inside-out 将来的にLev
『Redisとハサミは使いよう』
ロック機能のポイントはSETNXです。 指定したキーがなかった場合は値をセットして1を返し、 既に存在する場合は何もせず0が返ってきます。 つまり、1はロック成功、0は他からロック済みと判断することができます。 それでは実装に進みましょう。 まずロックのインタフェースを用意します。 public interface Lock { public void lock() throws TimeoutException; public void unlock(); } 最低限のロックとアンロックを用意しました。 続いて中身を実装します。 public class RedisLock implements Lock { private static final String LOCK_KEY_PREFIX = "lock:"; private static final int LOCK_EXPIR
ゲームサーバ開発現場の考え方
11. 通信システム リアルタイム通信が不要であればHTTP 送受信（POST）するデータ形式は？ XML, JSON, MessagePack, Google Protocol Buffers, 独自シリアライズ 通信の頻度とデータ量、デシリアライズ処理の重 さ、開発＆デバッグのやりやすさなどから検討（慣 れないうちはJSONオススメ） 11 12. 想定負荷 例）DAU(Daily Active Users) 10万 10万 x 20 Login/日= 200万 Login/日 = 23 Login/秒 3倍して 23 x 3 ≒ 70 Login/秒 これが日々のピーク Webサーバ1台で12程度さばけると仮定すると、Webサーバ6台 となる。（この時点はざっくり） 基本的にログインが最も重い（多くのデータを読み込み、送信 する必要がある）ので、まずはログインの負荷を目安に考える。
memcached活用は、格納オブジェクトの”粒度”がキモ
最近じゃmemcachedを活用してデータベース(RDB)の負荷を下げるって話、そこらじゅうから聞こえてくるけれど、memcachedの活用は、格納オブジェクトの”粒度”（granularity）がキモだと思ってます。 memcachedは、KeyとDataをペアで格納して、Keyが与えられると、関連付けられたDataを返すだけのシンプルなシステム。PerlやPHPの連想配列と同じ。このmemcachedをRDBのキャッシュとして活用してやる場合、memcachedに格納するキャッシュデータの単位、”粒度”をどう設計するかが重要になってくる。 RDBの場合、格納されるデータはRow(レコード)単位。じゃぁキャッシュもRow単位で作ってやればいいのかといえば、それではうまくいかないケースもたくさんある。RDBでは専用の問い合わせ言語であるSQLを使って、 SELECT * FROM hoge
yrmcds 1.0.0 をリリースしました - Cybozu Inside Out | サイボウズエンジニアのブログ
@ymmt2005 こと山本泰宇です。去る 7 月に yrmcds という memcached 互換な KVS を公開したことをご案内しました。それから 5 ヶ月経ちましたが、今回は安定版となるバージョン 1.0.0 をリリースをご案内します。 ダウンロードはこちらからどうぞ: https://github.com/cybozu/yrmcds/releases/tag/v1.0.0 0.9.0 からの変更点を短くまとめるとバグがなくなって、memcached より多分高速になっています。ちょっと長めの記事ですが、末尾にいいことが書いてありますので、是非ご一読ください。 yrmcds の特長 レプリケーション サーバーサイドロック No slabs その他 memcached との差異 運用実績と性能 クライアント 0.9.0 からの変更一覧 バグ報告を募集します！ yrmcds の特長 y
ISUCON 3 の参加記録 - aptheia.info
Web アプリケーションのパフォーマンスコンテスト ISUCON 3 に参加し、2 位の成績となった。どのような状態で当日を迎え、どのような作業を行ったのかをまとめる。 私自身はこれで三度目の ISUCON 参加となるが、今回チームを組むメンバーはみんな初めての参加ということもあり、事前の打ち合わせでは以下のようなことを話していた: これまでの大会の説明と典型的なアプローチ 同時に、過去にとられた戦法は参考程度であること、あくまで現物のアプリケーションを元に戦略を立てるべきでアプリケーションやミドルウェアを事前に決めることは危険であるということは強調 よく使われるミドルウェアの概要、メリット/デメリット 主要機能のほか、キャッシュ部分の永続性の有無（単純に考えればメモリだけで処理してファイルに書き出さない方が早いが、ベンチマークをまたいでキャッシュを引き継げれば切り札になり得る）、キャッシ
FluentdとRiakの話 - After Coding
Fluentdは、Ruby製のログコレクタだ。コードは公開されている。 様々なログを構造化して一元管理することができ、収集と解析へのハードルを大きく下げてくれる。 インストールもプラグイン開発も簡単。日本語の資料も多い。 その資料も様々あるが、プラグインを見るならこれが最良だと思う。必要な情報がよくまとまっており、必読といえる。 Big Data入門に見せかけたFluentd入門 from Keisuke Takahashi データの確実な転送を実現するバッファ機能については、池田大輔さんのブログが詳しい。さて、Fluentdはデータを収集してくれるが、保存はしてくれない。 永続化にはデータベースが必要だ。 そこで、Riak。 Basho社がスポンサードするErlang製分散型KVS。これもOSSだが、契約によって商用サービスが受けられる。 これがまたエッジ立ちまくってて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分割と整合性と戦う
LevelDB入門
運用が楽になる分散データベース Riak
