りおてく

そーだいさんがこんなことを呟いていた。

これは知見なのですが20TBのテーブルにINDEXは2週間待っても貼れません（諦めた #voyagebook

— そーだい@初代ALF (@soudai1025) October 9, 2020

ふーむ。これはやってみないといけないですね。
普通のPostgreSQLではちょっと無理っぽい件数なので、Azure Database for PostgreSQL Hyperscale (Citus)に入れてみる。海外さんのPGstromという変態実装（褒めている）を使う方法もあるけれど、PaaSでRDBMSで、っていうとHyperscale (Citus)がまず候補かな、と。

ちょっとどんな感じか分からないので、IOPSが最大になる2TBのストレージを持つワーカーノードを20台で構成してみる。

全体としてはこんな感じ。

で、64vCPUのVMにPremium SSDのData Diskを付けたUbuntuにpostgresql-clientをインストールした上で20TBのCSVデータを用意。splitコマンドで適当なサイズに分割して、

$ find chunks/ -type f | 
xargs -n1 -P64 sh \
-c "psql -h riotbindex-c.postgres.database.azure.com -p 5432 -d citus --username=citus \
-c \"\\copy table1 from '\$0' WITH CSV\""

投入するのに、約7時間かかった...。さて、入ってるかな？

citus=> \timing
Timing is on.
citus=> select count(*) from table1;
   count    
------------
 8887648000
(1 row)

Time: 7689798.324 ms (02:08:09.798)

さて、本筋はインデックスですね、やってみましょうこうですか分かりません。

psql > CREATE INDEX table1_index ON table1 (ev_type);
CREATE INDEX
Time: 4884228.616 ms (01:21:24.229)

先日来、OSMO Actionで撮影した動画にWahoo ELEMNT BOLTのデータを表示する、ということをやっている。元々、ELEMNT BOLTはCANYON用のマウントで搭載していて、これは下部にGo Proなどのアクションカメラのマウントもあるので、そこにOSMO Actionを装着した次第。OSMO Actionは記録する画質が2.7K以上で無いとRock Steadyという映像ブレ補正技術が効かず、2.7Kでは内蔵バッテリーで実測80分程度しか録画出来ないため、サドルバッグに入れたモバイルバッテリーまで1.5メートルのUSB-C to USB-Cなケーブルを引っ張り、タイラップでケーブルを固定している。

撮影した動画にELEMNT BOLTから出力したFITファイルのデータを表示するのに、まずはGarminのVIRB Editを試してみた。で、何が不満だったかというと、ギアが表示出来ないことと、動画とFITのタイミングを合わせるのが「地図上の位置」で行う点。自分が乗ってるCANYONはSRAM Force eTAP AXSにパワーメーターを追加しているが、シフターが無線なので現在ギアがいくつかということは、サイコンの画面でないと確認出来ない。なので、動画中でも「あー、この時、2-10までギア変えたのか」とか知りたい。タイヤの周長をL(mm)、ケイデンスをC(bpm)、フロントギア/リアギアの歯数をF/Rとすると、60CFL/1000000R(km/h)なので、ギアから計算される速度とサイコンの実測値の違いを確認したりもしたい。

じゃあ作るかということで、まずFITにfileコマンドして、まあバイナリだよねhexdumpするかなるほどFITというシグネチャが入ってるのね、まで数分。んでちょっとググって、FIT SDKを見つけてきて、ざーっと目を通す。んー、大して面倒じゃないけど、誰かパーサを書いてないかなぁ、とググる。最初に見つけたパーサは使い勝手が悪く、fit parserの検索結果を総当たりして見つけたのが、PyPIにあったfitdecode。FITファイルを食わせてとりまイテレータでメッセージ部分をダンプしてみると、問題無さそう。じゃあこいつで、というところまで小一時間。

ダンプは出来るようになったものの、フィールド名がunknownだったりするので、それを要・不要分けてdictの配列に突っ込むか否かを処理したり、FIT SDKには無い形式で保存されてるデータを変換したりをparseint()という関数にまず実装。ELEMNT BOLTのイメージを動画に合成するのに、PillowでPNGを出力してffmpegでオーバーレイする作戦にしたものの、Pillowが遅くてどうしたもんかなぁ、あ、ワークアラウンドがあるやん、で高速化に成功。でも、まだ遅いなぁ、ループ内に無駄な処理が多いからそれを直して、っと、はい、合成できた、までは結構時間がかかった。

