ネタが出てこなかった
あるにはあるけどなんかつまらんなと言うのと、昔Swing使ってゲーム作った事とかだったっけど今さらSwingというのも
まだ、やろうとしていることは残ってるので
- [ ] Zabbixのインストールとか
- [ ] 中途半端に終わってるPostgresqlの続きとか
- [ ] タスク管理の話とか
- [] ブログでの数式の書き方とか
ネタが出てこなかった
あるにはあるけどなんかつまらんなと言うのと、昔Swing使ってゲーム作った事とかだったっけど今さらSwingというのも
まだ、やろうとしていることは残ってるので
これ書いてなかったなというので追加
例えばORDER BYで項目をソートする場合に、インデックスを使用するとインデックスの検索によってソートがかかるので、ORDER BYでのソートを取りやめて効率化します。
これがどういうときに有効利用できるかというと、LIMIT句で取得件数を制限する場合、ソートがかかっていれば必要な件数取得した時点で検索を終了します(LIMIT SCAN)。
SORT CANCELが働く場合と言うのは * SORT CANCEL BY INDEX 上で書いたとおりです
SORT CANCEL BY JOIN ORDER BYで指定している項目が結合条件に使用されている場合にORDER BYのソートをキャンセルします
SORT CANCEL BY DISTINCT ORDER BYで指定している項目がDISTINCT処理でソートされる場合にORDER BYのソートをキャンセルします
SORT CANCEL BY GROUPING ORDER BYに含まれる列がすべてグループ化処理によってソートされる場合にORDER BYのソート処理をキャンセルします
つまり、何かの処理でGROUP BYでソートしようとしていた項目に対するソートが働けば改めてソートをしないということです
このタイトルで書いてたんですが、操作ミスで下書き保存されてないままブラウザ落として消えてしまいました(泣)
今回はスマホからダイジェスト版で
実例で使うRDBMSはどれがいいか 商用製品 * OracleDatabase(無料のEnterprize版もある) * HiRDB(日立) * DB2(IBM) * SQLserver(Microsoft)
OSS * postgresql * mysql
実際の環境はdocker-composeで入れよう 1. qiitaから持ってくる 1. container_nameでエラー 1. 使えないらしいのでnameに変更 1. サービス名に記号が使えない 1. 変えてみて実行 1. dockerにゴミが残ってて実行できない 1. Postgres関連のコンテナをstop、kill、rm
こんな感じです 結論はDB設定まで行けてないというオチでした
追記
つなげなかった理由はこれです
VMで放置しっ放しのpostgresqlが邪魔してました
最近何かやらんといかんなと思って何がいいかなというので、そろそろ(ちょっと遅いかも)機械学習の事も知っておかないと思っていろいろと調べてみた(実際には今年の初めくらいからやってたりするのですが)
そうしたら、20年ぶりに再会した事があってちょっと驚いた
テンソルフロー(テンサーフロー,Tensor flow)というAIフレームワークの名前ですが、テンソルは運動量とか場の理論などで使われていて、学生時代にやった相対性理論でも使ってました
逆にカーナビ *1 でも作らない限りまた出会うこと無いかなと思っていた物に再会してちょっと感動
テンソル解析で求めた行列成分の偏微分は勾配の求め方とまったく同じ 空間の歪みと確率の分布が同じような概念で求められるんだなといったおもしろさを感じた
今日はこの辺で
この後、その数学的なつながりとかも書いていきたいな
当時読んでた相対性理論の本(もう中古しかないのか…) www.amazon.co.jp
当時読んでたテンソルの本 www.amazon.co.jp
Deep Learningの本(こちらでEbook Storeで電子版を購入すると安く手に入れられます) www.oreilly.co.jp
つづきです
前回分はこちらになります SQLのパフォーマンスを最適化するために - 技術関連の覚書
インデックスを作っても使えなくなる事があるので気をつけて避けるようにしましょう 得に何も書かない場合はITEM1をインデックス項目とします
SELECT ITEM1 FROM TABLE1 WHERE (ITEM1=? AND ITEM2='000') OR (ITEM1=? AND ITEM2='111')
この場合、UNIONやUNION ALLにする方がよいようです
SELECT ITEM1 FROM TABLE1 WHERE ITEM1=? AND ITEM2='000' UNION SELECT ITEM1 FROM TABLE1 WHERE ITEM1=? AND ITEM2='111'
SELECT ITEM1 FROM TABLE1 WHERE (ITEM1=? OR ITEM2='000') AND ITEM3=?
この場合は (ITEM1=? AND ITEM3=?) OR (ITEM2=‘000’ AND ITEM3=?) に分解できます
SELECT ITEM1 FROM TABLE1 WHERE (ITEM1='000' OR ITEM1='001' OR ITEM1='002') AND ITEM3=?
同一項目をOR検索する場合はINに置き換えられるのでINを使う
ITEM1 IN ('000', '001', '002')
SELECT ITEM1 FROM TABLE1 WHERE ITEM1 IN (SELECT ITEM1 FROM TABLE2 WHERE ITEM1>'002')
これはFROM句でJOINさせた方がいいようです
SELECT ITEM1 FROM TABLE1 T1 INNER JOIN TABLE2 T2 ON T1.ITEM1 = T2.ITEM2 WHERE T2.ITEM1>'002'
関数を使うとインデックスが適用できなくなるので代用できる物があれば避ける
例)
LEFT関数で前方一致をLIKEでの前方一致にする
ITEM1=LEFT()
↓
LIKE 'X%'
ITEM1 || ITEM2='AAA000'
↓
ANDで結合しましょう
ランキングは以下のとおりです
=で比較するPK
=で比較するインデックス
LIKEでの前方一致
INでの比較
BETWEENでの範囲検索*1
不等号(>,>=,<,<=)での比較
GROUP BYかORDER BYの列にあるインデックス
何となく、結合と似たところがあります 副問合せは作業表を作るのでこれがパフォーマンスを低下させる原因になる場合があります
外のSQLから1件検索ごとに副問合せのSQLを検索してワークテーブルを作ります
インデックスを使って副問合せを検索する方法です
副問合せの選択式の値を求めて作業表を作って、外を実行して1件検索して副問合せの結果を問い合わせます
あらかじめ副問合せ結果からハッシュ表を作成しておいて,外側の問合せを1行取り出すごとに外側の問合せの値をハッシングして,ハッシュ表と突き合わせをする方式です。
副問合せのインデクスを使用して,外側の問合せの結果との条件を評価します
3つ(だけ?)くらい中途半端な状態ですが、出かける時間がきてしまうので続きはWEBで(ここだろと言うツッコミ)
*1:A >= x AND A <= y と言う検索の場合はBETWEENに内部的に展開されます
SQLの続き各予定でしたが、PC立ち上げたときにふと気がついたので
httpsをサービス起動するときに手動起動した場合はそのままパスフレーズを入れればいいけど 自動起動した場合、バックグラウンドで起動した場合はパスフレーズが入れられないので下記のコマンドを使います
systemd-tty-ask-password-agent --query
これを以前調べたときにsshでログインしてからと書いてあったので、素直にssh経由でやってたのですが このままコマンド打ったらどうなるかとふと思ったので打ってみたらそのままパスフレーズ入力が出てきたのでわざわざターミナルを立ち上げる必要は無かったということでした
ひとまず棚卸が終わったので、今回からちゃんと書いていきます。
これまで書いてあった物を見てDBのメモはあったけどSQLについて書いて無かったので今回はSQLについて書いていきます(ちょうど今やってることだし)。
SQLと言うのはいろいろな現場に行くごとに用語が違っていたりしてどれが標準的な言葉かわからない事もあるので、 まず言葉の定義からしておきます。
用語 | 意味 | 他の言い方 |
---|---|---|
副問合せ | SQLのFROM句やWHERE句で別のSQLを定義すること 副問合せの検索結果をWHERE条件にしたり、テーブルと同様に扱うことができる |
サブクエリー |
別名 | テーブルや項目に対してつける別の名前 関数を使った場合にもつけることができ、選択式、テーブル名につけることができる |
エイリアス |
外表 | テーブル結合時に基準になる側のテーブル 下記のSQLのTABLE1に該当するが、結合結果も次に結合がある場合はそれが外表として扱われるためTABLE1とTABLE2の結合結果もTABLE3に対する外表となる |
外部表、駆動表 |
内表 | テーブル結合時に外表から結合される側のテーブル 下のSQLではTABLE1に対するTABLE2、TABLE1とTABLE2の結合表に対するTABLE3 |
|
アクセスパス | SQL実行時にどのような手順で実行していくかを示したもの | 実行計画 |
SELECT COUNT(ITEM1) CNT, ITEM1 I1, ITEM2 I2 FROM TABLE1 T1 INNER JOIN TABLE2 T2 ON T1.ITEM1 = T2.ITEM1 INNER JOIN TABLE3 T3 ON T2.ITEM3 = T3.ITEM3 WHERE T1.ITEM2 = ? AND T2.ITEM1 IN ( SELECT ITEM1 FROM TABLE1 ) SUB_T1 ORDER BY ITEM1 GROUP BY ITEM1, ITEM2 ;
SQLのパフォーマンスをあげるための一つとしてインデックスを使用する方法があります。 インデックスとは、本の索引と同じく、頭文字などを見出しにしてそれがどこにあるかを記述しているところです。
インデックスを使うと、検索する量を減らせるため速度をあげることができます。
テーブルの結合順や結合項目によってパフォーマンスが変わります。 結合の方法としては以下の物があります
NESTED LOOPS JOIN
SORT MERGE JOIN
HASH JOIN
CROSS JOIN
外表からインデックスを利用して内表を検索する結合方法なので、結合条件にインデックスが使われていることが必要 外表の件数を少なくすることで検索回数を減らすことができるので、件数の少ないテーブル、検索条件によって件数が絞り込まれるテーブルを外表にする
計算量: *1
外表、内表をソートして上から順に検索して結合していく方法 外表が大量データの場合はNESTED MERGE JOINよりも有利な場合がある
計算量:
データベースで、2つの表の小さい方を使用して、メモリー内にハッシュ表を作成する結合 大きい方の表をスキャンしてハッシュ表を調べ、小さい方の表の対応する行のアドレスを見つけます メモリー内にハッシュ表を作るため大量のメモリが必要になるが、メモリが多い場合は有利な検索方法
計算量: *2
外表から1レコードずつ内表を全件検索する方法 外表件数×内表件数だけの検索回数があるためパフォーマンスはもっとも悪い
計算量:
計算量についてはここを参照しました www.madeiradata.com
今日はここまで 意外に時間がかかりました(数式の書き方調べたり色々と)
さーて、明日のこのブログは
インデックスを使えなくする検索条件
インデックスを使う優先順位
副問合せの検索方法
の3本です 来週もまた見てくださいね
と言いながら、明日は出かけるのでかけるかどうかわかりません
(某国民的アニメとは関係ありません)