トランザクション分離と、その内実

トランザクション分離という概念を知りました

トランザクションとは？

「命令ひとまとまり」のこと

例えば、「AさんがBさんに100万円振り込む」という処理について、

1. Aさんの口座残高を100万円減らす
2. Bさんの口座残高を100万円増やす

の二つの処理を行う必要があります。

この時、1. だけ実行されて、2. が実行されないと大問題になります。

偉い人総出で謝罪会見必至です。

そのため、複数の命令を一つのパッケージとしてまとめ上げ、「もし途中で止まったら、一連の命令が全部実行されなかったことにする」必要が出てきます。

それを実現するのがトランザクションです。

1. トランザクションスタート
2. Aさんの口座残高を100万円減らす
3. Bさんの口座残高を100万円増やす
4. コミットする

とすることで、例えば3の実行が失敗してBさんの口座残高を増やせなかった時、2でやったAさんの口座残高更新も巻き戻すことができるようになります。

トランザクションは、ACID原則を満たしているべきとされます。

ACID トランザクション | Databricks

んで、マルチスレッドで同時に複数のクエリが飛んできた時、このうちの「独立性（Isolation）」が脅かされます。

並列トランザクションの問題

トランザクション処理中に、ある二つの命令の間に別のトランザクションがテーブルを書き換えてしまい、他のトランザクションの影響を受ける、というシナリオですね。

具体的には、ファントムリードとか、ダーティリードとか、ノンリピータブルリードとかの問題が起こります。詳しくはこちら

https://qiita.com/momotaro98/items/ad859ec2934ee98540fb

トランザクション分離

この問題を回避するのが、トランザクション分離です。

具体的には、 - READ UNCOMMITTED - READ COMMITTED
- REPEATABLE READ - SERIALIZABLE

の四つに分類されております。

下に行けば行くほど強力な分離です。

というか、一個下に行くと、並列トランザクションの問題を一個づつ潰せるようになります。

トランザクション分離の仕組み

トランザクション分離は、トランザクション分離実行中に、データベースにロックをかけることで実現しています。

それぞれ、

• READ COMMITTED：書き込み処理中に、行ロックをかける
• REPEATABLE READ：読み込み・書き込み処理中に行ロックをかける
• SERIALIZABLE：読み込み・書き込み処理中にテーブルロックをかける

という感じでできてるらしい

考察

ここからは考察、というか妄想

トランザクション分離レベルを上げるデメリットは？

ロック対象が広くなるから、パフォーマンスが悪化しそう？

あと、デッドロックが発生しやすくなる...んでしょうか。

でもデッドロックはテーブルの構造じゃなくて、テーブルの扱いで避けるべきもの...な気もする。

まあ詳しくは現場ででくわしてからな

わたし、テンプレートエンジンを使うことになりました！！

テンプレートエンジンって？

サーバー、バックエンドで動的にHTMLを生成する手法。

XSlate（for perl）とか、Smarty (for php)とかがあります。

テンプレートエンジンはHTMLに、専用の文法で記述を追加することで、紐付けられた関数の返り値を埋め込むことができる。

これによって、例えばリクエストのあった時間をHTMLとしてテキストにした状態で送ったり、DBのデータを事前にHTMLに埋め込んでフロントに送ったりできる

なぜテンプレートエンジン

• デザインとロジックを切り分ける
• フロントの処理の負荷を低減できる？

SSRとの関係性は？

SSR（サーバーサイドレンダリング）。 Next.jsでやる、VirtualDOMの描画をサーバーサイドでやっちゃうやつって認識（ちょっと違う気がする）

なんかテンプレートエンジンはSSRの一部って言ってる記事も見つけたけど、関係性はよくわかりませんでした！！ はいはい、いかがでしたかいかがでしたか

file openしたらfile closeしないといけない理由

あけた　ものは　ちゃんと　しめないと　いけない　んだよ　！！

なんで閉めないといけないのか

ファイルの読み書きは、OSカーネルを経由して行われる。

実際にファイルにアクセスする際は、カーネル上のテーブルにファイルのメモリ上の位置とか、そういう話を記録しておく。

このテーブル上でのIDが「ファイルディスクリプタ（File Descriptor）」である。

プログラムは、このファイルディスクリプタを指定することで、ファイルへの書き込みや読み出しを行う

（＝openした値をオブジェクトとして持っておいて、そのオブジェクトを通じて書き込んだりするやつ）

んで、このファイルディスクリプタには上限がある。

（多くの場合、初期値は1024に設定されている）

すなわち、ファイルディスクリプタが1024を超える、＝1024個以上のファイルを同時に開くことはできない。（プログラム単位ではなく、OS単位で）

