書籍をつつく132－実践ハイパフォーマンスMySQL 第2版。色々なパフォーマンスがいい良書。

今日はデータベースに関する良書を思い出したから紹介するピヨ♪
実践ハイパフォーマンスMySQL 第2版
MySQLを実務に使う人は必見♪

【目次】
はじめに

1章　MySQLのアーキテクチャ
1.1　MySQLの論理アーキテクチャ
1.1.1　接続の管理とセキュリティ
1.1.2　最適化と実行
1.2　並行性の制御
1.2.1　読み取り/書き込みロック
1.2.2　ロックの粒度
1.3　トランザクション
1.3.1　分離レベル
1.3.2　デッドロック
1.3.3　トランザクションログ
1.3.4　MySQLのトランザクション
1.4　マルチバージョンの並行性制御（MVCC）
1.5　MySQLのストレージエンジン
1.5.1　MyISAMエンジン
1.5.2　MyISAM Mergeエンジン
1.5.3　InnoDBエンジン
1.5.4　メモリエンジン
1.5.5　Archiveエンジン
1.5.6　CSVエンジン
1.5.7　Federatedエンジン
1.5.8　Blackholeエンジン
1.5.9　NDB Clusterエンジン
1.5.10　Falconエンジン
1.5.11　solidDBエンジン
1.5.12　PBXT（Primebase XT）エンジン
1.5.13　Mariaエンジン
1.5.14　その他のストレージエンジン
1.5.15　正しいエンジンの選択
1.5.16　注意事項
1.5.17　実例
1.5.18　ストレージエンジンのまとめ
1.5.19　テーブル変換

2章　ボトルネックの検出：ベンチマークとプロファイリング
2.1　ベンチマークを実行する理由
2.2　ベンチマーク戦略
2.2.1　何を測定するか
2.3　ベンチマーク戦術
2.3.1　ベンチマークの設計と計画
2.3.2　正確な結果の取得
2.3.3　ベンチマークの実行と結果の分析
2.4　ベンチマークツール
2.4.1　フルスタックツール
2.4.2　単一コンポーネントツール
2.5　ベンチマークの例
2.5.1　http_load
2.5.2　sysbench
2.5.3　Database Test Suiteのdbt2 TPC-C
2.5.4　MySQL Benchmark Suite
2.6　プロファイリング
2.6.1　アプリケーションのプロファイリング
2.6.2　MySQLのプロファイリング
2.6.3　MySQLサーバーのプロファイリング
2.6.4　SHOW STATUSによるクエリのプロファイリング
2.6.5　SHOW PROFILE
2.6.6　MySQLの他のプロファイリング方法
2.6.7　プロファイリングコードを追加できない場合
2.7　オペレーティングシステムのプロファイリング
2.7.1　MySQL接続とプロセスのトラブルシューティング
2.7.2　高度なプロファイリングとトラブルシューティング

3章　スキーマの最適化とインデックス
3.1　最適なデータ型の選択
3.1.1　整数
3.1.2　実数
3.1.3　文字列型
3.1.4　日付と時刻型
3.1.5　ビットデータ型
3.1.6　識別子の選択
3.1.7　特殊なデータ型
3.2　インデックスの基礎
3.2.1　インデックスの種類
3.3　高いパフォーマンスを実現するためのインデックス戦略
3.3.1　列の分離
3.3.2　プレフィックスインデックスとインデックスの選択性
3.3.3　クラスタ化インデックス
3.3.4　カバリングインデックス
3.3.5　ソートのためのインデックススキャンの使用
3.3.6　圧縮された（プレフィックス圧縮された）インデックス
3.3.7　冗長インデックスと重複インデックス
3.3.8　インデックスとロック
3.4　インデックスのケーススタディ
3.4.1　さまざまなフィルタのサポート
3.4.2　複数の範囲条件の回避
3.4.3　ソートの最適化
3.5　インデックスとテーブルの管理
3.5.1　テーブルの破損の検出と修復
3.5.2　インデックス統計の更新
3.5.3　インデックスとデータの断片化の削減
3.6　正規化と非正規化
3.6.1　正規化されたスキーマの長所と短所
3.6.2　非正規化されたスキーマの長所と短所
3.6.3　正規化と非正規化の混合
3.6.4　キャッシュテーブルとサマリテーブル
3.7　ALTER TABLEの高速化
3.7.1　.frmファイルのみの変更
3.7.2　MyISAMインデックスのすばやい構築
3.8　ストレージエンジンに関する注意点
3.8.1　MyISAMストレージエンジン
3.8.2　Memoryストレージエンジン
3.8.3　InnoDBストレージエンジン

