kmiyako, profile picture
Uploaded bykmiyako
PDF, PPTX597 views

In Depth 4D v11 SQL 2010-03-03

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

Embed presentation

Download as PDF, PPTX
1 / 250
2 / 250
3 / 250
4 / 250
5 / 250
6 / 250
7 / 250
8 / 250
9 / 250
10 / 250
11 / 250
12 / 250
13 / 250
14 / 250
15 / 250
16 / 250
17 / 250
18 / 250
19 / 250
20 / 250
21 / 250
22 / 250
23 / 250
24 / 250
25 / 250
26 / 250
27 / 250
28 / 250
29 / 250
30 / 250
31 / 250
32 / 250
33 / 250
34 / 250
35 / 250
36 / 250
37 / 250
38 / 250
39 / 250
40 / 250
41 / 250
42 / 250
43 / 250
44 / 250
45 / 250
46 / 250
47 / 250
48 / 250
49 / 250
50 / 250
51 / 250
52 / 250
53 / 250
54 / 250
55 / 250
56 / 250
57 / 250
58 / 250
59 / 250
60 / 250
61 / 250
62 / 250
63 / 250
64 / 250
65 / 250
66 / 250
67 / 250
68 / 250
69 / 250
70 / 250
71 / 250
72 / 250
73 / 250
74 / 250
75 / 250
76 / 250
77 / 250
78 / 250
79 / 250
80 / 250
81 / 250
82 / 250
83 / 250
84 / 250
85 / 250
86 / 250
87 / 250
88 / 250
89 / 250
90 / 250
91 / 250
92 / 250
93 / 250
94 / 250
95 / 250
96 / 250
97 / 250
98 / 250
99 / 250
100 / 250
101 / 250
102 / 250
103 / 250
104 / 250
105 / 250
106 / 250
107 / 250
108 / 250
109 / 250
110 / 250
111 / 250
112 / 250
113 / 250
114 / 250
115 / 250
116 / 250
117 / 250
118 / 250
119 / 250
120 / 250
121 / 250
122 / 250
123 / 250
124 / 250
125 / 250
126 / 250
127 / 250
128 / 250
129 / 250
130 / 250
131 / 250
132 / 250
133 / 250
134 / 250
135 / 250
136 / 250
137 / 250
138 / 250
139 / 250
140 / 250
141 / 250
142 / 250
143 / 250
144 / 250
145 / 250
146 / 250
147 / 250
148 / 250
149 / 250
150 / 250
151 / 250
152 / 250
153 / 250
154 / 250
155 / 250
156 / 250
157 / 250
158 / 250
159 / 250
160 / 250
161 / 250
162 / 250
163 / 250
164 / 250
165 / 250
166 / 250
167 / 250
168 / 250
169 / 250
170 / 250
171 / 250
172 / 250
173 / 250
174 / 250
175 / 250
176 / 250
177 / 250
178 / 250
179 / 250
180 / 250
181 / 250
182 / 250
183 / 250
184 / 250
185 / 250
186 / 250
187 / 250
188 / 250
189 / 250
190 / 250
191 / 250
192 / 250
193 / 250
194 / 250
195 / 250
196 / 250
197 / 250
198 / 250
199 / 250
200 / 250
201 / 250
202 / 250
203 / 250
204 / 250
205 / 250
206 / 250
207 / 250
208 / 250
209 / 250
210 / 250
211 / 250
212 / 250
213 / 250
214 / 250
215 / 250
216 / 250
217 / 250
218 / 250
219 / 250
220 / 250
221 / 250
222 / 250
223 / 250
224 / 250
225 / 250
226 / 250
227 / 250
228 / 250
229 / 250
230 / 250
231 / 250
232 / 250
233 / 250
234 / 250
235 / 250
236 / 250
237 / 250
238 / 250
239 / 250
240 / 250
241 / 250
242 / 250
243 / 250
244 / 250
245 / 250
246 / 250
247 / 250
248 / 250
249 / 250
250 / 250
4D v11 SQL in Depth #1
4D v11 SQL in Depth #1 • アーキテクチャー / スケーラビリティ
用語の定義 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が実行されると作成される • それぞれの対話は異なるネットワークポートを使用する: ... $date:=Current date(*) ... QUERY([City];[City]Name=”Paris”) ... Begin SQL ... 4 Tokyo/2010-03-03/04
三対のツイン • 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
三対のツイン • 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
Tokyo/2010-03-03/04
ユーザー 1 プロセス U1-1 Req1... R2…⋯ R3…⋯ QUERY (Table1) サーバー 4D Server コオペラティブ プリエンプティブ コア 1 コア 2 コア 3 コア 4 オペレーティングシステム Tokyo/2010-03-03/04
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
ユーザー 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
コオペラティブ プリエンプティブ スケジューラー コア 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
10 クライアント, QUERY または ORDER BY 同時に実行 2004以前: コオペラティブ Tokyo/2010-03-03/04
10 クライアント, QUERY または ORDER BY 同時に実行 2004以前: コオペラティブ v11: プリエンプティブ... ...そしてスケーラブル 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
ユーザー 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
Tokyo/2010-03-03/04
ボトルネック ランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP 4D自体: サーバーのユーザーインタフェース コネクションハンドラー ある種の外部SQLリクエスト Tokyo/2010-03-03/04
ボトルネック ランゲージ トリガ メソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP Tokyo/2010-03-03/04
• サーバーが素早く終えられるように • トリガ: ボトルネック ‣ 絶対に必要な場合だけ ランゲージ トリガ ‣ 汎用的なコードは避ける メソッド «サーバーで実行» ストアドプロシージャー • クライアントからプリエンプティブに (STA/ Web サーバー/SOAP ATS, ...) • EXECUTE ON CLIENTが活用できるかも • コンパイルモードで重度のルー IDLE プ: • コードリファクタリング: そんなにたくさんのス トアドプロシージャーがほんとうに必要 ? • ... Tokyo/2010-03-03/04
• サーバーが素早く終えられるように • トリガ: ボトルネック ‣ 絶対に必要な場合だけ ランゲージ トリガ ‣ 汎用的なコードは避ける メソッド «サーバーで実行» ストアドプロシージャー • クライアントからプリエンプティブに (STA/ Web サーバー/SOAP ATS, ...) 度» • と速 EXECUTE ON CLIENTが活用できるかも 荷 よ «負 • コンパイルモードで重度のルー IDLE プ: 量 せ 考 • コードリファクタリング: そんなにたくさんのス トアドプロシージャーがほんとうに必要 ? • ... Tokyo/2010-03-03/04
4D v11 SQL in Depth #1 • アーキテクチャー / スケーラビリティ
4D v11 SQL in Depth #1 • アーキテクチャー / スケーラビリティ • SQL vs 4D
SQL vs 4D - パフォーマンス Clichy/2010-02-03
SQL vs 4D - パフォーマンス 4D, 通常 SQL QUERY( . . .) SELECT ... FROM ... WHERE ... Clichy/2010-02-03
SQL vs 4D - パフォーマンス 4D, 通常 SQL QUERY( . . .) SELECT ... FROM ... WHERE ... インタプリター Clichy/2010-02-03
SQL vs 4D - パフォーマンス 4D, 通常 SQL QUERY( . . .) SELECT ... FROM ... WHERE ... インタプリター DB4D エンジン データファイル/インデックスファイル Clichy/2010-02-03
SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 Clichy/2010-02-03
SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 ‣ QUERY - 検索,セレクションの作成,先頭レコードのロード - ここまでをすべてひとつのコマンドで Clichy/2010-02-03
SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 ‣ QUERY - 検索,セレクションの作成,先頭レコードのロード - ここまでをすべてひとつのコマンドで • SQLは汎用的 ‣ ひとつの命令 (SELECT) であらゆる要求に対処 Clichy/2010-02-03
SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 ‣ QUERY - 検索,セレクションの作成,先頭レコードのロード - ここまでをすべてひとつのコマンドで • SQLは汎用的 ‣ ひとつの命令 (SELECT) であらゆる要求に対処 ‣ 加えて存在するオーバーヘッド: - 解析 - 検証 - SQL パススルー Clichy/2010-02-03
SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 ‣ QUERY - 検索,セレクションの作成,先頭レコードのロード - ここまでをすべてひとつのコマンドで • SQLは汎用的 ‣ ひとつの命令 (SELECT) であらゆる要求に対処 ‣ 加えて存在するオーバーヘッド: - 解析 - 検証 - SQL パススルー - ランゲージバインディング Clichy/2010-02-03
SQL vs 4D - パフォーマンス • 4Dは不可分, ワンアクションに対して高度に最適化 ‣ QUERY - 検索,セレクションの作成,先頭レコードのロード - ここまでをすべてひとつのコマンドで • SQLは汎用的 ‣ ひとつの命令 (SELECT) であらゆる要求に対処 ‣ 加えて存在するオーバーヘッド: - 解析 - 検証 - SQL パススルー - ランゲージバインディング - エンジン障壁 Clichy/2010-02-03
4D, 通常 SQL QUERY( . . .) SELECT ... FROM ... WHERE ... インタプリター DB4D エンジン データファイル/インデックスファイル Clichy/2010-02-03
4D, 通常 SQL QUERY( . . .) SELECT ... FROM ... WHERE ... インタプリター DB4D エンジン データファイル/インデックスファイル Clichy/2010-02-03
SQL vs 4D - パフォーマンス • v11: SQL は 5-10 倍遅い場合がある Clichy/2010-02-03
SQL vs 4D - パフォーマンス • v11: SQL は 5-10 倍遅い場合がある ‣ しかしこれは飽くまで平均, あまり捕われないように ‣ 場合によっては, SQLのほうが速いことも Clichy/2010-02-03
SQL vs 4D - パフォーマンス • v11: SQL は 5-10 倍遅い場合がある ‣ しかしこれは飽くまで平均, あまり捕われないように ‣ 場合によっては, SQLのほうが速いことも - 典型例は計算を要するステートメント: SELECT (Debits - Credits) FROM Clients into :rBalance - プリエンプティブ - 少ないネットワークリクエスト Clichy/2010-02-03
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
SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? Clichy/2010-02-03
SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? ‣ そのほうが速いと思える根拠があるとき Clichy/2010-02-03
SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? ‣ そのほうが速いと思える根拠があるとき ‣ SQLで記述したほうが楽なとき: Clichy/2010-02-03
SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? ‣ そのほうが速いと思える根拠があるとき ‣ SQLで記述したほうが楽なとき: Clichy/2010-02-03
SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? ‣ そのほうが速いと思える根拠があるとき ‣ SQLで記述したほうが楽（美しい ?）なとき ‣ 他のDB（4Dあるいはそれ以外）に接続するとき Clichy/2010-02-03
SQL vs 4D - パフォーマンス • どのような場合にSQLを使用するべき ? ‣ そのほうが速いと思える根拠があるとき ‣ SQLで記述したほうが楽（美しい ?）なとき ‣ 他のDB（4Dあるいはそれ以外）に接続するとき ‣ SQL特有の機能が必要なとき Clichy/2010-02-03
SQL-92 • DBメーカーの数だけ仕様が存在するというのが実情: ‣ OracleのコードがすべてMySQLで動くわけではない ‣ MySQLのコードがすべてPostgreSQLで動くわけではない Clichy/2010-02-03
SQL-92 • DBメーカーの数だけ仕様が存在するというのが実情: ‣ OracleのコードがすべてMySQLで動くわけではない ‣ MySQLのコードがすべてPostgreSQLで動くわけではない ➡ Oracle, MySQL, PostgreSQL...で動いたコードがそのままでは4Dで動かないかもしれ ない（そしてこれをバグと呼ぶことはできない） Clichy/2010-02-03
4D v11 SQL in Depth #1 • アーキテクチャー / スケーラビリティ • SQL vs 4D
4D v11 SQL in Depth #1 • アーキテクチャー / スケーラビリティ • SQL vs 4D • キャッシュ
キャッシュ • 主要な目的は速度アップ（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% キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーは オブジェクトを アロケート 100MBパージしようとする Until 充分のスペース Tokyo/2010-03-03/04
キャッシュ キャッシュがメモリを必要とするときは ? Repeat 確保したキャッシュ合計の10% キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーは オブジェクトを アロケート 100MBパージしようとする Until 充分のスペース パージ Tokyo/2010-03-03/04
キャッシュ キャッシュがメモリを必要とするときは ? Repeat 確保したキャッシュ合計の10% キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーは オブジェクトを アロケート 100MBパージしようとする Until 充分のスペース パージ 汚れていないオブジェクトをパージ Tokyo/2010-03-03/04
キャッシュ キャッシュがメモリを必要とするときは ? Repeat 確保したキャッシュ合計の10% キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーは オブジェクトを アロケート 100MBパージしようとする Until 充分のスペース パージ 汚れていないオブジェクトをパージ メモリをアロケート Tokyo/2010-03-03/04
キャッシュ キャッシュがメモリを必要とするときは ? Repeat 確保したキャッシュ合計の10% キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーは オブジェクトを アロケート 100MBパージしようとする Until 充分のスペース パージ 汚れていないオブジェクトをパージ メモリをアロケート OK? Tokyo/2010-03-03/04
キャッシュ キャッシュがメモリを必要とするときは ? Repeat 確保したキャッシュ合計の10% キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーは オブジェクトを アロケート 100MBパージしようとする Until 充分のスペース パージ 汚れていないオブジェクトをパージ メモリをアロケート はい OK? Tokyo/2010-03-03/04
キャッシュ キャッシュがメモリを必要とするときは ? Repeat 確保したキャッシュ合計の10% キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーは オブジェクトを アロケート 100MBパージしようとする Until 充分のスペース パージ 汚れていないオブジェクトをパージ メモリをアロケート いいえ はい FLUSH BUFFERS OK? Tokyo/2010-03-03/04
キャッシュ キャッシュがメモリを必要とするときは ? Repeat 確保したキャッシュ合計の10% キャッシュの 10%を パージ キャッシュが1GBの場合,キャッシュマネー ジャーは オブジェクトを アロケート 100MBパージしようとする Until 充分のスペース パージ 汚れていないオブジェクトをパージ メモリをアロケート いいえ はい FLUSH BUFFERS OK? 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のみ) ➡ «制限なし» Tokyo/2010-03-03/04
4D v11 SQL in Depth #2
4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ, ...）
ユーザー 1 データベースコンテキスト プロセス U1-1 Req1... R2…⋯ R3 ORDER BY (Table1) 19813 19814 4D Server コオペラティブ プリエンプティブ プロセス U1-1 プロセス U1-1 Tokyo/2010-03-03/04
データベースコンテキスト プロセス U1-1 Req1... R2…⋯ R3 コオペラティブ プロセス U1-1 Tokyo/2010-03-03/04
データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 Tokyo/2010-03-03/04
データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 44 Tokyo/2010-03-03/04
データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド 44 Tokyo/2010-03-03/04
データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード 44 Tokyo/2010-03-03/04
データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード (*) (*) トリガのテーブルのみ 44 Tokyo/2010-03-03/04
データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 コオペラティブツインプロセスが使用するもの: - トリガ - “サーバーで実行” プロパティが有効にされたメソッド “サーバーで実行” トリガ トランザクションステート レコードロッキング プロセスセット プロセス命名セレクション カレントセレクション カレントレコード (*) (*) トリガのテーブルのみ 44 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 • クライアントサーバー: : ‣ セレクションとカレントレコード (カレントテーブルのレコード以外) ‣ クライアントと同期が取られていない => 再現する必要がある プロセスセット,プロセス命名セレクション,レコードロッキング,トランザク ションステートは同期がとられている • 複数が “同時に走る” (コオペラティブスレッドのプールの中で) • 制限 ‣ コオペラティブ(前述のとおり) ‣ 最短の時間で終了しなければならない=(汎用的でない) Tokyo/2010-03-03/04
4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ, ...）
4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ, ...） • スケジューラーを理解する
スケジューラー • スケジューラーの目的 ? • なぜ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
For 1からプロセス数まで スケジューラー If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) • 4Dは各プロセス1 tickの徹底を試みる Tokyo/2010-03-03/04
For 1からプロセス数まで スケジューラー If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する（ユーザーインタフェースも !）: Tokyo/2010-03-03/04
For 1からプロセス数まで スケジューラー If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する（ユーザーインタフェースも !）: ‣ インタプリタモードでは大丈夫 Tokyo/2010-03-03/04
For 1からプロセス数まで スケジューラー If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する（ユーザーインタフェースも !）: ‣ インタプリタモードでは大丈夫 ‣ コンパイルモードでは起こり得る（典型的な 例はIDLEをコールしない高密度ループ） Tokyo/2010-03-03/04
For 1からプロセス数まで スケジューラー If プロセスが遅延あるいは停止されていなければ そのコードを 1 tick 実行する(16 ms) • 4Dは各プロセス1 tickの徹底を試みる • スケジューラーに制御を返さないプロセスは他すべ てを妨害する（ユーザーインタフェースも !）: ‣ インタプリタモードでは大丈夫 ‣ コンパイルモードでは起こり得る（典型的な 例はIDLEをコールしない高密度ループ） ‣ プラグインは PA_Yield() あるいは PA_PieldAbsolute()をコールするべき 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 イベントがない For 1からプロセス数まで // それぞれの4Dプロセスに時間を与える For 4D If プロセスが遅延あるいは停止されていなければ プロセスそれぞれにつき Give そのコードを 1 tick 実行する(16 ms) 最低 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 Tokyo/2010-03-03/04
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
スケジューラー デフォルト値 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
スケジューラー: 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
スケジューラー チューニング • 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（最低/左） • 実行中のエンジンにローカルの値,保存されない Tokyo/2010-03-03/04
4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ, ...） • スケジューラーを理解する
4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ, ...） • スケジューラーを理解する • スタック（メモリ）
スタックとは ? • メモリの領域 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
スタックのサイズ プリエンプティブ スレッド:デフォルトサイズ • DB4D サーバー OS サイズ Windows 1 MB • SQL ネットセッションマネージャー Leopard 512 KB • SQL ネットコネクション Snow Leopard 1 MB • 予備 SQL • クライアントグローバルプロセスのプリエンプティ ブツイン Tokyo/2010-03-03/04
スタックのサイズ プリエンプティブ スレッド:デフォルトサイズ • 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
スタックのサイズ プリエンプティブスレッド:ハードコード値 ➡ フラッシュマネージャー (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) ーム 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
スタックのサイズ コオペラティブスレッド 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
スタックのサイズ コオペラティブスレッド Tokyo/2010-03-03/04
スタックのサイズ コオペラティブスレッド • デフォルト値: 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
スタックのサイズ コオペラティブスレッド • デフォルト値: 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
スタックのサイズ コオペラティブスレッド • デフォルト値: 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
4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System Tokyo/2010-03-03/04
4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System 100 クライアント - 2 グローバルプロセス / クライアント   サーバーのツインスレッドが占有するメモリのサイズは? Tokyo/2010-03-03/04
4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System 100 クライアント - 2 グローバルプロセス / クライアント   サーバーのツインスレッドが占有するメモリのサイズは? 258 MB 300 MB 200 MB (W) (SL) (L) Tokyo/2010-03-03/04
4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System 100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合 サーバーのツインスレッドが占有するメモリのサイズは? Tokyo/2010-03-03/04
4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System 100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合 サーバーのツインスレッドが占有するメモリのサイズは? Tokyo/2010-03-03/04
4D Server Cooperatives Preemptives Scheduler Core 1 Core 2 Core 3 Core 4 Operating System 100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合 サーバーのツインスレッドが占有するメモリのサイズは? 458 MB 500 MB 300 MB (W) (SL) (L) Tokyo/2010-03-03/04
4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ, ...） • スケジューラーを理解する • スタック（メモリ）
4D v11 SQL in Depth #2 • データベースコンテキスト（トリガ, ...） • スケジューラーを理解する • スタック（メモリ） • パラダイムシフト
廃止予定 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) • １月,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
昔のルックス System 7 Windows 3.11 Mac OS 9 Windows 95 • QuickDraw および Altura 使用のカスタムコード • 4D 2004 で廃止予定の対象に • 4D v13でシステムアピアランスに変換される運命 • 4D v13まで先延ばしにしないで ! 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 コンポーネントを現在検討中 Tokyo/2010-03-03/04
4D v12 The Next Version

