Recomendados
Más contenido relacionado
Destacado
Destacado (20)
Similar a 2010 in-depth-v11
Similar a 2010 in-depth-v11 (20)
Más de kmiyako
Más de kmiyako (20)
2010 in-depth-v11
- 1. 4D v11 SQL in Depth #1
- 2. 4D v11 SQL in Depth #1 • アーキテクチャー / スケーラビリティ
- 5. 用語の定義 • コオペラティブ: 他のプロセス（タスク,スレッ ド,...）に譲るCPU時間を自分で決めるプロセス ‣ 独占できる = ブロックできる（例 : Mac OS 9） Tokyo/2010-03-03/04
- 6. 用語の定義 • コオペラティブ: 他のプロセス（タスク,スレッ ド,...）に譲るCPU時間を自分で決めるプロセス ‣ 独占できる = ブロックできる（例 : Mac OS 9） ‣ ひとつのアプリケーションのコオペラティブス レッドは必ず同じコアで実行される Tokyo/2010-03-03/04
- 7. 用語の定義 • コオペラティブ: 他のプロセス（タスク,スレッ ド,...）に譲るCPU時間を自分で決めるプロセス ‣ 独占できる = ブロックできる（例 : Mac OS 9） ‣ ひとつのアプリケーションのコオペラティブス レッドは必ず同じコアで実行される • プリエンプティブ: それぞれのプロセスに与えられ るCPU時間はOSが判断する Tokyo/2010-03-03/04
- 8. 用語の定義 • コオペラティブ: 他のプロセス（タスク,スレッ ド,...）に譲るCPU時間を自分で決めるプロセス ‣ 独占できる = ブロックできる（例 : Mac OS 9） ‣ ひとつのアプリケーションのコオペラティブス レッドは必ず同じコアで実行される • プリエンプティブ: それぞれのプロセスに与えられ るCPU時間はOSが判断する • プリエンプティブな度合いが高いほど速い Tokyo/2010-03-03/04
- 10. 三対のツイン • 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツイ ンプロセスと対話している: ‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...) ‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...) 4 Tokyo/2010-03-03/04
- 11. 三対のツイン • 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツイ ンプロセスと対話している: ‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...) ‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...) • プリエンプティブな第三のスレッドと対話することもある 4 Tokyo/2010-03-03/04
- 12. 三対のツイン • 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツイ ンプロセスと対話している: ‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...) ‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...) • プリエンプティブな第三のスレッドと対話することもある ‣ これはBegin SQLが実行されると作成される 4 Tokyo/2010-03-03/04
- 13. 三対のツイン • 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツイ ンプロセスと対話している: ‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...) ‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...) • プリエンプティブな第三のスレッドと対話することもある ‣ これはBegin SQLが実行されると作成される • それぞれの対話は異なるネットワークポートを使用する: . . . $date:=Current date(*) . . . QUERY([City];[City]Name=”Paris”) . . . Begin SQL ... 4 Tokyo/2010-03-03/04
- 14. 三対のツイン • 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツイ ンプロセスと対話している: ‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...) ‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...) • プリエンプティブな第三のスレッドと対話することもある ‣ これはBegin SQLが実行されると作成される • それぞれの対話は異なるネットワークポートを使用する: . . . $date:=Current date(*) アプリケーションサーバーポート: 19813 . . . QUERY([City];[City]Name=”Paris”) . . . Begin SQL ... 4 Tokyo/2010-03-03/04
- 15. 三対のツイン • 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツイ ンプロセスと対話している: ‣ プリエンプティブ スレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...) ‣ コオペラティブ スレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...) • プリエンプティブな第三のスレッドと対話することもある ‣ これはBegin SQLが実行されると作成される • それぞれの対話は異なるネットワークポートを使用する: . . . $date:=Current date(*) アプリケーションサーバーポート: 19813 . . . QUERY([City];[City]Name=”Paris”) DB4D ポート: 19814 . . . SQLサーバーポート: 19812 Begin SQL ... 4 Tokyo/2010-03-03/04
- 17. ユーザー 1 プロセス U1-1 Req1... QUERY (Table1) R2…⋯ R3…⋯ サーバー 4D Server コオペラティブ コア 1 コア 2 プリエンプティブ コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 18. ユーザー 1 プロセス U1-1 Req1... QUERY (Table1) R2…⋯ R3…⋯ サーバー 4D Server 19813 19814 コオペラティブ プロセス U1-1 コア 1 プリエンプティブ プロセス U1-1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 19. ユーザー 1 ユーザー 2 プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R2…⋯ R3…⋯ R1... Current date(*) R2.. R1.. R3 プロセス U3-1 R1…⋯ R2 プロセス U3-2 R1…⋯ R2 サーバー 4D Server 19813 19814 コオペラティブ プロセス U1-1 コア 1 プリエンプティブ プロセス U1-1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 20. ユーザー 1 ユーザー 2 プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R2…⋯ R3…⋯ R1... Current date(*) R2.. R1.. R3 プロセス U3-1 R1…⋯ R2 プロセス U3-2 R1…⋯ R2 サーバー 4D Server 19813 19814 コオペラティブ プリエンプティブ プロセス U1-1 プロセス U3-1 プロセス U1-1 プロセス U3-1 プロセス U2-1 プロセス U3-2 プロセス U2-1 プロセス U3-2 プロセス U2-2 コア 1 プロセス U2-2 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 21. ユーザー 1 ユーザー 2 プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R2…⋯ R3…⋯ R1... Current date(*) R2.. R1.. R3 プロセス U3-1 R1…⋯ R2 プロセス U3-2 R1…⋯ R2 サーバー 4D Server 19813 19814 コオペラティブ プリエンプティブ プロセス U1-1 プロセス U3-1 プロセス U1-1 プロセス U3-1 プロセス U2-1 プロセス U3-2 プロセス U2-1 プロセス U3-2 プロセス U2-2 コア 1 プロセス U2-2 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 22. ユーザー 1 ユーザー 2 プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R2…⋯ R3…⋯ R1... Current date(*) R2.. R1.. R3 プロセス U3-1 R1…⋯ R2 プロセス U3-2 R1…⋯ R2 サーバー 4D Server 19813 19814 コオペラティブ プリエンプティブ プロセス U1-1 プロセス U3-1 プロセス U1-1 プロセス U3-1 プロセス U2-1 プロセス U3-2 プロセス U2-1 プロセス U3-2 プロセス U2-2 コア 1 プロセス U2-2 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 23. ユーザー 1 ユーザー 2 プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R2…⋯ R3 R1... Current date(*) R2.. R1.. R2 プロセス U3-1 R1…⋯ R2 プロセス U3-2 R1.. R2 サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ プロセス U1-1 プロセス U3-1 プロセス U1-1 プロセス U3-1 プロセス U2-1 プロセス U3-2 プロセス U2-1 プロセス U3-2 プロセス U2-2 コア 1 プロセス U2-2 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 24. ユーザー 1 ユーザー 2 プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R2…⋯ R3 R1... Current date(*) R2.. R1.. R2 プロセス U3-1 R1…⋯ R2 プロセス U3-2 R1.. R2 サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ プロセス U1-1 プロセス U3-1 プロセス U1-1 プロセス U3-1 プロセス U2-1 プロセス U3-2 プロセス U2-1 プロセス U3-2 プロセス U2-2 コア 1 プロセス U2-2 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 25. ユーザー 1 ユーザー 2 R2…⋯ プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R3 R1... Current date(*) R2.. R1.. R3 プロセス U3-1 R1…⋯ R2 プロセス U3-2 R1…⋯ R2 サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 26. ユーザー 1 ユーザー 2 R2…⋯ プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R3 R1... Current date(*) R2.. R1.. R2 プロセス U3-1 R1…⋯ R2 プロセス U3-2 R1.. R2 サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 27. ユーザー 1 ユーザー 2 R2…⋯ プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R3 R1... Current date(*) Begin SQL... R2.. R1.. Begin SQL... R2 Begin SQL... プロセス U3-1 R1…⋯ R2 Begin SQL... プロセス U3-2 R1.. R2 Begin SQL... サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 28. ユーザー 1 ユーザー 2 R2…⋯ プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R3 R1... Current date(*) Begin SQL... R2.. R1.. Begin SQL... R2 Begin SQL... プロセス U3-1 R1…⋯ R2 Begin SQL... プロセス U3-2 R1.. R2 Begin SQL... サーバー 19813 19814 1 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 29. ユーザー 1 ユーザー 2 R2…⋯ プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R3 R1... Current date(*) Begin SQL... R2.. R1.. Begin SQL... R2 Begin SQL... プロセス U3-1 R1…⋯ R2 Begin SQL... プロセス U3-2 R1.. R2 Begin SQL... サーバー 19813 19814 19812 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 30. ユーザー 1 ユーザー 2 R2…⋯ プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R3 R1... Current date(*) Begin SQL... R2.. R1.. Begin SQL... R2 Begin SQL... プロセス U3-1 R1…⋯ R2 Begin SQL... プロセス U3-2 R1.. R2 Begin SQL... サーバー 19813 19814 19812 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 31. ユーザー 1 ユーザー 2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) R2…⋯ ユーザー 3 R3 R1... Current date(*) Begin SQL... Process U2-2 R2.. R1.. Begin SQL... R2 Begin SQL... プロセス U3-1 R1…⋯ R2 Begin SQL... プロセス U3-2 R1.. R2 Begin SQL... サーバー 19813 19814 19812 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 32. ユーザー 1 ユーザー 2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) R2…⋯ ユーザー 3 R3 R1... Current date(*) Begin SQL... Process U2-2 R2.. R1.. Begin SQL... R2 Begin SQL... プロセス U3-1 R1…⋯ R2 Begin SQL... プロセス U3-2 R1.. R2 Begin SQL... サーバー 19813 19814 19812 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 33. ユーザー 1 ユーザー 2 R2…⋯ プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R3 R1... Current date(*) Begin SQL... R2.. R1.. Begin SQL... R2 Begin SQL... プロセス U3-1 R1…⋯ R2 Begin SQL... プロセス U3-2 R1.. R2 Begin SQL... サーバー 19813 19814 19812 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 34. コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 35. コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム 伸張性と速度 DBリクエストは同時に複数の クライアントが実行できる Tokyo/2010-03-03/04
- 36. コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム ボトルネック ランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP 4D自体: サーバーのユーザーインタフェース コネクションハンドラー ある種の外部SQLリクエスト 伸張性と速度 DBリクエストは同時に複数の クライアントが実行できる Tokyo/2010-03-03/04
- 37. 10 クライアント, QUERY または ORDER BY 同時に実 行 ボトルネック Tokyo/2010-03-03/04
- 38. 10 クライアント, QUERY または ORDER BY 同時に実 行 2004以前: コオペラティブ Tokyo/2010-03-03/04
- 39. 10 クライアント, QUERY または ORDER BY 同時に実 行 Tokyo/2010-03-03/04
- 40. 10 クライアント, QUERY または ORDER BY 同時に実 行 Tokyo/2010-03-03/04
- 41. 10 クライアント, QUERY または ORDER BY 同時に実 行 Tokyo/2010-03-03/04
- 42. 10 クライアント, QUERY または ORDER BY 同時に実 行 2004以前: コオペラティブ Tokyo/2010-03-03/04
- 43. 10 クライアント, QUERY または ORDER BY 同時に実 行 2004以前: コオペラティブ v11: プリエンプティブ... ...そしてスケーラブル Tokyo/2010-03-03/04
- 45. いろいろなサーバー アプリケーションサーバー コオペラティブ Web /SOAP コオペラティブ SQL サーバー プリエンプティブ DB4D サーバー プリエンプティブ Tokyo/2010-03-03/04
- 48. ユーザー 1 ユーザー 2 R2…⋯ プロセス U2-2 プロセス U2-1 プロセス U1-1 Req1... QUERY (Table1) ユーザー 3 R3 R1... Current date(*) Begin SQL... R2.. R1.. Begin SQL... R2 Begin SQL... プロセス U3-1 R1…⋯ R2 Begin SQL... プロセス U3-2 R1.. R2 Begin SQL... サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
- 52. • ボトルネック ランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP サーバーが素早く終えられるように • トリガ: ‣ 絶対に必要な場合だけ ‣ 汎用的なコードは避ける • クライアントからプリエンプティブに (STA/ ATS, ...) • EXECUTE ON CLIENTが活用できるかも • コンパイルモードで重度のルー IDLE プ: • コードリファクタリング: そんなにたくさんのス トアドプロシージャーがほんとうに必要 ? • ... Tokyo/2010-03-03/04
- 53. • • ボトルネック ランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP 度» 速 と 荷 考 «負 よ 量せ サーバーが素早く終えられるように トリガ: ‣ 絶対に必要な場合だけ ‣ 汎用的なコードは避ける • クライアントからプリエンプティブに (STA/ ATS, ...) • EXECUTE ON CLIENTが活用できるかも • コンパイルモードで重度のルー IDLE プ: • コードリファクタリング: そんなにたくさんのス トアドプロシージャーがほんとうに必要 ? • ... Tokyo/2010-03-03/04
- 54. 4D v11 SQL in Depth #1 • アーキテクチャー
- 55. 4D v11 SQL in Depth #1 • アーキテクチャー • SQL vs 4D
- 56. SQL vs 4D - パフォーマンス Clichy/2010-02-03
- 57. SQL vs 4D - パフォーマンス 4D, 通常 QUERY( . . .) SELECT ... SQL FROM ... WHERE ... Clichy/2010-02-03
- 58. SQL vs 4D - パフォーマンス 4D, 通常 QUERY( . . .) SELECT ... SQL FROM ... WHERE ... インタプリター Clichy/2010-02-03
- 59. SQL vs 4D - パフォーマンス 4D, 通常 QUERY( . . .) SELECT ... SQL FROM ... WHERE ... インタプリター DB4D エンジン データファイル/インデックスファイル Clichy/2010-02-03
- 60. SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 Clichy/2010-02-03
- 61. SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 ‣ QUERY - 検索,セレクションの作成,先頭レコードのロード - ここまでをすべてひとつのコマンドで Clichy/2010-02-03
- 62. SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 ‣ QUERY - 検索,セレクションの作成,先頭レコードのロード - ここまでをすべてひとつのコマンドで • SQLは汎用的 ‣ ひとつの命令 (SELECT) であらゆる要求に対処 Clichy/2010-02-03
- 63. SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 ‣ QUERY - 検索,セレクションの作成,先頭レコードのロード - ここまでをすべてひとつのコマンドで • SQLは汎用的 ‣ ひとつの命令 (SELECT) であらゆる要求に対処 ‣ 加えて存在するオーバーヘッド: - 解析 - 検証 - SQL パススルー Clichy/2010-02-03
- 64. SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 ‣ QUERY - 検索,セレクションの作成,先頭レコードのロード - ここまでをすべてひとつのコマンドで • SQLは汎用的 ‣ ひとつの命令 (SELECT) であらゆる要求に対処 ‣ 加えて存在するオーバーヘッド: - 解析 検証 SQL パススルー ランゲージバインディング Clichy/2010-02-03
- 65. SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 ‣ QUERY - 検索,セレクションの作成,先頭レコードのロード - ここまでをすべてひとつのコマンドで • SQLは汎用的 ‣ ひとつの命令 (SELECT) であらゆる要求に対処 ‣ 加えて存在するオーバーヘッド: - 解析 検証 SQL パススルー ランゲージバインディング エンジン障壁 Clichy/2010-02-03
- 66. 4D, 通常 QUERY( . . .) SELECT ... SQL FROM ... WHERE ... インタプリター DB4D エンジン データファイル/インデックスファイル Clichy/2010-02-03
- 67. 4D, 通常 QUERY( . . .) SELECT ... SQL FROM ... WHERE ... インタプリター DB4D エンジン データファイル/インデックスファイル Clichy/2010-02-03
- 68. SQL vs 4D - パフォーマンス • v11: SQL は 5-10 倍遅い場合がある Clichy/2010-02-03
- 69. SQL vs 4D - パフォーマンス • v11: SQL は 5-10 倍遅い場合がある ‣ しかしこれは飽くまで平均, あまり捕われないように ‣ 場合によっては, SQLのほうが速いことも Clichy/2010-02-03
- 70. SQL vs 4D - パフォーマンス • v11: SQL は 5-10 倍遅い場合がある ‣ しかしこれは飽くまで平均, あまり捕われないように ‣ 場合によっては, SQLのほうが速いことも - 典型例は計算を要するステートメント: SELECT (Debits - Credits) FROM Clients into :rBalance - プリエンプティブ - 少ないネットワークリクエスト Clichy/2010-02-03
- 71. SQL vs 4D - パフォーマンス • v11: SQL は 5-10 倍遅い場合がある ‣ しかしこれは飽くまで平均, あまり捕われないように ‣ 場合によっては, SQLのほうが速いことも - 典型例は計算を要するステートメント: SELECT (Debits - Credits) FROM Clients into :rBalance - プリエンプティブ - 少ないネットワークリクエスト • SQL 12 vs SQL v11 ‣ ローカルデータフェッチング = 2-3 倍高速 ‣ リモートデータフェッチング = 5-20 倍高速 Clichy/2010-02-03
- 72. SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? Clichy/2010-02-03
- 73. SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? ‣ そのほうが速いと思える根拠があるとき Clichy/2010-02-03
- 74. SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? ‣ そのほうが速いと思える根拠があるとき ‣ SQLで記述したほうが楽なとき: Clichy/2010-02-03
- 75. SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? ‣ そのほうが速いと思える根拠があるとき ‣ SQLで記述したほうが楽なとき: Clichy/2010-02-03
- 76. SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? ‣ そのほうが速いと思える根拠があるとき ‣ SQLで記述したほうが楽（美しい ?）なとき ‣ 他のDB（4Dあるいはそれ以外）に接続するとき Clichy/2010-02-03
- 77. SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? ‣ そのほうが速いと思える根拠があるとき ‣ SQLで記述したほうが楽（美しい ?）なとき ‣ 他のDB（4Dあるいはそれ以外）に接続するとき ‣ SQL特有の機能が必要なとき Clichy/2010-02-03
- 79. SQL-92 • DBメーカーの数だけ仕様が存在するというのが実情: ‣ OracleのコードがすべてMySQLで動くわけではない ‣ MySQLのコードがすべてPostgreSQLで動くわけではない ➡ Oracle, MySQL, PostgreSQL...で動いたコードがそのままでは4Dで動かないかもし れない（そしてこれをバグと呼ぶことはできない） Clichy/2010-02-03
- 80. 4D v11 SQL in Depth #1 • アーキテクチャー • SQL vs 4D
- 81. 4D v11 SQL in Depth #1 • アーキテクチャー • SQL vs 4D • キャッシュ
- 83. キャッシュ • 主要な目的は速度アップ（4D: データアクセス） ‣ 例: レコードをロードする - 初回はディスクから読み込み: アクセスはミリ秒の世界 Tokyo/2010-03-03/04
- 84. キャッシュ • 主要な目的は速度アップ（4D: データアクセス） ‣ 例: レコードをロードする - 初回はディスクから読み込み: アクセスはミリ秒の世界 - 以降はキャッシュから: アクセスはナノ秒の世界 Tokyo/2010-03-03/04
- 85. キャッシュ • 主要な目的は速度アップ（4D: データアクセス） ‣ 例: レコードをロードする - 初回はディスクから読み込み: アクセスはミリ秒の世界 - 以降はキャッシュから: アクセスはナノ秒の世界 1,000,000 倍高速 もし 1 ns = 1 秒だとすれば, 1 ms = 11,5 日 Tokyo/2010-03-03/04
- 86. キャッシュ • 主要な目的は速度アップ（4D: データアクセス） ‣ 例: レコードをロードする - 初回はディスクから読み込み: アクセスはミリ秒の世界 - 以降はキャッシュから: アクセスはナノ秒の世界 Tokyo/2010-03-03/04
- 87. キャッシュ • 主要な目的は速度アップ（4D: データアクセス） ‣ 例: レコードをロードする - 初回はディスクから読み込み: アクセスはミリ秒の世界 - 以降はキャッシュから: アクセスはナノ秒の世界 • キャッシュに収納されるものは ? - テーブル, フィールド, リレーション, インデックスなどストラクチャ定義情報 現在のデータベースに関する全般的な情報（ファイルパス, プロパティなど） データファイルアロケーションビットテーブル レコード, インデックス, BLOBの追加情報, 追加プロパティなど インデックスページ レコード BLOB（キャッシュに充分のスペースがなければメインメモリに行くことも） その他のプロパティ シーケンシャルナンバー トランザクション セレクション セット 並び替え用の一時的バッファ, 先読み, ディスク書き込み用バッファなど Tokyo/2010-03-03/04
- 89. キャッシュ • ほとんどは小さなオブジェクト: (= 64 KB) Tokyo/2010-03-03/04
- 90. キャッシュ • ほとんどは小さなオブジェクト: (= 64 KB) ‣ ファミリーごとにリンクしているため Tokyo/2010-03-03/04
- 91. キャッシュ • ほとんどは小さなオブジェクト: (= 64 KB) ‣ ファミリーごとにリンクしているため - 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは 複数のアドレステーブルに読み込まれる（それぞれは = 64 KB） Tokyo/2010-03-03/04
- 92. キャッシュ • ほとんどは小さなオブジェクト: (= 64 KB) ‣ ファミリーごとにリンクしているため - 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは 複数のアドレステーブルに読み込まれる（それぞれは = 64 KB） - 例 #2: セットは小さなオブジェクトに圧縮・分散されている Tokyo/2010-03-03/04
- 93. キャッシュ • ほとんどは小さなオブジェクト: (= 64 KB) ‣ ファミリーごとにリンクしているため - 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは 複数のアドレステーブルに読み込まれる（それぞれは = 64 KB） - 例 #2: セットは小さなオブジェクトに圧縮・分散されている • おおきいオブジェクトはユーザーオブジェクト: Tokyo/2010-03-03/04
- 94. キャッシュ • ほとんどは小さなオブジェクト: (= 64 KB) ‣ ファミリーごとにリンクしているため - 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは 複数のアドレステーブルに読み込まれる（それぞれは = 64 KB） - 例 #2: セットは小さなオブジェクトに圧縮・分散されている • おおきいオブジェクトはユーザーオブジェクト: ‣ BLOB Tokyo/2010-03-03/04
- 95. キャッシュ • ほとんどは小さなオブジェクト: (= 64 KB) ‣ ファミリーごとにリンクしているため - 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは 複数のアドレステーブルに読み込まれる（それぞれは = 64 KB） - 例 #2: セットは小さなオブジェクトに圧縮・分散されている • おおきいオブジェクトはユーザーオブジェクト: ‣ BLOB ‣ ピクチャ Tokyo/2010-03-03/04
- 96. キャッシュ • ほとんどは小さなオブジェクト: (= 64 KB) ‣ ファミリーごとにリンクしているため - 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは 複数のアドレステーブルに読み込まれる（それぞれは = 64 KB） - 例 #2: セットは小さなオブジェクトに圧縮・分散されている • おおきいオブジェクトはユーザーオブジェクト: ‣ BLOB ‣ ピクチャ ‣ テキスト Tokyo/2010-03-03/04
- 97. キャッシュ • ほとんどは小さなオブジェクト: (= 64 KB) ‣ ファミリーごとにリンクしているため - 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは 複数のアドレステーブルに読み込まれる（それぞれは = 64 KB） - 例 #2: セットは小さなオブジェクトに圧縮・分散されている • おおきいオブジェクトはユーザーオブジェクト: ‣ ‣ ‣ ‣ BLOB ピクチャ テキスト （レコード） «BLOBs»と総称する Tokyo/2010-03-03/04
- 103. キャッシュ • スタートアップで確保される • アプリケーション実行中,書き込み,パージ,フラッシュ,再配 置が繰り返される • FLUSH BUFFERS Tokyo/2010-03-03/04
- 106. キャッシュ • スタートアップで確保される • アプリケーション実行中,書き込み,パージ,フラッシュ,再配 置が繰り返される • FLUSH BUFFERS • «汚れた»オブジェクトをディスクの保存すること • その後 «汚れていない»という印が付けられる • それにより, パージしても良い状態になる Tokyo/2010-03-03/04
- 107. キャッシュ • スタートアップで確保される • アプリケーション実行中,書き込み,パージ,フラッシュ,再配 置が繰り返される • FLUSH BUFFERS • «汚れた»オブジェクトをディスクの保存すること • その後 «汚れていない»という印が付けられる • それにより, パージしても良い状態になる ディスクアクセスはミリ秒の世界 ! 不必要にFLUSH BUFFERSしてはいけない Tokyo/2010-03-03/04
- 109. キャッシュ キャッシュがメモリを必要とするときは ? • 状況: - ロードしなければならないオブジェクトがある:レコード,アドレステーブル,... - 充分なスペースがない Tokyo/2010-03-03/04
- 110. キャッシュ キャッシュがメモリを必要とするときは ? • 状況: - ロードしなければならないオブジェクトがある:レコード,アドレステーブル,... - 充分なスペースがない • 行動: Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース Tokyo/2010-03-03/04
- 111. キャッシュ キャッシュがメモリを必要とするときは ? • 状況: - ロードしなければならないオブジェクトがある:レコード,アドレステーブル,... - 充分なスペースがない • 行動: Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース Tokyo/2010-03-03/04
- 112. キャッシュ キャッシュがメモリを必要とするときは ? • 状況: - ロードしなければならないオブジェクトがある:レコード,アドレステーブル,... - 充分なスペースがない • 行動: Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース Tokyo/2010-03-03/04
- 113. キャッシュ キャッシュがメモリを必要とするときは ? Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース Tokyo/2010-03-03/04
- 114. キャッシュ キャッシュがメモリを必要とするときは ? Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース 確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは 100MBパージしようとする Tokyo/2010-03-03/04
- 115. キャッシュ キャッシュがメモリを必要とするときは ? Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース 確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは 100MBパージしようとする パージ Tokyo/2010-03-03/04
- 116. キャッシュ キャッシュがメモリを必要とするときは ? Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース 確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは 100MBパージしようとする パージ 汚れていないオブジェクトをパージ Tokyo/2010-03-03/04
- 117. キャッシュ キャッシュがメモリを必要とするときは ? Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース 確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは 100MBパージしようとする パージ 汚れていないオブジェクトをパージ メモリをアロケート Tokyo/2010-03-03/04
- 118. キャッシュ キャッシュがメモリを必要とするときは ? Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース 確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは 100MBパージしようとする パージ 汚れていないオブジェクトをパージ メモリをアロケート OK? Tokyo/2010-03-03/04
- 119. キャッシュ キャッシュがメモリを必要とするときは ? Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース 確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは 100MBパージしようとする パージ 汚れていないオブジェクトをパージ メモリをアロケート OK? はい Tokyo/2010-03-03/04
- 120. キャッシュ キャッシュがメモリを必要とするときは ? Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース 確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは 100MBパージしようとする パージ 汚れていないオブジェクトをパージ メモリをアロケート FLUSH BUFFERS いいえ OK? はい Tokyo/2010-03-03/04
- 121. キャッシュ キャッシュがメモリを必要とするときは ? Repeat キャッシュの 10%を パージ オブジェクトを アロケート Until 充分のスペース 確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネー ジャーは 100MBパージしようとする パージ 汚れていないオブジェクトをパージ メモリをアロケート FLUSH BUFFERS いいえ OK? はい Tokyo/2010-03-03/04
- 128. キャッシュ キャッシュがメモリを必要とするときは ? 汚れていないオブジェクトをパージ v11は2004よりも劇的に速くなった • 2004: ハンドル(Mac)と連結リスト ➡ オブジェクトは動いた ➡ 4Dはリスト全体をたどる必要があった Tokyo/2010-03-03/04
- 129. キャッシュ キャッシュがメモリを必要とするときは ? 汚れていないオブジェクトをパージ v11は2004よりも劇的に速くなった • 2004: ハンドル(Mac)と連結リスト ➡ オブジェクトは動いた ➡ 4Dはリスト全体をたどる必要があった • V11: ポインタと一種のアドレステーブル ➡ オブジェクトは動かない ➡ 最大 3 アクセスでオブジェクトに到達 Tokyo/2010-03-03/04
- 130. キャッシュ キャッシュがメモリを必要とするときは ? 汚れていないオブジェクトをパージ v11は2004よりも劇的に速くなった • 2004: ハンドル(Mac)と連結リスト ➡ オブジェクトは動いた ➡ 4Dはリスト全体をたどる必要があった • V11: ポインタと一種のアドレステーブル ➡ オブジェクトは動かない ➡ 最大 3 アクセスでオブジェクトに到達 (v11の新しいキャッシュメモリマネージャーのおかげ) Tokyo/2010-03-03/04
- 131. キャッシュ 最大サイズは ? • 4D 32 ビット Tokyo/2010-03-03/04
- 132. キャッシュ 最大サイズは ? • 4D 32 ビット ➡ 最大 2.5 GB ➡ OS(32/64)に関係なく ‣ ハードコードされた値 ‣ ユーザーが 2.5 を設定した場合は下方修正 Tokyo/2010-03-03/04
- 133. キャッシュ 最大サイズは ? • 4D 32 ビット ➡ 最大 2.5 GB ➡ OS(32/64)に関係なく ‣ ハードコードされた値 ‣ ユーザーが 2.5 を設定した場合は下方修正 • 4D 64 ビット(4D Server v12のみ) Tokyo/2010-03-03/04
- 134. キャッシュ 最大サイズは ? • 4D 32 ビット ➡ 最大 2.5 GB ➡ OS(32/64)に関係なく ‣ ハードコードされた値 ‣ ユーザーが 2.5 を設定した場合は下方修正 • 4D 64 ビット(4D Server v12のみ) ➡ «制限なし» Tokyo/2010-03-03/04
- 135. 4D v11 SQL in Depth #2
- 136. 4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ, ...）
- 137. データベースコンテキスト ユーザー 1 プロセス U1-1 Req1... ORDER BY (Table1) R2…⋯ R3 19813 19814 4D Server コオペラティブ プロセス U1-1 プリエンプティブ プロセス U1-1 Tokyo/2010-03-03/04
- 141. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド 44 Tokyo/2010-03-03/04
- 142. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
- 143. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
- 144. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
- 145. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
- 146. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
- 147. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
- 148. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード (*) (*) トリガのテーブルのみ 44 Tokyo/2010-03-03/04
- 149. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード (*) (*) トリガのテーブルのみ 44 Tokyo/2010-03-03/04
- 150. データベースコンテキスト • 例: リレートセレクションのsumをトリガで計算 ‣ クライアントサイド: . . . QUERY([OrderLines];[OrderLines]_OrderID=[Order]ID) SAVE RECORD([Order]) . . . ‣ サーバーサイド («On save existing record») [Order]Total:=Sum([OrderLines]Price) Tokyo/2010-03-03/04
- 151. データベースコンテキスト • 例: リレートセレクションの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
- 153. トリガ • (特性と目的を考慮する) • クライアントサーバー: : ≠ 2004 ‣ セレクションとカレントレコード (カレントテーブルのレコード以外) ‣ クライアントと同期が取られていない = 再現する必要がある Tokyo/2010-03-03/04
- 154. トリガ • (特性と目的を考慮する) • クライアントサーバー: : ≠ 2004 ‣ セレクションとカレントレコード (カレントテーブルのレコード以外) ‣ クライアントと同期が取られていない = 再現する必要がある プロセスセット,プロセス命名セレクション,レコードロッキング,トランザク Tokyo/2010-03-03/04
- 155. トリガ • (特性と目的を考慮する) • クライアントサーバー: : ≠ 2004 ‣ セレクションとカレントレコード (カレントテーブルのレコード以外) ‣ クライアントと同期が取られていない = 再現する必要がある プロセスセット,プロセス命名セレクション,レコードロッキング,トランザク ションステートは同期がとられている Tokyo/2010-03-03/04
- 156. トリガ • (特性と目的を考慮する) • クライアントサーバー: : ≠ 2004 ‣ セレクションとカレントレコード (カレントテーブルのレコード以外) ‣ クライアントと同期が取られていない = 再現する必要がある プロセスセット,プロセス命名セレクション,レコードロッキング,トランザク ションステートは同期がとられている • 複数が “同時に走る” (コオペラティブスレッドのプールの中で) • 制限 Tokyo/2010-03-03/04
- 157. トリガ • (特性と目的を考慮する) • クライアントサーバー: : ≠ 2004 ‣ セレクションとカレントレコード (カレントテーブルのレコード以外) ‣ クライアントと同期が取られていない = 再現する必要がある プロセスセット,プロセス命名セレクション,レコードロッキング,トランザク ションステートは同期がとられている • 複数が “同時に走る” (コオペラティブスレッドのプールの中で) • 制限 ‣ コオペラティブ(前述のとおり) Tokyo/2010-03-03/04
- 158. トリガ • (特性と目的を考慮する) • クライアントサーバー: : ≠ 2004 ‣ セレクションとカレントレコード (カレントテーブルのレコード以外) ‣ クライアントと同期が取られていない = 再現する必要がある プロセスセット,プロセス命名セレクション,レコードロッキング,トランザク ションステートは同期がとられている • 複数が “同時に走る” (コオペラティブスレッドのプールの中で) • 制限 ‣ コオペラティブ(前述のとおり) ‣ 最短の時間で終了しなければならない=(汎用的でない) Tokyo/2010-03-03/04
- 159. 4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ
- 160. 4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ • スケジューラーを理解する
- 162. スケジューラー • スケジューラーの目的 ? • なぜv11になってもスケジューラーが必要なのか ? フではないから ‣ 4Dランゲージはスレッドセー Tokyo/2010-03-03/04
- 163. スケジューラー • スケジューラーの目的 ? • なぜv11になってもスケジューラーが必要なのか ? フではないから ‣ 4Dランゲージはスレッドセー • スケジューラーの擬似コード: For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) Tokyo/2010-03-03/04
- 164. スケジューラー For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) Tokyo/2010-03-03/04
- 165. スケジューラー • 4Dは各プロセス1 tickの徹底を試みる For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) Tokyo/2010-03-03/04
- 166. スケジューラー • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する（ユーザーインタフェースも !）: For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) Tokyo/2010-03-03/04
- 167. スケジューラー • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する（ユーザーインタフェースも !）: ‣ インタプリタモードでは大丈夫 For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) Tokyo/2010-03-03/04
- 168. スケジューラー • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する（ユーザーインタフェースも !）: ‣ インタプリタモードでは大丈夫 ‣ コンパイルモードでは起こり得る（典型的な For 1からプロセス数まで 例はIDLEをコールしない高密度ルー プ） If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) Tokyo/2010-03-03/04
- 169. スケジューラー • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する（ユーザーインタフェースも !）: ‣ インタプリタモードでは大丈夫 ‣ コンパイルモードでは起こり得る（典型的な For 1からプロセス数まで 例はIDLEをコールしない高密度ルー プ） If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) ‣ プラグインは PA_Yield() あるいは PA_PieldAbsolute()をコールするべき Tokyo/2010-03-03/04
- 171. スケジューラー 実際には 1.イベントをチェック（マウス, キーボード, ...） ➡ 適切な4Dプロセスに伝達する 2.その後,アクティブプロセスに1 tickずつのルー プに突入 For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) Tokyo/2010-03-03/04
- 172. 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
- 173. While 4D 実行中 // システムイベントを処理 Repeat If チェック_間隔 が経過した If 4Dはビジーである タイムアウト = タイムアウト_最短 Else タイムアウト = タイムアウト_最長 End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない ! For 1からプロセス数まで // それぞれの4Dプロセスに時間を与える For 4D If プロセスが遅延あるいは停止されていなければ プロセスそれぞれにつき Give そのコードを 1 tick 実行する(16 ms) 最低 1 tick アクティブプロセスを実行 End while Tokyo/2010-03-03/04
- 174. 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
- 175. 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
- 176. 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
- 177. While 4D 実行中 // システムイベントを処理 Repeat If チェック_間隔 が経過した If 4Dはビジーである タイムアウト = タイムアウト_最短 Else タイムアウト = タイムアウト_最長 End if // ここでシステムに制御を返す Get イベントあるいは タイムアウト まで待機 If イベントは4Dプロセスに関係 SET DATABASE PARAMETER Pass イベントをプロセスに伝達 4D Server Scheduler End if 4D Remote Scheduler End if 4D Local Mode Scheduler Until イベントがない ! // それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while Tokyo/2010-03-03/04
- 180. スケジューラー 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
- 181. スケジューラー: 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
- 182. スケジューラー: 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
- 183. スケジューラー: 4Dを最低に 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 Tokyo/2010-03-03/04
- 185. スケジューラー チューニング • SET DATABASE PARAMETER（スコー プ;値） ‣ スコープ: - 4D Server スケジューラー - 4D Remote スケジューラー - 4D Local Mode スケジューラー Tokyo/2010-03-03/04
- 186. スケジューラー チューニング • 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
- 187. スケジューラー チューニング • 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
- 188. スケジューラー チューニング • 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
- 189. 4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ • スケジューラーを理解する
- 190. 4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ • スケジューラーを理解する • スタック（メモリ）
- 192. スタックとは ? • メモリの領域 • コードの実行に不可欠な «オブジェクト» を収容 Tokyo/2010-03-03/04
- 193. スタックとは ? • メモリの領域 • コードの実行に不可欠な «オブジェクト» を収容 • LIFOスタック: ‣ 返り値が収容される場所 ‣ パラメーター ‣ ローカル変数 ‣ （サブルーチン毎） Tokyo/2010-03-03/04
- 195. スタックのサイズ プリエンプティブ スレッド:デフォルトサイズ OS サイズ Windows 1 MB Leopard 512 KB Snow Leopard 1 MB Tokyo/2010-03-03/04
- 196. スタックのサイズ プリエンプティブ スレッド:デフォルトサイズ OS サイズ Windows 1 MB Leopard 512 KB Snow Leopard 1 MB • DB4D サーバー • SQL ネットセッションマネージャー • SQL ネットコネクション • 予備 SQL • クライアントグローバルプロセスのプリエンプティ ブツイン Tokyo/2010-03-03/04
- 197. スタックのサイズ プリエンプティブ スレッド:デフォルトサイズ 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
- 198. スタックのサイズ プリエンプティブスレッド:ハードコード値 ➡ フラッシュマネージャー (512 KB) ➡ インデックスビルダー (512 KB) Tokyo/2010-03-03/04
- 200. スタックのサイズ コオペラティブスレッド • • 4Dコードを実行するため 起源: ‣ ランゲージ - New process / Execute on server - 自動 ‣ Web/SOAP サーバープロセス ‣ メニューアイテムのプロパティ, ... ‣ On exit データベースメソッド ‣ 内部コード - ランタイムエクスプローラー,リモート管理画面, SQL プロセス,... Tokyo/2010-03-03/04
- 202. スタックのサイズ コオペラティブスレッド • 最終的に配分される値は常に増量されている ‣ Windows - realSize = requested + 40 KB ‣ Mac - realSize = requested + (requested / 2) + 128 KB Tokyo/2010-03-03/04
- 203. スタックのサイズ コオペラティブスレッド • 最終的に配分される値は常に増量されている ‣ 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
- 205. スタックのサイズ コオペラティブスレッド New process() とスタック 要求値 プラットフ (rs) 0 0 0 および 16 KB 0 および 16 KB 16 KB 16 KB ォーム Windows Mac Windows Mac Windows Mac OS Windows 0 Mac 再定義 配分値 512 KB 512 KB 16 KB 16 KB 変更なし 変更なし 552 KB 896 KB 56 KB 152 KB rs + 40 KB rs + (rs/2) + 128 KB rs + 40 KB 変更なし rs + (rs/2) + 128 KB 絶対にダメ. 例えば, -128*1024 を要求した場合, 4Dは4GBを配分しようとしてしま う（符号つき/符号なしの変換） Execute on serverに-1はNew processに0と同じ Tokyo/2010-03-03/04
- 207. スタックのサイズ コオペラティブスレッド • デフォルト値: ‣ '4STK' リソース ID 名称 1 On event call 2 On serial port call 値 512 KB 512 KB Exec on server, on client, 3 メソッド実行, マクロ 512 KB 4 5 6 7 8 512 KB 256 KB 512 KB 512 KB 256 KB メニュー新プロセス サーバータスク 旧・バックアップ 旧・復元 Web Server event loop, cache, 9 runtime explorer 10 アップルイベント 512 KB 512 KB Tokyo/2010-03-03/04
- 208. スタックのサイズ コオペラティブスレッド • デフォルト値: ‣ '4STK' リソース クライアントグローバルプロセス のサーバーコオペラティブツイン ID 名称 1 On event call 2 On serial port call 値 512 KB 512 KB Exec on server, on client, 3 メソッド実行, マクロ 512 KB 4 5 6 7 8 512 KB 256 KB 512 KB 512 KB 256 KB メニュー新プロセス サーバータスク 旧・バックアップ 旧・復元 Web Server event loop, cache, 9 runtime explorer 10 アップルイベント 512 KB 512 KB Tokyo/2010-03-03/04
- 209. スタックのサイズ コオペラティブスレッド • デフォルト値: ‣ '4STK' リソース クライアントグローバルプロセス のサーバーコオペラティブツイン ID 名称 1 On event call 2 On serial port call 値 512 KB 512 KB 実際の値 552-896 KB 552-896 KB Exec on server, on client, 3 メソッド実行, マクロ 512 KB 552-896 KB 4 5 6 7 8 512 KB 256 KB 512 KB 512 KB 256 KB 552-896 KB 296-512 KB 552-896 KB 552-896 KB 296-512 KB 512 KB 552-896 KB 512 KB 552-896 KB メニュー新プロセス サーバータスク 旧・バックアップ 旧・復元 Web Server event loop, cache, 9 runtime explorer 10 アップルイベント Tokyo/2010-03-03/04
- 210. 4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System Tokyo/2010-03-03/04
- 211. 4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System 100 クライアント - 2 グローバルプロセス / クライアント ! サーバーのツインスレッドが占有するメモリのサイズは? Tokyo/2010-03-03/04
- 212. 4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System 100 クライアント - 2 グローバルプロセス / クライアント ! サーバーのツインスレッドが占有するメモリのサイズは? 258 MB (W) 300 MB (SL) 200 MB (L) Tokyo/2010-03-03/04
- 213. 4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System 100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合 ! サーバーのツインスレッドが占有するメモリのサイズは? Tokyo/2010-03-03/04
- 214. 4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System 100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合 ! サーバーのツインスレッドが占有するメモリのサイズは? Tokyo/2010-03-03/04
- 215. 4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System 100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合 ! サーバーのツインスレッドが占有するメモリのサイズは? 458 MB (W) 500 MB (SL) 300 MB (L) Tokyo/2010-03-03/04
- 216. 4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ • スケジューラーを理解する • スタック（メモリ）
- 217. 4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ • スケジューラーを理解する • スタック（メモリ） • パラダイムシフト
- 220. 廃止予定 • 4D誕生から25年が経過 ! • この間に種々のコンセプトは進化した • OSが変わった,これからも変わり続ける ‣ 68k, PPC, x86, 64Bits ‣ OS9, OSX, Carbon, Cocoa • 4Dコードの互換性が失われてはいけない • しかし,そうはいっても... Tokyo/2010-03-03/04
- 222. 4D Draw • QuickDrawを使用している • Alturaでエミュレーション • 座標系に整数を使用, フォント番号, 模様パターン, ... • 現行の画像形式が開けない,独自のフォーマットを使用 • 4D Draw文書を4Dの外部で編集する術がない Tokyo/2010-03-03/04
- 224. SVG • • • CoreGraphics CoreText, GDI+を使用 • • 4Dピクチャ操作コマンドはすべてそのまま使用できる 標準テキスト形式 (xml) 高度なエフェクト: グラデーション, 透明度, レイヤー, 回転, 変形, 組み込み,... フォームオブジェクトとして表示や操作もできる ‣ MiniDraw (v12) • • １月,SVGワーキンググルー プにIEチームが加入 ! Tokyo/2010-03-03/04
- 226. 4D Open • 4D Openは4D v11でも動作する ‣ ただしインタプリタモードのみ • さまざまな方法で置き換えられる: ‣ HTTP - DOM Parse XML source( «http://site.com») ‣ Webサービス ‣ SQLパススルー ‣ 複製と同期 (v12) Tokyo/2010-03-03/04
- 228. PICT • • • • • 4DはWindowsでも画像をPICTで保存していた • • CONVERT PICTUREを推奨 4D v11はPICTが渡されたときだけPICTを使用する AppleはPICTフォーマットを廃止する予定 4DはAppleに頼ってMacでPICTを解読している 4DはAlturaまたはQuickTimeに頼ってWindowsで PICTを解読している BLOB TO PICTURE( «.4dblob») Tokyo/2010-03-03/04
- 230. uickTime • • • QuickTime はいまや動画処理に注力している技術 • QuickTimeを使用するコマンドは4D v12ですべて接頭 辞‘QT’が付き,廃止予定に 4D v11はQuickTimeをもはや必要とはしない 4D v12はImageIOおよび Windows Imaging Component (WIC) をサポート ‣ 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
- 234. リソース • • • • Unicode非対応, リソースの上限は2727個または16MB • • 4Dはいずれリソースの書き出しが不可能に Appleはサポートを中止, Windowsエディタ無し テキストはxliff, ピクチャは pngが主流 フォームエディタとランゲージでxliffとピクチャファイ ルをサポート 読み取りは当面できるはずだが, PICTリソースは無理 Tokyo/2010-03-03/04
- 235. Tokyo/2010-03-03/04
- 236. • 4DのWindows移植に一役買った技術 • 毎回の4Dバージョンアップで少しずつMac2Win依存を なくしてきた • 互換性のためにいまだ多く依存が残されている: ‣ リソース, PICT, プラグイン • Mac2Winを使用しているプラグインは, 依存関係を切る, さもなければ4Dに見切られる運命... • いまはまだAsifont.mapを使用 Tokyo/2010-03-03/04
- 237. 昔のルックス System 7 Windows 3.11 Mac OS 9 Windows 95 Tokyo/2010-03-03/04
- 238. 昔のルックス System 7 Windows 3.11 Mac OS 9 Windows 95 • QuickDraw および Altura 使用のカスタムコード • 4D 2004 で廃止予定の対象に • 4D v13でシステムアピアランスに変換される運命 • 4D v13まで先延ばしにしないで ! Tokyo/2010-03-03/04
- 242. サブテーブル • 特殊なリレーションに変換される • サブテーブルコマンドはすべてまだ動作する ‣ 例外 SEND RECORD, DUPLICATE RECORD • いますぐ廃止される訳ではない • テーブルへの変換が完了するまでの猶予を設けている Tokyo/2010-03-03/04
- 244. MODIFY SELECTION DISPLAY SELECTION • 廃止予定ではないけれど, 4Dアプリケーションがユー ザーから低い評価を受けてしまう理由のひとつ Tokyo/2010-03-03/04
- 245. Tokyo/2010-03-03/04
- 246. MODIFY SELECTION DISPLAY SELECTION • 廃止予定ではないけれど, 4Dアプリケーションがユー ザーから低い評価を受けてしまう理由のひとつ Tokyo/2010-03-03/04
- 247. MODIFY SELECTION DISPLAY SELECTION • 廃止予定ではないけれど, 4Dアプリケーションがユー ザーから低い評価を受けてしまう理由のひとつ ‣ リストボックスまたはサブフォームを推奨 • 要件に合うのならばリストボックス（配列・セレクション）を使用 ! • 特殊な必要があり,リストボックスがダメならばサブフォームを使用 ! Tokyo/2010-03-03/04
- 249. ラベルエディター • 4D 最古のエディターのひとつ • PRINT OBJECT (v12) はすごく便利 ! • 新しい 4D コンポーネントを現在検討中 Tokyo/2010-03-03/04
- 250. 4D v12 The Next Version