マンガ作成アシストツールを作ろう②DBMSの仕様とEntityについて

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

さて、あーキティくちゃの考察をしないといけないのであった。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

IndexedDBで暗号化をしつつ速度を維持できる仕組みを考えないといけない。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

indexedDBの仕組みを考えると ①KVSである。 ②キーを複数個指定できないわけではない。 ③Valueは単純にバイナリ？ ④キーから情報が漏れるのは避けたい。 ⑤テーブルはまあいろいろある。ここからの漏洩も避けたい。 という場合に取れる構造を考えよ。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

ということなのだけど、さてはてそんなことはそもそも可能なのか。 実現したところで使い物になるパフォーマンスを維持できるか？なのである。 まあまずは件数オーダーから確認しようか。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

当方が想定するツールは個人ユーズなので ①月に１作品３２Pを仕上げる ②年１２作品がリリースされる ③同一マシン上での情報蓄積は５年とする ④１作品につき３倍程度のゴミ情報が発生する ⑤ページは平均１０コマ以下で構成される ⑥コマは１吹き出しを含む ⑦１ツイートで２コマを確定する

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

単純にレコード件数の概算を求めると ３２ｘ１２ｘ５ｘ３ｘ１０ｘ２/2=57600レコード なんだかわいい数字じゃないか（MySQL的に考えて）

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

では、次に実行環境のスペックを考えてみよう。 ①PC、仕上げ用メモリ４GBをターゲットにする ②スマホ、メモリ２GBをターゲットにする。iOSは考えない。 ③タブレット、まあこっちも２GBかなー うん、済まない。資料を開くともうだめかれしれない。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

KVSを暗号化する場合にどうすれば良い？ ①テーブルは分け、キーはそのまま、Valueを暗号化する。 ②テーブルは分け、キーも暗号化、Valueを暗号化する。 ③テーブルはわけずに、キーもValueも暗号化。 Indexeddbは総レコード数が多い場合テーブルを分けたほうが良い？

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

常識的に考えれば、データ量が大きなテーブルと小さなテーブルがあった場合、 小さなテーブルの操作に大きなテーブルの影響を受けないようになっているはず。 さて、じゃあテーブルは適度に分散させなければいけない。 この分散感がうまくようにするにはどうしたら良い？どうなんだろうか。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

結局、DBの中に何が入っているかを確認させないのが暗号化の目的なので データの物理層の状態はパフォーマンスに致命的な何かがなければ問題としない。 KVSなので参照のためのキーは暗号化してValueの中に格納されていればそれでいい的な。すでに持ってる的な状態を想定したい。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

じゃまあ、次のように処理したら良いのかな？ ①{key,value}を生成する ②keyはハッシュを取って長くする ③前後反転させて一部をテーブル名にする ④KVSでテーブルを作りつつ、格納する テーブルが増えまくるがまあ１００個ぐらいになるように頭２、３文字にしたらいいのかな？

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

ここで注意しないといけないのはキーと名前は確実に分けないといけない。 名称なんてどうせほいほい変わるので。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

じゃあ記録面はこれでいいとして、 １Entityで記録されるものを範囲指定して取り出す場合 どうすればいい？

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

永続性を担保したいだけなので、富豪プログラミングとして全部オンメモリでよくね？クライアントアプリだし。という悪魔の囁きもある 復号化されたデータを始めに持っておくのである。起動時は一旦DBの中身をオンメモリに持ってくる体で。これをやってしまうと書き込み保証がどうなん？という問題が

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

ここは条件として都度DB呼び出しを行う体で設計を行ってみよう。 で、ここではキーからはなんの情報も読み取れない、いや読み取れる＝フルスキャンになる。 フルスキャンなど恐るるに足らずなのか。 間にIndex管理テーブルを挟むのか。 挟むとそこからデータ漏れるよね常識的に。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

漏れるデータは関係性で、そこからどのデータが対象なのかEntityの構成はどうなってるのかは漏れる。漏れるがどんな破廉恥な内容が格納されているかまではもれない。 守る範囲は利用者の作業頻度、使い方なのか？うーん。やはり一括して暗号化出来るDBMSは強いなー

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

IndexedDBにはテーブルに相当するObjectStoreについてのメタデータについてアクセスはできないようだ。要するになんのテーブルが存在するか問い合わせる方法がないということ。 じゃあ、メタデータ保存用のテーブルを作ってそこにIndex情報を入れれば良いわけだ。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

問題は目的のシステムは複数ユーザで１クライアントを使用する前提であるということ。 何を意味するかというと、メタデータもどうする？レコード単位でマルチテナントなのか？テーブル単位なのか？暗号用のキーは各ユーザで異なるからどうするんだよそもそもという問題が

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

暗号化キーの異なる問題はデータの投入には何ら影響はない。 問題は読み込み際に持ってきたレコードが読めるかどうかのジャッジをしないといけない。複合化をしない状態でそれって判断できるべきなの？ 職人の目で見ると一発でわかるみたいなのを許すべきかという。 片手落ち感がするなぁ

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

じゃあ次のように安直に実装しよう。 ①起動時にフルロード ②フルロードするのはキーと行のEntity属性情報のみ ③１行ごとにユーザキーで復号化を試みOKだったらロードする。 ⑤書き込み時に一度書き込んで、データをロードできるか確認する。 物理層からのキー一本釣りは可能だからOK

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

問題はIndexedDbがマルチスレッドで作動している場合、書き込み制御をしてくれるかということ。 トランザクションがあるから信用して良いのかな？ jsの文法にスレッドセーフにする文法とかあるのかな？ 削除処理が走った際にゴーストな不整合が発生しそうで怖い。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

あと、この方式を取るとリロードをかまされた時に再ログインが必要になる。 ということはリフレッシュボタンを用意するしかない。 ブラウザのタブ間でログイン状態を維持するかというとそれ出来るんだっけ？ セッションストレージに持てばいいけどそれってどうなん？

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

セッションストレージがログイン情報の伝播として使われるというのはユーザー認証情報を置かないといけなくて、認証情報をコピペして次回使われないを担保するにはどうすればよいか？なんだよな。 ちなみに開発者ツールで見えるものはデバッガでメモリを見る以外はなんでもコピペされる前提で。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

文字列単体を受け取ってそいつが時間軸的に許していいやつか判断する。 それでいて、偽造が難しいこと。照合が事前情報のみで確認が出来ること。 となると・・・・

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

①一度他タブ認証用のレコードを用意 ②そこのキーをセッションストレージに置く ③そのキーで呼び出すと認証用のキーが取得可能 ④キーを取得したら有効期限の日付とソルトが取れる ⑤そのキーとソルトと日付で暗号化をしたレコードに認証情報の元がある ⑥ストレッチを行うと認証キーになる。