Blog by Sadayuki Furuhashi
MessagePackフォーマット仕様のPull Request #209をマージし、MessagePackにTimestamp型を追加しました。 ※この記事の英語版は XXX にあります（翻訳中） Extension型の型コード -1 として定義されているため、後方互換性が維持されています。つまり、既にExtension型に対応しているデシリアライザであれば、Timestamp型を使用して作成されたデータを、Timestamp型に対応していない古いデシリアライズで読み出すことができます。 新しいTimestamp型には timestamp 32、timestamp 64、timestamp 96 の3つのフォーマットがあり、よく使う値をより少ないバイト数で保存できるようになっています。例えば、1970年〜2106年までの時刻で、秒までの精度しか持たない時刻であれば、合計6バイトで保存でき
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
デシリアライズ速度の比較 ByteBuffer vs DirectBuffer vs Unsafe vs C - Blog by Sadayuki Furuhashi
OpenJDK や Hotspot VM には sun.misc.Unsafe という内部APIがあり*1、これを使うと ByteBuffer.getInt や ByteBuffer.getLong よりも高速にバイト列から整数値をデコードできるという。これを駆使することで、Cで実装された拡張ライブラリに匹敵する速度を出せるらしい。 それが本当なら、データ圧縮やハッシュ関数、シリアライザ/デシリアライザなどの実装を高速化できる。例えば、lz4 や xxhash のJava実装が Unsafe API を使用している*2：jpountz/lz4-java Prestoも、中間データのシリアライズ/デシリアライズにはすべて Unsafe API を使っている*3。 そこで、実際にベンチマークしてみた。 ベンチマーク内容 10MBのランダムなバイト列を生成する 先頭から1バイト読み出す その1バ
データの更新履歴をRDBMSからfluentdに流すfluent-plugin-sql - Blog by Sadayuki Furuhashi
Fluentd Advent Calendar 9日目。担当の古橋です。 Fluentd v11の情報は Fluentd Casual Talks #3 at :D でお話しすることにして、今回はFluentdの大幅な性能向上を可能にするMultiprocessプラグインを紹介…しようと思っていたら@niku4i さんに先を越されてしまったので！今回はSQL inputプラグインを紹介します。 SQL inputプラグインとは？ SQL inputプラグインは、SELECT文を定期的に実行することで、RDBMSから最近更新されたレコードや最近追加されたレコードを定期的に取り出してFluentdに流すことができるプラグインです。内部では"前回読み出したレコード"を記憶しており、前回読み出したタイミングより後になって更新/追加されたレコードを定期的に読み出します。 SQL input plug
「分散システムのためのメッセージ表現手法に関する研究」 - 筑波大学大学院を卒業しました - Blog by Sadayuki Furuhashi
このたび筑波大学大学院を卒業し、修士号を取得しました。卒業にあっては本当に多くの方々にご助力いただきました。この場を借りて御礼申し上げます。ありがとうございました。 現在は起業して、12月からアメリカに在住しています。新たな価値を生み出すべく "下から上まで" システムの設計と開発に携わっており、エキサイティングな毎日を送っています。 修論シーズンに日本にいなかったので、修士論文はメールで送って提出し、卒業式にも出席していないというありさまなので、本当に卒業できたのかどうか実感がないのですが、友人によれば「学位記はあった」らしいので、きっと大丈夫でしょう。（写真はカリフォルニア州マウンテンビューにて） さて、せっかく時間を割いて書いたので、修士論文を公開することにしました。 分散システムのためのメッセージ表現手法に関する研究と題して、バイナリ形式のシリアライズ形式である MessagePa
分散Key-Valueストア「kumofs」を公開しました！ - Blog by Sadayuki Furuhashi
分散Key-Valueストア kumofs を、本日オープンソースソフトウェアとしてリリースしました！ kumofs@SourceForge kumofs関連資料まとめ kumofsとは？ kumofs（クモエフエス）は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