githubに公開したやつは、ここまでを実装してある。手元のバージョンでは地図を表示出来るようにしてあるけれど、公開する前にちゃんとオブジェクティブに書き直したいわぁ...。

半分仕事、半分興味本位でMariaDBのSpiderクラスタをAzure上に構築するスクリプトを書いたので、GitHubに晒しておいた。

半分しか仕事じゃないのはこれがPaaSのサービスでは無いからなんだけど、仕事に「含まれている」Hyperscale (Citus)はスケールアウト出来るPostgreSQLである一方、MySQL / MariaDBのスケールアウト出来る実装って何やろな？って感じでSpiderを選んでみた。

スクリプトを書いて動かしてみた雑感としては、Citusだとシャーディングの設定はcreate_distributed_table('table', 'shard_key')で済むところを、データノードでInnoDBのテーブルを作成しSpiderでspiderのテーブルを作成しないとならないところが微妙に面倒なので、ここは改良されると嬉しいかと。あとはCitusと比較すると様々な面で（特にエンタープライズで）不足してる機能があるので、このあたりを自前で補わないと実運用は厳しそうだなぁ、というところ。

2020.07.09 追記
VMだけで構成していたんだけど、ちゃんと仕事になるようにSpider Data NodeはPaaSのMySQLを使うバージョンも作ってみた。create_spider_with_orcas.shは、PaaSを使う方。解説は後日。

GitHubにアップしといた。

brew file、AppleScript (osascript)、シェルスクリプト等々を組み合わせて、おおむね自動化した。
ただし、Terminal.appを[システム環境設定]→[セキュリティとプライバシー]の[アクセシビリティ]と[フルディスクアクセス]に追加するのと、注記に入れているosascriptのワンライナーだけは手動で実行する必要がある。これはまあ、致し方ないなぁ。
あと、AppleScriptの部分はかなり怪しいしGUIの変化に大変に弱いので、果たして新しいmacOSが出たときに動くかは不明...。

微妙に動かない設定しか見つからなかったのでメモっておく。

zsh-completionをインストールする。

% brew install zsh-completion

で、エラーが出る。

zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]?

compauditでチェックして、パーミッションを修正する。

% compaudit   
There are insecure directories:
/usr/local/share/zsh/site-functions
/usr/local/share/zsh

% chmod 755 /usr/local/share/zsh/site-functions
% chmod 755 /usr/local/share/zsh/

bash completion用のファイルを~/.azure/az.completionとしてダウンロードする。

% mkdir ~/.azure
% curl -o ~/.azure/az.completion https://raw.githubusercontent.com/Azure/azure-cli/dev/az.completion

~/.zprofileに以下を追加する。

if type brew &>/dev/null; then
    FPATH=$(brew --prefix)/share/zsh/site-functions:$FPATH

    autoload -Uz compinit
    compinit
fi

autoload -U +X bashcompinit && bashcompinit
source ~/.azure/az.completion

This article describes how storage size affects the result of benchmarking, pgbench.

The storage size of Azure DB for PostgreSQL is 100 GB by default. It can be enough for your data, but you should know that IOPS is defined with storage size by 3 IOPS per GB. And you should understand the fact that pgbench is just a benchmark as well. It doesn't reflect the real querying pattern from your app. The queries from pgbench are too simple, so the result will be very sensitive for latency. Another I need to mention here is that the minimum IOPS for Azure DB for PostgreSQL is 100 regardless of storage size. Both 5GB and 33GB show a similar result of benchmarking.

I tested with following settings.
PostgreSQL: General Purpose, 4 vCore(s)
Client: Standard F16s (16 vcpus, 32 GiB memory), Ubuntu 18.04

Firstly, inserted 10M records.

$ pgbench -i "host=riopostgres.postgres.database.azure.com port=5432 dbname=postgres user=rifujita@riopostgres password={password} sslmode=require" -s 100

Checked that about 1.5GB data existed after inserting.

