tgkのブックマーク - はてなブックマーク

第2章　PostgreSQLの内部構造―プロセスやメモリの流れ、特徴的な機能のしくみ | gihyo.jp

図1　主なプロセスの流れ PostgreSQLは、ライタがデータファイルやインデックスファイルをディスクに更新しています。ただし、その更新は、コミットに合わせてリアルタイムで行われているわけではありません。性能向上のため、チェックポイントと呼ばれる更新タイミングが発生するまでは、更新があっても共有バッファにデータを貯めておきます。この貯められたデータをダーティページと呼びます。そしてチェックポイントのタイミングで、チェックポインタがダーティページをディスクに書き込みます。そのため、共有バッファに更新情報を貯めている間に障害が起きると、ダーティーページを失う可能性があります。それを防ぐために、共有バッファ中のデータに対してどのような更新を行ったかの情報を保存しているのがWALです。WALはコミットのタイミングでWALライタが記録しています。クラッシュリカバリが必要になったときは、WALの中

tgk 2021/05/26

「INDEX ONLY SCANを利用するためには，VACUUMが実行されてから対象のテーブルに更新，削除，追加が実行されていないことが必須です」

postgresql

リンク

第3回　ブランチvs.フラグ | gihyo.jp

とっておきの変更ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。短いリリース間隔に身を置くと気づくことがあります。「⁠リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終

tgk 2013/08/06

「「ブランチAがトランクにマージされたとしましょう。ブランチBの開発者には地獄が待っています」「フラグにこうした問題はありません。マージのように複雑さが一度に打ち寄せる危険が少ないのです」

dev

リンク

第1回　サブクエリ・パラノイア～副問い合わせ乱用による性能劣化を治療せよ！ | gihyo.jp

図1　テーブルのレイアウト図2　リスト1の実行結果 cust_id | seq | price --------+-----+------- A | 1 | 500 B | 5 | 100 C | 10 | 600 D | 3 | 2000 リスト1　サブクエリ・パラノイア　患者1号 SELECT R1.cust_id, R1.seq, R1.price FROMReceiptsR1 （※） INNER JOIN (SELECT cust_id, MIN(seq) AS min_seq FROMReceipts ※ GROUP BY cust_id) R2 ON R1.cust_id = R2.cust_id AND R1.seq = R2.min_seq; ※　同一テーブルを結合する自己結合さてワイリー、お前ならどうする。ええっ、ちょっと待ってください。整理します。このReceip

tgk 2011/08/10

sql

リンク

第3回　MRTGのインストール | gihyo.jp

ここでは、各tarballの保存パスと展開用のワークパスを以下のようにしています。ご自分の環境に合わせて変更してインストールを進めていってください。保存領域パス：/usr/local/src/archive 作業領域パス：/usr/local/src/work MRTGのインストールを始めるワークパスに移動 % cd /usr/local/src/work zlibのコンパイル。インストールは不要 % tar zxvfp ../archive/zlib-1.2.3.tar.gz % mv zlib-1.2.3 zlib % cd zlib % ./configure % make % cd .. libpngのコンパイル。インストールは不要 % tar zxvfp ../archive/libpng-1.2.34.tar.gz % mv libpng-1.2.34 libpng % c

tgk 2010/09/21

GDはインストールしなくていいのか...

監視
mrtg

リンク

第21回　KiokuDB：マッピングが複雑すぎると感じたら | gihyo.jp

Shibuya.pm #12連動企画本日開催のShibuya Perl Mongersテクニカルトーク#12のテーマは "No Perl, NoSQL, NoKVS" または "Not only Perl, Not only SQL, Not only KVS" ということなので、今回はそれにあわせてYAPC::Asia 2009でも紹介されていたKiokuDBについて簡単に取り上げてみます。オブジェクトをまるごと保存する牧大輔氏も『モダンPerl入門』のなかで、データベースをハッシュテーブルのようにとらえて、「⁠基本的にプライマリキーからデータを持ってくる構成のみにすると、ORMを使用することによりキャッシュの導入も含めてチューニングが楽になります」と書いているように、Perlの世界では最近RDBMSやその上位層で頑張りすぎるより、モデリングの仕方そのものを工夫して実装や保守のしや

tgk 2009/12/01

orm

リンク

Flashのフレームワーク「Progression3」を始めてみよう！記事一覧 | gihyo.jp

tgk 2009/03/18

リンク

第1回　DBFluteの概要 | gihyo.jp

はじめに JavaにおけるDBアクセス周りの実装は、アプリケーション開発において非常に問題の多い領域です。数多くのO/Rマッパが登場していますが、現場の要件を満たせるものはまだまだ少ないかと思います。そのような状況の中、DBFluteは誕生しました。本稿では、このDBFluteが一体どういったもので、現場の問題に対してどのように解決をしていくか、基本から応用まで紹介していきます。今回のターゲットとする言語はJavaですが、実はDBFluteはC#版も存在します。ほぼ同じ仕様で実現されていますので、文法的な違いだけを読み替えることでC#ユーザの方にもお楽しみ頂ける内容かと思います。前提とするテーブル構造これからの説明で登場するサンプルの実装では、図1のテーブル構造を前提として話を進めていきます。図1　サンプルのテーブル構造（詳細は、こちらをご覧ください） DBFluteの概要（１）

tgk 2009/02/03

seasar
orm

リンク

第6回　意外に知られていないブラインドSQLインジェクション | gihyo.jp

前回の記事でSQLインジェクションの話は終わりにして、クロスサイトスクリプティングの話を書かせて頂こうと思っていました。しかし、6月5日に東京にて開催されたPostgreSQLカンファレンス2007でセキュリティをテーマに講演させて頂き、意外にブラインドSQLインジェクションをご存じでない方が沢山いらっしゃいました。40名ほどの聴講者の皆様にSQLインジェクションをご存じの方？とお聞きするとほぼ全ての方が知っていると答えたのですが、ブラインドSQLインジェクションをご存じの方は数名でした。 SQLインジェクションの常識ブラインドSQLインジェクションの話をする前に、SQLインジェクションとその対策の常識について確認します。 SQLインジェクション対策として間違ってはいないが不十分な対策エラーメッセージを表示しない（特にSQLエラー）ユーザ入力文字列をエスケープするこれらはSQLイン

tgk 2009/01/22

security

リンク

配色事典

INDEX リンク先は、各テーマ（Color Image）ごとの「配色（3色組合せ）」一覧です。 01　さわやかな・清潔な（Clear） 02　女らしい・フェミニンな（Elegant） 03　楽しい・にぎやかな（Casual） 04　和風・日本的な・伝統的な（Classic） 05　異国風・エスニック（Ethnic） 06　真面目な・堅実な（Formal） 07　くつろぎ・のどかな（Natural） 08　幽玄な・神秘的な（Mysterious） 09　元気な・活動的な（Sporty） 10　かわいらしい・子どもっぽい（Pretty） 11　都会的・シャープな（Urban）