26/04/10Campagne Retraite "RV 2010" - V11 Campagne Retraite « Rendez-vous 2010 »
2010 in-depth-v11
description
Transcript of 2010 in-depth-v11
4D v11 SQLin Depth #1
4D v11 SQLin Depth #1
• アーキテクチャー / スケーラビリティ
Tokyo/2010-03-03/04
用語の定義
Tokyo/2010-03-03/04
用語の定義• コオペラティブ: 他のプロセス(タスク, スレッド, ...)に譲るCPU時間を自分で決めるプロセス
Tokyo/2010-03-03/04
用語の定義• コオペラティブ: 他のプロセス(タスク, スレッド, ...)に譲るCPU時間を自分で決めるプロセス
‣ 独占できる = ブロックできる(例 : Mac OS 9)
Tokyo/2010-03-03/04
用語の定義• コオペラティブ: 他のプロセス(タスク, スレッド, ...)に譲るCPU時間を自分で決めるプロセス
‣ 独占できる = ブロックできる(例 : Mac OS 9)
‣ ひとつのアプリケーションのコオペラティブスレッドは必ず同じコアで実行される
Tokyo/2010-03-03/04
用語の定義• コオペラティブ: 他のプロセス(タスク, スレッド, ...)に譲るCPU時間を自分で決めるプロセス
‣ 独占できる = ブロックできる(例 : Mac OS 9)
‣ ひとつのアプリケーションのコオペラティブスレッドは必ず同じコアで実行される
• プリエンプティブ: それぞれのプロセスに与えられるCPU時間はOSが判断する
Tokyo/2010-03-03/04
用語の定義• コオペラティブ: 他のプロセス(タスク, スレッド, ...)に譲るCPU時間を自分で決めるプロセス
‣ 独占できる = ブロックできる(例 : Mac OS 9)
‣ ひとつのアプリケーションのコオペラティブスレッドは必ず同じコアで実行される
• プリエンプティブ: それぞれのプロセスに与えられるCPU時間はOSが判断する
• プリエンプティブな度合いが高いほど速い
Tokyo/2010-03-03/04
三対のツイン
���4
Tokyo/2010-03-03/04
三対のツイン• 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツインプロセスと対話している:
‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...)
‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...)
���4
Tokyo/2010-03-03/04
三対のツイン• 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツインプロセスと対話している:
‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...)
‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...)
• プリエンプティブな第三のスレッドと対話することもある
���4
Tokyo/2010-03-03/04
三対のツイン• 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツインプロセスと対話している:
‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...)
‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...)
• プリエンプティブな第三のスレッドと対話することもある‣ これはBegin SQLが実行されると作成される
���4
Tokyo/2010-03-03/04
三対のツイン• 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツインプロセスと対話している:
‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...)
‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...)
• プリエンプティブな第三のスレッドと対話することもある‣ これはBegin SQLが実行されると作成される
• それぞれの対話は異なるネットワークポートを使用する:
���4
. . . $date:=Current date(*) . . . QUERY([City];[City]Name=”Paris”) . . . Begin SQL . . .
Tokyo/2010-03-03/04
三対のツイン• 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツインプロセスと対話している:
‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...)
‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...)
• プリエンプティブな第三のスレッドと対話することもある‣ これはBegin SQLが実行されると作成される
• それぞれの対話は異なるネットワークポートを使用する:
���4
. . . $date:=Current date(*) . . . QUERY([City];[City]Name=”Paris”) . . . Begin SQL . . .
アプリケーションサーバーポート: 19813
Tokyo/2010-03-03/04
三対のツイン• 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツインプロセスと対話している:
‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...)
‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...)
• プリエンプティブな第三のスレッドと対話することもある‣ これはBegin SQLが実行されると作成される
• それぞれの対話は異なるネットワークポートを使用する:
���4
. . . $date:=Current date(*) . . . QUERY([City];[City]Name=”Paris”) . . . Begin SQL . . .
DB4D ポート: 19814
アプリケーションサーバーポート: 19813
SQLサーバーポート: 19812
Tokyo/2010-03-03/04
Tokyo/2010-03-03/04
4D Server
サーバー
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3…⋯
ユーザー 1
Tokyo/2010-03-03/04
4D Server
サーバー
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3…⋯
ユーザー 1
プロセス U1-1 プロセス U1-1
19813 19814
Tokyo/2010-03-03/04
4D Server
サーバー
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3…⋯
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1…⋯ R2
ユーザー 3
プロセス U1-1 プロセス U1-1
プロセス U2-2
R1.. R3
19813 19814
Tokyo/2010-03-03/04
4D Server
サーバー
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3…⋯
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1…⋯ R2
ユーザー 3
プロセス U1-1
プロセス U2-1
プロセス U2-2
プロセス U3-1
プロセス U3-2
プロセス U1-1
プロセス U2-1
プロセス U2-2
プロセス U3-1
プロセス U3-2
プロセス U2-2
R1.. R3
19813 19814
Tokyo/2010-03-03/04
4D Server
サーバー
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3…⋯
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1…⋯ R2
ユーザー 3
プロセス U1-1
プロセス U2-1
プロセス U2-2
プロセス U3-1
プロセス U3-2
プロセス U1-1
プロセス U2-1
プロセス U2-2
プロセス U3-1
プロセス U3-2
プロセス U2-2
R1.. R3
19813 19814
Tokyo/2010-03-03/04
4D Server
サーバー
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3…⋯
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1…⋯ R2
ユーザー 3
プロセス U1-1
プロセス U2-1
プロセス U2-2
プロセス U3-1
プロセス U3-2
プロセス U1-1
プロセス U2-1
プロセス U2-2
プロセス U3-1
プロセス U3-2
プロセス U2-2
R1.. R3
19813 19814
Tokyo/2010-03-03/04
4D Server
サーバー
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1.. R2
ユーザー 3
プロセス U1-1
プロセス U2-1
プロセス U2-2
プロセス U3-1
プロセス U3-2
プロセス U1-1
プロセス U2-1
プロセス U2-2
プロセス U3-1
プロセス U3-2
プロセス U2-2
R1.. R2
19813 19814
Tokyo/2010-03-03/04
4D Server
サーバー
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1.. R2
ユーザー 3
プロセス U1-1
プロセス U2-1
プロセス U2-2
プロセス U3-1
プロセス U3-2
プロセス U1-1
プロセス U2-1
プロセス U2-2
プロセス U3-1
プロセス U3-2
プロセス U2-2
R1.. R2
19813 19814
Tokyo/2010-03-03/04
4D Server
サーバー
19813 19814
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1…⋯ R2
ユーザー 3
プロセス U2-2
R1.. R3
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
Tokyo/2010-03-03/04
4D Server
サーバー
19813 19814
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1.. R2
ユーザー 3
プロセス U2-2
R1.. R2
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
Tokyo/2010-03-03/04
Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...
4D Server
サーバー
19813 19814
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1.. R2
ユーザー 3
プロセス U2-2
R1.. R2
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
Tokyo/2010-03-03/04
Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...
4D Server
サーバー
19813 19814
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1.. R2
ユーザー 3
プロセス U2-2
R1.. R2
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
1
Tokyo/2010-03-03/04
Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...
4D Server
サーバー
19813 19814
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1.. R2
ユーザー 3
プロセス U2-2
R1.. R2
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
19812
Tokyo/2010-03-03/04
Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...
4D Server
サーバー
19813 19814
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1.. R2
ユーザー 3
プロセス U2-2
R1.. R2
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
19812
Tokyo/2010-03-03/04
Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...
4D Server
サーバー
19813 19814
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1.. R2
ユーザー 3
Process U2-2
R1.. R2
19812
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
Tokyo/2010-03-03/04
Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...
4D Server
サーバー
19813 19814
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1.. R2
ユーザー 3
Process U2-2
R1.. R2
19812
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
Tokyo/2010-03-03/04
Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...
4D Server
サーバー
19813 19814
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1.. R2
ユーザー 3
プロセス U2-2
R1.. R2
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
19812
Tokyo/2010-03-03/04
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
Tokyo/2010-03-03/04
伸張性と速度
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
DBリクエストは同時に複数のクライアントが実行できる
Tokyo/2010-03-03/04
伸張性と速度ボトルネック
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
DBリクエストは同時に複数のクライアントが実行できる
ランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP
4D自体: サーバーのユーザーインタフェース コネクションハンドラー ある種の外部SQLリクエスト
Tokyo/2010-03-03/04
10 クライアント, QUERY または ORDER BY 同時に実行
ボトルネック
Tokyo/2010-03-03/04
10 クライアント, QUERY または ORDER BY 同時に実行
2004以前: コオペラティブ
Tokyo/2010-03-03/04
10 クライアント, QUERY または ORDER BY 同時に実行
Tokyo/2010-03-03/04
10 クライアント, QUERY または ORDER BY 同時に実行
Tokyo/2010-03-03/04
10 クライアント, QUERY または ORDER BY 同時に実行
Tokyo/2010-03-03/04
2004以前: コオペラティブ
10 クライアント, QUERY または ORDER BY 同時に実行
Tokyo/2010-03-03/04
2004以前: コオペラティブ v11: プリエンプティブ... ...そしてスケーラブル
10 クライアント, QUERY または ORDER BY 同時に実行
Tokyo/2010-03-03/04
いろいろなサーバー
Tokyo/2010-03-03/04
いろいろなサーバー
アプリケーションサーバー
Web /SOAP
SQL サーバー
DB4D サーバー
コオペラティブ
コオペラティブ
プリエンプティブ
プリエンプティブ
Tokyo/2010-03-03/04
v11-v12デスクトップ クライアント-サーバー
コオペラティブ プリエンプティブ コオペラティブ プリエンプティブ
インタフェース全般
ランゲージ
ストアドプロシージャー
HTTP サーバー
アプリケーションサーバー
インデックスビルダー
フラッシュマネージャー
SQL サーバー
DB4D(データアクセス)
Tokyo/2010-03-03/04
v11-v12デスクトップ クライアント-サーバー
コオペラティブ プリエンプティブ コオペラティブ プリエンプティブ
インタフェース全般
ランゲージ
ストアドプロシージャー
HTTP サーバー
アプリケーションサーバー
インデックスビルダー
フラッシュマネージャー
SQL サーバー
DB4D(データアクセス)
Tokyo/2010-03-03/04
Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...
4D Server
サーバー
19813 19814
プロセス U1-1Req1... QUERY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U2-1R1... Current date(*)
R2..
ユーザー 2
プロセス U3-1R1…⋯ R2
プロセス U3-2R1.. R2
ユーザー 3
プロセス U2-2
R1.. R2
オペレーティングシステム
コオペラティブ プリエンプティブ
コア 1 コア 2 コア 3 コア 4
スケジューラー
Tokyo/2010-03-03/04
Tokyo/2010-03-03/04
ボトルネックランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP
!4D自体: サーバーのユーザーインタフェース コネクションハンドラー ある種の外部SQLリクエスト
Tokyo/2010-03-03/04
ボトルネックランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP
Tokyo/2010-03-03/04
ボトルネックランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP
• サーバーが素早く終えられるように
• トリガ:
‣ 絶対に必要な場合だけ
‣ 汎用的なコードは避ける
• クライアントからプリエンプティブに (STA/
ATS, ...)
• EXECUTE ON CLIENTが活用できるかも
• コンパイルモードで重度のループ: IDLE
• コードリファクタリング: そんなにたくさんのストアドプロシージャーがほんとうに必要 ?
• . . .
Tokyo/2010-03-03/04
ボトルネックランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP
• サーバーが素早く終えられるように
• トリガ:
‣ 絶対に必要な場合だけ
‣ 汎用的なコードは避ける
• クライアントからプリエンプティブに (STA/
ATS, ...)
• EXECUTE ON CLIENTが活用できるかも
• コンパイルモードで重度のループ: IDLE
• コードリファクタリング: そんなにたくさんのストアドプロシージャーがほんとうに必要 ?
• . . .
考量せよ
«負荷と速度»
4D v11 SQLin Depth #1
• アーキテクチャー
4D v11 SQLin Depth #1
• アーキテクチャー• SQL vs 4D
Clichy/2010-02-03
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
4D, 通常 QUERY( . . .)
SQL SELECT . . . FROM . . . WHERE . . .
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
4D, 通常 QUERY( . . .)
SQL SELECT . . . FROM . . . WHERE . . .
インタプリター
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
4D, 通常 QUERY( . . .)
SQL SELECT . . . FROM . . . WHERE . . .
インタプリター
DB4D エンジン
データファイル/インデックスファイル
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• 4Dは不可分, ワンアクションに対して高度に最適化
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• 4Dは不可分, ワンアクションに対して高度に最適化
‣ QUERY- 検索, セレクションの作成, 先頭レコードのロード- ここまでをすべてひとつのコマンドで
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• 4Dは不可分, ワンアクションに対して高度に最適化
‣ QUERY- 検索, セレクションの作成, 先頭レコードのロード- ここまでをすべてひとつのコマンドで
• SQLは汎用的
‣ ひとつの命令 (SELECT) であらゆる要求に対処
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• 4Dは不可分, ワンアクションに対して高度に最適化
‣ QUERY- 検索, セレクションの作成, 先頭レコードのロード- ここまでをすべてひとつのコマンドで
• SQLは汎用的
‣ ひとつの命令 (SELECT) であらゆる要求に対処
‣ 加えて存在するオーバーヘッド:
- 解析- 検証- SQL パススルー
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• 4Dは不可分, ワンアクションに対して高度に最適化
‣ QUERY- 検索, セレクションの作成, 先頭レコードのロード- ここまでをすべてひとつのコマンドで
• SQLは汎用的
‣ ひとつの命令 (SELECT) であらゆる要求に対処
‣ 加えて存在するオーバーヘッド:
- 解析- 検証- SQL パススルー- ランゲージバインディング
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• 4Dは不可分, ワンアクションに対して高度に最適化
‣ QUERY- 検索, セレクションの作成, 先頭レコードのロード- ここまでをすべてひとつのコマンドで
• SQLは汎用的
‣ ひとつの命令 (SELECT) であらゆる要求に対処
‣ 加えて存在するオーバーヘッド:
- 解析- 検証- SQL パススルー- ランゲージバインディング- エンジン障壁
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
4D, 通常 QUERY( . . .)
SQL SELECT . . . FROM . . . WHERE . . .
インタプリター
DB4D エンジン
データファイル/インデックスファイル
Clichy/2010-02-03
4D, 通常 QUERY( . . .)
SQL SELECT . . . FROM . . . WHERE . . .
インタプリター
DB4D エンジン
データファイル/インデックスファイル
Clichy/2010-02-03
• v11: SQL は 5-10 倍遅い場合がある
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• v11: SQL は 5-10 倍遅い場合がある
‣ しかしこれは飽くまで平均, あまり捕われないように
‣ 場合によっては, SQLのほうが速いことも
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• v11: SQL は 5-10 倍遅い場合がある
‣ しかしこれは飽くまで平均, あまり捕われないように
‣ 場合によっては, SQLのほうが速いことも- 典型例は計算を要するステートメント:
SELECT (Debits - Credits) FROM Clients into :rBalance
- プリエンプティブ
- 少ないネットワークリクエスト
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• v11: SQL は 5-10 倍遅い場合がある
‣ しかしこれは飽くまで平均, あまり捕われないように
‣ 場合によっては, SQLのほうが速いことも- 典型例は計算を要するステートメント:
SELECT (Debits - Credits) FROM Clients into :rBalance
- プリエンプティブ
- 少ないネットワークリクエスト
• SQL 12 vs SQL v11
‣ ローカルデータフェッチング => 2-3 倍高速
‣ リモートデータフェッチング => 5-20 倍高速
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• どのような場合にSQLを使用するべき ?
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• どのような場合にSQLを使用するべき ?
‣ そのほうが速いと思える根拠があるとき
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• どのような場合にSQLを使用するべき ?
‣ そのほうが速いと思える根拠があるとき‣ SQLで記述したほうが楽なとき:
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• どのような場合にSQLを使用するべき ?
‣ そのほうが速いと思える根拠があるとき‣ SQLで記述したほうが楽なとき:
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• どのような場合にSQLを使用するべき ?
‣ そのほうが速いと思える根拠があるとき‣ SQLで記述したほうが楽(美しい ?)なとき
‣ 他のDB(4Dあるいはそれ以外)に接続するとき
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• どのような場合にSQLを使用するべき ?
‣ そのほうが速いと思える根拠があるとき‣ SQLで記述したほうが楽(美しい ?)なとき
‣ 他のDB(4Dあるいはそれ以外)に接続するとき
‣ SQL特有の機能が必要なとき
SQL vs 4D - パフォーマンス
Clichy/2010-02-03
• DBメーカーの数だけ仕様が存在するというのが実情:
‣ OracleのコードがすべてMySQLで動くわけではない
‣ MySQLのコードがすべてPostgreSQLで動くわけではない
SQL-92
Clichy/2010-02-03
• DBメーカーの数だけ仕様が存在するというのが実情:
‣ OracleのコードがすべてMySQLで動くわけではない
‣ MySQLのコードがすべてPostgreSQLで動くわけではない
➡ Oracle, MySQL, PostgreSQL...で動いたコードがそのままでは4Dで動かないかもしれない(そしてこれをバグと呼ぶことはできない)
SQL-92
4D v11 SQLin Depth #1
• アーキテクチャー• SQL vs 4D
4D v11 SQLin Depth #1
• アーキテクチャー• SQL vs 4D• キャッシュ
Tokyo/2010-03-03/04
キャッシュ• 主要な目的は速度アップ(4D:データアクセス)
Tokyo/2010-03-03/04
キャッシュ• 主要な目的は速度アップ(4D:データアクセス)‣ 例:レコードをロードする
- 初回はディスクから読み込み:アクセスはミリ秒の世界
Tokyo/2010-03-03/04
キャッシュ• 主要な目的は速度アップ(4D:データアクセス)‣ 例:レコードをロードする
- 初回はディスクから読み込み:アクセスはミリ秒の世界- 以降はキャッシュから:アクセスはナノ秒の世界
Tokyo/2010-03-03/04
キャッシュ• 主要な目的は速度アップ(4D:データアクセス)‣ 例:レコードをロードする
- 初回はディスクから読み込み:アクセスはミリ秒の世界- 以降はキャッシュから:アクセスはナノ秒の世界
1,000,000 倍高速
もし 1 ns = 1 秒だとすれば, 1 ms = 11,5 日
Tokyo/2010-03-03/04
キャッシュ• 主要な目的は速度アップ(4D:データアクセス)‣ 例:レコードをロードする
- 初回はディスクから読み込み:アクセスはミリ秒の世界- 以降はキャッシュから:アクセスはナノ秒の世界
Tokyo/2010-03-03/04
キャッシュ• 主要な目的は速度アップ(4D:データアクセス)‣ 例:レコードをロードする
- 初回はディスクから読み込み:アクセスはミリ秒の世界- 以降はキャッシュから:アクセスはナノ秒の世界
• キャッシュに収納されるものは ?- テーブル, フィールド, リレーション, インデックスなどストラクチャ定義情報 - 現在のデータベースに関する全般的な情報(ファイルパス, プロパティなど) - データファイルアロケーションビットテーブル - レコード, インデックス, BLOBの追加情報, 追加プロパティなど - インデックスページ - レコード - BLOB(キャッシュに充分のスペースがなければメインメモリに行くことも) - その他のプロパティ - シーケンシャルナンバー - トランザクション - セレクション - セット - 並び替え用の一時的バッファ, 先読み, ディスク書き込み用バッファなど
Tokyo/2010-03-03/04
キャッシュ
Tokyo/2010-03-03/04
キャッシュ• ほとんどは小さなオブジェクト: (<= 64 KB)
Tokyo/2010-03-03/04
キャッシュ• ほとんどは小さなオブジェクト: (<= 64 KB)
‣ ファミリーごとにリンクしているため
Tokyo/2010-03-03/04
キャッシュ• ほとんどは小さなオブジェクト: (<= 64 KB)
‣ ファミリーごとにリンクしているため- 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは複数のアドレステーブルに読み込まれる(それぞれは <= 64 KB)
Tokyo/2010-03-03/04
キャッシュ• ほとんどは小さなオブジェクト: (<= 64 KB)
‣ ファミリーごとにリンクしているため- 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは複数のアドレステーブルに読み込まれる(それぞれは <= 64 KB)
- 例 #2: セットは小さなオブジェクトに圧縮・分散されている
Tokyo/2010-03-03/04
キャッシュ• ほとんどは小さなオブジェクト: (<= 64 KB)
‣ ファミリーごとにリンクしているため- 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは複数のアドレステーブルに読み込まれる(それぞれは <= 64 KB)
- 例 #2: セットは小さなオブジェクトに圧縮・分散されている
• おおきいオブジェクトはユーザーオブジェクト:
Tokyo/2010-03-03/04
キャッシュ• ほとんどは小さなオブジェクト: (<= 64 KB)
‣ ファミリーごとにリンクしているため- 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは複数のアドレステーブルに読み込まれる(それぞれは <= 64 KB)
- 例 #2: セットは小さなオブジェクトに圧縮・分散されている
• おおきいオブジェクトはユーザーオブジェクト:
‣ BLOB
Tokyo/2010-03-03/04
キャッシュ• ほとんどは小さなオブジェクト: (<= 64 KB)
‣ ファミリーごとにリンクしているため- 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは複数のアドレステーブルに読み込まれる(それぞれは <= 64 KB)
- 例 #2: セットは小さなオブジェクトに圧縮・分散されている
• おおきいオブジェクトはユーザーオブジェクト:
‣ BLOB ‣ ピクチャ
Tokyo/2010-03-03/04
キャッシュ• ほとんどは小さなオブジェクト: (<= 64 KB)
‣ ファミリーごとにリンクしているため- 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは複数のアドレステーブルに読み込まれる(それぞれは <= 64 KB)
- 例 #2: セットは小さなオブジェクトに圧縮・分散されている
• おおきいオブジェクトはユーザーオブジェクト:
‣ BLOB ‣ ピクチャ‣ テキスト
Tokyo/2010-03-03/04
キャッシュ• ほとんどは小さなオブジェクト: (<= 64 KB)
‣ ファミリーごとにリンクしているため- 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは複数のアドレステーブルに読み込まれる(それぞれは <= 64 KB)
- 例 #2: セットは小さなオブジェクトに圧縮・分散されている
• おおきいオブジェクトはユーザーオブジェクト:
‣ BLOB ‣ ピクチャ‣ テキスト‣ (レコード)
«BLOBs»と総称する
Tokyo/2010-03-03/04
キャッシュ
Tokyo/2010-03-03/04
キャッシュ• スタートアップで確保される
• アプリケーション実行中, 書き込み, パージ, フラッシュ, 再配置が繰り返される
Tokyo/2010-03-03/04
キャッシュ• スタートアップで確保される
• アプリケーション実行中, 書き込み, パージ, フラッシュ, 再配置が繰り返される
Tokyo/2010-03-03/04
キャッシュ• スタートアップで確保される
• アプリケーション実行中, 書き込み, パージ, フラッシュ, 再配置が繰り返される
Tokyo/2010-03-03/04
キャッシュ• スタートアップで確保される
• アプリケーション実行中, 書き込み, パージ, フラッシュ, 再配置が繰り返される
Tokyo/2010-03-03/04
キャッシュ• スタートアップで確保される
• アプリケーション実行中, 書き込み, パージ, フラッシュ, 再配置が繰り返される
• FLUSH BUFFERS
Tokyo/2010-03-03/04
キャッシュ• スタートアップで確保される
• アプリケーション実行中, 書き込み, パージ, フラッシュ, 再配置が繰り返される
• FLUSH BUFFERS• «汚れた»オブジェクトをディスクの保存すること
Tokyo/2010-03-03/04
キャッシュ• スタートアップで確保される
• アプリケーション実行中, 書き込み, パージ, フラッシュ, 再配置が繰り返される
• FLUSH BUFFERS• «汚れた»オブジェクトをディスクの保存すること
• その後 «汚れていない»という印が付けられる
Tokyo/2010-03-03/04
キャッシュ• スタートアップで確保される
• アプリケーション実行中, 書き込み, パージ, フラッシュ, 再配置が繰り返される
• FLUSH BUFFERS• «汚れた»オブジェクトをディスクの保存すること
• その後 «汚れていない»という印が付けられる
• それにより, パージしても良い状態になる
Tokyo/2010-03-03/04
キャッシュ• スタートアップで確保される
• アプリケーション実行中, 書き込み, パージ, フラッシュ, 再配置が繰り返される
• FLUSH BUFFERS• «汚れた»オブジェクトをディスクの保存すること
• その後 «汚れていない»という印が付けられる
• それにより, パージしても良い状態になる
ディスクアクセスはミリ秒の世界 !
不必要にFLUSH BUFFERSしてはいけない
Tokyo/2010-03-03/04
キャッシュキャッシュがメモリを必要とするときは ?
Tokyo/2010-03-03/04
キャッシュ
• 状況:
- ロードしなければならないオブジェクトがある: レコード,アドレステーブル, ...
- 充分なスペースがない
キャッシュがメモリを必要とするときは ?
Tokyo/2010-03-03/04
キャッシュ
• 状況:
- ロードしなければならないオブジェクトがある: レコード,アドレステーブル, ...
- 充分なスペースがない
• 行動:
キャッシュがメモリを必要とするときは ?
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
Tokyo/2010-03-03/04
キャッシュ
• 状況:
- ロードしなければならないオブジェクトがある: レコード,アドレステーブル, ...
- 充分なスペースがない
• 行動:
キャッシュがメモリを必要とするときは ?
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
Tokyo/2010-03-03/04
キャッシュ
• 状況:
- ロードしなければならないオブジェクトがある: レコード,アドレステーブル, ...
- 充分なスペースがない
• 行動:
キャッシュがメモリを必要とするときは ?
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
Tokyo/2010-03-03/04
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
キャッシュキャッシュがメモリを必要とするときは ?
Tokyo/2010-03-03/04
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
キャッシュキャッシュがメモリを必要とするときは ?
確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは100MBパージしようとする
Tokyo/2010-03-03/04
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
キャッシュキャッシュがメモリを必要とするときは ?
確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは100MBパージしようとする
パージ
Tokyo/2010-03-03/04
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
キャッシュキャッシュがメモリを必要とするときは ?
確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは100MBパージしようとする
パージ汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
キャッシュキャッシュがメモリを必要とするときは ?
確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは100MBパージしようとする
パージ
メモリをアロケート
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
キャッシュキャッシュがメモリを必要とするときは ?
確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは100MBパージしようとする
パージ
OK?
メモリをアロケート
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
キャッシュキャッシュがメモリを必要とするときは ?
確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは100MBパージしようとする
パージ
OK?
メモリをアロケート
はい
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
キャッシュキャッシュがメモリを必要とするときは ?
確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは100MBパージしようとする
パージ
OK?
メモリをアロケート
FLUSH BUFFERSいいえ はい
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース
キャッシュキャッシュがメモリを必要とするときは ?
確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは100MBパージしようとする
パージ
OK?
メモリをアロケート
FLUSH BUFFERSいいえ はい
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
キャッシュキャッシュがメモリを必要とするときは ?
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
キャッシュキャッシュがメモリを必要とするときは ?
• フラッシュする最初のオブジェクトまでジャンプ
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
キャッシュキャッシュがメモリを必要とするときは ?
• フラッシュする最初のオブジェクトまでジャンプ➡キャッシュが先にフラッシュするオブジェクトはい
つも一緒とは限らない
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
キャッシュキャッシュがメモリを必要とするときは ?
• フラッシュする最初のオブジェクトまでジャンプ➡キャッシュが先にフラッシュするオブジェクトはい
つも一緒とは限らない
• ディスクでの近接度を考慮して最適のフラッシュを試みる
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
キャッシュキャッシュがメモリを必要とするときは ?
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
キャッシュキャッシュがメモリを必要とするときは ?
v11は2004よりも劇的に速くなった汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
キャッシュキャッシュがメモリを必要とするときは ?
v11は2004よりも劇的に速くなった
• 2004: ハンドル(Mac)と連結リスト➡ オブジェクトは動いた➡ 4Dはリスト全体をたどる必要があった
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
キャッシュキャッシュがメモリを必要とするときは ?
v11は2004よりも劇的に速くなった
• 2004: ハンドル(Mac)と連結リスト➡ オブジェクトは動いた➡ 4Dはリスト全体をたどる必要があった
• V11: ポインタと一種のアドレステーブル➡ オブジェクトは動かない➡ 最大 3 アクセスでオブジェクトに到達
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
キャッシュキャッシュがメモリを必要とするときは ?
v11は2004よりも劇的に速くなった
• 2004: ハンドル(Mac)と連結リスト➡ オブジェクトは動いた➡ 4Dはリスト全体をたどる必要があった
• V11: ポインタと一種のアドレステーブル➡ オブジェクトは動かない➡ 最大 3 アクセスでオブジェクトに到達
(v11の新しいキャッシュメモリマネージャーのおかげ)
汚れていないオブジェクトをパージ
Tokyo/2010-03-03/04
キャッシュ
• 4D 32 ビット
最大サイズは ?
Tokyo/2010-03-03/04
キャッシュ
• 4D 32 ビット
➡ 最大 2.5 GB
➡ OS(32/64)に関係なく‣ ハードコードされた値‣ ユーザーが > 2.5 を設定した場合は下方修正
最大サイズは ?
Tokyo/2010-03-03/04
キャッシュ
• 4D 32 ビット
➡ 最大 2.5 GB
➡ OS(32/64)に関係なく‣ ハードコードされた値‣ ユーザーが > 2.5 を設定した場合は下方修正
• 4D 64 ビット(4D Server v12のみ)
最大サイズは ?
Tokyo/2010-03-03/04
キャッシュ
• 4D 32 ビット
➡ 最大 2.5 GB
➡ OS(32/64)に関係なく‣ ハードコードされた値‣ ユーザーが > 2.5 を設定した場合は下方修正
• 4D 64 ビット(4D Server v12のみ)
➡ «制限なし»
最大サイズは ?
4D v11 SQLin Depth #2
4D v11 SQLin Depth #2
• データベースコンテキスト(トリガ, ...)
Tokyo/2010-03-03/04
データベースコンテキスト
4D Server
プリエンプティブコオペラティブ
19813 19814
プロセス U1-1Req1... ORDER BY (Table1)
R2…⋯ R3
ユーザー 1
プロセス U1-1 プロセス U1-1
Tokyo/2010-03-03/04
データベースコンテキスト
コオペラティブプロセス U1-1
プロセス U1-1Req1... R2…⋯ R3
Tokyo/2010-03-03/04
データベースコンテキストコオペラティブ
プロセス U1-1プロセス U1-1Req1... R2…⋯ R3
Tokyo/2010-03-03/04
データベースコンテキスト
���44
コオペラティブプロセス U1-1プロセス U1-1
Req1... R2…⋯ R3
Tokyo/2010-03-03/04
データベースコンテキスト
���44
コオペラティブプロセス U1-1プロセス U1-1
Req1... R2…⋯ R3
コオペラティブツインプロセスが使用するもの:
- トリガ
- “サーバーで実行” プロパティが有効にされたメソッド
Tokyo/2010-03-03/04
データベースコンテキスト
���44
コオペラティブプロセス U1-1プロセス U1-1
Req1... R2…⋯ R3
コオペラティブツインプロセスが使用するもの:
- トリガ
- “サーバーで実行” プロパティが有効にされたメソッド
“サーバーで実行” トリガ
トランザクションステート
レコードロッキング
プロセスセット
プロセス命名セレクション
カレントセレクション
カレントレコード
Tokyo/2010-03-03/04
データベースコンテキスト
���44
コオペラティブプロセス U1-1プロセス U1-1
Req1... R2…⋯ R3
コオペラティブツインプロセスが使用するもの:
- トリガ
- “サーバーで実行” プロパティが有効にされたメソッド
“サーバーで実行” トリガ
トランザクションステート
レコードロッキング
プロセスセット
プロセス命名セレクション
カレントセレクション
カレントレコード
Tokyo/2010-03-03/04
データベースコンテキスト
���44
コオペラティブプロセス U1-1プロセス U1-1
Req1... R2…⋯ R3
コオペラティブツインプロセスが使用するもの:
- トリガ
- “サーバーで実行” プロパティが有効にされたメソッド
“サーバーで実行” トリガ
トランザクションステート
レコードロッキング
プロセスセット
プロセス命名セレクション
カレントセレクション
カレントレコード
Tokyo/2010-03-03/04
データベースコンテキスト
���44
コオペラティブプロセス U1-1プロセス U1-1
Req1... R2…⋯ R3
コオペラティブツインプロセスが使用するもの:
- トリガ
- “サーバーで実行” プロパティが有効にされたメソッド
“サーバーで実行” トリガ
トランザクションステート
レコードロッキング
プロセスセット
プロセス命名セレクション
カレントセレクション
カレントレコード
Tokyo/2010-03-03/04
データベースコンテキスト
���44
コオペラティブプロセス U1-1プロセス U1-1
Req1... R2…⋯ R3
コオペラティブツインプロセスが使用するもの:
- トリガ
- “サーバーで実行” プロパティが有効にされたメソッド
“サーバーで実行” トリガ
トランザクションステート
レコードロッキング
プロセスセット
プロセス命名セレクション
カレントセレクション
カレントレコード
Tokyo/2010-03-03/04
データベースコンテキスト
���44
コオペラティブプロセス U1-1プロセス U1-1
Req1... R2…⋯ R3
コオペラティブツインプロセスが使用するもの:
- トリガ
- “サーバーで実行” プロパティが有効にされたメソッド
“サーバーで実行” トリガ
トランザクションステート
レコードロッキング
プロセスセット
プロセス命名セレクション
カレントセレクション
カレントレコード
Tokyo/2010-03-03/04
データベースコンテキスト
���44
コオペラティブプロセス U1-1プロセス U1-1
Req1... R2…⋯ R3
コオペラティブツインプロセスが使用するもの:
- トリガ
- “サーバーで実行” プロパティが有効にされたメソッド
“サーバーで実行” トリガ
トランザクションステート
レコードロッキング
プロセスセット
プロセス命名セレクション
カレントセレクション
カレントレコード(*) トリガのテーブルのみ
(*)
Tokyo/2010-03-03/04
データベースコンテキスト
���44
コオペラティブプロセス U1-1プロセス U1-1
Req1... R2…⋯ R3
コオペラティブツインプロセスが使用するもの:
- トリガ
- “サーバーで実行” プロパティが有効にされたメソッド
“サーバーで実行” トリガ
トランザクションステート
レコードロッキング
プロセスセット
プロセス命名セレクション
カレントセレクション
カレントレコード(*) トリガのテーブルのみ
(*)
Tokyo/2010-03-03/04
データベースコンテキスト• 例: リレートセレクションのsumをトリガで計算
‣ クライアントサイド:
. . .
QUERY([OrderLines];[OrderLines]_OrderID=[Order]ID) SAVE RECORD([Order]) . . .
‣ サーバーサイド («On save existing record»)
[Order]Total:=Sum([OrderLines]Price)
Tokyo/2010-03-03/04
データベースコンテキスト• 例: リレートセレクションのsumをトリガで計算
‣ クライアントサイド:
. . .
QUERY([OrderLines];[OrderLines]_OrderID=[Order]ID) SAVE RECORD([Order]) . . .
‣ サーバーサイド («On save existing record»)
[Order]Total:=Sum([OrderLines]Price)
[OrderLines] のセレクションは空
Tokyo/2010-03-03/04
トリガ• (特性と目的を考慮する)
Tokyo/2010-03-03/04
トリガ• (特性と目的を考慮する)
• クライアントサーバー: :
‣ セレクションとカレントレコード (カレントテーブルのレコード以外)
‣ クライアントと同期が取られていない => 再現する必要がある
≠ 2004
Tokyo/2010-03-03/04
トリガ• (特性と目的を考慮する)
• クライアントサーバー: :
‣ セレクションとカレントレコード (カレントテーブルのレコード以外)
‣ クライアントと同期が取られていない => 再現する必要がある
プロセスセット,プロセス命名セレクション,レコードロッキング,トランザク
≠ 2004
Tokyo/2010-03-03/04
トリガ• (特性と目的を考慮する)
• クライアントサーバー: :
‣ セレクションとカレントレコード (カレントテーブルのレコード以外)
‣ クライアントと同期が取られていない => 再現する必要がある
プロセスセット,プロセス命名セレクション,レコードロッキング,トランザクションステートは同期がとられている
≠ 2004
Tokyo/2010-03-03/04
トリガ• (特性と目的を考慮する)
• クライアントサーバー: :
‣ セレクションとカレントレコード (カレントテーブルのレコード以外)
‣ クライアントと同期が取られていない => 再現する必要がある
プロセスセット,プロセス命名セレクション,レコードロッキング,トランザクションステートは同期がとられている
• 複数が “同時に走る” (コオペラティブスレッドのプールの中で)
• 制限
≠ 2004
Tokyo/2010-03-03/04
トリガ• (特性と目的を考慮する)
• クライアントサーバー: :
‣ セレクションとカレントレコード (カレントテーブルのレコード以外)
‣ クライアントと同期が取られていない => 再現する必要がある
プロセスセット,プロセス命名セレクション,レコードロッキング,トランザクションステートは同期がとられている
• 複数が “同時に走る” (コオペラティブスレッドのプールの中で)
• 制限‣ コオペラティブ(前述のとおり)
≠ 2004
Tokyo/2010-03-03/04
トリガ• (特性と目的を考慮する)
• クライアントサーバー: :
‣ セレクションとカレントレコード (カレントテーブルのレコード以外)
‣ クライアントと同期が取られていない => 再現する必要がある
プロセスセット,プロセス命名セレクション,レコードロッキング,トランザクションステートは同期がとられている
• 複数が “同時に走る” (コオペラティブスレッドのプールの中で)
• 制限‣ コオペラティブ(前述のとおり)
‣ 最短の時間で終了しなければならない=(汎用的でない)
≠ 2004
4D v11 SQLin Depth #2
• データベースコンテキスト(トリガ
4D v11 SQLin Depth #2
• データベースコンテキスト(トリガ• スケジューラーを理解する
Tokyo/2010-03-03/04
スケジューラー
• スケジューラーの目的 ?
• なぜv11になってもスケジューラーが必要なのか ?
Tokyo/2010-03-03/04
スケジューラー
• スケジューラーの目的 ?
• なぜv11になってもスケジューラーが必要なのか ?
‣ 4Dランゲージはスレッドセーフではないから
Tokyo/2010-03-03/04
スケジューラー
• スケジューラーの目的 ?
• なぜv11になってもスケジューラーが必要なのか ?
‣ 4Dランゲージはスレッドセーフではないから
• スケジューラーの擬似コード:
For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms)
Tokyo/2010-03-03/04
スケジューラー
For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms)
Tokyo/2010-03-03/04
スケジューラー
• 4Dは各プロセス1 tickの徹底を試みる
For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms)
Tokyo/2010-03-03/04
スケジューラー
• 4Dは各プロセス1 tickの徹底を試みる
• スケジューラーに制御を返さないプロセスは他すべてを妨害する(ユーザーインタフェースも !):
For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms)
Tokyo/2010-03-03/04
スケジューラー
• 4Dは各プロセス1 tickの徹底を試みる
• スケジューラーに制御を返さないプロセスは他すべてを妨害する(ユーザーインタフェースも !):
‣ インタプリタモードでは大丈夫
For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms)
Tokyo/2010-03-03/04
スケジューラー
• 4Dは各プロセス1 tickの徹底を試みる
• スケジューラーに制御を返さないプロセスは他すべてを妨害する(ユーザーインタフェースも !):
‣ インタプリタモードでは大丈夫‣ コンパイルモードでは起こり得る(典型的な例はIDLEをコールしない高密度ループ)For 1からプロセス数まで
If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms)
Tokyo/2010-03-03/04
スケジューラー
• 4Dは各プロセス1 tickの徹底を試みる
• スケジューラーに制御を返さないプロセスは他すべてを妨害する(ユーザーインタフェースも !):
‣ インタプリタモードでは大丈夫‣ コンパイルモードでは起こり得る(典型的な例はIDLEをコールしない高密度ループ)
‣ プラグインは PA_Yield()あるいはPA_PieldAbsolute()をコールするべき
For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms)
Tokyo/2010-03-03/04
スケジューラー実際には
Tokyo/2010-03-03/04
1.イベントをチェック(マウス, キーボード, ...)
➡ 適切な4Dプロセスに伝達する
2.その後, アクティブプロセスに1 tickずつのループに突入
スケジューラー実際には
For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms)
Tokyo/2010-03-03/04
While 4D 実行中 // システムイベントを処理 Repeat If チェック_間隔 が経過した If 4Dはビジーである タイムアウト = タイムアウト_最短 Else タイムアウト = タイムアウト_最長 End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !
// それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while
Tokyo/2010-03-03/04
While 4D 実行中 // システムイベントを処理 Repeat If チェック_間隔 が経過した If 4Dはビジーである タイムアウト = タイムアウト_最短 Else タイムアウト = タイムアウト_最長 End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !
// それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while
For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms)
Tokyo/2010-03-03/04
While 4D 実行中 // システムイベントを処理 Repeat If チェック_間隔 が経過した If 4Dはビジーである タイムアウト = タイムアウト_最短 Else タイムアウト = タイムアウト_最長 End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !
// それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while
Tokyo/2010-03-03/04
While 4D 実行中 // システムイベントを処理 Repeat If チェック_間隔 が経過した If 4Dはビジーである タイムアウト = タイムアウト_最短 Else タイムアウト = タイムアウト_最長 End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !
// それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while
Tokyo/2010-03-03/04
While 4D 実行中 // システムイベントを処理 Repeat If チェック_間隔 が経過した If 4Dはビジーである タイムアウト = タイムアウト_最短 Else タイムアウト = タイムアウト_最長 End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !
// それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while
Tokyo/2010-03-03/04
While 4D 実行中 // システムイベントを処理 Repeat If チェック_間隔 が経過した If 4Dはビジーである タイムアウト = タイムアウト_最短 Else タイムアウト = タイムアウト_最長 End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !
// それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while
SET DATABASE PARAMETER4D Server Scheduler 4D Remote Scheduler 4D Local Mode Scheduler
Tokyo/2010-03-03/04
スケジューラーデフォルト値
Tokyo/2010-03-03/04
スケジューラーデフォルト値
タイムアウト_最短 タイムアウト_最長 チェック_間隔
4Dを最高に 0 1 5
4Dを標準に 0 8 0
4Dを最低に 1 16 0
Tokyo/2010-03-03/04
スケジューラーWhile 4D 実行中 // システムイベントを処理 Repeat If チェック_間隔 が経過した If 4Dはビジーである タイムアウト = タイムアウト_最短 Else タイムアウト = タイムアウト_最長 End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !
// それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while
Tokyo/2010-03-03/04
スケジューラー: 4Dを最高にWhile 4D 実行中 // システムイベントを処理 Repeat If 5 ticks が経過した If 4Dはビジーである タイムアウト = 0 tick Else タイムアウト = 1 ticks End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !
// それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while
Tokyo/2010-03-03/04
スケジューラー: 4Dを標準にWhile 4D 実行中 // システムイベントを処理 Repeat If 0 ticks が経過した If 4Dはビジーである タイムアウト = 0 tick Else タイムアウト = 8 ticks End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !
// それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while
Tokyo/2010-03-03/04
While 4D 実行中 // システムイベントを処理 Repeat If 0 ticks が経過した If 4Dはビジーである タイムアウト = 1 tick Else タイムアウト = 16 ticks End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !
// それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while
スケジューラー: 4Dを最低に
Tokyo/2010-03-03/04
スケジューラー• SET DATABASE PARAMETER(スコープ;値)
チューニング
Tokyo/2010-03-03/04
スケジューラー• SET DATABASE PARAMETER(スコープ;値)‣ スコープ:
- 4D Server スケジューラー- 4D Remote スケジューラー- 4D Local Mode スケジューラー
チューニング
Tokyo/2010-03-03/04
スケジューラー• SET DATABASE PARAMETER(スコープ;値)‣ スコープ:
- 4D Server スケジューラー- 4D Remote スケジューラー- 4D Local Mode スケジューラー
‣ 値:- 16進数で表記: 0x00mmMMBB
‣ タイムアウト_最短: 0 から 100 (0x00 から 0x64)
‣ タイムアウト_最長: 0 から 100 (0x00 から 0x64)
‣ チェック_間隔: 0 から 20 (0x00 から 0x14)
チューニング
Tokyo/2010-03-03/04
スケジューラー• SET DATABASE PARAMETER(スコープ;値)‣ スコープ:
- 4D Server スケジューラー- 4D Remote スケジューラー- 4D Local Mode スケジューラー
‣ 値:- 16進数で表記: 0x00mmMMBB
‣ タイムアウト_最短: 0 から 100 (0x00 から 0x64)
‣ タイムアウト_最長: 0 から 100 (0x00 から 0x64)
‣ チェック_間隔: 0 から 20 (0x00 から 0x14)
- デフォルト値: -1(最高/右)-2(標準/中央)-3(最低/左)
チューニング
Tokyo/2010-03-03/04
スケジューラー• SET DATABASE PARAMETER(スコープ;値)‣ スコープ:
- 4D Server スケジューラー- 4D Remote スケジューラー- 4D Local Mode スケジューラー
‣ 値:- 16進数で表記: 0x00mmMMBB
‣ タイムアウト_最短: 0 から 100 (0x00 から 0x64)
‣ タイムアウト_最長: 0 から 100 (0x00 から 0x64)
‣ チェック_間隔: 0 から 20 (0x00 から 0x14)
- デフォルト値: -1(最高/右)-2(標準/中央)-3(最低/左)
• 実行中のエンジンにローカルの値,保存されない
チューニング
4D v11 SQLin Depth #2
• データベースコンテキスト(トリガ• スケジューラーを理解する
4D v11 SQLin Depth #2
• データベースコンテキスト(トリガ• スケジューラーを理解する• スタック(メモリ)
Tokyo/2010-03-03/04
スタックとは ?• メモリの領域
Tokyo/2010-03-03/04
スタックとは ?• メモリの領域
• コードの実行に不可欠な «オブジェクト» を収容
Tokyo/2010-03-03/04
スタックとは ?• メモリの領域
• コードの実行に不可欠な «オブジェクト» を収容
• LIFOスタック:
‣ 返り値が収容される場所‣ パラメーター‣ ローカル変数‣ (サブルーチン毎)
Tokyo/2010-03-03/04
スタックのサイズプリエンプティブ スレッド: デフォルトサイズ
Tokyo/2010-03-03/04
スタックのサイズプリエンプティブ スレッド: デフォルトサイズ
OS サイズWindows 1 MB
Leopard 512 KB
Snow Leopard 1 MB
Tokyo/2010-03-03/04
スタックのサイズプリエンプティブ スレッド: デフォルトサイズ
OS サイズWindows 1 MB
Leopard 512 KB
Snow Leopard 1 MB
• DB4D サーバー
• SQL ネットセッションマネージャー
• SQL ネットコネクション
• 予備 SQL
• クライアントグローバルプロセスのプリエンプティブツイン
Tokyo/2010-03-03/04
スタックのサイズプリエンプティブ スレッド: デフォルトサイズ
OS サイズWindows 1 MB
Leopard 512 KB
Snow Leopard 1 MB
• DB4D サーバー
• SQL ネットセッションマネージャー
• SQL ネットコネクション
• 予備 SQL
• クライアントグローバルプロセスのプリエンプティブツイン
GET/SET DATABASE PARAMETER(53;バイト数)
Tokyo/2010-03-03/04
スタックのサイズプリエンプティブスレッド: ハードコード値
➡フラッシュマネージャー (512 KB)
➡インデックスビルダー (512 KB)
Tokyo/2010-03-03/04
スタックのサイズコオペラティブスレッド
Tokyo/2010-03-03/04
スタックのサイズ
• 4Dコードを実行するため
• 起源:
‣ ランゲージ - New process / Execute on server
- 自動 ‣ Web/SOAP サーバープロセス ‣ メニューアイテムのプロパティ, ...
‣ On exit データベースメソッド
‣ 内部コード - ランタイムエクスプローラー, リモート管理画面, SQL プロセス, ...
コオペラティブスレッド
Tokyo/2010-03-03/04
スタックのサイズ
• 最終的に配分される値は常に増量されているコオペラティブスレッド
Tokyo/2010-03-03/04
スタックのサイズ
• 最終的に配分される値は常に増量されている‣ Windows- realSize = requested + 40 KB
‣ Mac- realSize = requested + (requested / 2) + 128 KB
コオペラティブスレッド
Tokyo/2010-03-03/04
スタックのサイズ
• 最終的に配分される値は常に増量されている‣ Windows- realSize = requested + 40 KB
‣ Mac- realSize = requested + (requested / 2) + 128 KB
• 512 KB要求した場合, 配分されるのは:
‣ Windows では 552 KB
‣ Mac では 896 KB
コオペラティブスレッド
Tokyo/2010-03-03/04
スタックのサイズコオペラティブスレッド
New process() とスタック要求値
(rs)
プラットフォーム
再定義 配分値
Tokyo/2010-03-03/04
スタックのサイズコオペラティブスレッド
New process() とスタック要求値
(rs)
プラットフォーム
再定義 配分値
0 Windows 512 KB 552 KB0 Mac 512 KB 896 KB
> 0 および < 16 KB Windows 16 KB 56 KB> 0 および < 16 KB Mac 16 KB 152 KB
> 16 KB Windows 変更なし rs + 40 KB> 16 KB Mac OS 変更なし rs + (rs/2) + 128 KB
< 0Windows
Mac変更なし
rs + 40 KB
rs + (rs/2) + 128 KB
絶対にダメ. 例えば, -128*1024 を要求した場合, 4Dは4GBを配分しようとしてしまう(符号つき/符号なしの変換)
Execute on serverに-1はNew processに0と同じ
Tokyo/2010-03-03/04
スタックのサイズコオペラティブスレッド
Tokyo/2010-03-03/04
スタックのサイズ
• デフォルト値:
‣ '4STK' リソース
コオペラティブスレッドID 名称 値1 On event call 512 KB2 On serial port call 512 KB
3Exec on server, on client, メソッド実行, マクロ 512 KB
4 メニュー新プロセス 512 KB5 サーバータスク 256 KB6 旧・バックアップ 512 KB7 旧・復元 512 KB8 Web 256 KB
9Server event loop, cache, runtime explorer
512 KB
10 アップルイベント 512 KB
Tokyo/2010-03-03/04
スタックのサイズ
• デフォルト値:
‣ '4STK' リソース
コオペラティブスレッドID 名称 値1 On event call 512 KB2 On serial port call 512 KB
3Exec on server, on client, メソッド実行, マクロ 512 KB
4 メニュー新プロセス 512 KB5 サーバータスク 256 KB6 旧・バックアップ 512 KB7 旧・復元 512 KB8 Web 256 KB
9Server event loop, cache, runtime explorer
512 KB
10 アップルイベント 512 KB
クライアントグローバルプロセスのサーバーコオペラティブツイン
Tokyo/2010-03-03/04
スタックのサイズ
• デフォルト値:
‣ '4STK' リソース
コオペラティブスレッドID 名称 値1 On event call 512 KB2 On serial port call 512 KB
3Exec on server, on client, メソッド実行, マクロ 512 KB
4 メニュー新プロセス 512 KB5 サーバータスク 256 KB6 旧・バックアップ 512 KB7 旧・復元 512 KB8 Web 256 KB
9Server event loop, cache, runtime explorer
512 KB
10 アップルイベント 512 KB
クライアントグローバルプロセスのサーバーコオペラティブツイン
実際の値552-896 KB552-896 KB
552-896 KB
552-896 KB296-512 KB552-896 KB552-896 KB296-512 KB
552-896 KB
552-896 KB
Tokyo/2010-03-03/04
4D Server
Operating System
Cooperatives Preemptives
Core 1 Core 2 Core 3 Core 4
Scheduler
Tokyo/2010-03-03/04
4D Server
Operating System
Cooperatives Preemptives
Core 1 Core 2 Core 3 Core 4
Scheduler
100 クライアント - 2 グローバルプロセス / クライアント !
サーバーのツインスレッドが占有するメモリのサイズは?
Tokyo/2010-03-03/04
4D Server
Operating System
Cooperatives Preemptives
Core 1 Core 2 Core 3 Core 4
Scheduler
100 クライアント - 2 グローバルプロセス / クライアント !
サーバーのツインスレッドが占有するメモリのサイズは?
258 MB(W)
300 MB(SL)
200 MB(L)
Tokyo/2010-03-03/04
4D Server
Operating System
Cooperatives Preemptives
Core 1 Core 2 Core 3 Core 4
Scheduler
100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合
!サーバーのツインスレッドが占有するメモリのサイズは?
Tokyo/2010-03-03/04
4D Server
Operating System
Cooperatives Preemptives
Core 1 Core 2 Core 3 Core 4
Scheduler
100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合
!サーバーのツインスレッドが占有するメモリのサイズは?
Tokyo/2010-03-03/04
4D Server
Operating System
Cooperatives Preemptives
Core 1 Core 2 Core 3 Core 4
Scheduler
100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合
!サーバーのツインスレッドが占有するメモリのサイズは?
458 MB (W)
500 MB (SL)
300 MB (L)
4D v11 SQLin Depth #2
• データベースコンテキスト(トリガ• スケジューラーを理解する• スタック(メモリ)
4D v11 SQLin Depth #2
• データベースコンテキスト(トリガ• スケジューラーを理解する• スタック(メモリ)• パラダイムシフト
Tokyo/2010-03-03/04
廃止予定
Tokyo/2010-03-03/04
廃止予定• 4D誕生から25年が経過 !
Tokyo/2010-03-03/04
廃止予定• 4D誕生から25年が経過 !
• この間に種々のコンセプトは進化した
• OSが変わった, これからも変わり続ける
‣ 68k, PPC, x86, 64Bits
‣ OS9, OSX, Carbon, Cocoa
• 4Dコードの互換性が失われてはいけない
• しかし, そうはいっても...
Tokyo/2010-03-03/04
4D Draw
Tokyo/2010-03-03/04
4D Draw
• QuickDrawを使用している
• Alturaでエミュレーション
• 座標系に整数を使用, フォント番号, 模様パターン, ...
• 現行の画像形式が開けない, 独自のフォーマットを使用
• 4D Draw文書を4Dの外部で編集する術がない
Tokyo/2010-03-03/04
SVG
Tokyo/2010-03-03/04
SVG
• CoreGraphics & CoreText, GDI+を使用
• 標準テキスト形式 (xml)
• 高度なエフェクト: グラデーション, 透明度, レイヤー, 回転, 変形, 組み込み,...
• 4Dピクチャ操作コマンドはすべてそのまま使用できる
• フォームオブジェクトとして表示や操作もできる‣ MiniDraw (v12)
• 1月, SVGワーキンググループにIEチームが加入 !
•
Tokyo/2010-03-03/04
4D Open
Tokyo/2010-03-03/04
4D Open
• 4D Openは4D v11でも動作する
‣ ただしインタプリタモードのみ
• さまざまな方法で置き換えられる:
‣ HTTP- DOM Parse XML source( «http://site.com»)
‣ Webサービス
‣ SQLパススルー
‣ 複製と同期 (v12)
Tokyo/2010-03-03/04
PICT
Tokyo/2010-03-03/04
PICT
• 4DはWindowsでも画像をPICTで保存していた
• 4D v11はPICTが渡されたときだけPICTを使用する
• AppleはPICTフォーマットを廃止する予定
• 4DはAppleに頼ってMacでPICTを解読している
• 4DはAlturaまたはQuickTimeに頼ってWindowsでPICTを解読している
• CONVERT PICTUREを推奨• BLOB TO PICTURE( «.4dblob»)
Tokyo/2010-03-03/04
uickTime
Tokyo/2010-03-03/04
uickTime
• QuickTime はいまや動画処理に注力している技術
• 4D v11はQuickTimeをもはや必要とはしない
• 4D v12はImageIOおよび Windows Imaging Component (WIC) をサポート
• QuickTimeを使用するコマンドは4D v12ですべて接頭辞‘QT’が付き, 廃止予定に‣ QT COMPRESS PICTURE
‣ QT LOAD COMPRESSED PICTURE FROM FILE
‣ QT COMPRESS PICTURE FILE
‣ CONVERT PICTURE, READ PICTURE FILE, WRITE PICTURE FILEで代用
Tokyo/2010-03-03/04
ピクチャ
Tokyo/2010-03-03/04
ピクチャ• 別名で保存:
• インストールされたドライバー次第で, ほとんどのメーカーのカメラ形式をサポート
• 4D Picture形式は複数のフォーマットおよび変形を保存できる独自のコンテナ形式
Tokyo/2010-03-03/04
リソース
Tokyo/2010-03-03/04
リソース• Unicode非対応, リソースの上限は2727個または16MB
• Appleはサポートを中止, Windowsエディタ無し
• テキストはxliff, ピクチャは pngが主流
• フォームエディタとランゲージでxliffとピクチャファイルをサポート
• 4Dはいずれリソースの書き出しが不可能に
• 読み取りは当面できるはずだが, PICTリソースは無理
Tokyo/2010-03-03/04
Tokyo/2010-03-03/04
• 4DのWindows移植に一役買った技術
• 毎回の4Dバージョンアップで少しずつMac2Win依存をなくしてきた
• 互換性のためにいまだ多く依存が残されている:
‣ リソース, PICT, プラグイン
• Mac2Winを使用しているプラグインは, 依存関係を切る,
さもなければ4Dに見切られる運命...
• いまはまだAsifont.mapを使用
Tokyo/2010-03-03/04
昔のルックスSystem 7 Windows 3.11 Mac OS 9 Windows 95
Tokyo/2010-03-03/04
昔のルックス
• QuickDraw および Altura 使用のカスタムコード
• 4D 2004 で廃止予定の対象に
• 4D v13でシステムアピアランスに変換される運命
• 4D v13まで先延ばしにしないで !
System 7 Windows 3.11 Mac OS 9 Windows 95
Tokyo/2010-03-03/04
昔のルックス• 時 ,々 エンドユーザーの反応が気になりませんか ?
Tokyo/2010-03-03/04
昔のルックス• 時 ,々 エンドユーザーの反応が気になりませんか ?
Tokyo/2010-03-03/04
サブテーブル
Tokyo/2010-03-03/04
サブテーブル• 特殊なリレーションに変換される
• サブテーブルコマンドはすべてまだ動作する‣ 例外 SEND RECORD, DUPLICATE RECORD
• いますぐ廃止される訳ではない
• テーブルへの変換が完了するまでの猶予を設けている
Tokyo/2010-03-03/04
MODIFY SELECTION DISPLAY SELECTION
Tokyo/2010-03-03/04
MODIFY SELECTION DISPLAY SELECTION
• 廃止予定ではないけれど, 4Dアプリケーションがユーザーから低い評価を受けてしまう理由のひとつ
Tokyo/2010-03-03/04
Tokyo/2010-03-03/04
MODIFY SELECTION DISPLAY SELECTION
• 廃止予定ではないけれど, 4Dアプリケーションがユーザーから低い評価を受けてしまう理由のひとつ
Tokyo/2010-03-03/04
MODIFY SELECTION DISPLAY SELECTION
‣ リストボックスまたはサブフォームを推奨
• 要件に合うのならばリストボックス(配列・セレクション)を使用 !
• 特殊な必要があり, リストボックスがダメならばサブフォームを使用 !
• 廃止予定ではないけれど, 4Dアプリケーションがユーザーから低い評価を受けてしまう理由のひとつ
Tokyo/2010-03-03/04
ラベルエディター
Tokyo/2010-03-03/04
ラベルエディター• 4D 最古のエディターのひとつ
• PRINT OBJECT (v12) はすごく便利 !
• 新しい 4D コンポーネントを現在検討中
4D v12The Next Version