4章　クエリパフォーマンスの最適化
4.1　スロークエリの基礎：データアクセスの最適化
4.1.1　データベースから必要のないデータを取得していないか
4.1.2　MySQLが調査するデータが多すぎないか
4.2　クエリを再構築する方法
4.2.1　複雑なクエリと多数のクエリ
4.2.2　クエリの分割
4.2.3　結合分解
4.3　クエリの実行の基礎
4.3.1　MySQLクライアント/サーバープロトコル
4.3.2　クエリキャッシュ
4.3.3　クエリ最適化プロセス
4.3.4　クエリ実行エンジン
4.3.5　クライアントへの結果の返送
4.4　MySQLクエリオプティマイザの制限
4.4.1　相関サブクエリ
4.5　特定の種類のクエリの最適化
4.5.1　COUNTクエリの最適化
4.5.2　JOINクエリの最適化
4.5.3　サブクエリの最適化
4.5.4　GROUP BYとDISTINCTの最適化
4.5.5　LIMITとOFFSETの最適化
4.5.6　SQL_CALC_FOUND_ROWSの最適化
4.5.7　UNIONの最適化
4.6　クエリオプティマイザのヒント
4.7　ユーザー定義変数
4.7.1　MySQLのアップグレードに関する注意点

5章　MySQLの高度な機能
5.1　MySQLクエリキャッシュ
5.1.1　MySQLがキャッシュヒットをチェックする方法
5.1.2　キャッシュはどのようにメモリを使用するか
5.1.3　クエリキャッシュが役立つ状況
5.1.4　クエリキャッシュの調整と管理の方法
5.1.5　InnoDBとクエリキャッシュ
5.1.6　一般的なクエリキャッシュの最適化
5.1.7　クエリキャッシュに代わるもの
5.2　MySQL内でのコードの格納
5.2.1　ストアドプロシージャとストアド関数
5.2.2　トリガ
5.2.3　イベント
5.2.4　ストアドコードでのコメントの維持
5.3　カーソル
5.4　プリペアドステートメント
5.4.1　プリペアドステートメントの最適化
5.4.2　プリペアドステートメントへのSQLインターフェイス
5.4.3　プリペアドステートメントの制限
5.5　ユーザー定義関数
5.6　ビュー
5.6.1　更新可能ビュー
5.6.2　ビューによるパフォーマンスへの影響
5.6.3　ビューの制限
5.7　文字セットと照合順序
5.7.1　MySQLは文字セットをどう扱うか
5.7.2　文字セットと照合順序の選択
5.7.3　文字セットと照合順序がクエリに与える影響
5.8　全文検索
5.8.1　自然言語の全文検索
5.8.2　ブーリアン全文検索
5.8.3　MySQL 5.1以降での全文検索の変更点
5.8.4　全文検索のトレードオフと次善策
5.8.5　全文インデックスの調整と最適化
5.9　外部キー制約
5.10　マージテーブルとパーティショニング
5.10.1　マージテーブル
5.10.2　パーティションテーブル
5.11　分散（XA）トランザクション
5.11.1　内部XAトランザクション
5.11.2　外部XAトランザクション

6章　サーバー設定の最適化
6.1　設定の基礎
6.1.1　構文、スコープ、動的な変数
6.1.2　変数設定の副作用
6.1.3　変数を設定するための準備
6.2　一般的な調整
6.2.1　メモリの調整
6.2.2　MyISAMキーキャッシュ
6.2.3　InnoDBバッファプール
6.2.4　スレッドキャッシュ
6.2.5　テーブルキャッシュ
6.2.6　InnoDBデータディクショナリ
6.3　MySQLのI/Oの調整
6.3.1　MyISAMのI/Oの調整
6.3.2　InnoDBのI/Oの調整
6.4　MySQLの並行処理の調整
6.4.1　MyISAMの並行処理の調整
6.4.2　InnoDBの並行処理の調整
6.5　ワークロードベースの調整
6.5.1　BLOBワークロードとTEXTワークロードのための最適化
6.5.2　MySQLサーバーの状態変数の調査
6.6　接続ごとの設定の調整

7章　オペレーティングシステムとハードウェアの最適化
7.1　MySQLのパフォーマンスを制限するもの
7.2　MySQLに合わせてCPUを選択する方法
7.2.1　CPUの速さか、CPUの数か
7.2.2　CPUアーキテクチャ
7.2.3　複数のCPUとコアへの拡張
7.3　メモリリソースとディスクリソースのバランス
7.3.1　ランダムI/OとシーケンシャルI/O
7.3.2　キャッシュ、読み取り、書き込み
7.3.3　作業セットは何か
7.3.4　メモリとディスクの効果的な割合の検出
7.3.5　ハードディスクの選択
7.4　スレーブのためのハードウェアの選択
7.5　RAIDのパフォーマンスの最適化
7.5.1　RAIDの障害、復元、監視
7.5.2　ハードウェアRAIDとソフトウェアRAIDのバランス
7.5.3　RAID設定とRAIDキャッシュ
7.6　SANとNAS
7.6.1　SAN
7.6.2　NAS
7.7　複数のディスクボリュームの使用
7.8　ネットワーク設定
7.9　オペレーティングシステムの選択
7.10　ファイルシステムの選択
7.11　スレッディング
7.12　スワッピング
7.13　オペレーティングシステムの状態
7.13.1　vmstatの出力の読み方
7.13.2　iostatの出力の読み方
7.13.3　CPUバウンドのマシン
7.13.4　I/Oバウンドのマシン
7.13.5　スワッピングマシン
7.13.6　アイドルマシン