More Related Content

PPTX
そうだったのか！ よくわかる process.nextTick() node.jsのイベントループを理解する
byshigeki_ohtsu
 
PDF
Linuxのプロセススケジューラ(Reading the Linux process scheduler)
byHiraku Toyooka
 
PDF
x86とコンテキストスイッチ
byMasami Ichikawa
 
PDF
OpenvSwitchのモニタリングと管理機能
byTakashi Naito
 
PDF
2010 in-depth-v11
bykmiyako
 
PPTX
Trema の紹介とネットワーク仮想化への応用
bykazuyas
 
PDF
Node-v0.12の新機能について
byshigeki_ohtsu
 
PDF
SDN Framework Ryu Internal
bySatoshi KOBAYASHI
 
そうだったのか！ よくわかる process.nextTick() node.jsのイベントループを理解する
byshigeki_ohtsu
 
Linuxのプロセススケジューラ(Reading the Linux process scheduler)
byHiraku Toyooka
 
x86とコンテキストスイッチ
byMasami Ichikawa
 
OpenvSwitchのモニタリングと管理機能
byTakashi Naito
 
2010 in-depth-v11
bykmiyako
 
Trema の紹介とネットワーク仮想化への応用
bykazuyas
 
Node-v0.12の新機能について
byshigeki_ohtsu
 
