日本郵便や楽天グループなどは1月23日、住所を7ケタの英数字で表現する「デジタルアドレス」の社会実装を加速させるためのコンソーシアム「デジタルアドレス・オープンイノベーション」を発足させた。業界をまたいで協力し、ECや物流、金融など幅広い分野への利用を目指す。
住所を7ケタの英数字で表現「デジタルアドレス」普及へ 日本郵便が楽天・セールスフォースなどとコンソーシアム - ITmedia NEWS
デジタルアドレスは、住所を「ABC-1234」のような7ケタの英数字で表現するサービスで、引っ越し後も同じコードを使い続けられる。日本郵便は、デジタルアドレスから住所を取得できるAPIを事業者向けに無償で提供している。
住所を7ケタの英数字で表現「デジタルアドレス」普及へ 日本郵便が楽天・セールスフォースなどとコンソーシアム - ITmedia NEWS
⇧ 一応、全ての「住所」に「重複」しない「デジタルアドレス」が割り当てできるのか「AI」に質問してみたところ、以下のような回答が返ってきた。
7桁の英数字（0-9, a-z, A-Z）の組み合わせは、大文字と小文字を区別する場合、約65兆通り（
)は誤り、
)は3.5兆ではなく、(
=3,521,614,606,208 )通り＝約3.5兆通り、小文字数字のみなら約80億通り）です。この膨大な組み合わせにより、セキュリティコードや日本郵便の新しい「デジタルアドレス」のように、住所やIDの識別に使用されています。
まぁ、
- 住所
- デジタルアドレス
のマッピングが正確であれば、「利用者」が「デジタルアドレス」を利用する時に入力ミスしたりしなければ問題ないのか。
既存の「住所」の数がどれぐらいあるのか分からないですけど、
- アパート
- マンション
のような「集合住宅」とかにも「デジタルアドレス」を割り当てる感じになるんですかね？
そうなって来ると「マスターデータ」となる「デジタルアドレス」の「管理」が大変になりな気がしますな...
『「デジタルアドレス」+ α』 の「情報」で、一意に識別されるようにするのかしら？
兎にも角にも、具体的な仕組みが気になって参りますな...
OxidizedでGitのbare repositoryの肥大化の問題は解決されていないのか...
「Git」は「差分」を管理するので、軽量というイメージがあったのですが、「コミット」の度に「履歴」は蓄積していくはずなので、「塵も積もれば山となる」ではないですが、変更の頻度に依りけりとは思いますが、「ローカル」の「Gitリポジトリ」のサイズは着実に増加していくので、「ディスク容量」を逼迫していくよなぁ、と思った今日この頃です。
ネットの情報を漁っていたところ、
⇧ 上記サイト様で、「Gitリポジトリ」の「サイズ」を削減する話は出て来ますと。
で、「Ruby」製のライブラリである「Oxidized」は、「NW機器」から取得した「設定情報」などを「出力（Output）」する際の方式を選択できるのだが、
⇧ 上記にあるように、「Git」が選択できる。
で、「Oxidized」は内部的に、「Rugged」という「ライブラリ」を利用している関係上、「ローカル」の「Gitリポジトリ」は「bare repository」を利用することになりますと。
で、「bare repository」はと言うと、
⇧ 上記サイト様にありますように、「working tree」が無い状態なので、「normal」な「Gitリポジトリ」に比べれば、サイズの増加率は小さくなるはずですと。
とは言え、「コミット」の回数が増えれば、「履歴」の「情報」が増加していくので、「normal」の「Gitリポジトリ」に比べれば「サイズ」の増加は緩やかなのかもしれないですが、増加していくことには変わりないですと。
「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
✅ Bare リポジトリでも コミットすればサイズは増える
Git の bare repository（作業ツリーを持たない中央リポジトリ）でも、コミットするたびに Git の オブジェクトデータ（履歴） が作成されるので、履歴が積み上がるごとにリポジトリサイズは増加します。サイズが「増えない」という保証はありません。 Stack Overflow
なぜサイズが増えるのか（Git の基本）
-
Git は ファイルの履歴全体を管理します。各コミットはその瞬間のスナップショット情報を内部オブジェクトとして保存します。
-
過去の状態や差分はすべて
.git/objects（bare ではルート）として保存されます。 -
新しいコミットを作るたびに、新しいオブジェクトが追加される → オブジェクト数・サイズは増えていく。 DEV Community
✅ ただしサイズの増加の仕方はこんな性質
📌 1) 差分だけでなくヒストリーを丸ごと保持する
Git はファイルの 変更の差分だけ ではなく、各コミットのスナップショットを管理します。
（圧縮はするが過去の内容は基本的に残る） DEV Community
📌 2) small commit でも大きく増えるケースあり
Stack Overflow でも、小さな変更のコミットでも bare リポジトリサイズが倍になった例があります。これは Git が 差分だけでなくオブジェクトや pack ファイルを作り直す過程でもサイズが増えるためです。 Stack Overflow
📌 3) 削除しても 即座にサイズが減らない
ファイルを削除してコミットしても、古いオブジェクトはすぐには削除されません。
Git のガーベジコレクション（git gc）を行うまでは古いオブジェクトが残るため、サイズが減らないことがあります。 GitLab
📊 見た目のサイズ比較（考え方）
| 項目 | non-bare | bare |
|---|---|---|
.git/objects |
あり | あり |
| 実際のソースファイル | あり | なし |
| ビルド成果物 / untracked | ある場合あり | なし |
| 合計容量 | 大きくなりがち | smaller |
つまり、
- 更新内容が多い
- コミットの頻度が高い
- 長期的に「保守・運用」している
といった場合、「ローカル」の「Gitリポジトリ」の肥大化による「ディスク容量」の逼迫は深刻な問題になって来る可能性がありますと...
で、「Oxidized」においても、
⇧ 上記で「issue」が上がっているのだが、ライブラリ的に対応されたのかが分からない...
一応、
⇧ 上記の「Wiki」のページで手動で「Gitリポジトリ」の「サイズ」を小さくする手順が記載されているということは、「Oxidized」の「機能」としては「Gitリポジトリ」の「サイズ」を縮小することが実現されていないということですかね...
「Oxidized」で用意されている「model」で「日時」の「情報」を取得する処理が無かったのは、無駄に「コミット」されるのを防止する意図が込められているということなんですかね？
う～む...、「設計」の「思想」が分からないから何とも言えませんが...
とは言え、「Oxidized」の「機能」で「設定情報」を取得する対象の「NW機器」の数が膨大、且つ、頻繫に「設定情報」を変更したりすると、「コミット」の頻度が高くなって、「ローカル」の「Gitリポジトリ」が肥大化していく問題に対応する必要が出て来ますと。
勿論、「リモート」側の「Gitリポジトリ」を管理してる「サーバー」の「ディスク容量」も逼迫していくことになるとは思うのだが...
「保守・運用」の対応として、定期的に「メンテナンス」していくにしても、最終的に古い「情報」を削除する取り決めをしておく必要はありそうね...
つまり、「要件定義」などで、事前に「保持期間」を決めておかないとマズいということですかね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