8章　レプリケーション
8.1　レプリケーションの概要
8.1.1　レプリケーションによって解決される問題
8.1.2　レプリケーションの仕組み
8.2　レプリケーションの設定
8.2.1　レプリケーションアカウントの作成
8.2.2　マスターとスレーブの設定
8.2.3　スレーブの開始
8.2.4　別のサーバーからのスレーブの初期化
8.2.5　推奨されるレプリケーション設定
8.3　レプリケーションの裏側
8.3.1　ステートメントベースのレプリケーション
8.3.2　行ベースのレプリケーション
8.3.3　レプリケーションファイル
8.3.4　他のスレーブへのレプリケーションイベントの送信
8.3.5　レプリケーションフィルタ
8.4　レプリケーショントポロジ
8.4.1　マスターと複数のスレーブ
8.4.2　アクティブ/アクティブモードでのマスター/
　　　マスターレプリケーション
8.4.3　アクティブ/パッシブモードでのマスター/
　　　マスターレプリケーション
8.4.4　複数のスレーブを持つマスター/マスターレプリケーション
8.4.5　リングレプリケーション
8.4.6　マスター、分散マスター、スレーブ
8.4.7　ツリーまたはピラミッド
8.4.8　カスタムレプリケーションソリューション
8.5　レプリケーションとキャパシティの計画
8.5.1　レプリケーションが書き込みのスケーラビリティに役立たない理由
8.5.2　利用率を抑える計画
8.6　レプリケーションの管理とメンテナンス
8.6.1　レプリケーションの監視
8.6.2　スレーブの遅延の測定
8.6.3　スレーブとマスターの一貫性の確認
8.6.4　マスターからのスレーブの再同期
8.6.5　マスターの変更
8.6.6　マスター/マスター構成での役割の切り替え
8.7　レプリケーションの問題点と解決策
8.7.1　データの破壊または損失によるエラー
8.7.2　非トランザクショナルテーブルの使用
8.7.3　トランザクショナルテーブルと非トランザクショナルテーブルの混在
8.7.4　非決定的な文
8.7.5　マスターとスレーブでストレージエンジンが異なる
8.7.6　スレーブでのデータの変更
8.7.7　一意でないサーバーID
8.7.8　未定義のサーバーID
8.7.9　複製されていないデータへの依存
8.7.10　一時テーブルの損失
8.7.11　複製する更新の選択
8.7.12　InnoDBのロック選択によるロックの競合
8.7.13　マスター/マスターレプリケーションでの
　　　  両方のマスターへの書き込み
8.7.14　レプリケーションの過度の遅延
8.7.15　マスターからの特大パケット
8.7.16　レプリケーションの帯域幅の制限
8.7.17　ディスク領域の不足
8.7.18　レプリケーションの制限
8.8　レプリケーションの速度
8.9　MySQLレプリケーションの未来

9章　スケーラビリティと高可用性
9.1　用語
9.2　MySQLのスケーリング
9.2.1　スケーラビリティの計画
9.2.2　スケーリング前の時間稼ぎ
9.2.3　スケールアップ
9.2.4　スケールアウト
9.2.5　スケールバック
9.2.6　クラスタ化によるスケーリング
9.3　負荷分散
9.3.1　直接接続
9.3.2　プロキシの導入
9.3.3　1つのマスターと複数のスレーブによる負荷分散
9.4　高可用性
9.4.1　高可用性の計画
9.4.2　冗長性の追加
9.4.2　フェイルオーバーとフェイルバック

10章　アプリケーションレベルの最適化
10.1　アプリケーションのパフォーマンスの概要
10.1.1　問題の原因の究明
10.1.2　一般的な問題の調査
10.2　Webサーバーの問題
10.2.1　最適な並行性の模索
10.3　キャッシュ
10.3.1　アプリケーションよりも低いレベルでのキャッシュ
10.3.2　アプリケーションレベルのキャッシュ
10.3.3　キャッシュ制御ポリシー
10.3.4　キャッシュオブジェクト階層
10.3.5　コンテンツの事前生成
10.4　MySQLの拡張
10.5　MySQLに代わるもの

11章　バックアップとリカバリ
11.1　概要
11.1.1　用語
11.1.2　リカバリがすべて
11.1.3　ここで取り上げない話題
11.1.4　全体像
11.1.5　バックアップする理由
11.2　注意点と妥協点
11.2.1　失ってもよいものは何か
11.2.2　オンラインバックアップとオフラインバックアップ
11.2.3　論理バックアップとローバックアップ
11.2.4　何をバックアップするか
11.2.5　ストレージエンジンと一貫性
11.2.6　レプリケーション
11.3　バイナリログの管理とバックアップ
11.3.1　バイナリログのフォーマット
11.3.2　古いバイナリログの安全なパージ
11.4　データのバックアップ
11.4.1　論理バックアップの作成
11.4.2　ファイルシステムのスナップショット
11.5　バックアップからのリカバリ
11.5.1　MySQLへのアクセスの制限
11.5.2　ローファイルの復元
11.5.3　論理バックアップの復元
11.5.4　Point-in-Timeリカバリ
11.5.5　より高度なリカバリ手法
11.5.6　InnoDBのリカバリ
11.6　バックアップとリカバリの速さ
11.7　バックアップツール
11.7.1　mysqldump
11.7.2　mysqlhotcopy
11.7.3　InnoDB Hot Backup
11.7.4　mk-parallel-dump
11.7.5　mylvmbackup
11.7.6　Zmanda Recovery Manager
11.7.7　R1Soft
11.7.8　MySQLオンラインバックアップ
11.7.9　バックアップツールの比較
11.8　バックアップのスクリプト化