SDN Framework Ryu Internal
bySatoshi KOBAYASHI
 

Viewers also liked

PDF
Wakanda#1
bykmiyako
 
PDF
XSLT 2010-03-03
bykmiyako
 
PDF
Web Basics 2013-01-10
bykmiyako
 
PDF
Optimisation 2013-07-02
bykmiyako
 
PDF
Lep 2013-07-23
bykmiyako
 
PDF
Wakanda 2013-07-02
bykmiyako
 
PDF
2012 keynote-0
bykmiyako
 
PDF
Current Selection 2010-02-14
bykmiyako
 
PDF
Uminohi 2013-07-14
bykmiyako
 
PDF
Data conversion
bykmiyako
 
PDF
4D Tags
bykmiyako
 
PDF
Japanese Collation 2010-03-03
bykmiyako
 
PDF
Mirroring
bykmiyako
 
PDF
Picture 2013-05-28
bykmiyako
 
PDF
Paint Tool 2013-05-14
bykmiyako
 
PDF
バックアップと復元
bykmiyako
 
PDF
正しいクエリの書き⽅
bykmiyako
 
PDF
Inside Multi-Threading
bykmiyako
 
PDF
⾼解像度ディスプレイ
bykmiyako
 
Wakanda#1
bykmiyako
 