なんで、開けたモノをちゃんと閉めないと（＝file closeしてファイルディスクリプタを解放しないと）、他の人に迷惑がかかるよ、って話。

【脇道回】DTMで「この音もっと前に来てほし〜〜」って時にやること一覧

曲、作ってますか〜〜？？？？

作ってますよね。

作ってますよね？？

作ってますよね。

そんな時、気になるのが「この音、もっとしっかり聴こえてほしいんだけどな〜〜〜〜〜〜〜〜」ってのです。

自分がよくやる方法をびゃっとまとめました。

正しいのかどうかはわからんから自己責任で

フェーダーを上げる

まずこれ。

「何もしてねぇのにパソコン壊れた！！」に対して「コンセント確認しろ」っていうのと同じくらい基本。

特に、サンプル音源とか使ってる場合、プロが気合い入れて調整した音が収録されてます。

素人が適当にフィーリングで触るより、「一般的に良い音」のはず。

EQコンプサチュ色々やる前にまずフェーダをあげなさい

帯域を持ち上げる

使うもの：EQ、サチュレーター

大体2パターンあります

1. 基音を持ち上げる。

単体楽器の音をアナライザとかで周波数特性を見ると、おそらく櫛かのこぎりみたいに、たくさんの山があるはずです。

それらは、「基本周波数の倍音」となります。

んで、連なる山々の一番低域がわにあるのが「基本周波数」です。

ここを3~6dbくらい持ち上げてあげると、音の存在感が増える...気がします。

とりあえずやってみよう

2. 1kを持ち上げる

人間の音の聞こえ方は、音の振幅に対して均一ではありません。（等ラウドネス曲線）

んで、人間はどうやら進化の過程で、1kHzのあたりに敏感になってるらしい。

なので、その辺の帯域が持ち上がっていると「前に聞こえる」「抜けて聞こえる」って感覚になるらしい

絶妙に後ろに隠れてんだよなぁ〜〜って時は試してみよう

歪ませる

saturation系のプラグインをブッ刺して、キュっとつまみを捻ると、なんか前に出てきます。

歪ませると、倍音が増えます。

倍音が増えると、高域が持ち上がります。

すると、なぜかよく聞こえるようになります（ガバ）。

この辺も等ラウドネス曲線が関連してそう。

人間は高域の音に敏感。。。ってことかなぁ

ちなみに、ギターの歪みみたいな、ガビガビにするやつじゃなくて、テープシミュとかのおとなしいやつです。

私はCubase付属のMagneto Ⅱってやつを使ってます。

ダイナミクス系エフェクト

大体三つあります

1. Compressor

何もわからんことでお馴染み、コンプ

音のボディが聞こえない（e.g. ベルの残響）場合は、これで持ち上げてあげるとうまくいく..気がする

2. Tranjent Shaper

コンプが音の振幅に反応して音量を下げるものであり、対してこのTranjent Shaperは音の変化量に反応して音量をあげるもの。

つまり、音のアタック感が強い場所の音を持ち上げてくれる。

音を歪ませずに、輪郭を強調できる良い子

SnareやPluck、時にはKickみたいなのにも、とりあえずアタック感がほしいときに使います。

3.OTT

OTT最強！！！！！！OTT最強！！！！！！

OTTとは、コンプのお化けみたいなもんです。

音量が大きいところを叩き潰し、音量が小さいところをパンプして、全体的にムッチリミチミチな音にします。

盛大に音が変わるので、音作りの一環として、用法用量を守って使いましょう。

王道の使い方はシンセベースとか

個人的には、ホーンセクションにブッ刺してあげるのが気に入ってます。

干渉してそうな音を逃す

主に周波数的に、干渉してそうな音を下げてあげたりすることで抜けを良くします。

ただ、これやりすぎると、ふと我に帰った時に「なんか曲全体の印象変わってね？？？？」ってなるので注意

左右に逃す

一個上と同じような発想。

パンを振ってあげて、抜けを良くします。

カウンターフレーズやシーケンスなんかで良くやる

逆に、キックとかスネアではできないので注意

オクターブ上げる・下げる

意外とこれが効く

シンセとかピアノとか、雑にオク上げ/下げできる楽器はこれで対応しても良いね

ギターとか管楽器とかは音域外にはみ出して死んだりするので注意、というかできないこと多い

サイドチェイン

キック限定

キックに限ってはこれが一番効く

キックがなるタイミングで、全体の音量を落とす、コンプレッサーサイドチェインや、KickStartみたいなオートダッキングプラグインを使いましょう。

DBのレプリケーションについておべんきょうしたよ