12章　セキュリティ
12.1　用語
12.2　アカウントの基礎
12.2.1　特権
12.2.2　グラントテーブル
12.2.3　MySQLが特権を確認する方法
12.2.4　グラントの追加、削除、表示
12.2.5　MySQL特権のセットアップ
12.2.6　MySQL 4.1での特権の変更
12.2.7　MySQL 5.0での特権の変更
12.2.8　特権とパフォーマンス
12.2.9　一般的な問題と解決策
12.3　オペレーティングシステムのセキュリティ
12.3.1　ガイドライン
12.4　ネットワークのセキュリティ
12.4.1　localhostのみの接続
12.4.2　ファイアウォール
12.4.3　DMZでのMySQL
12.4.4　接続の暗号化とトンネリング
12.4.5　TCPラッパー
12.4.6　ホストの自動ブロック
12.5　データの暗号化
12.5.1　パスワードのハッシュ
12.5.2　暗号化ファイルシステム
12.5.3　アプリケーションレベルの暗号化
12.5.4　ソースコードの変更
12.6　chroot環境でのMySQL

13章　MySQLサーバーの状態
13.1　システム変数
13.2　SHOW STATUS
13.2.1　スレッドと接続の統計値
13.2.2　バイナリログの状態
13.2.3　コマンドカウンタ
13.2.4　一時ファイルと一時テーブル
13.2.5　ハンドラ操作
13.2.6　MyISAMキーバッファ
13.2.7　ファイル記述子
13.2.8　クエリキャッシュ
13.2.9　SELECTの種類
13.2.10　ソート
13.2.11　テーブルロック
13.2.12　SSL
13.2.13　InnoDB固有の変数
13.2.14　プラグイン固有の変数
13.2.15　その他の変数
13.3　SHOW INNODB STATUS
13.3.1　見出し
13.3.2　SEMAPHORES
13.3.3　LATEST FOREIGN KEY ERROR
13.3.4　LATEST DETECTED DEADLOCK
13.3.5　TRANSACTIONS
13.3.6　FILE I/O
13.3.7　INSERT BUFFER AND ADAPTIVE HASH INDEX
13.3.8　LOG
13.3.9　BUFFER POOL AND MEMORY
13.3.10　ROW OPERATIONS
13.4　SHOW PROCESSLIST
13.5　SHOW MUTEX STATUS
13.6　レプリケーションの状態
13.7　INFORMATION_SCHEMA

14章　ハイパフォーマンスのためのツール
14.1　インターフェイスツール
14.1.1　MySQLのビジュアルツール
14.1.2　SQLyog
14.1.3　phpMyAdmin
14.2　監視ツール
14.2.1　非対話型の監視システム
14.2.2　対話型ツール
14.3　解析ツール
14.3.1　HackMySQLツール
14.3.2　Maatkitの解析ツール
14.4　MySQLユーティリティ
14.4.1　MySQL Proxy
14.4.2　DormandoのProxy for MySQL
14.4.3　Maatkitユーティリティ
14.5　その他の情報源

付録A　大きなファイルの転送
A.1　ファイルのコピー
A.1.1　安直な方法
A.1.2　ワンステップの方法
A.1.3　暗号化のオーバーヘッドの回避
A.1.4　その他のオプション
A.2　ファイルのコピーのベンチマーク

付録B　EXPLAINの使用
B.1　EXPLAINの実行
B.1.1　非SELECTクエリの書き換え
B.2　EXPLAINの列
B.2.1　id列
B.2.2　select_type列
B.2.3　table列
B.2.4　type列
B.2.5　possible_keys列
B.2.6　key列
B.2.7　key_len列
B.2.8　ref列
B.2.9　rows列
B.2.10　filtered列
B.2.11　Extra列
B.3　ビジュアルなEXPLAIN

付録C　MySQLでのSphinxの使用
C.1　概要：一般的なSphinx検索
C.2　Sphinxを使用する理由
C.2.1　効率的でスケーラブルな全文検索
C.2.2　WHERE句の効率的な適用
C.2.3　結果を上位のものから順に検索する
C.2.4　GROUP BYクエリの最適化
C.2.5　結果セットの並行生成
C.2.6　スケーリング
C.2.7　シャードデータの集計
C.3　アーキテクチャの概要
C.3.1　インストールの概要
C.3.2　パーティションの一般的な用途
C.4　特別な機能
C.4.1　フレーズ近傍ランキング
C.4.2　属性のサポート
C.4.3　フィルタリング
C.4.4　SphinxSEストレージエンジン
C.4.5　高度なパフォーマンス制御
C.5　実装の実例
C.5.1　Mininova.orgの全文検索
C.5.2　BoardReader.comでの全文検索
C.5.3　Sahibinden.comでの選択の最適化
C.5.4　BoardReader.comでのGROUP BYの最適化
C.5.5　Grouply.comでのシャードJOINクエリの最適化
C.6　まとめ