XSLT 2010-03-03
bykmiyako
 
Web Basics 2013-01-10
bykmiyako
 
Optimisation 2013-07-02
bykmiyako
 
Lep 2013-07-23
bykmiyako
 
Wakanda 2013-07-02
bykmiyako
 
2012 keynote-0
bykmiyako
 
Current Selection 2010-02-14
bykmiyako
 
Uminohi 2013-07-14
bykmiyako
 
Data conversion
bykmiyako
 
4D Tags
bykmiyako
 
Japanese Collation 2010-03-03
bykmiyako
 
Mirroring
bykmiyako
 
Picture 2013-05-28
bykmiyako
 
Paint Tool 2013-05-14
bykmiyako
 
バックアップと復元
bykmiyako
 
正しいクエリの書き⽅
bykmiyako
 
Inside Multi-Threading
bykmiyako
 
⾼解像度ディスプレイ
bykmiyako
 

Similar to In Depth 4D v11 SQL 2010-03-03

PPTX
IBM DB2 for zOSのソースエンドポイントとしての利用
byQlikPresalesJapan
 
PDF
C16 45分でわかるPostgreSQLの仕組み by 山田努
byInsight Technology, Inc.
 
PPTX
第2章アーキテクチャ
byKenta Hattori
 
PDF
Kyoto Tycoon Guide in Japanese
byMikio Hirabayashi
 
