タグ

ブックマーク / frsyuki.hatenablog.com (5)

  • バイナリシリアライズ形式「MessagePack」 - Blog by Sadayuki Furuhashi

    Googleが公開したバイナリエンコード手法であるProtocol Buffersは、クライアントとサーバーの両方でシリアライズ形式を取り決めておき(IDL)、双方がそれに従ってデータをやりとりするようにします。 この方法では高速なデータのやりとりができる反面、IDLを書かなければならない、仕様を変えるたびにIDLを書き直さなければならない(あらかじめしっかりとIDLを設計しておかないとプログラミングを始められない)という面倒さがあります。 ※追記:Protocol BuffersのデシリアライザはIDLに記述されていないデータが来ても無視するので(Updating A Message Type - Protocol Buffers Language Guide)、仕様を拡張していっても問題ないようです。 一方JSONやYAMLなどのシリアライズ形式では、何も考えずにシリアライズしたデータ

    バイナリシリアライズ形式「MessagePack」 - Blog by Sadayuki Furuhashi
    nilab
    nilab 2015/11/19
    バイナリシリアライズ形式「MessagePack」 - Blog by Sadayuki Furuhashi
  • Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi

    Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい>< みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか!?というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の3テーブルは、例えば次のようになる(PostgreSQLの場合): -- immutableなマスタ。 create table records ( id serial

    Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
    nilab
    nilab 2015/03/26
    Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
  • Protocol Buffersは遅い - Blog by Sadayuki Furuhashi

    Google の Protocol Buffers は、同技術と競合するバイナリシリアライズ形式である MessagePack と比べて、場合によっては 19倍 以上遅く、シリアライズ後のデータサイズは 7倍 以上になることがあります。平均的に見ると MessagePack の方が高速であり、高い性能が必要とされるなら Protocol Buffers より MessagePack を選択するべきです。 …とはいえどちらも非常に高速なので、実際にはそのAPIの違いで選んだ方が良い。Protocol Buffers と MessagePack は重視している点が異なり、使い勝手は大きく異なる。 Protocol Buffers とは何か Protocol BuffersはGoogleが開発したバイナリエンコード手法で、以下のような要素が提供されます: データフォーマットを記述するための言語(

    Protocol Buffersは遅い - Blog by Sadayuki Furuhashi
    nilab
    nilab 2013/03/29
    Protocol Buffersは遅い - 古橋貞之の日記
  • イベントログ収集ツール fluent リリース! - Blog by Sadayuki Furuhashi

    こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました! Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です:イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め

    イベントログ収集ツール fluent リリース! - Blog by Sadayuki Furuhashi
    nilab
    nilab 2012/10/31
    イベントログ収集ツール fluent リリース! - 古橋貞之の日記
  • 世界の「NoSQL」開発者が東京に集結 - NOSQL afternoon in Japan - Blog by Sadayuki Furuhashi

    NoSQLと呼ばれる新型の分散データストアの開発者が一堂に会するイベント NOSQL afternoon in Japan が、2010年11月1日、楽天タワーで開かれました。 海外からは「Cassandra」のサポートを行う Riptano や、「MongoDB」を開発する 10gen、「Couch DB」の Cloudant、「Hadoop」の Cloudera のエンジニアが登壇し、日からは Hibari、Okuyama、ROMA、そして kumofs の開発者が講演しました: ContentsPresenters HibariJoe NortonGemini Mobile Technologies OkuyamaTakahiro Iwase CassandraNate McCallRiptano ROMAMuga NishizawaRakuten Mongo DBRoger Bo

    nilab
    nilab 2010/11/12
    「分散Key-valueストア Kumofs と、高速メッセージングシステム MessagePack について発表してきました」世界の「NoSQL」開発者が東京に集結 - NOSQL afternoon in Japan - 古橋貞之の日記
  • 1