付録D　ロックのデバッグ
D.1　サーバーレベルでのロック待ち
D.1.1　テーブルロック
D.1.2　グローバル読み取りロック
D.1.3　名前ロック
D.1.4　ユーザーロック
D.2　ストレージエンジンでのロック待ち
D.2.1　InnoDBのロック待ち
D.2.2　Falconのロック待ち

索引

これは題名通りの本で、MySQLに特化したパフォーマンスに関する広範囲な情報が載っている本ピヨ♪ボクが読んだのは第1版なんだけど、ページ数が少なく、突っ込んだ情報がないものの、広範囲にMySQLのパフォーマンスを検討する際に役に立ったピヨ。
それで、第2版が出版されたのを知り、オライリーのサイトを見て吃驚したんだ。第1版よりも2倍近くページ数が増えているピヨっ！第1版の弱点は、突っ込んだ情報が足りない事だったから、これは期待できるピヨ♪ しかもこの本は価格もそれ程高くなく、コストパフォーマンスが優れた本ピヨ♪ パフォーマンスが悪いという事はシステムにのバグといえるピヨ。実務でMySQLを使用する人は、パフォーマンス不足というバグを未然に防ぐためにもこの本を読むべきだとボクは思う。
それと、実務で使用しないホビープログラマやプログラマを目指す人もこれを読むといいと思う。何故ならば、パフォーマンスをUPさせる事は楽しいからね♪娯楽目的で買うのもよし。


【追加情報】
もっと本が知りたいという本好きは書籍レビュー目次と書籍レビューを見ると良いピヨ♪

中の人の徒然草302

こんにちは。今日も元気なインドリです♪
昨日集合論を復習していて、ふと感じました。
「集合理論って情報処理技術ぽっくねぇ？」
例えば、順序数と数列集合の話しはとってもプログラミングチックです♪
積集合の話題である「Aの濃度はP(A)の濃度と等しくない」なんて正しく関数プログラミングの世界。
それとか、空集合φの扱い方なんかnull値の扱いと似ています。
おそらく、そういった概念が情報処理技術の構築に役立っているのだろうと考えると、先人の偉大さをひしひしと感じます。
カントールが集合論を考えたのは1870年代だから、100年以上前にあのような高度な境地に達していたわけですね。
「数学には言葉と論理しかいらない。数学の本質はその自由性にある。」by　カントール
天才は凄すぎます！これって、情報処理技術に置き換えたらぴったりです。
情報処理技術の世界は基本的に言葉と論理しかいらない世界で、インターネットの様に現実のありようさえ変化させてしまいます。
そうした自由性により、人は想像の羽で抽象的な世界へ飛び立ち、具象をも変化させてしまうのです♪
これは私が目指すものと同じです。私がオリジナルのプログラミング言語やOSなどを作りたい理由も自由の羽が欲しいからです。
現在のプログラミング言語はまだまだ窮屈です。私が考える様々な事を表現できません。
それを解消するには自分でプログラミング言語を作るしかありません。
さらに、既存のOSもまだ窮屈です。だから自分のOSを作り、自由を満喫したい。
それでも飽き足らず、もっと情報処理技術を拡張したい。
そんな内から湧き上がる欲求と情熱が私を支えています。
来年も情報処理技術を探求します。嗚呼、なんて幸せなんだろう。

中の人の徒然草301

こんばんは。インドリです。もう直ぐ2009年も終わりですね・・・
なんだか感慨深いものがあります。
2009年を振り返ってみると、並列処理に萌えたという印象が強いです。
実際は色々やっていますし、マルチスレッドプログラミングは既知なのですが、そんな私にとっても並列処理はとても印象が強かったです。
それは何故かと言いますと、マルチスレッドプログラミングと並列処理では違いが大きいからです。
マルチスレッドプログラミングはどちらかというと並行処理的発想です。しかし、TBBなどの技術は並列処理な上にスケーラブです。この差は大きい。
システム設計レベルでの変革が必要です。この点が非常に重要です。
来年以降はこの変革に対する動きが活発になるでしょう。例えば、UMLは動的図もありますが、並列指向で設計するには表現能力が不十分です。さらに、一般的な並列的設計法がありません。
並列と分散に関するデザインパターンも存在しますが、まだマルチスレッドプログラミングの延長線という印象が拭い去れません。まだまだ試行錯誤する余地があります。
如何にシステムを並列的に実現するのかをもっと探求する必要があるでしょう。
私は来年もきっとごく自然に並列処理について考えるでしょう。あまりに普通すぎて、目標とすら思いませんでした。
改めて思うに、人間の思考や行動は並列の方が自然です。今まで逐次プログラミングを行っていたのが不自然なのです。
情報処理技術が人間の思考により近づく時、いったい何が起こるのでしょうか？
非常に興味深いものがあります。
私は作る側に回りたいので、来年はより一層鍛錬が必要となります。
来年が非常に楽しみです♪来年はどんな発見が待っているのかな♪

中の人の徒然草300

やっほー♪本日