PDF
PostgreSQLアーキテクチャ入門
byUptime Technologies LLC (JP)
 
PDF
C21 SQL Server のスレッド管理 by 古賀啓一郎
byInsight Technology, Inc.
 
PDF
PostgreSQLバックアップの基本
byUptime Technologies LLC (JP)
 
PDF
単なるキャッシュじゃないよ！？infinispanの紹介
byAdvancedTechNight
 
PDF
アーキテクチャから理解するPostgreSQLのレプリケーション
byMasahiko Sawada
 
PDF
PostgreSQLアーキテクチャ入門（INSIGHT OUT 2011）
byUptime Technologies LLC (JP)
 
PDF
不安定な環境の中でのバッチ処理～JobQueueシステムQudoを使った事例～
byAkabane Hiroyuki
 
PDF
Android binder-ipc
bymagoroku Yamamoto
 
PDF
Node.js入門
by俊夫 森
 
PDF
COD2012 C3 : SQL Server 2012で振り返る、SQLOSのスレッド スケジューリング
byMasayuki Ozawa
 
PPTX
Dbts2012 unconference wttrw_yazekatsu_publish
byYohei Azekatsu
 
PPT
第2回 分散システム本読書会
byKenji Ohtsuka
 
PPT
S4
byあしたのオープンソース研究所 　
 
