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をつかうと楽ですよ、ってことですかね。

以上

投稿日時:2024年10月19日 00:02   カテゴリー:mariadb  

0.6.7をリリースしました。

https://github.com/shigenobu/ebonyrack/releases

0.6.5、0.6.6、0.6.7での対応内容は以下となります。


これは、「use 〇〇;」をDDLファイルの先頭に入れるためです。

オブジェクト(テーブル、シーケンス、ノート)は、今までも右クリックでコピー&ペイストができたのですが、

CTR+CとCTR+Vの操作に対応しました。

CTR+Vでは、最も新しいコピー元を貼り付けます。

テーブル内のカラム一覧に、挿入貼り付けを対応しました。

これは大量のカラムを登録したいときに、エクセルなどで予め準備しておくことで、

一気に挿入可能となるものです。

「Column name」のセルの背景が薄い赤になっているので、

ここに対してCTR+Vで挿入貼り付けとなります。

また、DELキーで複数行の削除が可能となります。

「Edit」のメニューに追加しています。

テーブルやシーケンスの情報を一括更新可能です。

テーブルでは、カラムグループとパーティションも編集可能です。

薄紫のセルに対して、CTR+Vをすることで、上書き貼り付けが可能です。

エクセルで変換情報を用意しておき、貼り付けるとよいかなと思います。

また、パーティションを一気に付与するなどができるようになっています。

(パーティションってあとでやる場合も多いので)

今まではオブジェクト1つずつしか移動できませんでしたが、

SHIFT+左クリックで対象を複数選択し、移動することができるようになりました。

オブジェクトの重なり合いが少し微妙な部分はありますが、操作性の向上は図れています。


JTableのセル操作の向上が難しく、エクセルとの併用のほうが良いかと思い、

貼り付けなどを対応している感じになってます。

今後ですが、

  • 特定の名称パターンのオブジェクトのみを表示する(例えば「shop」が含まれているテーブルだけ表示するなど)
  • VIEWの対応

あたりを優先的に考えてます。

その他としては、

  • 外部キーのDDLを読めるようにする(ANTLRのパースで、自前で生成したものくらいは読めるようしたいかな)
  • FUNCTION/TRIGGER/PROCEDUREの追加
  • 検索機能
  • データ作成機能

あたりを考えています。

以上

投稿日時:2024年10月18日 23:40   カテゴリー:java, mariadb  

MariaDBの同一ホスト間のデータ同期システムとして作っていたmagentadeskなのですが、

0.7.0のリリースで、MySQL 8.0.31 と 8.0.32 の対応を入れました。

https://github.com/shigenobu/magentadesk

なんで今までやらなかったかというと、

  • テーブルの解析でのinformation_schemaの格納のされ方が微妙にMariaDBとMySQLで異なる
  • MySQLではEXCEPTが8.0.31までなかった
  • MariaDBのdynamic columnに相当する機能がMySQLでは賄えるか不安だった
  • シーケンスがないのをどうするか

といったところでしたが、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は結構昔から不具合あるようで、

なんかこうなってくると複雑な集計クエリーを投げるのがちょっと怖い感じもしますね。

現状では、気をつけましょうとしかいいようがないですが。。

以上

投稿日時:2024年09月26日 00:43   カテゴリー:java, mariadb, mysql  

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側も同様の対応をしてくれると嬉しいです。

以上

投稿日時:2024年09月26日 00:18   カテゴリー:mariadb  

大したリリースではないのですが、記載します。

https://github.com/shigenobu/ebonyrack/releases

0.6.1と比べて、

・マルチディスプレイの修正

・tableのカラムのテキスト部分をダブルクリックで選択可能(コピーしやすいように)

・読み込み専用モードで開く環境変数追加

という薄い内容です。

tableのカラムのテキストを選択可能とするのは意外と難しく、

もともろJLabelでやっていたのですが、JLabelではテキスト選択ができないため、

JTextFieldにして、ダブルクリックイベントで、コメントの部分の選択範囲を修正するなどの対応を行っています。

やりたいことが難しくて、なかなか進まない現状。。

外部キーのANTLRのパースとかも入れたほうがいい気がしてきています。。

以上

投稿日時:2024年07月09日 23:37   カテゴリー:java, mariadb  

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#を利用している側の人間に過ぎないのですが、

こういったリスクについても、ふっとばされているようにも感じます。

「当たり前」なのかもしれませんが、開発エンジニアの知識レベルは様々であり、

ただでさえ近年複雑な要求仕様に対応を迫らている上で、

完璧な非同期コードを書くことも一苦労だと思います。

なので、非同期のリスク(お作法)についても、現場の理解力と、教育が大事だなと思う今日この頃です。