が届きました♪今ちょっと読んでみたけど、良書の予感がします。
どうやら集合理論の知識が前提として求められているようですから、集合理論の復習をしてから読みます♪
この本は絶版臭がぷんぷんするから、気になる人は一刻も早くゲットしておくといいと思います。 入手しておいたら後でゆっくり読む事が出来ます。

どうやら、来年は数学とコンパイラがテーマになりそうです。
数学を学習したらグラフィックスの道も開け、アルゴリズムがより深く理解できるようになるでしょう。
そうすれば、情報処理技術全般を学んだ事になりますので非常に楽しみです♪
来年は半年ぐらいで数学を学習し、後の半年はコンパイラの研究を進め、それと同時にグラフィックスプログラミングも学習したいです。
あと、それと並行して英語の学習もしていきます。もう洋書が読めないときついのです。
厳しいスケジュールですが、自分を甘やかしても何もいい事がありません！
私は常に自分に対して厳しい要求をしていきます。
人間はこれでいいと思ったらそこでおしまいですからね♪

中の人の徒然草299

メリークリスマス♪今日は楽しいクリスマス♪いぇいっ♪
皆はいかがお過ごしかな？私はもちろん・・・仕事ですorz
でも仕事が終わったら家族でケーキを食べたりします♪
それから、数学かプログラミングを堪能しようと思っています。
話しは変わりますが、本日アマゾンでこれを買いました。



なんか難しそうな本です。私にもわかるかな？
不安だったのですが、在庫切ればかりになるので思い切って買っちゃいました♪
本格的なコンパイラを実装しようと思ったらこれは避けられない本だと思います。
まぁ、ただ実装するだけならば、オープンソースの時代だからなんとかなると思いますが、
コードの奥に広がる世界を見つめ、オリジナルのプログラム言語を設計しようとすれば、λ計算は避けられませんね。
ラムちゃん計算が分かったらどんな世界が広がっているんだろう。
それを考えるとワク♪ワク♪します♪
LISPもどき言語ならば実装した事があるのですが、やっぱりラムダ計算を理解していると違うのでしょうね。
分かる人が見ればビリビリするプログラミングが出来るようになるかな？

ネタつつき74－オブジェクト指向に対する誤解。OOｖｓDO？

今回はオブジェクト指向に関する誤解について書きます。私はよく、オブジェクト指向は誤解を受けていると感じます。そのうちの一つがオブジェクト指向はデータ指向と対立しているという誤解です。それが誤解である事をこれから説明していきます。
誤解を解くためには、先ずオブジェクト指向とデータ指向について整理する必要がありますので、各理論を整理する事から始めます。
データ指向ことデータ中心アプローチは、データの安定性に注目して、データ基盤を共有資源として設計するアプローチ法です。このアプローチ法が考えだされた背景には、その時代の一般的な技法である構造化分析法（POA）が、データをあまり意識したものではなく、プログラム事にデータの操作が重複し、おまけにデータが分散してしまったので、保守性が低く変化に弱いシステムになってしまったという深刻な問題がありました。それを解消するために、データそのものは安定している事に注目してDOAが考えだされたのです。これにより、情報システムは以前に比べて変化に強くなりました。
それで、データの安定性とは何かと申しますと、会社は業務手順（プロセス）が変化しても、業務内容であるデータは、経営が変わらない限りそれ程変わらないという性質です。これは少し考えて頂ければ分かると思いますが、業務手順は結構変わります。その変化に合わしてシステムを作るとなると、それがどれ程大変なのか察しが付くかと思います。
しかし、データ中心な考え方もシステムが複雑化する事に従って、その弱点が露呈してきました。それは、生産効率が十分でないという点です。データ中心な考え方は、個々のシステムにとって安定性をもたらし、システムに柔軟性を生みましたが、システム開発という巨視的な視点から見ると同じことを繰り返している点で生産性は十分なものではあく、その状態では複雑化するシステムに対応しきれなくなりました。同じことを々していれば、十分なスピードで開発が出来ません。その弱点を解消するのがオブジェクト指向です。
オブジェクト指向は一言で表すのが難しい概念ですが、敢えて簡潔に表現するとすれば、物事を抽象的に扱い、それにより再利用性を高める技術となると思います。オブジェクト指向では、同じ事を繰り返すのを避けるための智慧が詰まっています。例えば、以前は画面の線画を毎回コーディングするか、コードをコピー・アンド・ペーストして、プロジェクト独自のロジックを追加していました。一方オブジェクト指向では、画面を継承する事によりそれに対応します。
また、プロセス（手順）とデータを一緒に使う事により、人間の思考を助けるのもオブジェクト指向の特徴です。データ中心アプローチを用いて変化に対応するために、データとプロセスを分離したのはいいのですが、それ故に情報が爆発的に増えました。例えば、商品データがあるとします。この時、商品を扱うプロセスは無数に存在し、関数を必要とされるだけ作っていけば、システム規模によっては数百個になるかもしれません。この様な状況が開発者にとってどれ程負担になるのかは想像がつくでしょう。これを避けるために、プロセスとデータを一体化させたのがオブジェクト指向です。
今まで述べた歴史的背景を鑑みれば、オブジェクト指向にとって、データ中心な考え方は切っても切れない関係である事が分かって頂けると思います。何故ならば、データの安定性を無視し、プロセスのみに注目して開発すれば、それはプロセス指向（構造化技法）であり、変化に弱いシステムが出来上がってしまうからです。ソフトウェア工学は学問であり、その産物であるオブジェクト指向もまた積み重ねで出来ているのです。ある日突然生まれてきた概念ではありません。
ところが、データ中心な考え方を踏まえないオブジェクト指向家？達が以外と多いのが現実です。その背景には、オブジェクト指向の宣伝が影響していると私は考えております。皆様も「オブジェクト指向は現実を反映するものであり全てをオブジェクトで表現できる」という内容の宣伝文句を見聞きした事があるでしょう。例えば、動物オブジェクトを継承し人間オブジェクトを表現できるなどといった事です。しかし、10年程実務で使っている自身の経験から私は断言できます。