PDF
【16-E-3】 プロジェクトIchiganの目指す新しい自治体ITアーキテクチャのあり方
byProject ICHIGAN
 
PDF
【17-C-1】 Big Data を扱うアーキテクチャーの原則
byMasayoshi Hagiwara
 
PPT
"Formalizing Architectural Connection" 紹介
byTadayoshi Sato
 
IBM DB2 for zOSのソースエンドポイントとしての利用
byQlikPresalesJapan
 
C16 45分でわかるPostgreSQLの仕組み by 山田努
byInsight Technology, Inc.
 
第2章アーキテクチャ
byKenta Hattori
 
Kyoto Tycoon Guide in Japanese
byMikio Hirabayashi
 
PostgreSQLアーキテクチャ入門
byUptime Technologies LLC (JP)
 
C21 SQL Server のスレッド管理 by 古賀啓一郎
byInsight Technology, Inc.
 
PostgreSQLバックアップの基本
byUptime Technologies LLC (JP)
 
単なるキャッシュじゃないよ！？infinispanの紹介
byAdvancedTechNight
 
アーキテクチャから理解するPostgreSQLのレプリケーション
byMasahiko Sawada
 
PostgreSQLアーキテクチャ入門（INSIGHT OUT 2011）
byUptime Technologies LLC (JP)
 
