EBt の最新版を公開しました

EBt の最新版を公開しました

ここんとこ疲労困憊で死んでいたので公開の案内が遅れてしまい申し訳ありません。EBt の最新版を無事公開することが出来ました。
今回は見た目はあんまり変化ないですが、内部処理を結構いじって速くなりました。というか、EBt の独特なDB構造を使って、送信データを削減するというアイデアを思いついたんで、それを実装していました。

EBt の独自のデータ構造？

なんというか、あちこちで非同期に修正したデータを最新版を正としてマージするという機能が普通に実装されています。これは、P2Pベースでのアプリケーションとの同期が保証されない分散環境での動作をする上で不可欠な機能です。
まぁ、ルールとして最後に修正したものが勝つという物があるんですけど、修正の単位をデータ単位ではなく、データ内の要素単位でやっているんで、世の中にあるファイル単位での同期みたいな残念なことは（全く起きないわけではないけど）基本あんまり起きないようになっています。
こんな面倒くさいDB内部で作っていたから、EBt3 の DB 開発にかなり時間がかかっていたんですよ。しかも、その機能を持つDB自体をEBtに組み込むから DB 自体自分でフルスクラッチしてますからね。まあ、こんな物好きな実装、そうそうするもんじゃないです。

分散環境でのデータ整合性の確保

結局、EBt の DB 開発でやたらと時間がかかっていたのは、これを実現するためでした。完全ではないですが、EBt が必要としているレベルはクリアできたので、個人的にはまぁ、いいかな…ってところです。
OneDrive とかでしょっちゅうコンフリクトが起きるんですが、その原因って何かな？って思うと、同じデータを複数箇所で編集するからという余りにも当たり前の問題につきます。
んで、これを起きにくくするためにはどうすればいいか？というと、ファイルなんていう巨大な単位ではなく、もっと小さな単位でデータの更新管理をすれば良いというこれまた当たり前のところに到達します。
全てのデータが独立しているのであれば、Excel のファイル一つというでっかい単位で同期するのではなく、その中のセルという単位でデータを同期すればよっぽど衝突は起きないよね？って発想です。
まぁ、行追加したらどうするのとか言い出す人もいるでしょうが、そこをうまく解決するのが設計ですよね！私は今は考え方の話しかしていません。設計の話は気が向いたら書きます。

分散環境はデータがあるとは限らない

もちろん、データはどっかにあるけど今すぐにはアクセスできないということもシステム設計の大前提として存在しています。
だから、データの完全性なんて EBt ではあんまり重視していません。全てのデータがきっちり揃っていないと駄目なシステムでは無いのですよ、EBt は。だから、ランダムにデータが抜けてたり、バージョンが結構バラバラでもそれなりに動いちゃうというかなりルーズな条件を前提に設計しています。これも、世の中にありがちなシステムではあんまりやらないところですよね。
そして、こんなルーズなDBが前提のシステムだからこそ、分散環境でも何とか動いちゃうのです。分散環境では、通信も不完全かもしれない。いつデータが届くかわかんないかもしれない。だからこそ、完全なデータ構造を求めてはシステムが破綻しちゃうのですよ。

通信量の削減

EBt のプロトコルは実は対したものではないです。種類としては大きく二つ。

1. これちょうだい

2. これあげる

これだけです。1 を受けるとデータがあれば 2 を実行します。また、データを修正したら 2 を実行します。どっかのメモを開いたらそのメモについて1 と 2 を実行します。
まぁ、必用に応じてちょこちょこデータを送り合うというわけですね。決して同期処理はしません。

で、こんなのですから、2 で同じものをいっぱい送りつけたり送りつけられたりします。これは通信量を闇雲に増やす要因になっていました。実際、調べてみたら、同じデータに対してリクエストが来たり、更新情報が届いたりするケースが多いんですよ。だから、同じのをやたらと送る羽目になる。

あと、やっぱり DB の更新は遅いので、DBの更新回数はできるだけ減らしたいという想いもある。

というわけで、DB 更新処理の中の、時間を意識した更新処理（二つのデータを時間を考慮して一つにくっつける処理）のところだけ抜き出してきました。で、それを送信データバッファと受信データバッファに組み込みました。

送信データバッファに更新処理を組み込むと何が嬉しいの？

同じデータをくっつけるので、ある ID で示されるデータを複数送信しなくてすみます。既にデータがあって、それを再度送信する場合は、マージしたものを1回送信するだけでOKなんです。
データも五月雨式に修正されるんでね。あと、これで次以降に送るデータで更新されているから最終的に消えてしまう無駄なデータを送ってしまう問題も解消。良いことだらけです。

ついでに

ネットワーク上に存在している稼働中の EBt 全てに修正内容がブロードキャストされる仕組みになっています。サーバーがある場合はサーバー経由で。
というわけで、作業中、意味も無くスマホで EBt 立ち上げておくと、スマホにどんどん修正内容が転送されていきます。他にも、ページアクセスするとその時にもデータのやりとりが発生するのでそいつもまた勝手にスマホに蓄えられていきます。
というわけで、稼働中は意味も無くスマホで EBt を動かしておくのもお薦めです。充電は後ろで動かし続けてね！過剰負荷でスマホがきつい状態になる可能性もありますけど。
あと、古いスマホは処理が追いつかないです…

残件

Android がネットワークに参加していると通信が詰まる問題が実はまだ残っています。
一応、原因がリリース後にわかって対策コードも作ったんですが、マルチユーザー化と一緒くたにして作業していたんで、リリースはそのタイミングになります。
当面は、Android が参加すると使いにくい状態になっちゃいます。ごめんなさい。

なんとなくのまとめ

多分、こんな変態DBが背後で動いているなんて、想像もしていないでしょうし興味も無いだろうなーと思っています。でも、分散環境でのデータハンドリングをしっかり考えると、これぐらいはミニマムでやらなきゃならんことなんですよ。

というわけで

EBt の地味に大変なところの紹介でした。RDB? んなもんで同等の機能作ったってこのパフォーマンスなんか出ないよ？