Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - 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に殺さ
データの更新履歴を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
Webサイトをgithubで管理してpush時に自動的に同期する方法 - Blog by Sadayuki Furuhashi
Webサーバに Subversion のサーバを立てておき、HTML や CSS を commit することでWebサイトを更新する方法は、良く知られているテクニック、らしいですね*1。更新の履歴を残すことができるし、ましてチマチマとFTPやsftpでアップロードするよりずっと簡単です。 しかし SVN の代わりに git を使おうとすると、pushしてもリポートリポジトリではファイルを更新してくれません。 また、リポジトリはWebサーバ上に作るよりも、便利な管理インタフェースがある github（や噂のgitosis）に置いておきたいところです。 そこで、github の Post-Receive Hook を使うと、リポジトリに変更を push すると同時に、Webサーバにも同期させることができます*2。 Webサーバに同期する前に、Sphinxでドキュメントを整形したり、SassをC
共有ホームディレクトリ環境の管理方法 - Blog by Sadayuki Furuhashi
MacPorts や apt などのパッケージ管理システムでインストールできないアプリケーションやライブラリ、自分で書いたツールなどを、ホームディレクトリにインストールしたいことは良くある。 ホームディレクトリならroot権限が要らないし、rootを持っている場合でも思わぬ操作ミスや設定ミスのリスクを抑えられる利点がある。アンインストールもしやすい。gem や easy_install などのスクリプト言語の管理システムが、OS全体のパッケージ管理システムと競合してしまう問題も回避できる。 このようにホームディレクトリにアプリケーションをインストールするときに、複数のバージョンを同時にインストールしたいことがある。また、異種のOSやCPUアーキテクチャのマシンでホームディレクトリを共有したかったりする*1 *2。 以上のような要求があるときに、ホームディレクトリ環境をどうのように構築し、P
古橋貞之の日記 - 開発環境としてのMac OS Xカスタマイズ
Mac OS Xを使っていないプログラマは、時間の80％を無駄にしている、かどうかは知りませんが、堅いGUIとUNIX系のコマンドラインツールを使えるMac OS Xは、開発環境として使いやすいことは確か。 が、デフォルトのままでは、Terminal.appで日本語が表示できないとか、lsやfindがGNU系じゃなくてBSD系だとか、要するにOSだってカスタマイズしてなんぼというわけであります。 というわけで、私のMac OS Xのカスタマイズをこのあたりに書いておきます。 ※2008/2/3追記: Leopard版書きました > 開発環境としてのMac OS X Leopard Terminal.app Mac OS Xにはデフォルトで「ターミナル」（/Applications/Utilities/Terminal.app）が付いてきますが、これがデフォルトではまったくイケてない。主要な
丸レク2010「分散Key-valueストアkumofsの思想と設計」 - Blog by Sadayuki Furuhashi
分散Key-valueストアkumofsの思想と設計 と題して、丸レクセミナー2010で発表してきました。 kumofs を使いたくなるユースケースの紹介を中心に、kumofs のメリットを紹介しています。 会場は楽天タワーで、何やらスゴイ数の方に聞いていただけたようです。来場者数は500名を超えたと聞いています。 ネット中継でも多くの方に視聴していただいたようで、Twitterでも多くのフィードバックをいただきました。ありがとうございます。 分散Key-valueストアkumofsの思想と設計View more presentations from frsyuki. 発表スライド（PDF） Ustream.tvの録画 あわせて読みたい 情報システムの信頼性：対策は進んだが改善の余地も 企業IT動向調査2009 kumofsから学ぶNot only SQLの技術＠Developers Su
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