不安定な環境の中でのバッチ処理～JobQueueシステムQudoを使った事例～
byAkabane Hiroyuki
 
Android binder-ipc
bymagoroku Yamamoto
 
Node.js入門
by俊夫 森
 
COD2012 C3 : SQL Server 2012で振り返る、SQLOSのスレッド スケジューリング
byMasayuki Ozawa
 
Dbts2012 unconference wttrw_yazekatsu_publish
byYohei Azekatsu
 
第2回 分散システム本読書会
byKenji Ohtsuka
 
S4
byあしたのオープンソース研究所 　
 
【16-E-3】 プロジェクトIchiganの目指す新しい自治体ITアーキテクチャのあり方
byProject ICHIGAN
 
【17-C-1】 Big Data を扱うアーキテクチャーの原則
byMasayoshi Hagiwara
 
"Formalizing Architectural Connection" 紹介
byTadayoshi Sato
 

More from kmiyako

PDF
初心者からプロフェッショナルまで～データベース開発ソフト4Dの魅力を徹底紹介～
bykmiyako
 
PDF
4d
bykmiyako
 
PDF
Web area-phone-home
bykmiyako
 
PDF
Code Optimisation
bykmiyako
 
PDF
アップグレードセミナー
bykmiyako
 
PDF
4D WORLD TOUR 2017
bykmiyako
 
PDF
Xslt
bykmiyako
 
PDF
ラベルエディター
bykmiyako
 
PDF
Journaling slides
bykmiyako
 
PDF
⽇本語全⽂検索
bykmiyako
 
PDF
4D Tags
bykmiyako
 
PDF
Auto Update
bykmiyako
 
PDF
Unicode-v11-5
bykmiyako
 
PDF
Leaflet
bykmiyako
 
PDF
Build an iOS app with Ionic and 4D
bykmiyako
 
PDF
Unicode-v11-0
bykmiyako
 
PDF
Objects Fields
bykmiyako
 
PDF
Classic Query Editor
bykmiyako
 
PDF
4D Write Pro
bykmiyako
 
PDF
MONET研究会 #14
bykmiyako
 
初心者からプロフェッショナルまで～データベース開発ソフト4Dの魅力を徹底紹介～
bykmiyako
 
4d
bykmiyako
 
Web area-phone-home
bykmiyako
 
Code Optimisation
bykmiyako
 
アップグレードセミナー
bykmiyako
 
4D WORLD TOUR 2017
bykmiyako
 
Xslt
bykmiyako
 
ラベルエディター
bykmiyako
 
Journaling slides
bykmiyako
 