オブジェクト指向は現実を全て実装できる万能の技術でありません！そんなの嘘です！！

この事実は冷静に考えれば分かると思います。人間オブジェクトはDNAを持ちます。だからと言って、ビジネス系のシステムで顧客オブジェクトにDNA情報を実装する人が居るでしょうか？商品オブジェクトと一言で言っても、林檎と魚は違う商品です。家ならばもっと違うでしょう。それらの情報をオブジェクトで表現しますか？（以下省略）・・・
これでお分かりだと思いますが、全てがオブジェクトで表現できるというのは過剰広告であり、システム開発をやりやすくするための一つの概念にしかすぎないのです。オブジェクト指向は万能ではありません。オブジェクト指向だけでシステム開発が出来るなんて甘い事はなく、開発するために色々な技術と知識が必要となります。その点を理解すれば、データ中心アプローチはオブジェクト指向と敵対するものではなく、足りない部分を補完する技術、もしくは包合された技術であると言う事が分かります。
人間がオブジェクト指向を考えだしても、依然としてデータは安定はしているのです。
その事実から目を背けてはなりません。

書籍をつつく131－Linuxプログラミング。いかしたLinuxプログラミング本。

今日はLinuxプログラミングに関する書籍を紹介するピヨ♪
Linuxプログラミング―例題で学ぶUNIXプログラミング環境のすべて
この本は凄いよー♪

【目次】
第1章 さあ、はじめよう
第2章 シェルプログラミング
第3章 ファイルの操作
第4章 UNIX環境
第5章 端末
第6章 curses
第7章 データの管理
第8章 開発ツール
第9章 デバッグ
第10章 プロセスとシグナル
第11章 プロセス間通信とパイプ
第12章 セマフォ、メッセージキュー、共有メモリ
第13章 ソケット
付録（Xプログラミングの概要
GNU General Public License（GPL）
参考文献）

この書籍は題名通りLinuxでのプログラミングを解説した本で、C言語とBシェルを使用しているピヨ♪この本の特徴は、Linux上でプログラミングをするにあたっての概念も丁寧に解説されている点ピヨ♪これは一見普通の事に思えるだろうけど、Windowsしか知らないでLinuxに不慣れな場合大変重要な事なんだ。
C言語を使ってプログラミングをする事は、どのOSでも同じように思えると思う。でも実際は、両方に十分習熟すればそうなるんだろうけど、初めてLinux場でプログラミングをする際に勝手が違って驚くと思う。というのも、WindowsとUnix系OSの思想はずいぶんと違い、その思想性の違いから開発環境や流儀が違うからなんだ。
だから、この書籍のように、開発時に必要な関連知識も教えてくれるのは凄く助かるピヨっ♪
この書籍を読めばLinuxプログラミングを楽しむ土台は出来あがるピヨ。Linuxプログラミングをしたい人は是非読もう♪


【参照情報】
もっと本が知りたいという本好きは書籍レビュー目次と書籍レビューを見ると良いピヨ♪

VC++雑談ープロセッサアフィニティとOpenMP実行ライブラリの不和？？？

今日OpenMPで遊んでいたら不思議な出来事に遭遇したピヨ。
今回はそれをお伝えするピヨ。
OpenMPには、呼び出された時点でプログラムが利用可能なプロセッサ数を返す実行時ライブラリomp_get_num_procsが規定されているピヨ。この関数の説明を読んだボクは一つの疑問が脳裏に浮かんだピヨ。
じゃあ、現在使用可能なCPUという事は、ハードアフィニティを使って、そのプログラムで利用可能なCPUを一つに制限すれば、関数の戻り値が1になるのかなって。
という事で、VC++2008で実際に試したピョッ♪


#include <stdio.h> #include <omp.h> #include <Windows.h> #include <process.h> int main(void) { printf( "現時点で利用可能なプロセッサ数は%dです。\n", 　　　　　　omp_get_num_procs() ); SetProcessAffinityMask( GetCurrentProcess(), 3 ); Sleep( 1000 ); //念のために待つ printf( "現時点で利用可能なプロセッサ数は%dです。\n", 　　　　　　omp_get_num_procs() ); printf( "\n" ); return 0; }