駄文失礼いたしました。

以上

投稿日時:2024年06月24日 23:20   カテゴリー: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対応しました。

以上

投稿日時:2024年06月24日 22:33   カテゴリー:mariadb  

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"

(パターン1)

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;
    }
}

(パターン2)

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の言語まで待ちかな?)

以上

投稿日時:2024年04月25日 00:43   カテゴリー:c#  

ちょこちょこ作業してます。

https://github.com/shigenobu/ebonyrack/releases

たまには画面もつけてみよう。(GITHUBに載せたままですが)

v0.5.2からv0.6.1までの主な変更は以下のとおりです。

  • テーブル・シーケンスの右クリックに「Edit」追加(ダブルクリック以外でも開けるように)
  • DDLインポート修正(DOCコメントの不具合、カラムオプションに生成列とチェック制約を登録できるように)
  • 起動時に最新バージョンのチェックを行う(古いバージョンの場合最新バージョンのリンクが表示されます)
  • HTMLにおいて、ダイアログの外側をクリックしたときに、ダイアログを閉じる処理を追加

やりたいことはたくさんあるのですが、なかなか実装が難しいので、

とりあえず未来のTODOを記録しておきます。

  • VIEWの対応
  • TRIGGERの対応
  • FUNCTIONの対応
  • PROCEDUREの対応
  • まとめて行う処理諸々(テーブルやパーティションに対してのグループの一括付与・除去とか、テーブルからカラムをまとめて付与・除去とか)
  • カラムを選択可能にしたい(JEditorPaneとか)
  • オブジェクトの複数一括移動
  • オブジェクトのグループ化みたいなもの

うーん、どれも難しい。。

以上

投稿日時:2024年04月25日 00:22   カテゴリー:java, mariadb, mysql  

1ヶ月ほど立ちましたが、MariaDB 11.3がGAされました。

https://mariadb.com/kb/en/mariadb-11-3-2-release-notes/

※debianパッケージで不具合があるようですが。。

11系のGAはまだですが、11系のリリースを少しピックアップしてみます。


(11.0)

・オプティマイザのコストが進化

(11.1)

・DATE関数、YEAR関数の左辺配置でもINDEXが利用されるよう修正

(11.2)

・オンラインDDLの修正

(11.3)

・リダイレクトの導入

・DATE_FORMAT関数にタイムゾーンの書式追加


ぱらっと見た限り、日付系の対応がちょこちょこはいっており、

タイムゾーン(datetime with timezone みたいな)に対応していくような動きですね。

次の11.4では、timestampの変更(intからunsignedへの変更、ドライバー影響を抑えるため)が予定されており、

2039年問題が伸びるので、それまでに新しい型の導入を進めていく感じになるのでしょうか。

このあたりは、MySQL側の動きにも注目ですね。

で、個人的にちょっと気になったのは、11.2でのオンラインDDLの修正でしょうか。

(参考)

https://mariadb.com/resources/blog/alter-table-is-now-universally-online/

MySQLではオンラインDDLというと、「LOCK=NONE」なもの、

つまりALTER中も並行してDMLを受け入れるというものです。

「LOCK=NONE」なDDLというと、基本的には「ALGORITHM=NOCOPY」のもの、

「INSTANT」や「INPLACE」のみでした。

11.2の対応では、「ALGORITHM=COPY」も「LOCK=NONE」で動作するようになりました。

すべての動作ではないようですが、参考ページによるとおおよそ以下のDDLが「LOCK=NONE」となったようです。

  • カラムのデータ型変更
  • カラムをNOT NULLに変更
  • 制約のないカラムに対してDEFAULTの追加
  • STOREDの生成列の追加
  • チェック制約の追加
  • 主キーの削除
  • パーティションテーブルへの変更または削除
  • システムバージョニングの追加
  • オートインクリメントの追加

細かい制約もあるようなので、参考ページをちゃんと読んでもらえばと思います。

MySQLでは、

https://dev.mysql.com/doc/refman/8.0/ja/innodb-online-ddl-operations.html#online-ddl-foreign-key-operations

ということで、見比べてみると、拡張されたことがわかるかと思います。

とはいえ、DDLの適用コストは、INSTANTのような軽さはないので、油断はせずいてもらればと思います。

ちなみに、INSTANTの適用範囲は、以前書いたものから変わっていないようです。

※metaデータロックはかかりますのでご注意を。

また、magentadeskのv0.6.1が、MariaDB 11.3対応しています。

https://github.com/shigenobu/magentadesk

以上

投稿日時:2024年03月21日 23:20   カテゴリー:mariadb, mysql