postgres=> select datname, pg_size_pretty(pg_database_size(datname)) from pg_database where datname='postgres';
 datname  | pg_size_pretty 
----------+----------------
 postgres | 1503 MB
(1 row)

pgbench command executed

$ pgbench -c 10 -t 1000 "host=riopostgres.postgres.database.azure.com port=5432 dbname=postgres user=rifujita@riopostgres password={password} sslmode=require"

Common parameters through benchmarks

transaction type: 
scaling factor: 100
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 1000
number of transactions actually processed: 10000/10000

• 33 GB(100 IOPS)
  latency average = 91.464 ms
  tps = 109.332645 (including connections establishing)
  tps = 109.800127 (excluding connections establishing)
• 50 GB(150 IOPS)
  latency average = 60.443 ms
  tps = 165.445682 (including connections establishing)
  tps = 166.176647 (excluding connections establishing)
• 100 GB(300 IOPS)
  latency average = 34.883 ms
  tps = 286.669194 (including connections establishing)
  tps = 288.647951 (excluding connections establishing)
• 200 GB(600 IOPS)
  latency average = 29.285 ms
  tps = 341.474144 (including connections establishing)
  tps = 344.244699 (excluding connections establishing)
• 400 GB(1,200 IOPS)
  latency average = 28.352 ms
  tps = 352.708873 (including connections establishing)
  tps = 355.236614 (excluding connections establishing)
• 800 GB(2,400 IOPS)
  latency average = 28.632 ms
  tps = 349.256644 (including connections establishing)
  tps = 352.543669 (excluding connections establishing)

Conclusion: From the performance standpoint, the best storage size is 200GB with this querying pattern, and data size, 1.5GB.

Twitterでは散々書いてることなんだけどもブログには書いていなかったので、そろそろまとめておくかという感じで。

今年の9月にルイガノのロードバイクを買った。サイクルベースあさひの在庫処分で本体は68,000円。ヘルメットやポンプ、諸経費込みで10万円以内で収まった。

きっかけは娘ちゃんの自転車の練習。2018年6月に供用した外環道と国道298号の横には歩行者・自転車専用道が整備されたので、そこで娘ちゃんに練習させている時に、ふと「この道で結構遠くまで行けるのでは？」と思ったこと。

2週間と経たずに、あまりのブレーキ性能の酷さにブレーキだけUltegraにした。

10月8日にはContinental Grand Prix 5000に履き替えた。

SPDペダルにしたりホイールをアルミにしたりしつつ、9月の数日で100km、10月に514km、11月に500km、さらにZwift環境を整えて屋内でのローラー練習も始めた。

ここまでの時点でメンテの知識もだいぶ身に付いたし工具も大体揃った。フィッティングのような経験のいる作業はともかく、エボIVのメンテや洗濯機の分解、あるいは子供の頃からやってきた機械いじりに慣れていることもあって自転車のメンテ作業に抵抗感はない。

自転車って完全に自分で弄れるのでは？と思い始めたタイミングでもあったので、10.8kgもあるルイガノよりもっと軽くて性能の良い、でも安いのが良いということで12月13日にCANYONのUltimate WMN CF SL Disc 8.0 ETAPを注文し、17日にドイツのフランクフルトから届いた。ステム一体型のハンドルを取り付け、シートポストを差し込み、前輪をスルーアクスルで締め、ペダルを取り付ければ良いだけで、あっけないほど簡単。ディスクブレーキのスペーサーを取り外すのを忘れずに。ペダルはルイガノで使っていて気に入っているシマノのSPDペダル・PD-ES600をCANYONにも。

さらに輸入したSRAM Force用のパワーメーター、ブランドはSRAMのQUARQになっている、を取り付けた。これは、8mmヘキサで固定されているSRAMのdub規格のチェーンリングを外して、インナー、アウター、オクトパスをT20とT30のトルクスレンチで分解し、オクトパスを入れ替えるだけでパワーとケイデンスがBluetooth / ANT+で取得出来るようになる。$599はリーズナブルだと思う。

シートチューブとボトルケージの隙間に写っている黒いパーツは、AlterLock。ある程度高価な、あるいは大事にしているバイクなら絶対付けておくことを強くオススメする。盗まれてもGPSで追跡できる。

