水曜日 8 24, 2016

インメモリ(またはカラム型)データベースでのキャッシュって

CPUキャッシュ、メモリー、ディスク、ネットワークなどのレイテンシー(および一部転送速度)を
比較しているGitHub上のテキストファイルを見つけました。4年以上コメントが付け続けられていて
かなり参照されているようです。

Latency Numbers Every Programmer Should Know · GitHub

L1 cache reference 0.5 ns

DB系のパフォーマンス系の仕事でナノ秒レベルの精度すら求められたことはないのですが
CPUの中ではピコ秒レベルなんですね。

ところで"キャッシュ"というと以前は"Buffer Cache"のようにメインメモリー上を指していました。
Oracleデータベース 12.1.0.2 で新登場した Database In-Memory のようなインメモリーのDBでは
"キャッシュ"というと "CPU" 上のL1,L2,L3キャッシュを指します。
(ディスクベースのカラム型DBベンダーでそれ以前からキャッシュとしてCPUを指していたところもあるかもしれません...)

上記GitHubファイルに戻ります。メインメモリーはL1 キャッシュの "200倍" も遅いそうです。

Oracleの開発部門ではCPUキャッシュ利用率もプロファイリングしてコンパイラーに全てをまかせることなく
コードを最適化して高速化しています。

このブログでも以前弊社開発部門と違う方法でやった若干精度の粗いプロファイリング結果について書いています。

木曜日 8 18, 2016

マクラーレン・ホンダの66年分のJSONデータの検索

以前2015年の最終順位だけ見ましたが先週66年分のデータをロードしたのでまとめて見てみます。

Oracle 12c JSON機能でマクラーレン・ホンダの順位を見てみる

Oracle DB 12.1.0.2 の新機能であるJSON_VALUE()関数で年間順位を取り出した結果

JSON_VALUE()関数の2番目の引数のJSON pathは同じのを使えます。


SQL> select count(*) from api_responses
  2  where
  3  JSON_VALUE(RESPONSE,'$.MRData.StandingsTable.StandingsLists[0].ConstructorStandings[0].position')=1
  4  /
  COUNT(*)
----------
         8

以下の結果と合ってますね。

マクラーレン - Wikipedia

コンストラクターズタイトル  8

なお、McLARENのF1初参戦は1966年らしいので1965年のデータは以下のように空っぽです。
API自体は整形式のJSONを返してきたのでDBに格納する際にはエラーになりませんでした。

SQL> select RESPONSE from API_RESPONSES
  2  where URL like '%/1965/%'
  3  /
--------------------------------------------------------------------------------
{"MRData":{"xmlns":"http:\/\/ergast.com\/mrd\/1.4","series":"f1","url":"http://e
rgast.com/api/f1/1965/constructors/mclaren/constructorstandings.json","limit":"3
0","offset":"0","total":"0","StandingsTable":{"season":"1965","constructorId":"m
claren","StandingsLists":[]}}}
About

Personal View of a Sales Engineer in Tokyo.

Search

Archives
« 8月 2016
 
1
4
6
7
9
11
12
13
14
16
17
19
20
21
22
23
24
25
26
27
28
29
30
31
   
       
Today