IT系のめもを蓄積していこうかと
誰も見ていないこのブログを立ち上げ、2024年11月で11年目となります。
丸10年ですね。
約200弱の記事を書いてきましたが、今見直してみると過去のやつは不十分なものもあるなと感じています。
さくらのVPSのCentos7で運用していますが、そろそろリプレイスが必要だな、とも思いつつ。。
この10年振り返ってみると、年々仮想化が強くなり、ITの巨人の肩にのる割合が増えている感じがします。
今後もこの流れは続くのかなとは思いますが、やはり銀の弾丸はないものなので、
特性を把握し、うまく利用していくための学習・情報収集・試行が必要なのかなと思います。
一方で、ビジネスとしては、小さいシステムが淘汰されていくのだろうかと感じつつ、
小さいシステムをちゃんと構築する経験を踏めなくなっていくのは、
今後の人材育成においても懸念に感じています。
確実なことはわからないのが世の常かもしれませんが、
このブログを少しでも長く続けられればいいなと今は思うばかりです。
以上
0.7.0をリリースしました。
https://github.com/shigenobu/ebonyrack/releases
今月はがんばった。。
0.6.8、0.6.9、0.7.0での対応内容は以下となります。
（依存ライブラリの最新化）
一定サイクルでやらないとね。
（HTMLの修正）
HTMLのsvgにtextを埋め込み、検索可能としました。
FONTを合わせないと、検索のときにずれてしまうので、
FONTもGoogleFontから取得するよう、HTMLも修正しています。
（検索機能）
CTR+Fで検索BOXが出現するようになりました。
workspace上で見えているテキストに対して検索し、
見つかった場合は、ワードをハイライトするとともに、
ワードを含んでいないオブジェクトを目立たないようにしました。
とはいえ、改善の余地がある感じではあります。
（サイドとワークスペースの連動修正）
これまではサイドのオブジェクト名をクリックすると、
ワークスペースの該当オブジェクトに移動し、フォーカスさせていました。
これを、クリックまたは十字キー選択では、該当オブジェクトに移動するにとどめ、
ダブルクリックまたはENTERキーで、フォーカスさせるようにしました。
これは検索時にサイドのオブジェクト名を目立たせないようにしたため、
クリックでフォーカスを当てると操作性が悪くなるためです。
また、ワークスペース上でフォーカスを持っているオブジェクトに対して、
サイドが連動して選択状態になるようにしています。
今回の検索機能で、指定のオブジェクトのみを目立たせることは不要になったので、
予定を修正して、以下のプランで今後を進めようかと思います。
テストデータ用のINSERT文作成というのが正確ですが、開発中にあると便利だなと思いました。
他のツールでもあったりするようなので、優先度上げてやってみようかなと思ってたりします。
以上
mysqlで連番を生成しようとすると以外と難しいです。
再起CTEなんかでやらないといけないかなと。
mariadbではsequence storage engineの機能を使うと、とてもかんたんです。
https://mariadb.com/kb/en/sequence-storage-engine
に書いてあるとおりです。
↓の感じですね。
> select * from seq_1_to_10;
+-----+
| seq |
+-----+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
+-----+
なんで連番を生成したいかというと、歯抜けが許されない場合があるからですね。
たとえば、↓のような状況だったとします。
> CREATE TABLE `active` (
`ymd` date NOT NULL,
`cnt` int(11) NOT NULL,
PRIMARY KEY (`ymd`)
);
> select * from active;
+------------+-----+
| ymd | cnt |
+------------+-----+
| 2024-10-01 | 10 |
| 2024-10-02 | 7 |
| 2024-10-04 | 11 |
+------------+-----+
見てのとおり、「2024-10-03」のデータがありません。
ここで連番テーブルとLEFT JOINすることで、
「2024-10-03」を「0」として計上できます。
↓の感じですね。
> with
t as
(
select date('2024-10-01') + interval seq day as ymd from seq_0_to_3
)
select
t.ymd as ymd,
coalesce(active.cnt, 0) as cnt
from
t
left outer join
active
on t.ymd = active.ymd
order by
t.ymd
;
+------------+------+
| ymd | cnt |
+------------+------+
| 2024-10-01 | 10 |
| 2024-10-02 | 7 |
| 2024-10-03 | 0 |
| 2024-10-04 | 11 |
+------------+------+
まあ、今更ですが、意外と連番生成は求められるので、
mariadbであるなら、sequence storage engineをつかうと楽ですよ、ってことですかね。
以上
0.6.7をリリースしました。
https://github.com/shigenobu/ebonyrack/releases
0.6.5、0.6.6、0.6.7での対応内容は以下となります。
（DDLの出力時にスキーマ名を指定可能）
これは、「use 〇〇;」をDDLファイルの先頭に入れるためです。
（オブジェクトのCTR+CとCTR+Vの対応）
オブジェクト（テーブル、シーケンス、ノート）は、今までも右クリックでコピー＆ペイストができたのですが、
CTR+CとCTR+Vの操作に対応しました。
CTR+Vでは、最も新しいコピー元を貼り付けます。
（テーブルのカラムへの挿入貼り付けとDELキーによる行削除の対応）
テーブル内のカラム一覧に、挿入貼り付けを対応しました。
これは大量のカラムを登録したいときに、エクセルなどで予め準備しておくことで、
一気に挿入可能となるものです。
「Column name」のセルの背景が薄い赤になっているので、
ここに対してCTR+Vで挿入貼り付けとなります。
また、DELキーで複数行の削除が可能となります。
（テーブルおよびシーケンス一覧の追加）
「Edit」のメニューに追加しています。
テーブルやシーケンスの情報を一括更新可能です。
テーブルでは、カラムグループとパーティションも編集可能です。
薄紫のセルに対して、CTR+Vをすることで、上書き貼り付けが可能です。
エクセルで変換情報を用意しておき、貼り付けるとよいかなと思います。
また、パーティションを一気に付与するなどができるようになっています。
（パーティションってあとでやる場合も多いので）
（複数オブジェクトの移動）
今まではオブジェクト1つずつしか移動できませんでしたが、
SHIFT＋左クリックで対象を複数選択し、移動することができるようになりました。
オブジェクトの重なり合いが少し微妙な部分はありますが、操作性の向上は図れています。
JTableのセル操作の向上が難しく、エクセルとの併用のほうが良いかと思い、
貼り付けなどを対応している感じになってます。
今後ですが、
あたりを優先的に考えてます。
その他としては、
あたりを考えています。
以上
MariaDBの同一ホスト間のデータ同期システムとして作っていたmagentadeskなのですが、
0.7.0のリリースで、MySQL 8.0.31 と 8.0.32 の対応を入れました。
https://github.com/shigenobu/magentadesk
なんで今までやらなかったかというと、
といったところでしたが、MySQL 8.0.31でEXCEPTが入ったので、
本腰入れて対応してみました。
やってみて色々大変でした。
なかでもUNIONの動作がおかしくて、無理やりやる感じでした。
MariaDBとMySQLでのUNIONの動作を見てみます。
まず以下のデータを用意します。
> select * from base;
+------+
| c |
+------+
| 1 |
| 2 |
+------+
> select * from compare;
+------+
| c |
+------+
| 1 |
| 3 |
+------+
次にこんなSQLを投げます。
with
t1 as
(
select * from base
except
select * from compare
),
t2 as
(
select * from compare
except
select * from base
),
tt1 as
(
select
json_object('c', t1.c) as b,
json_object('c', t2.c) as c
from
t1
left outer join
t2
on t1.c = t2.c
),
tt2 as
(
select
json_object('c', t1.c) as b,
json_object('c', t2.c) as c
from
t1
right outer join
t2
on t1.c = t2.c
),
t as
(
select * from tt1
union
select * from tt2
)
select * from t;
ちょっとややこしいのですが、
MariaDBとMySQLの結果を見てみます。
(MariaDB)
+-------------+-------------+
| b | c |
+-------------+-------------+
| {"c": 2} | {"c": null} |
| {"c": null} | {"c": 3} |
+-------------+-------------+
(MySQL)
+-------------+-------------+
| b | c |
+-------------+-------------+
| {"c": 2} | {"c": null} |
| {"c": 1} | {"c": 1} |
| {"c": null} | {"c": 3} |
+-------------+-------------+
いやー、MySQLの結果がおかしいですよね。これ仕様なのか？
EXCEPTで除いている筈なのに。。
MySQLのUNIONは結構昔から不具合あるようで、
なんかこうなってくると複雑な集計クエリーを投げるのがちょっと怖い感じもしますね。
現状では、気をつけましょうとしかいいようがないですが。。
以上
Rolling release（つまりSTS）なのですが、2024年8月にMariaDB11.5がGAになりました。
（参考）
https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-5
気になっていたtimestamp拡張が入り、
2106-02-07 06:28:15 UTC
までtimestampを扱えるようになりました。
実際に、10.11と11.5で比較してみました。
なお、timezoneは日本にしています。
MariaDB 10.11
-- int max
> set timestamp = 2147483647; select now();
Query OK, 0 rows affected (0.000 sec)
+---------------------+
| now() |
+---------------------+
| 2038-01-19 12:14:07 |
+---------------------+
-- int max + 1
> set timestamp = 2147483648; select now();
ERROR 1231 (42000): Variable 'timestamp' can't be set to the value of '2147483648'
+---------------------+
| now() |
+---------------------+
| 2038-01-19 12:14:07 |
+---------------------+
-- unsigned int max
> set timestamp = 4294967295; select now();
ERROR 1231 (42000): Variable 'timestamp' can't be set to the value of '4294967295'
+---------------------+
| now() |
+---------------------+
| 2038-01-19 12:14:07 |
+---------------------+
-- unsigned int max + 1
> set timestamp = 4294967296; select now();
ERROR 1231 (42000): Variable 'timestamp' can't be set to the value of '4294967296'
+---------------------+
| now() |
+---------------------+
| 2038-01-19 12:14:07 |
+---------------------+
見てもらえればわかりますが、
2038-01-19 12:14:07
が限界となっています。
MariaDB 11.5
-- int max
> set timestamp = 2147483647; select now();
Query OK, 0 rows affected (0.001 sec)
+---------------------+
| now() |
+---------------------+
| 2038-01-19 12:14:07 |
+---------------------+
-- int max + 1
> set timestamp = 2147483648; select now();
Query OK, 0 rows affected (0.001 sec)
+---------------------+
| now() |
+---------------------+
| 2038-01-19 12:14:08 |
+---------------------+
この時点で、超えましたね。
-- unsigned int max
> set timestamp = 4294967295; select now();
Query OK, 0 rows affected (0.001 sec)
+---------------------+
| now() |
+---------------------+
| 2106-02-07 15:28:15 |
+---------------------+
-- unsigned int max + 1
> set timestamp = 4294967296; select now();
Query OK, 0 rows affected, 1 warning (0.001 sec)
+---------------------+
| now() |
+---------------------+
| 2106-02-07 15:28:15 |
+---------------------+
> show warnings;
+---------+------+---------------------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------------------+
| Warning | 1292 | Truncated incorrect timestamp value: '4294967296' |
+---------+------+---------------------------------------------------+
unsigned int の最大値を超えるとwaningはでましたが、
2106-02-07 15:28:15
まで最大値が伸びているようです。
そもそも、timestampをunsignedにしたというのは、ドライバー影響を抑えるという名目だったかなと。
で、実際に以下のようにデータを入れてみます。
CREATE TABLE `t1` (
`c1` timestamp NULL DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
insert into t1 values ('2106-02-07 15:28:15');
> select * from t1;
+---------------------+
| c1 |
+---------------------+
| 2106-02-07 15:28:15 |
+---------------------+
これをPHPとC#（mysqlconnector）で取得してみたところ、
2106-02-07 15:28:15
が取得できることは確認できました。
MySQL側も同様の対応をしてくれると嬉しいです。
以上
大したリリースではないのですが、記載します。
https://github.com/shigenobu/ebonyrack/releases
0.6.1と比べて、
・マルチディスプレイの修正
・tableのカラムのテキスト部分をダブルクリックで選択可能（コピーしやすいように）
・読み込み専用モードで開く環境変数追加
という薄い内容です。
tableのカラムのテキストを選択可能とするのは意外と難しく、
もともろJLabelでやっていたのですが、JLabelではテキスト選択ができないため、
JTextFieldにして、ダブルクリックイベントで、コメントの部分の選択範囲を修正するなどの対応を行っています。
やりたいことが難しくて、なかなか進まない現状。。
外部キーのANTLRのパースとかも入れたほうがいい気がしてきています。。
以上
OS: Pop!_OS 22.04 LTS
dotnet: 8.0.204
という環境で、
ASP.NET coreのWEBアプリケーションから、
mysql, memcached, redisへのアクセスをするのベンチマークをしてみたところ、
同期＞非同期
となる局面があったので、書いておきます。
使用したライブラリは、
mysql: https://github.com/mysql-net/MySqlConnector
memcached: https://github.com/cnblogs/EnyimMemcachedCore
redis: https://github.com/StackExchange/StackExchange.Redis
です。
行ったベンチマークは、1回のリクエスト〜レスポンス処理の間に、上記データベースに複数回問い合わせるというもので、
よくあるWEBアプリケーションみたいな感じのものです。
で、結果を載せるほうがよいのですが、環境によって大きく左右されるので、
「こういうときは同期が速い」という所感レベルなものとさせていただきます。
というか、なんでこんなことをしたのかというと、
C#界隈では、どうしてもasync/awaitを使った非同期がベストプラクティスと言われているのですが、
async/awaitを使った非同期って、
・await一箇所でも書かなかったら実行時に気づかないような不具合を生むことがあり、
大きいプロジェクトほど、そのミスに気づけなくなる。
・呼び出し階層がすべて非同期になっている必要がある。
・ローカルネットワーク内にあるmysqlのような高速なデータベースに、
主キーで問い合わせるなどの高速なIOのケースにおいて、
CPUのコンテキストスイッチのほうがコスト高いときがあるんじゃないか？という疑問をもっていた。
のような課題もあるなとずっと思っていました。
とはいえ、同期の欠点は「詰まりやすい」ということで、
確かに1つの処理が遅れると、全体の遅れに影響してくるというのも経験しています。
しかしながら、エンドレスにハイトラフィックな事例というのもごく一部であり、
アプリケーションサーバのCPUを常に100%近く使うようにさせられている（つまり無駄を削ぎ落とす）
ようなことも稀かと思います。
ITの世界では、大は小を兼ねるかと思いますが、予算も限られた中でやるとして、
一定の余裕がある構成で、トラフィックも読めているのであれば、
無理にすべてをasync/awaitの非同期でやる必要もないとは個人的には考えています。
とはいいつつも、昨今のデータベースなどのミドルウェア事情として、ITの巨人が開発した巨大なソフトウェアを利用する局面も増えており、
こういったものは、mysqlのスタンドアロンとは違い、内部的になんども通信しているため、
IOレイテンシーは悪くなっています。
となると、結局、こういったものを利用することを想定して、
IOレイテンシーが悪くなっても耐えうるアプリケーションを用意しておかないといけないなと思いったわけです。
だけど、やっぱり計測してみないといけないなと思い、同期と非同期のベンチマークを取ったということです。
話が少しそれましたが、
同期＞非同期
となるのは、
・同一ネットワーク内で高速なIOが見込めるとき
・アプリケーションに負荷がかかっていないとき
という条件を同時に満たすときです。
これが満たせなければ非同期のほうが良いと思われます。
たとえば、
・インターネット越しにIOを行う
・IOが高速でないデータベースを使う
・アプリケーションへの負荷が高いことが予想される
などの場合は、非同期に分があるでしょう。
C#のASP.NETでkerstrelを使う場合、スピンアップの悪さも、
非同期を使うことで抑え込めるという利点もあります。
「結局非同期のほうがいいじゃないか」という結論とも捉えられますが、
いろいろ考えると「結局非同期のほうがいい」のです。
ただ、1回でもawait書き忘れた場合のリスクについては、
開発エンジニアへの教育であったり、レビューなどでカバーしないといけないか思います。
私は、C#を利用している側の人間に過ぎないのですが、
こういったリスクについても、ふっとばされているようにも感じます。
「当たり前」なのかもしれませんが、開発エンジニアの知識レベルは様々であり、
ただでさえ近年複雑な要求仕様に対応を迫らている上で、
完璧な非同期コードを書くことも一苦労だと思います。
なので、非同期のリスク（お作法）についても、現場の理解力と、教育が大事だなと思う今日この頃です。
駄文失礼いたしました。
以上
忙しくて放置気味でしたが、
MariaDB11.4がLTSとして2024年5月にリリースされました。
https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-4
2029年5月までのサポートとなります。
見落としていたのですが、またリリースサイクルが変わったようで、
次のLTSも1年後とかなのかなと思います。
注目していたtimestamp型の拡張は、11.5に見送られたようですね。
また、自分の作成している
https://github.com/shigenobu/magentadesk
もv0.6.2で11.4対応しました。
以上
TAPベースに非同期処理に関連して、
ネットを調べると、「同期と非同期の混在によるデッドロック」みたいな記事が多い。
これ、よく調べてみると、.NET FRAMEWORKの話だったりして、
.NET（core以降）のASPでは、どうやら事情が違うようです。
（※GUIについては、ここでは触れません）
CUI（コンソール）アプリケーションについては、もともとSyncronizedContextがないから、
デッドロックしないよ、みたいな話はあるのですが、
ASP.NET Core以降は、SyncronizedContextがなくなったため、よくあるデッドロックというのは起きません。
（参考）
https://blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html
https://qiita.com/jun1s/items/c178d37a2cbcd8594461
というわけで、デッドロックしそうなコードをかき集めて検証してみました。
下記コードの検証環境は以下の通りです。
$ dotnet --version
8.0.204
$ cat /etc/os-release
NAME="Pop!_OS"
VERSION="22.04 LTS"
（パターン１）
app.MapGet("/test1", async () =>
{
Console.WriteLine("test 1-------------------------");
Console.WriteLine($"before - {Thread.CurrentThread.ManagedThreadId}"); // 1: スレッドIDは15
var ret = MyClass.Get().Result;
Console.WriteLine($"after - {Thread.CurrentThread.ManagedThreadId}"); // 4: スレッドIDは15
return ret;
});
class MyClass
{
public static async Task<string> Get()
{
Console.WriteLine($"before in - {Thread.CurrentThread.ManagedThreadId}"); // 2: スレッドIDは15
var ret = await Task.Run(() => "ok");
Console.WriteLine($"after in - {Thread.CurrentThread.ManagedThreadId}"); // 3: スレッドIDは14 ★ここでスレッドが変わっている
return ret;
}
}
（パターン２）
app.MapGet("/test4", async () =>
{
Console.WriteLine("test 4-------------------------");
Console.WriteLine($"before - {Thread.CurrentThread.ManagedThreadId}"); // 1: スレッドIDは9
var result = MyClass.GetFromHttp().Result;
Console.WriteLine($"after - {Thread.CurrentThread.ManagedThreadId}"); // 4: スレッドIDは9
return result;
});
class MyClass
{
public static async Task<string> GetFromHttp()
{
var client = new HttpClient();
Console.WriteLine($"before in - {Thread.CurrentThread.ManagedThreadId}"); // 2: スレッドIDは9
var response = await client.GetAsync("http://localhost:8080");
Console.WriteLine($"after in - {Thread.CurrentThread.ManagedThreadId}"); // 3: スレッドIDは7 ★ここでスレッドが変わっている
return response.Content.ReadAsStringAsync().Result;
}
}
というわけで、色々勘違いしそうなんですが、
ASP.NET Core以降では、「同期と非同期の混在」によるデッドロックは起きないようです。
つまり、「ConfigureAwait(false)」がなくても良いのです。
※すいません、間違ってたら教えて下さい。
とはいえ、ライブラリアプリケーションの場合は、
どの実行基盤で使われるかわからないので、「ConfigureAwait(false)」はつけておいたほうが良いかと思います。
C#のasync/awaitは沼だなといつも思う。
わからないことだらけです。
ちょっとしか見てないんですが、Restsharp なんかでは内部でSyncronizedContextを持っているようで、
どうしてこうなっているのかは謎が深まるばかりです。
いつか、スッキリ整理してまとめたいと思うこの頃。
できれば、IO待ちに関しては、「AWAIT」ではなく「NOWAIT」にして欲しかったりする。
つまり、非同期をデフォルトってことですかね。（新しいMSの言語まで待ちかな？）
以上