Your SlideShare is downloading. ×
0
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
In Depth 4D v11 SQL 2010-03-03
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

In Depth 4D v11 SQL 2010-03-03

240

Published on

2010年3月3日デベロッパ・カンファレンス資料。

2010年3月3日デベロッパ・カンファレンス資料。

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
240
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 4D v11 SQL in Depth #1
  • 2. 4D v11 SQL in Depth #1• アーキテクチャー / スケーラビリティ
  • 3. 用語の定義 Tokyo/2010-03-03/04
  • 4. 用語の定義• コオペラティブ: 他のプロセス(タスク,スレッ ド,...)に譲るCPU時間を自分で決めるプロセス Tokyo/2010-03-03/04
  • 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
  • 9. 三対のツイン 4 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
  • 16. Tokyo/2010-03-03/04
  • 17. ユーザー 1 プロセス U1-1 Req1... R2…⋯ R3…⋯ QUERY (Table1)サーバー 4D Server コオペラティブ プリエンプティブ コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 18. ユーザー 1 プロセス U1-1 Req1... R2…⋯ R3…⋯ QUERY (Table1)サーバー 4D Server 19813 19814 コオペラティブ プリエンプティブ プロセス U1-1 プロセス U1-1 コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 19. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3…⋯ R1... R2.. R1.. R3 R1…⋯ R2 R1…⋯ R2 QUERY (Table1) Current date(*) サーバー 4D Server 19813 19814 コオペラティブ プリエンプティブ プロセス U1-1 プロセス U1-1 コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 20. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3…⋯ R1... R2.. R1.. R3 R1…⋯ R2 R1…⋯ R2 QUERY (Table1) Current date(*) サーバー 4D Server 19813 19814 コオペラティブ プリエンプティブ プロセス U1-1 プロセス U3-1 プロセス U1-1 プロセス U3-1 プロセス U2-1 プロセス U3-2 プロセス U2-1 プロセス U3-2 プロセス U2-2 プロセス U2-2 コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 21. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3…⋯ R1... R2.. R1.. R3 R1…⋯ R2 R1…⋯ R2 QUERY (Table1) Current date(*) サーバー 4D Server 19813 19814 コオペラティブ プリエンプティブ プロセス U1-1 プロセス U3-1 プロセス U1-1 プロセス U3-1 プロセス U2-1 プロセス U3-2 プロセス U2-1 プロセス U3-2 プロセス U2-2 プロセス U2-2 コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 22. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3…⋯ R1... R2.. R1.. R3 R1…⋯ R2 R1…⋯ R2 QUERY (Table1) Current date(*) サーバー 4D Server 19813 19814 コオペラティブ プリエンプティブ プロセス U1-1 プロセス U3-1 プロセス U1-1 プロセス U3-1 プロセス U2-1 プロセス U3-2 プロセス U2-1 プロセス U3-2 プロセス U2-2 プロセス U2-2 コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 23. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R2 R1…⋯ R2 R1.. R2 QUERY (Table1) Current date(*)サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ プロセス U1-1 プロセス U3-1 プロセス U1-1 プロセス U3-1 プロセス U2-1 プロセス U3-2 プロセス U2-1 プロセス U3-2 プロセス U2-2 プロセス U2-2 コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 24. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R2 R1…⋯ R2 R1.. R2 QUERY (Table1) Current date(*)サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ プロセス U1-1 プロセス U3-1 プロセス U1-1 プロセス U3-1 プロセス U2-1 プロセス U3-2 プロセス U2-1 プロセス U3-2 プロセス U2-2 プロセス U2-2 コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 25. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R3 R1…⋯ R2 R1…⋯ R2 QUERY (Table1) Current date(*) サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 26. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R2 R1…⋯ R2 R1.. R2 QUERY (Table1) Current date(*)サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 27. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R2 R1…⋯ R2 R1.. R2 QUERY (Table1) Current date(*) Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 28. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R2 R1…⋯ R2 R1.. R2 QUERY (Table1) Current date(*) Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...サーバー 19813 19814 19812 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 29. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R2 R1…⋯ R2 R1.. R2 QUERY (Table1) Current date(*) Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...サーバー 19813 19814 19812 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 30. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R2 R1…⋯ R2 R1.. R2 QUERY (Table1) Current date(*) Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...サーバー 19813 19814 19812 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 31. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 Process U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R2 R1…⋯ R2 R1.. R2 QUERY (Table1) Current date(*) Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...サーバー 19813 19814 19812 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 32. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 Process U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R2 R1…⋯ R2 R1.. R2 QUERY (Table1) Current date(*) Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...サーバー 19813 19814 19812 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 33. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R2 R1…⋯ R2 R1.. R2 QUERY (Table1) Current date(*) Begin SQL... Begin SQL... Begin SQL... Begin SQL... 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 オペレーティングシステムボトルネック 伸張性と速度ランゲージ DBリクエストは同時に複数の トリガ クライアントが実行できる メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP4D自体: サーバーのユーザーインタフェース コネクションハンドラー ある種の外部SQLリクエスト 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
  • 44. いろいろなサーバー Tokyo/2010-03-03/04
  • 45. いろいろなサーバー アプリケーションサーバー コオペラティブ Web /SOAP コオペラティブ SQL サーバー プリエンプティブ DB4D サーバー プリエンプティブ Tokyo/2010-03-03/04
  • 46. v11-v12 デスクトップ クライアント-サーバー クライアント コオペラティブ プリエンプティブ コオペラティブ プリエンプティブ インタフェース全般 ランゲージストアドプロシージャー HTTP サーバーアプリケーションサーバー インデックスビルダー フラッシュマネージャー SQL サーバーDB4D(データアクセス) Tokyo/2010-03-03/04
  • 47. v11-v12 デスクトップ クライアント-サーバー クライアント コオペラティブ プリエンプティブ コオペラティブ プリエンプティブ インタフェース全般 ランゲージストアドプロシージャー HTTP サーバーアプリケーションサーバー インデックスビルダー フラッシュマネージャー SQL サーバーDB4D(データアクセス) Tokyo/2010-03-03/04
  • 48. ユーザー 1 ユーザー 2 ユーザー 3 プロセス U1-1 プロセス U2-1 プロセス U2-2 プロセス U3-1 プロセス U3-2 Req1... R2…⋯ R3 R1... R2.. R1.. R2 R1…⋯ R2 R1.. R2 QUERY (Table1) Current date(*) Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...サーバー 19813 19814 4D Server コオペラティブ プリエンプティブ スケジューラー コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
  • 49. Tokyo/2010-03-03/04
  • 50. ボトルネックランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP4D自体: サーバーのユーザーインタフェース コネクションハンドラー ある種の外部SQLリクエスト Tokyo/2010-03-03/04
  • 51. ボトルネックランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP Tokyo/2010-03-03/04
  • 52. • サーバーが素早く終えられるように • トリガ:ボトルネック ‣ 絶対に必要な場合だけランゲージ トリガ ‣ 汎用的なコードは避ける メソッド «サーバーで実行» ストアドプロシージャー • クライアントからプリエンプティブに (STA/ Web サーバー/SOAP ATS, ...) • EXECUTE ON CLIENTが活用できるかも • コンパイルモードで重度のルー IDLE プ: • コードリファクタリング: そんなにたくさんのス トアドプロシージャーがほんとうに必要 ? • ... Tokyo/2010-03-03/04
  • 53. • サーバーが素早く終えられるように • トリガ:ボトルネック ‣ 絶対に必要な場合だけランゲージ トリガ ‣ 汎用的なコードは避ける メソッド «サーバーで実行» ストアドプロシージャー • クライアントからプリエンプティブに (STA/ Web サーバー/SOAP 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, 通常 SQL QUERY( . . .) SELECT ... FROM ... WHERE ... Clichy/2010-02-03
  • 58. SQL vs 4D - パフォーマンス 4D, 通常 SQL QUERY( . . .) SELECT ... FROM ... WHERE ... インタプリター Clichy/2010-02-03
  • 59. SQL vs 4D - パフォーマンス 4D, 通常 SQL QUERY( . . .) SELECT ... 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, 通常 SQLQUERY( . . .) SELECT ... FROM ... WHERE ... インタプリター DB4D エンジンデータファイル/インデックスファイル Clichy/2010-02-03
  • 67. 4D, 通常 SQLQUERY( . . .) SELECT ... 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
  • 78. SQL-92• DBメーカーの数だけ仕様が存在するというのが実情: ‣ OracleのコードがすべてMySQLで動くわけではない ‣ MySQLのコードがすべてPostgreSQLで動くわけではない 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• キャッシュ
  • 82. キャッシュ• 主要な目的は速度アップ(4D: データアクセス) Tokyo/2010-03-03/04
  • 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
  • 88. キャッシュ 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
  • 98. キャッシュ Tokyo/2010-03-03/04
  • 99. キャッシュ• スタートアップで確保される• アプリケーション実行中,書き込み,パージ,フラッシュ,再配 置が繰り返される Tokyo/2010-03-03/04
  • 100. キャッシュ• スタートアップで確保される• アプリケーション実行中,書き込み,パージ,フラッシュ,再配 置が繰り返される Tokyo/2010-03-03/04
  • 101. キャッシュ• スタートアップで確保される• アプリケーション実行中,書き込み,パージ,フラッシュ,再配 置が繰り返される Tokyo/2010-03-03/04
  • 102. キャッシュ• スタートアップで確保される• アプリケーション実行中,書き込み,パージ,フラッシュ,再配 置が繰り返される Tokyo/2010-03-03/04
  • 103. キャッシュ• スタートアップで確保される• アプリケーション実行中,書き込み,パージ,フラッシュ,再配 置が繰り返される• FLUSH BUFFERS Tokyo/2010-03-03/04
  • 104. キャッシュ• スタートアップで確保される• アプリケーション実行中,書き込み,パージ,フラッシュ,再配 置が繰り返される• FLUSH BUFFERS • «汚れた»オブジェクトをディスクの保存すること Tokyo/2010-03-03/04
  • 105. キャッシュ• スタートアップで確保される• アプリケーション実行中,書き込み,パージ,フラッシュ,再配 置が繰り返される• 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
  • 108. キャッシュキャッシュがメモリを必要とするときは ? 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%キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーはオブジェクトを アロケート 100MBパージしようとするUntil 充分のスペース Tokyo/2010-03-03/04
  • 115. キャッシュ キャッシュがメモリを必要とするときは ?Repeat 確保したキャッシュ合計の10%キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーはオブジェクトを アロケート 100MBパージしようとするUntil 充分のスペース パージ Tokyo/2010-03-03/04
  • 116. キャッシュ キャッシュがメモリを必要とするときは ?Repeat 確保したキャッシュ合計の10%キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーはオブジェクトを アロケート 100MBパージしようとするUntil 充分のスペース パージ 汚れていないオブジェクトをパージ Tokyo/2010-03-03/04
  • 117. キャッシュ キャッシュがメモリを必要とするときは ?Repeat 確保したキャッシュ合計の10%キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーはオブジェクトを アロケート 100MBパージしようとするUntil 充分のスペース パージ 汚れていないオブジェクトをパージ メモリをアロケート Tokyo/2010-03-03/04
  • 118. キャッシュ キャッシュがメモリを必要とするときは ?Repeat 確保したキャッシュ合計の10%キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーはオブジェクトを アロケート 100MBパージしようとするUntil 充分のスペース パージ 汚れていないオブジェクトをパージ メモリをアロケート OK? Tokyo/2010-03-03/04
  • 119. キャッシュ キャッシュがメモリを必要とするときは ?Repeat 確保したキャッシュ合計の10%キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーはオブジェクトを アロケート 100MBパージしようとするUntil 充分のスペース パージ 汚れていないオブジェクトをパージ メモリをアロケート はい OK? Tokyo/2010-03-03/04
  • 120. キャッシュ キャッシュがメモリを必要とするときは ?Repeat 確保したキャッシュ合計の10%キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーはオブジェクトを アロケート 100MBパージしようとするUntil 充分のスペース パージ 汚れていないオブジェクトをパージ メモリをアロケート いいえ はい FLUSH BUFFERS OK? Tokyo/2010-03-03/04
  • 121. キャッシュ キャッシュがメモリを必要とするときは ?Repeat 確保したキャッシュ合計の10%キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーはオブジェクトを アロケート 100MBパージしようとするUntil 充分のスペース パージ 汚れていないオブジェクトをパージ メモリをアロケート いいえ はい FLUSH BUFFERS OK? Tokyo/2010-03-03/04
  • 122. キャッシュキャッシュがメモリを必要とするときは ? 汚れていないオブジェクトをパージ Tokyo/2010-03-03/04
  • 123. キャッシュ キャッシュがメモリを必要とするときは ? 汚れていないオブジェクトをパージ• フラッシュする最初のオブジェクトまでジャンプ Tokyo/2010-03-03/04
  • 124. キャッシュ キャッシュがメモリを必要とするときは ? 汚れていないオブジェクトをパージ• フラッシュする最初のオブジェクトまでジャンプ ➡ キャッシュが先にフラッシュするオブジェクトはい つも一緒とは限らない Tokyo/2010-03-03/04
  • 125. キャッシュ キャッシュがメモリを必要とするときは ? 汚れていないオブジェクトをパージ• フラッシュする最初のオブジェクトまでジャンプ ➡ キャッシュが先にフラッシュするオブジェクトはい つも一緒とは限らない• ディスクでの近接度を考慮して最適のフラッシュを試みる Tokyo/2010-03-03/04
  • 126. キャッシュキャッシュがメモリを必要とするときは ? 汚れていないオブジェクトをパージ Tokyo/2010-03-03/04
  • 127. キャッシュキャッシュがメモリを必要とするときは ? 汚れていないオブジェクトをパージ v11は2004よりも劇的に速くなった 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... R2…⋯ R3 ORDER BY (Table1) 19813 19814 4D Server コオペラティブ プリエンプティブ プロセス U1-1 プロセス U1-1 Tokyo/2010-03-03/04
  • 138. データベースコンテキスト プロセス U1-1Req1... R2…⋯ R3 コオペラティブ プロセス U1-1 Tokyo/2010-03-03/04
  • 139. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1Req1... R2…⋯ R3 Tokyo/2010-03-03/04
  • 140. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1Req1... R2…⋯ R3 44 Tokyo/2010-03-03/04
  • 141. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド 44 Tokyo/2010-03-03/04
  • 142. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
  • 143. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
  • 144. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
  • 145. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
  • 146. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
  • 147. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
  • 148. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード (*) (*) トリガのテーブルのみ 44 Tokyo/2010-03-03/04
  • 149. データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1Req1... 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
  • 152. トリガ• (特性と目的を考慮する) 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• データベースコンテキスト(トリガ, ...)• スケジューラーを理解する
  • 161. スケジューラー• スケジューラーの目的 ?• なぜv11になってもスケジューラーが必要なのか ? Tokyo/2010-03-03/04
  • 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. For 1からプロセス数まで スケジューラーIf プロセスが遅延あるいは停止されていなければそのコードを 1 tick 実行する(16 ms) • 4Dは各プロセス1 tickの徹底を試みる Tokyo/2010-03-03/04
  • 166. For 1からプロセス数まで スケジューラーIf プロセスが遅延あるいは停止されていなければそのコードを 1 tick 実行する(16 ms) • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する(ユーザーインタフェースも !): Tokyo/2010-03-03/04
  • 167. For 1からプロセス数まで スケジューラーIf プロセスが遅延あるいは停止されていなければそのコードを 1 tick 実行する(16 ms) • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する(ユーザーインタフェースも !): ‣ インタプリタモードでは大丈夫 Tokyo/2010-03-03/04
  • 168. For 1からプロセス数まで スケジューラーIf プロセスが遅延あるいは停止されていなければそのコードを 1 tick 実行する(16 ms) • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する(ユーザーインタフェースも !): ‣ インタプリタモードでは大丈夫 ‣ コンパイルモードでは起こり得る(典型的な 例はIDLEをコールしない高密度ループ) Tokyo/2010-03-03/04
  • 169. For 1からプロセス数まで スケジューラーIf プロセスが遅延あるいは停止されていなければそのコードを 1 tick 実行する(16 ms) • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する(ユーザーインタフェースも !): ‣ インタプリタモードでは大丈夫 ‣ コンパイルモードでは起こり得る(典型的な 例はIDLEをコールしない高密度ループ) ‣ プラグインは PA_Yield() あるいは PA_PieldAbsolute()をコールするべき Tokyo/2010-03-03/04
  • 170. スケジューラー 実際には 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プロセスに関係DATABASE PARAMETER SET Pass イベントをプロセスに伝達 4D Server Scheduler End if 4D Remote Scheduler End if Until イベントがない 4D Local Mode Scheduler // それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行End while Tokyo/2010-03-03/04
  • 178. スケジューラー デフォルト値 Tokyo/2010-03-03/04
  • 179. スケジューラー デフォルト値 タイムアウト_最短 タイムアウト_最長 チェック_間隔4Dを最高に 0 1 54Dを標準に 0 8 04Dを最低に 1 16 0 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
  • 184. スケジューラー チューニング• SET DATABASE PARAMETER(スコープ;値) 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• データベースコンテキスト(トリガ, ...)• スケジューラーを理解する• スタック(メモリ)
  • 191. スタックとは ?• メモリの領域 Tokyo/2010-03-03/04
  • 192. スタックとは ?• メモリの領域• コードの実行に不可欠な «オブジェクト» を収容 Tokyo/2010-03-03/04
  • 193. スタックとは ?• メモリの領域• コードの実行に不可欠な «オブジェクト» を収容• LIFOスタック: ‣ 返り値が収容される場所 ‣ パラメーター ‣ ローカル変数 ‣ (サブルーチン毎) Tokyo/2010-03-03/04
  • 194. スタックのサイズプリエンプティブ スレッド:デフォルトサイズ Tokyo/2010-03-03/04
  • 195. スタックのサイズプリエンプティブ スレッド:デフォルトサイズ OS サイズ Windows 1 MB Leopard 512 KBSnow Leopard 1 MB Tokyo/2010-03-03/04
  • 196. スタックのサイズプリエンプティブ スレッド:デフォルトサイズ • DB4D サーバー OS サイズ Windows 1 MB • SQL ネットセッションマネージャー Leopard 512 KB • SQL ネットコネクションSnow Leopard 1 MB • 予備 SQL • クライアントグローバルプロセスのプリエンプティ ブツイン Tokyo/2010-03-03/04
  • 197. スタックのサイズプリエンプティブ スレッド:デフォルトサイズ • DB4D サーバー OS サイズ Windows 1 MB • SQL ネットセッションマネージャー Leopard 512 KB • SQL ネットコネクションSnow Leopard 1 MB • 予備 SQL • クライアントグローバルプロセスのプリエンプティ ブツイン GET/SET DATABASE PARAMETER(53;バイト数) Tokyo/2010-03-03/04
  • 198. スタックのサイズプリエンプティブスレッド:ハードコード値 ➡ フラッシュマネージャー (512 KB) ➡ インデックスビルダー (512 KB) Tokyo/2010-03-03/04
  • 199. スタックのサイズコオペラティブスレッド Tokyo/2010-03-03/04
  • 200. スタックのサイズ コオペラティブスレッド• 4Dコードを実行するため• 起源: ‣ ランゲージ - New process / Execute on server - 自動 ‣ Web/SOAP サーバープロセス ‣ メニューアイテムのプロパティ, ... ‣ On exit データベースメソッド ‣ 内部コード - ランタイムエクスプローラー,リモート管理画面, SQL プロセス,... Tokyo/2010-03-03/04
  • 201. スタックのサイズ コオペラティブスレッド• 最終的に配分される値は常に増量されている 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
  • 204. スタックのサイズ コオペラティブスレッド New process() とスタック 要求値 プラットフォ 再定義 配分値 (rs) ーム 0 Windows 512 KB 552 KB 0 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 Windows rs + 40 KB <0 変更なし Mac rs + (rs/2) + 128 KB絶対にダメ. 例えば, -128*1024 を要求した場合, 4Dは4GBを配分しようとしてしまう(符号つき/符号なしの変換) Tokyo/2010-03-03/04
  • 205. スタックのサイズ コオペラティブスレッド New process() とスタック 要求値 プラットフォ 再定義 配分値 (rs) ーム 0 Windows 512 KB 552 KB 0 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 Windows rs + 40 KB <0 変更なし Mac rs + (rs/2) + 128 KB絶対にダメ. 例えば, -128*1024 を要求した場合, 4Dは4GBを配分しようとしてしまう(符号つき/符号なしの変換) Execute on serverに-1はNew processに0と同じ Tokyo/2010-03-03/04
  • 206. スタックのサイズコオペラティブスレッド Tokyo/2010-03-03/04
  • 207. スタックのサイズ コオペラティブスレッド• デフォルト値: ID 名称 1 On event call 値 512 KB 2 On serial port call 512 KB ‣ 4STK リソース Exec on server, on client, 3 512 KB メソッド実行, マクロ 4 メニュー新プロセス 512 KB 5 サーバータスク 256 KB 6 旧・バックアップ 512 KB 7 旧・復元 512 KB 8 Web 256 KB Server event loop, cache, 9 512 KB runtime explorer 10 アップルイベント 512 KB Tokyo/2010-03-03/04
  • 208. スタックのサイズ コオペラティブスレッド• デフォルト値: ID 名称 1 On event call 値 512 KB 2 On serial port call 512 KB ‣ 4STK リソース Exec on server, on client, 3 512 KB メソッド実行, マクロクライアントグローバルプロセス 4 メニュー新プロセス 512 KB 5 サーバータスク 256 KBのサーバーコオペラティブツイン 6 旧・バックアップ 512 KB 7 旧・復元 512 KB 8 Web 256 KB Server event loop, cache, 9 512 KB runtime explorer 10 アップルイベント 512 KB Tokyo/2010-03-03/04
  • 209. スタックのサイズ コオペラティブスレッド• デフォルト値: ID 名称 1 On event call 値 512 KB 実際の値 552-896 KB 2 On serial port call 512 KB 552-896 KB ‣ 4STK リソース Exec on server, on client, 3 512 KB 552-896 KB メソッド実行, マクロクライアントグローバルプロセス 4 メニュー新プロセス 512 KB 552-896 KB 5 サーバータスク 256 KB 296-512 KBのサーバーコオペラティブツイン 552-896 KB 6 旧・バックアップ 512 KB 7 旧・復元 512 KB 552-896 KB 8 Web 256 KB 296-512 KB Server event loop, cache, 9 512 KB 552-896 KB runtime explorer 10 アップルイベント 512 KB 552-896 KB Tokyo/2010-03-03/04
  • 210. 4D Server Cooperatives PreemptivesScheduler 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 System100 クライアント - 2 グローバルプロセス / クライアント  サーバーのツインスレッドが占有するメモリのサイズは? Tokyo/2010-03-03/04
  • 212. 4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System100 クライアント - 2 グローバルプロセス / クライアント  サーバーのツインスレッドが占有するメモリのサイズは?258 MB 300 MB 200 MB (W) (SL) (L) Tokyo/2010-03-03/04
  • 213. 4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合サーバーのツインスレッドが占有するメモリのサイズは? Tokyo/2010-03-03/04
  • 214. 4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合サーバーのツインスレッドが占有するメモリのサイズは? Tokyo/2010-03-03/04
  • 215. 4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合サーバーのツインスレッドが占有するメモリのサイズは?458 MB 500 MB 300 MB (W) (SL) (L) Tokyo/2010-03-03/04
  • 216. 4D v11 SQL in Depth #2• データベースコンテキスト(トリガ, ...)• スケジューラーを理解する• スタック(メモリ)
  • 217. 4D v11 SQL in Depth #2• データベースコンテキスト(トリガ, ...)• スケジューラーを理解する• スタック(メモリ)• パラダイムシフト
  • 218. 廃止予定 Tokyo/2010-03-03/04
  • 219. 廃止予定• 4D誕生から25年が経過 ! Tokyo/2010-03-03/04
  • 220. 廃止予定• 4D誕生から25年が経過 !• この間に種々のコンセプトは進化した• OSが変わった,これからも変わり続ける ‣ 68k, PPC, x86, 64Bits ‣ OS9, OSX, Carbon, Cocoa• 4Dコードの互換性が失われてはいけない• しかし,そうはいっても... Tokyo/2010-03-03/04
  • 221. 4D Draw Tokyo/2010-03-03/04
  • 222. 4D Draw• QuickDrawを使用している• Alturaでエミュレーション• 座標系に整数を使用, フォント番号, 模様パターン, ...• 現行の画像形式が開けない,独自のフォーマットを使用• 4D Draw文書を4Dの外部で編集する術がない Tokyo/2010-03-03/04
  • 223. SVG Tokyo/2010-03-03/04
  • 224. SVG• CoreGraphics & CoreText, GDI+を使用• 標準テキスト形式 (xml)• 高度なエフェクト: グラデーション, 透明度, レイヤー, 回転, 変形, 組み込み,...• 4Dピクチャ操作コマンドはすべてそのまま使用できる• フォームオブジェクトとして表示や操作もできる ‣ MiniDraw (v12)• 1月,SVGワーキンググループにIEチームが加入 ! Tokyo/2010-03-03/04
  • 225. 4D Open 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
  • 227. PICT Tokyo/2010-03-03/04
  • 228. 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
  • 229. uickTime Tokyo/2010-03-03/04
  • 230. 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
  • 231. ピクチャ Tokyo/2010-03-03/04
  • 232. ピクチャ• 別名で保存:• インストールされたドライバー次第で,ほとんどのメー カーのカメラ形式をサポート• 4D Picture形式は複数のフォーマットおよび変形を保 存できる独自のコンテナ形式 Tokyo/2010-03-03/04
  • 233. リソース Tokyo/2010-03-03/04
  • 234. リソース• Unicode非対応, リソースの上限は2727個または16MB• Appleはサポートを中止, Windowsエディタ無し• テキストはxliff, ピクチャは pngが主流• フォームエディタとランゲージでxliffとピクチャファイル をサポート• 4Dはいずれリソースの書き出しが不可能に• 読み取りは当面できるはずだが, 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
  • 239. 昔のルックス• 時々,エンドユーザーの反応が気になりませんか ? Tokyo/2010-03-03/04
  • 240. 昔のルックス• 時々,エンドユーザーの反応が気になりませんか ? Tokyo/2010-03-03/04
  • 241. サブテーブル Tokyo/2010-03-03/04
  • 242. サブテーブル• 特殊なリレーションに変換される• サブテーブルコマンドはすべてまだ動作する ‣ 例外 SEND RECORD, DUPLICATE RECORD• いますぐ廃止される訳ではない• テーブルへの変換が完了するまでの猶予を設けている Tokyo/2010-03-03/04
  • 243. MODIFY SELECTIONDISPLAY SELECTION 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
  • 248. ラベルエディター Tokyo/2010-03-03/04
  • 249. ラベルエディター• 4D 最古のエディターのひとつ• PRINT OBJECT (v12) はすごく便利 !• 新しい 4D コンポーネントを現在検討中 Tokyo/2010-03-03/04
  • 250. 4D v12The Next Version

×