今の俺の認識：コピーを作っておくことで、クエリのスループットを上げる

レプリケーションとは？

DBの複製を作ること。

複数のマシンに分散して複製を作り、常に同期させること

何のためにレプリケーションするの？

1. 可用性の向上・障害対策
2. DBシステム全体の性能向上のため

1. 可用性の向上・障害対策

雷が落ちてサーバが死んだ・祈りが足りなくてサーバが死んだ・妖精さんの仕業でサーバが死んだなどなど、物理的なマシンが死んだ時、それの完璧なコピーが存在していれば、DBシステムそのものはダウンしないよね〜という発想

割と直感的

2. DBシステム全体の性能向上のため

一秒に100件のクエリが処理できるPCを使ってDBを構築している場合、一秒に120件のクエリが飛んでくると、処理しきれずにパンクしてしまいます。

この場合、高いPCを買ってそこにDBをおけば解決できますが...

1000件、100000件のクエリが来る場合、PCの性能がそもそも追いつかないケースがあります。

そんな時にレプリケーション。

常に同期されている、別々のDBを使ってクエリのスループットをあげようという発想

受付窓口業務を考える

どれだけ優秀な人でも、一時間あたりに捌ける人数は決まっている。

捌く人数を増やしたいなら...？

全く同じ台帳を元に、受付窓口をいっぱい作ればいいじゃない！という感じ

シングルマスタとマルチマスタ

レプリケーションはマスタとスレーブに分けられる。

マスタは書き込み権限があるDB、スレーブは読み出しだけできないDBである。

マスタが複数あると（マルチマスタ）、書き込みのスループットも向上させることができるが、複数のマスタに同時に異なる書き込み命令が出た場合、解決が非常に難しくなる（というか、定められない）

マスタが一つしないと（シングルマスタ）、書き込みのスループットは増えないが、上記の問題は発生しない。

シャーディング

似ている技術にシャーディングがある

レプリケーションは、同じ台帳をみんなで持とうね！って手法

一方、シャーディングは、みんなで少しづつ台帳を分割して持ってようね！って手法

シャーディングのメリット...多分各マシンの性能が小さくても行けるから、経済的ってことくらいかな...？わかんね

Perlのクラスわっっっっかんねぇ〜〜〜

Perlのクラス、かなりゆるゆる設計っぽい

フィールドは一個しか持てない

例えばpythonは

class hoge:
    def __init__(self):
        self.a = 1
        self.b = 2
        .
        .
        .

みたいに複数のメンバを持てます。

普通ですね。

でもPerlのクラスは一個しかメンバを持てません。

んじゃどうすんねん...と

メンバとして連想配列（PythonのDict）を持って、複数のメンバを扱えるようにするんですね

sub new {
    my $class = shift;
    
    my $self = bless \%_;  # ハッシュをメンバとして登録して...
    my $self->{a} = 1.        # ハッシュのaに1を代入

    return self;
}

クラス作成のためのモジュールがある

さっきのこれ、getterとかsetterとかまで作ると結構だるい

sub new {
    my $class = shift;
    
    my $self = bless \%_;  # ハッシュをメンバとして登録して...
    my $self->{a} = 1.        # ハッシュのaに1を代入

    return self;
}

そんなあなたに、Class::Accessor::Fast

use base 'Class::Accessor::Fast';

__PACKAGE__->mk_accessors(qw/a b/);

って書くと同じものが作れる...らしい

Class::Accessor::Fast見たいのは、拡張性とかによって他にも種類があるとか

Class::Accessor::Fastは特に拡張性が少なく、記述が簡単なやつらしいです

VSCode拡張機能とRemote Developement

VSCode拡張機能、いいですよね

我々の法であり、守護者であり、幸福の根源です。

私は最近、VSCode Power Modeを導入し、華やかなコーディングができるようになりました

https://www.premium-tsubu-hero.net/howtovscode-powermode/

ですが、最近リモートマシンにRemode Developementでアクセスした際にPower Modeが動かないという状況に陥りました。

なして？？？

Remote Developement

Remote Developementは、VSCodeからリモートマシンやコンテナ内にSSHで接続し、自分のマシン上のようにリモート環境で開発できる、VSCodeの素晴らしい機能です。

どうして動かなかったか？

Remote Developementで開発する場合、VSCodeの拡張機能の実体ファイルはリモートマシン側に配置されるそうです。

Linterも、Git Graphも、Power Modeも、全部リモートマシンの(home)/.vscode-server/extensions に置かれるそうです。

リモート環境でExtensionを使いたい場合、そのリモートマシンの管理者に許可をとってそのExtensionsを導入しないといけない。。。のかもしれない（これはそのチームのルール次第）