よし！これで2回目の実行は1を返すはずピヨ。・・・あれ？？2が返ってきたピヨォ。
現在利用可能って事は、1つのCPUにハードアフィニティしたプログラムは1を返さないとおかしいよね？
う～ん、ハードアフィニティを使用したら指定したCPUでのみ実行されるはずピヨ。
何か設定が間違っているのかもしれないから、試しにこのプログラムに無限ループを埋め込んでタスクマネージャでCPUの利用率を確認したけど、やっぱりCPU1でコードが実行されていたピヨ。という事は、確実にCPU1でしかプログラムが動かないって事だから・・・
この状況で使用できない関数に何の意味があるんだろう。どうやったら戻り値が変化するのかな？
この動作、将来のヴァージョンで見直されるといいな♪
もしかしたらこの関数、物理的に使用できるCPUの数を返すのかもしれないけど、アフィニティも考慮してくれなきゃ使いにくいピヨォ。
アフィニティも考慮して、現在利用可能なCPUが返ってきたら便利だと思うピヨ♪

中の人の徒然草298

おはようございます。体は寒くても心は熱いインドリです♪
昨日数学を学習していてふと私は考えました。
自動定理証明を工夫すれば、テスト指向言語が作れると。
昨今は品質を上げつつ短納期で情報処理システムを仕上げる事が求められております。
しかし、現状ではC++をテストしたいならばC++でという風に言語を合わす必要があります。
無論.NETやJavaなどの仮想マシンで動く実行環境ならば違う言語でテストを行えますが、いかせんテスト能力が高いとはいえません。テスト指向言語の開発が望ましいと思います。テスト指向言語を作れば、テスター達はテスト指向言語を学習するだけで高品質なテストが行えるようになります。
では、テスト指向言語とはどうゆう機能を持つべきなのかと言いますと、システムの内部まで探る機能とテストを実施するうえで便利な記法を持つ多実行環境な言語だと私は考えております。
より具体的に述べますと、次の要素が必要でしょう。

【テスト指向言語の要件】
• システムの内部の情報まで取り出せる機能を持つ事。
• 有効なテストパターンを記述できる事。
• プロファイル機能を持つ事。
• 可読性が優れている事。
• 基本的に実行環境に依存しない構文を持つ事。
• 実行環境に特化した情報も扱える事。
• セキュリティチェックを行うのに必要な機能を持つ事。
• テスト項目のチェックを行える事。
• 変化に強い事。
• パフォーマンスが測定しやすい事。
• バージョン管理ソフトなどと連携できる事。

今この瞬間に思いつくのはこれぐらいです。つまり、多くの普通のテスターがテストを間違えないようにサポートし、それでいて、熟練テスターがより高度なテストを行うための基盤も持つ言語だと言う事です。
これだけ書けば普通のシステム言語ですが、テスト指向言語には一つ重要な機能が必要です。それは、テスト計画を立てられる機能です。テストは無計画に個人々が実施するものではありません。テスト計画に基づき、ちゃんとしたテストを実施する必要があります。その時必要なのは、ドキュメントと言語間の差異をなくし、テストの漏れを防ぐための機能なのです。
これを実現するためには、テストフレームワークとアスペクト指向機能を組み合わす事になるでしょう。それに加えて、リフレクションは必須です。これを考慮すると、一番実現しやすいのは.NETかJavaです。実際私がオリジナルのテストツールを作った時、アスペクト指向・オブジェクト指向・リフレクション機能の三つが役立ちました。しかし、それで十分ではなく、Prolog的な機能も必要だと感じました。

そして、昨今の言語の機能を鑑みると、これからの言語はパラダイム（関数型・命令型などの分類の事）間の壁はより一層壊れ、マルチパラダイムが基本となると思います。それでは何を元に分類するのかと言いますと、テスト指向などの言語目的です。もちろん今までもプログラム言語の目的や目標はありましたが、より一層強い目的意識が要求される事になるでしょう。すなわち、プログラム言語の高度化です。例えるなら、第7世代言語ですね。

その様なプログラム言語の方向性は考えるのが楽しいし、実現すると有用なものですが、技術者のレベルの低下を私は危惧しています。言語が便利になるに従って技術者のレベルは反比例するのは避けられない事なのでしょうか？
私は利便性と学習の両輪を実現して欲しいと願っています。

中の人の徒然草297

こんばんは。最近めっきりブログの記事を書いていないインドリです。
大変申し訳ないのですが、今は数学と仕事に追われていますのでこのブログの記事が書けていません。
でも、最後まで書くつもりなので今しばらくお待ち下さい。

昨晩は数学の感性を取り戻すために、因数分解や複素数などの基礎問題をひたすら解いていました。
その結果、ちょっとましになりました。でもまだ昔の能力には達していませんorz
高校生の時は問題を見た瞬間に答えが閃いたんだけどなぁ・・・暗算能力が落ちているぜ。
今夜は数学に加えて、情報処理技術についての基礎を復習しようと考えています。
基礎知識って意外と忘れているかもしれませんし、改めて考える事により重大な発見があるかもしれません。
基礎って大事ですよね♪簡単だけど奥が深い時も多々あります。
では、また明日会いましょう♪ばいピヨっ♪