Ultimate WMN CF SL Disc 8.0 ETAPについては新しいこともあって色々情報がなく、ひょっとしたら役立つかもしれないのでここにまとめておく。

• 納車時にSRAM FORCE eTAP AXSのフロントディレイラー、リアディレイラー、左右のシフターがリンクしているかスマホアプリでチェックした方が良い。自分の場合、フロントディレイラーがリンクしていない上、10-33Tが付いて来てるのに、10-26Tが付いてることになってた。
• スルーアクスルはフロント100mm、リア142mmで、ネジピッチがM12 x 1mmとなっているX-12規格のもの。これがほとんど代替品が無いので、ホイールの交換などを考えているのであれば新車購入時に同時に注文しておくのが良い。でないと、送料11,000円がまた必要になる...。
• 付属のタイヤはSchwalbe Pro One Evoで、同じくSchwalbeのチューブが入った状態で出荷されてくる。シーラントを別途用意すれば、Reynoldsのホイール用のバルブステム（DT Swiss製？）は付属しているのでチューブレス化が可能。ただし、Schwalbe Pro One Evoの個体差かも知れないけれど、納車から2回目の実走で後輪がパンクし、その後もウォール・トレッドのあちこちからシュワシュワ言い出す始末で信頼出来ないため、とっととContinental Grand Prix 5000 TLにスイッチ。車体色に合わせた赤いTNIのステムでも問題なく使えた。
• フレームやチェーンステーの傷保護用のシールは最初から貼られているので別途購入の必要はなし。
• XOSSなどのケイデンスセンサーはクランクに取り付けるクリアランスが全く無いので注意が必要（ということもあって、上記の通りパワーメーターを購入した）。
• ディレイラーハンガーは、No.40。
• ディスクローターはウェブページには、SRAM Centerline Xと書いてあるけれど、実際にはSRAM Centerline XRが付いて来た。

ブレーキパッドは写真のようなものが付いてくるが、型番が分からず。
色々探してみたところ、サービスマニュアルからパーツナンバーが00.5318.024.000だということが分かった。

今月は実走1,000km超えが、Festive500もあって確定。Zwiftは300kmいくかいかないか...。

追記：Festive500達成。

PDFとイラレファイルも置いておく。

自宅からAzureの各リージョンへのiperfでのネットワーク帯域とは別に、Azure東日本から各リージョンへの帯域も計測してみた。東日本にUbuntuを立てて、そこから「VNET peeringをしない」で、各リージョンに立てたUbuntuにiperfをかけるとこんな感じ、と。

「自宅から直接、各リージョンに接続するより、東日本を経由した方が（当然のことながら）高速」
→「VPN Gatewayを東日本に立てて、他のリージョンにアクセスした方が高速」
→でも、それを全部自前で設定するのは面倒だなぁ、ということになるので、Azure Virtual WANの登場、と。

japaneast : 938 Mbits/sec
japanwest : 890 Mbits/sec
koreacentral : 589 Mbits/sec
koreasouth : 458 Mbits/sec
eastasia : 330 Mbits/sec
southeastasia : 211 Mbits/sec
southindia : 201 Mbits/sec
westus2 : 146 Mbits/sec
westus : 132 Mbits/sec
australiaeast : 127 Mbits/sec
australiacentral : 121 Mbits/sec
westcentralus : 109 Mbits/sec
australiasoutheast : 108 Mbits/sec
westindia : 93.4 Mbits/sec
centralus : 87.5 Mbits/sec
southcentralus : 85.1 Mbits/sec
northcentralus : 83.9 Mbits/sec
eastus2 : 81.9 Mbits/sec
eastus : 80.6 Mbits/sec
centralindia : 75.3 Mbits/sec
canadacentral : 69.1 Mbits/sec
uksouth : 65.6 Mbits/sec
canadaeast : 61.2 Mbits/sec
northeurope : 50.6 Mbits/sec
ukwest : 47.3 Mbits/sec
francecentral : 46.9 Mbits/sec
westeurope : 44.3 Mbits/sec
brazilsouth : 39.3 Mbits/sec
southafricanorth : 31.3 Mbits/sec
uaenorth : 19.6 Mbits/sec