マルチコア時代の高並列性IOアーキテクチャ Wavy - Blog by Sadayuki Furuhashi
シングルスレッドではもう遅い。 以前にマルチコア時代の高速サーバーの実装で、「ネットワークIOはマルチスレッドで動かすが、その他の部分はシングルスレッドで動かす」というIOアーキテクチャの実装（mp::iothreads）を紹介しました。iothreadsはロジック部分をシングルスレッドで書けるため実装の手間を抑えることができ、ネットワークIOがボトルネックになるプログラムには特に適していると思われます。 しかし実際にiothreadsを使ってプログラムを書いてみると、非常に負荷が高い状況でシングルスレッドの部分の処理速度がボトルネックになってしまうことがありました。 そこでマルチコアCPUの性能を引き出すために、徹頭徹尾マルチスレッドで動かすIOアーキテクチャを実装してみました。 1つのスレッドが、ある時はepoll_wait()し、ある時はread(2)を行い、ある時はイベントを処理す
MessagePackフォーマット仕様にTimestamp型を追加 - 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
いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが！ 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン６：操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE） 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する（UPDATE） この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE）→
Embulkでやりたいことリスト（2015年7月版） - Blog by Sadayuki Furuhashi
バルクロード機能 1つの設定ファイルで複数ジョブを実行する Running multiple jobs using one config file · Issue #167 · embulk/embulk · GitHub 例えば users.csv と histories.csv の2つのファイルを、それぞれPostgreSQLにある users と histories の2つのテーブル にロードしたいというようなユースケースに対応する機能。 設定ファイルの構文はissueに書いてあるように、default: に書き並べた設定に対して、jobs: に書いた設定をマージしたものを実際の設定ファイルとして実行していく方法で良さそう。しかし、fliters: は配列なので、default: に書かれた filters: に jobs: に書かれた filters: をどうマージするか、あまり良
Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