⽇本語全⽂検索
bykmiyako
 
4D Tags
bykmiyako
 
Auto Update
bykmiyako
 
Unicode-v11-5
bykmiyako
 
Leaflet
bykmiyako
 
Build an iOS app with Ionic and 4D
bykmiyako
 
Unicode-v11-0
bykmiyako
 
Objects Fields
bykmiyako
 
Classic Query Editor
bykmiyako
 
4D Write Pro
bykmiyako
 
MONET研究会 #14
bykmiyako
 

Recently uploaded

PDF
20260119_VIoTLT_vol22_kitazaki_v1___.pdf
byAyachika Kitazaki
 
PDF
TomokaEdakawa_職種と講義の関係推定に基づく履修支援システムの基礎検討_HCI2026
byMatsushita Laboratory
 
PDF
自転車ユーザ参加型路面画像センシングによる点字ブロック検出における性能向上方法の模索 (20260123 SeMI研)
byYuto Matsuda
 
PDF
アジャイル導入が止まる3つの壁 ─ 文化・他部門・組織プロセスをどう乗り越えるか
byGraat（グラーツ）
 
PDF
maisugimoto_曖昧さを含む仕様書の改善を目的としたアノテーション支援ツールの検討_HCI2025.pdf
byMatsushita Laboratory
 
PDF
ST2024_PM1_2_Case_study_of_local_newspaper_company.pdf
byakipii ogaoga
 
PDF
Team Topology Adaptive Organizational Design for Rapid Delivery of Valuable S...
byakipii ogaoga
 
20260119_VIoTLT_vol22_kitazaki_v1___.pdf
byAyachika Kitazaki
 
TomokaEdakawa_職種と講義の関係推定に基づく履修支援システムの基礎検討_HCI2026
byMatsushita Laboratory
 
自転車ユーザ参加型路面画像センシングによる点字ブロック検出における性能向上方法の模索 (20260123 SeMI研)
byYuto Matsuda
 
アジャイル導入が止まる3つの壁 ─ 文化・他部門・組織プロセスをどう乗り越えるか
byGraat（グラーツ）
 
maisugimoto_曖昧さを含む仕様書の改善を目的としたアノテーション支援ツールの検討_HCI2025.pdf
byMatsushita Laboratory
 
ST2024_PM1_2_Case_study_of_local_newspaper_company.pdf
byakipii ogaoga
 
Team Topology Adaptive Organizational Design for Rapid Delivery of Valuable S...
byakipii ogaoga
 

In Depth 4D v11 SQL 2010-03-03

  • 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.
  • 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 サーバー/SOAP 4D自体: サーバーのユーザーインタフェース コネクションハンドラー ある種の外部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.
  • 50.
    ボトルネック ランゲージ トリガ メソッド«サーバーで実行» ストアドプロシージャー Web サーバー/SOAP 4D自体: サーバーのユーザーインタフェース コネクションハンドラー ある種の外部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, 通常 SQL QUERY( . . .) SELECT ... FROM ... WHERE ... インタプリター DB4D エンジン データファイル/インデックスファイル Clichy/2010-02-03
  • 67.
    4D, 通常 SQL QUERY( . . .) 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.
  • 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-1 Req1... R2…⋯ R3 コオペラティブ プロセス U1-1 Tokyo/2010-03-03/04
  • 139.
    データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 Tokyo/2010-03-03/04
  • 140.
    データベースコンテキスト コオペラティブ プロセス U1-1 プロセス U1-1 Req1... R2…⋯ R3 44 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
  • 152.
  • 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.
  • 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.
  • 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.
  • 179.
    スケジューラー デフォルト値 タイムアウト_最短 タイムアウト_最長 チェック_間隔 4Dを最高に 0 1 5 4Dを標準に 0 8 0 4Dを最低に 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.
  • 195.
    スタックのサイズ プリエンプティブ スレッド:デフォルトサイズ OS サイズ Windows 1 MB Leopard 512 KB Snow 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.
  • 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.
  • 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 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 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 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 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) • １月,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.
  • 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.
  • 244.
    MODIFY SELECTION DISPLAY SELECTION • 廃止予定ではないけれど, 4Dアプリケーションがユーザ ーから低い評価を受けてしまう理由のひとつ Tokyo/2010-03-03/04
  • 245.
  • 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.