画像処理勉強することリスト
- オライリー実践コンピュータビジョン
- 特徴点抽出アルゴリズムの論文(SIFT/AKAZE)
- Structure from Motion系の論文(global/incremental)
- ベクトル計算とかの数学的知識(射影変換など)
# なぜ勉強するか
- 仕事で関わってるから
- 画像処理×並列分散的な研究で弊社チームは後者担当
- 前者は別の研究機関が分担してる
- が割と最近は前者の知識も要求されている感がある
- 中身がわからないと、トラブルシュートがログを随時ググって思いついたこと総当たりみたいなことしかできない
- 対症療法しか打てない
- 画像処理は割と避けてきたが、この際いい機会なので勉強する
Game of thrones 最終章(8章)見終わった
ドラマ系の作品で最後までちゃんと見たのはBreaking Bad、プリズンブレイクにつぐ3作目。
剣と魔法の世界領土争い戦争みたいなドラマ。魔法はあんまり出てこないけど、ドラゴンやゾンビが出てくる。 原作も少し読んでみたが英語が全然分からなくて妥協した。原作はドラマでいうところのシーズン6までしか作成されていないので、シーズン6までしか原作準拠ではないらしい。 確かに面白さのピークもそのあたりだった気がする。英語ちゃんと勉強して原作も読みたい。
音楽や衣装、小道具、CGどれをとっても映画のような重厚感で、一話一話映画をみてるようなスケールを感じました。 この作品は主人公補正的なものがないというか、お前死んだらダメだろみたいなキャラがガンガン死んでいくので、常にハラハラで見ていて飽きなかったです。 反面、ネタバレがあると楽しみが減るのでネットの情報などはあまり見ないほうがいいと思います。
最初第一話を見たときは登場人物が多すぎるのと、似たような顔の人が多くてストーリが理解できなかったので楽しめませんでしたが、 スターチャンネルで公開されている人物相関図とか見てなんとか乗り切りました。(ここに乗ってない人たちもたくさん出てきます。)
wikipediaは積極的にネタバレを書いていく方針なのか、ネタバレだらけなので全部見終わるまで見ないほうがいいと思います。
- 作者:ジョージ・Ｒ・Ｒ・マーティン,岡部 宏之
- 発売日: 2012/08/01
- メディア: Kindle版
A Game of Thrones: Book 1 of a Song of Ice and Fire
- 作者:Martin, George R. R.
- 発売日: 2011/09/01
- メディア: ペーパーバック
SQLパフォーマンス詳解オンライン読書会(3)ノート
p45「LIKEフィルタに対するインデックス」から読んだ
次回p70 「列の連結」から
like
- 最初のワイルドカードの前までインデックスツリーの操作がされる
- 最初のワイルドカードの前部分の選択性を高くする
'WI%ND' > 'WIN%D' > 'WINA%'- ワイルドカードから始まるLIKE式は効率が悪いからやめる
%TERM%
- Prepared Statement + Like式を使った場合、postgreSQLだとインデックスが使われない。
- 全文検索を使う
- MySQL
- match
- against
- Oracle
- contains
- postgreSQL
@@演算子
- SQL Server
- containns
- MySQL
- 最初に1つだけワイルドカードのある条件(
'%TERM')の対処- 逆キー索引:REVERSEキーワード(Oracle)
https://jeffkemponoracle.com/2008/01/like-with-wildcard-at-start-can-use-an-index/
インデックスの結合
インデックスは、2つ使うより1つだけ使う方が高速。
二つ以上の範囲条件を含むクエリをサポートする単一のindexはない
- マルチカラムインデックス+フィルタ述語
- 選択制の高い列をインデックス定義の最初におく
- 別々の列にそれぞれindexをはる。
- 複数をまとめて効率的に使えるインデックス→ビットマップインデックス
- 事前にクエリが分かっている場合はマルチカラムBツリーインデックスの方が早い
- insert,update,deleteの性能が悪い
- DWH向き。OLTPでは使い物にならない。
- 複数をまとめて効率的に使えるインデックス→ビットマップインデックス
- マルチカラムインデックス+フィルタ述語
- 余談:マルチカラムインデックスの単一カラムのみを使用するインデックススキャン
- オプティマイザの判断なので狙うのは難しい。
部分インデックス
- 特定の行にのみインデックスを張る
- INDEX定義時にwhere句を使うだけなので簡単に作れる。
CREATE INDEX messages_todo ON messages (receiver) WHERE processed = 'N'
- MySQLの部分インデックスはこれとはまた違うみたい。
- 長さがわからないテキストの最初のデータにindexをはるみたいなやつ
- 2GBのカラムを含むレコードにindexを張るのは無理
- 長さがわからないテキストの最初のデータにindexをはるみたいなやつ
- 余談:indexに対するSQL標準はない
OracleのNULL
- 空文字列をNULLとして扱う
- SQL標準と違っている
- NULLの連結は通常のDBはNULLになる
- Oracleの場合、空文字になる
- VARCHAR2に空文字を格納できない
- 格納するとNULLになってしまう。
このような奇妙な動作に対するOracle互換モードがある
インデックス定義に含まれる列の全てがNULLの場合はindexに含まれない。
- 全てのindexはNULLを含まない部分インデックスのようになっている
NULLを含むインデックスを作成したい場合はNULLになることがない列をインデックスに追加する(定数でもOK)
CREATE INDEX emp_dob ON employees (date_of_birth, '1')
インデックスに含まれる列に NOT NULL制約がないとインデックスが使われない→フルスキャンになる。
これ以降眠い&謎のzoom中断によりメモってません。。。
- 作者:Markus Winand
- 発売日: 2015/09/14
- メディア: ペーパーバック
Database Concurrency Control Papadimitriou 読会(26回)に参加
p74「The Gadget」から読んだ。
次回はp76 「Our proof~」から
PSPACE
- polynnomial amounnt of space で解決できる問題
P ⊂ NP ⊂ PSPACE
Gadget
- time t:
- 最初のstepを1,次に起こったstepを2,という風に順序付けていく全順序
- tはHistoryの開始~終了までのうちのどこかの時点を表す
- もちろんassignするのはlegal versionである。
:tが入ったポリグラフのこと
- complition of
- time tまでのfull scheduleが(s,V)と一致している
- tの時点でactiveなtransactionのなんらかの順序が決まる
- legal version?:要復習
Polygraph of t
- (1)AがwriteしたxをBが持つ
- (2)Aがread,writeしたxをBがwriteする。Bがwriteしたxはtの時点で唯一の"available"である(?)
- (3)Aがxの初期値を読み、Bがxを上書きした場合
- (2)と(3)の違いは？
- availableの意味は？
にマップされない？
- 謎
- availableの意味は？
- ?マーク付き無方向エッジ
- 同じentityをwriteしてconflictしているが、どちらが先かわからない状態
- (A,B) or (B,A)
- 同じentityをwriteしてconflictしているが、どちらが先かわからない状態
- 例:Figure 3.2のSchedulle sの
がFigure 3.3になる
- 補足
=standard version functionを採用したVのこと
- Dがabortされた場合
- (A,B)のarchが追加される
- A,Bはxのwriteでconflictしていたが、
が読むxはDが上書きしていたため順序を決める必要がなかった
- Dがなくなったことによりこの順序を決める必要がある
- (A,B)が追加された時により、(G,B,F)のチョイスは(G,B)が選ばれる
- 消去法。(A,B,F)の循環を避けるため
- (G,B)が選択されたことにより、?マーク付き無方向エッジは(E,C)が選ばれる
- これも消去法で (G,B)が選ばれたことによる(G,B,C,E)の循環を避けるため
- 補足
Theory of Database Concurrency Control
- 作者:Papadimitriou, Christos
- 発売日: 1986/07/01
- メディア: ハードカバー
SQLパフォーマンス詳解オンライン読書会(2)ノート
- 2020/05/07 20:00~22:00
- 今回はp18「遅いインデックスパートII 」からp44「大なり、小なり、BETWEEN」まで読んだ
- 次回は45から
遅いインデックス パートII
クエリオプティマイザ:SQLを実行計画に変換するコンポーネント
- Cost-Base-Optimizer
- 統計情報などからコストを評価する
- Rule-Base-Optimizer
- ハードコードされた優先順位で実行計画を生成
- oracleは10で廃止
- Cost-Base-Optimizer
インデックスを遅くする要因
- 広範囲のインデックス探索
- 沢山の行を1行づつ読み出す処理
- 統計情報が存在しない時のデフォルト値が最適でない
- INDEX RANGE SCANのデフォルト値=40
関数
大文字小文字を無視した検索条件を書きたい
WHERE UPPER(last_name) = UPPER('winand')- FULL SCANが発生する
- 定数は左辺に置かないと遅くなる？
対策:関数インデックスを使う
CREATE INDEX emp_up_name ON employees (UPPER(last_name))- SQL Serverは関数インデックスはサポートしない
- 計算列/生成列にindexをはる
ALTER TABLE employees ADD last_name_up AS UPPER(last_name) CREATE INDEX emp_up_name ON employees (last_name_up)- viewにindexを貼る方法は？
- SQL Serverのみ可能だが一般的ではない。
- 計算列/生成列にindexをはる
- 関数indexはdeterministicな関数にしか利用できない
- deterministic→引数に対して同じ値を返すこと
- ダメな例;現在時刻や乱数的な要素を隠し入力としてもつ関数
- Sysdateを使うget_age関数
RETURN TRUNC(MONTHS_BETWEEN(SYSDATE, date_of_birth)/12);
- Sysdateを使うget_age関数
- ダメな例;現在時刻や乱数的な要素を隠し入力としてもつ関数
- deterministic→引数に対して同じ値を返すこと
注意;ORMがUPPER/LOWERを勝手に使うことがある
- 例;hibernateの大文字・小文字を区別しない検索
- FULL SCANが発生する
この本はSQL ServerやPostgreSQLの統計情報の読み方が解説されているらしい。
- 以外とそういう資料ないので貴重
インデックスの作り過ぎ
uppere(last_name)の関数indexを作った際に、lower(last_name)も作りたい- 余計なindexが増える
- 1つのテーブルに対して6つまで、という本もある
- オラクルパフォーマンスチューニング？という本らしい
- 6個は厳しいのでは
- 1つのテーブルに対して6つまで、という本もある
- 余計なindexが増える
パラメータ化クエリ
- パラメータ化クエリ＝プレースホルダを使った実行
- メリット
- セキュリティ=SQLインジェクションの防止
- パフォーマンス
- デメリット
- オプティマイザがコスト計算を使い回す
- 最初に実行した変なワークロードのクエリで計算したコストがキャッシュされる可能性
- オプティマイザがコスト計算を使い回す
- メリット
- プレースホルダが埋められた状態で評価されるのか？それとも埋められる前に評価されるのか？
- 歯切れのいい回答が出なかった
- 埋めらる前に評価される、という風に書かれているように読めるけど？
- JDBCの仕様でプリペアドステイトメントの機能が必須化されている
- MySQLの過去バージョンではインターフェースのみ準拠して、内部で適当にやっていたらしい？
- 5系でもそんな感じらしいが最近のは未確認とのこと
- MySQLの過去バージョンではインターフェースのみ準拠して、内部で適当にやっていたらしい？
- DBI
- DBD
範囲検索
- 複合インデックスの検索時にはインデックスの列の定義順に注意する。
- インデックスの定義順により実行計画の以下が変わる
- アクセス述語
- フィルタ述語
- インデックスの定義順により実行計画の以下が変わる
