msgpack-inspect を作った - たごもりすメモ
MessagePackはJSONぽいけどバイナリでデータサイズが小さく抑えられ、またシリアライズ/デシリアライズが比較的高速であるとして広く使われておるところであります。なんか #linedevday にいるせいで口調がおかしいな。 が、バイナリなせいでデータを作ったあとその内容が正しいかどうか確認するのがいまいち面倒くさく、いちいちunpackするスクリプトを書いて中身を見る必要がある。JSONみたいに目で見て思った通りの表現になっているかどうかを判別するのは普通の人間にはなかなか難しい*1。 このため開発時にデータがバグってるのかコードがバグってるのかが分かりづらく、MessagePackを利用したアプリケーションおよびサービスを開発する上で問題になっていた。 ので、MessagePackのバイナリデータを食わせると内容を分かりやすくダンプしてくれるツールを作った！ のです！ msgp
Protocol Buffersは遅いのか - Qiita
はじめに Protocol Buffers でググると「Protocol Buffersは遅い」という記事が上位にヒットし、（記事公開から7年以上立っている現在でも）これをもって「Protocol Buffers は遅くて非効率」という印象を持たれることが多いようです。 しかし、この記事のベンチマーク実装は Protocol Buffers の性能特性を十分に活かしきれておらず、不公平な比較となっているように思われます。この記事では Protocol Buffers 寄りの視点で Protocol Buffers と MessagePack 比較を試みます。 で、遅いんですか？ わかりません。遅いんじゃないでしょうか？（！） 今回はシリアライズ速度の比較は行いません。計測がめんどくさいのと、私は ScalaPB を使っているので C++ 実装のシリアライズ速度にあまり興味がないためです。
JSONで疲弊したら試したい、アプリのデータをSQLiteで受け渡すという選択肢 - アニマネ開発日誌
アニマネの内部ではアプリとサーバー間でどのようにデータを受け渡ししているかという話をしてみます。 一般的にアプリとサーバー間のデータの受け渡しだとJSONやXML、YAMLなどが多いと思います。 ここにSQLiteという選択肢を入れると色々幸せになれるという話です。 もはや何で今までJSONという固定観念が捨てられなかったのかというぐらい、個人的にはコロンブスの卵でした。 あまり事例はなさそうなので、ここで紹介してみます。 アニマネでの問題点 アニメアプリのアニマネでは主にアニメの番組表やニュースをサーバーから受け取って表示しています。 都道府県にもよりますが、一つの都道府県の1週間分の番組表（アニメだけ）をJSONにすると大体750KBぐらいになるんですね。 これを開発初期ではMessagePackに置き換えてました。 話の本筋とは関係ないですが、JSONよりはMessagePackの方
Thrift、Avro、MessagePackのシリアライズ、デシリアライズ速度比較
Thrift、Avro、MessagePackで郵便番号データをシリアライズ。 PostgreSQLのbytea列に登録してみました。 PostgreSQLのBLOB(bytea)列にThriftで変換したバイナリデータを登録する PostgreSQLのBLOB(bytea)列にApache Avroで変換したバイナリデータを登録する MessagePackでシリアライズした内容をPostgreSQLのbytea列にJavaで登録する せっかくなので速度比較してみます。 郵便番号約12万件の登録にかかった時間はこんな感じになりました。 単位はmsです。 1回目：25,138 2回目：24,525 3回目：25,018 4回目：25,105 5回目：24,515 平均：24,860 Thriftが24,904、Avroが24,716だったのでそんなに差はないのかな？と思います。 全件フェッチ
msgpack javaについて - xuwei-k's blog
色々あってmsgpackいじってたりするのですが、とりあえず見つけたバグとかその他色々まとめてみる。 最近1、2ヶ月でいじりだした程度で、べつにmsgpackのエキスパートではないので、なにか間違ってたらツッコミください。 そもそもmsgpack javaの話だけがしたかったわけではなく、それを元にScalaのやつ新しくつくったり、もしくはJavaに依存させずに別途pure Scalaで作ってパフォーマンス比較したかったけど、Javaのやつがバグってるままだと話にならないので、まずJavaのやつを理解して安定させたい、ということで、こうやってblog書いたり、pull reqやissue報告してる状況です。 msgpack自体の説明はあまりしないので、知らない人はググってください。簡単に言っておくと、だいたいJsonっぽい*1けど、バイナリフォーマットなので、Jsonに比べてパースも速い、
Treasure DataのPlazmaDBを理解する - Qiita
こんにちは。Treasure Dataの斉藤です。出張中に時間ができたのでシアトル空港でこの記事を書いています。日本語でブログを書くのはものすごく久しぶりなのですが、Treasure Dataの列志向(columnar)圧縮ストレージであるPlazmaDBについて紹介していきたいと思います。 Treasure Dataでは2014年現在まで5兆(trillion)件を超えるレコードが取り込まれており、一秒あたりでは40万以上(!)のレコードを処理しています。 2013年のTwitterでは１秒あたり5,700 tweets処理していたとのことなので、その処理量の大きさが実感できるのではないでしょうか。この量のレコードをそのまま蓄積するのではストレージ量が膨大になってしまいますので、Treasure Dataではレコードを列分解し、MessagePack形式に変換＋圧縮処理を施すことでデータ
LedisDB - A high performance NoSQL like Redis powered by Go.
Data structure Rich data structure: KV, List, Hash, ZSet, Set. Various Backend Various backend databases to choose: LevelDB, goleveldb, LMDB, RocksDB, BoltDB or Memory. Expiration & TTL Supports expiration and ttl in all kinds of data structures. CLI Support Redis clients, like redis-cli, are supported directly. Easy Embedding Easy to embed in Go application. Data Protection Replication to guarant
MessagePack RPC によるドキドキ非同期通信 @関ジャバ 2012年度8月
2. 自己紹介 染田貴志 (SOMEDA Takashi) http://d.hatena.ne.jp/tksmd 株式会社ヌーラボ所属 Backlog の開発・インフラ・サポート Cacoo のインフラ FxUG 京都スタッフ JAWS UG 京都支部長 関西 Java エンジニアの会 常連 kanjava vol.8 3. 1年ぶり4度目の登板 http://d.hatena.ne.jp/tksmd/20100929 https://cacoo.com/diagrams/zIPOGa9u3sP8NHHf http://d.hatena.ne.jp/tksmd/20110720 kanjava vol.8
Tarantool Data Integration Platform
How Tarantool works Tarantool keeps all the data in random-access memory (RAM). Solutions of this class are fast, but they often lack data persistence. Tarantool helps overcome these problems. Try Tarantool to see how fast, flexible, and scalable it is. Download When to use in-memory? In-memory solutions are very fast because they work in RAM. This helps you avoid overhead associated with caching
MessagePack-RPCのプロトコル仕様（ドラフト）と実装例 - Blog by Sadayuki Furuhashi
以前に書いた MessagePack RPC プロトコル は少し古くなってしまったので、ここでまとめ直しておこうと思います。 MessagePack-RPCのプロトコルは、非同期型の呼び出しができる点（非同期プロトコル）が大きな特徴となっています。複数のサーバが相互に通信し合ったり、通信と計算をオーバーラップさせて高速化を図ったりするような、高度なネットワークアプリケーションを実装しやすくなります。 RPCライブラリと言うよりも、シンプルな非同期メッセージングライブラリと言えます。 ここではMessagePack-RPCのプロトコル仕様と、以上の特徴を活かせるような実装例も合わせて紹介します。 基本仕様：MessagePack-RPC specification version 0.1 MessagePack-RPCのプロトコルは、メソッドの呼び出すRequestメッセージと、それに対する
ZeroMQのJava実装のJeroMQを試す - bose999の試験管の中の話
ZeroMQ http://zguide.zeromq.org/page:all JeroMQ https://github.com/zeromq/jeromq ZeroMQはシンプルで高速なプロセス間通信を実現する C/C++のライブラリ。ライブラリのラッパーは対応言語が豊富。 キューは永続化はされない。メモリで処理されるので高速。 ライセンスはLGPL。 こちらのエントリが詳しい ØMQ(zeromq)について調査する。 JeroMQはZeroMQがC/C++で書かれてるのに対してJavaで書かれている。 libzmq 3.2.2に基づいた0.3.0-SNAPSHOTを今回は使用する。 ZeroMQと違いJava実装なのでJVMとjarがあれば動いてしまう手軽さが良い。 またパフォーマンスも頑張っている。ライセンスはLGPL。 では上記のような Client REQUEST <-> R
20130215 fluentd esper_2
3. こんな感じ select count(*) from accesslog:win(30sec ) group by path having count(*) > 5 output input { { count(*): 20, host: 10.1.1.1, path “/index.html” path : “/index.html”, } code: 200 { } count(*):6, path “/favicon.ico” } 5. Data Flow Query Registration Proces Compone Client(ruby) s nt RPC Client msgpack-RPC fluentd (ruby) Subscriber(java) query input 0mq publish 0mq Esper RPC output msgpack sub
Home
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert Test Platform OS:Mac OS X JVM:Oracle Corporation 11.0.19 CPU:2.6 GHz 6-Core Intel Core i7 os-arch:Darwin Kernel Version 21.6.0 Cores (incl HT):12 Disclaimer Th
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Geekなぺーじ:MessagePackがIETF標準化に巻き込まれてる件について
ここ数日、MessagePackがIETFにおける標準化に巻き込まれてザワザワしています。 何が起きているかというと、MessagePackプロジェクトとは関係が無い第三者がIETFで派生物の標準化を進めようとしています(binarypack、Informational RFCとして)。 binarypackは、自らをMessagePackの派生であるとしながらも、MessagePackとの後方互換性が無いものです。 MessagePack is in danger! binarypackのInternet-Draftを提出しているのは、coreと6lowpanのchairです。 Chairであるかどうかが議論そのものに与える影響はそこまで大きくないとも言えますが、少なくともIETFでの話の進め方に精通した人物であることは確かです。 ただ、今回のInternet-Draftは、その人物がC
Kazuho Oku
MessagePack is in danger! MessagePack is a well-known data format, which is often used for storing various kinds of data on key-value stores, or as a...
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
studio-ousia/mprpc · GitHub - A fast MessagePack RPC library
Rubyによるお手軽分散処理
https://github.com/msgpack/msgpack-java/blob/master/src/test/java/org/msgpack/TestSimplePackable.java
Serialization using ByteBuffer and recycled objects