PubNub

2021-05-06

Knowledge ManagementBaaS

BaaS, Messaging System

参考
メモ
- 概要
- 動作確認

参考

aa

公式ドキュメント

blog

PubNubで5分でリアルタイムWebこと初め

サンプル

PubNubExample

メモ

概要

The PubNub Platform Overview によると、

とのこと。概要にIoTと記載されている通り、小型のデバイス利用も想定されているようだ。主な用途は「メッセージング」と「シグナリング」。

特徴は以下の通り。

サイズの小さなメッセージに限らず、画像、動画、ファイルを対象に含めているのがポイントか。

ユースケースは以下の通り。

これ自体に特筆すべきポイントはない。

SDK に記載のある通り、非常に幅広いSDKを提供している。

PubNubのGitHub を見る限り、多様なクライアントライブラリがOSSとして公開、開発されているようだ。

動作確認

プライシングによるとアカウントを作ってお試しする限りでは無料のようだ。ということで、Pythonチュートリアルの通り実行してみる。

このチュートリアルでは、PubSubモデルのメッセージングを試せる。

アカウント作成

サインアップからアカウント作成。もろもろ情報入れて登録したら、Demo Keysetが得られた。

（補足）公式チュートリアルのソースコード

以下のようにクローンできる。

1	[dobachi@home Sources]$ git clone git@github.com:pubnub/python-quickstart-platform.git

今回はゼロから作ってみるので、これは参考とする。

プロジェクトディレクトリ作成

適当なところに空ディレクトリを作り、プロジェクトのルートとする。

1 2	[dobachi@home Sources]$ mkdir pubnub_example [dobachi@home Sources]$ cd pubnub_example/

今回は、pyenvを利用してインストールしたPython3.8.10を利用し、venvで環境構築する。

[dobachi@home pubnub_example]$ pyenv local 3.8.10
[dobachi@home pubnub_example]$ python -m venv venv
[dobachi@home pubnub_example]$ . ./venv/bin/activate
(venv) [dobachi@home pubnub_example]$ pip install 'pubnub>=4.5.1'

ここで、Pythonチュートリアルに従い、2個の実装pub.py、sub.pyを作成する。このとき、ソースコードのキーのところに先ほどアカウント作成した際に得られたキーを記載するようにする。

ここから端末を2個立ち上げる。

1個目でサブスクライバーを起動

(venv) [dobachi@home pubnub_example]$ python sub.py
***************************************************
* Waiting for updates to The Guide about Earth... *
***************************************************
[STATUS: PNConnectedCategory]
connected to channels: ['the_guide', 'the_guide-pnpres']
[PRESENCE: join]
uuid: serverUUID-SUB, channel: the_guide

2個目でパブリッシャーを起動

(venv) [dobachi@home pubnub_example]$ python pub.py
*****************************************
* Submit updates to The Guide for Earth *
*     Enter 42 to exit this process     *
*****************************************
Enter an update for Earth: Harmless
[PUBLISH: sent]
timetoken: 16202911568484264

プロンプトが表示されるので、「Harmless」と入力してエンターキーを押下。

サブスクライバーに以下のように表示される。

1 2	[MESSAGE received] Earth: Harmless

Pythonチュートリアルに実装の説明があるが、基本的には

サブスクライバーはハンドラの実装のみ
パブリッシャーは標準入力からメッセージを受け取り、それを送信するのみ

という単純な仕組み。

パブリッシャー側のポイントは、

1	envelope = pubnub.publish().channel(CHANNEL).message(the_message).sync()

まだ詳しくは分からないが、チャンネルやエントリという概念がありそう。チャンネルを使うと同報できるのだろうか。

Python API あたりを読むと記載ありそう。

ファイル

Files API for PubNub Python SDK を読むと、ファイルを取り扱うAPIがあった。 5MBまでのファイルをアップロードできるようだ。アプリケーションで画像を取り扱う場合などを想定している様子。

これを簡単に動作確認してみる。 Pythonチュートリアルのサンプルコードpub.pyとsub.pyを参考に実装する。参考実装を PubNubExample にまとめておいた。 READMEを参照。

メッセージングのAPIとは異なるが、簡単に小さなファイルを登録できるのは便利ではある。

またファイルを登録したことを通知するAPIもあるようだ。これは使い方としては

ファイルを送信し、合わせてファイル送信したことをチャンネルにメッセージ送信
受信者は、メッセージを受領したら、その情報を使ってファイル受信

ということだと思われる。ファイルの送受信自体は、メッセージングのようにSubscribeできず、単発実行のAPIであり、かつ受信についてはIDを引数に渡さないといけないから、と考えられる。

（補足）ERROR: Could not find a version that satisfies the requirement pubnub>=4.5.1

以下のようなエラーが出たら、

1	ERROR: Could not find a version that satisfies the requirement pubnub>=4.5.1

libffi-devel をインストールしたうえで、Pythonをビルドするようにするとよい。

1
2
3

(venv) [dobachi@home pubnub_example]$ pyenv uninstall 3.8.10
(venv) [dobachi@home pubnub_example]$ sudo yum install -y libffi-devel
(venv) [dobachi@home pubnub_example]$ pyenv install 3.8.10

Use any fonts in CentOS7

2021-04-30

参考
メモ
- 元ネタ

参考

Microsoft Windows用TrueTypeフォントを使用する

メモ

/usr/share/fonts以下に適当なディレクトリを作成。

1	$ sudo mkdir /usr/share/fonts/original

フォントを格納

1	$ sudo cp ＜何かしらのフォント＞ /usr/share/fonts/original

更新。

1
2
3

$ cd /usr/share/fonts/original
$ sudo mkfontdir
$ sudo mkfontscale

元ネタ

Microsoft Windows用TrueTypeフォントを使用するが参考になった。（が、MS社フォントは今回は用いていない）

CentOS on WSL

2021-04-25

Knowledge ManagementWSLCentOS

CentOS, WSL

参考
メモ
- CentOS

参考

メモ

Redhat系LinuxをWSL（ないしWSL2）で動かしたい、という話。

wsl2上で無料でCentOS8を動かそうで挙げられているレポジトリはアーカイブされているため、代替手段で対応した。

CentOS

CentOS7

CentOS-WSL を参考に、まずは手堅くCentOS7。

wsl2上で無料でCentOS8を動かそうを参考にすすめる。

CentOS7.zip をダウンロードし解凍。中に含まれている rootfs.tar.gz を解凍しておきます。ここでは、 C:\Users\dobachi\Downloads\CentOS7\rootfs.tar\rootfs.tar として解凍されたものとします。

インポート先のディレクトリがなければ、予め作成。ここでは以下にしました。（他のイメージと同じ感じで）

1	C:\Users\dobachi\AppData\Local\Packages\CentOS7

1	wsl --import CentOS7 "C:\Users\dobachi\AppData\Local\Packages\CentOS7" "C:\Users\dobachi\Downloads\CentOS7\rootfs.tar\rootfs.tar"

必要に応じてWSL2用に変換。

1	wsl --set-version CentOS7 2

その他、必要に応じてWindows Terminalの設定を行う。

また日本語とGUI利用のための設定は、UbuntuとCentOSは少し違うので注意。日本語でのハマりポイントは以下。

localectlが使えない
- /etc/profileに直接ロケール情報を記載すると良い
Ubuntuとは日本語対応方法が異なる
- CentOSではibus-kkcを利用すると良い

CentOS8 Stream

＜あとで書く＞

Fedora

＜あとで書く＞

readPredicates in inserting records

2021-04-23

Knowledge ManagementStorage LayerDelta Lake

Delta Lake

参考
メモ

参考

メモ

前提

Delta Lake 0.7.0

動機

Delta Lakeのトランザクション管理について、 org.apache.spark.sql.delta.OptimisticTransactionImpl#readPredicates がどのように利用されるか、を確認した。

特にInsert時に、競合確認するかどうかを決めるにあたって重要な変数である。

org/apache/spark/sql/delta/OptimisticTransaction.scala:600

val predicatesMatchingAddedFiles = ExpressionSet(readPredicates).iterator.flatMap { p =>
  val conflictingFile = DeltaLog.filterFileList(
    metadata.partitionSchema,
    addedFilesToCheckForConflicts.toDF(), p :: Nil).as[AddFile].take(1)

  conflictingFile.headOption.map(f => getPrettyPartitionMessage(f.partitionValues))
}.take(1).toArray

準備

SparkをDelta Lakeと一緒に起動する。（ここではついでにデバッガをアタッチするコンフィグを付与している。不要なら、--driver-java-optionsを除外する）

dobachi@home:~/tmp$ /opt/spark/default/bin/spark-shell --packages io.delta:delta-core_2.12:0.7.0 --conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension" --conf "spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog" --driver-java-options "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=localhost:5005"

ファイルはSparkに含まれているサンプルファイルを使うことにする。

scala> val filePath = "/home/dobachi/Sources/spark/examples/src/main/resources/users.parquet"
filePath: String = /home/dobachi/Sources/spark/examples/src/main/resources/users.parquet

scala> val df = spark.read.parquet(filePath)
df: org.apache.spark.sql.DataFrame = [name: string, favorite_color: string ... 1 more field]

こんな感じのデータ

scala> df.show
+------+--------------+----------------+
|  name|favorite_color|favorite_numbers|
+------+--------------+----------------+
|Alyssa|          null|  [3, 9, 15, 20]|
|   Ben|           red|              []|
+------+--------------+----------------+

テーブル作成

1	df.write.format("delta").save("users1")

ここまでで後でデータを追記するためのテーブル作成が完了。

簡単な動作確認

ここで、競合状況を再現するため、もうひとつターミナルを開き、Sparkシェルを起動した。

/opt/spark/default/bin/spark-shell --packages io.delta:delta-core_2.12:0.7.0 --conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension" --conf "spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog"

ターミナル1でデバッガを有効化しながら、以下を実行。

1 2	val tblPath = "users1" df.write.format("delta").mode("append").save(tblPath)

ちなみにブレイクポイントは以下の箇所に設定した。

org/apache/spark/sql/delta/OptimisticTransaction.scala:482

1
2
3

deltaLog.store.write(
  deltaFile(deltaLog.logPath, attemptVersion),
  actions.map(_.json).toIterator)

ターミナル2で以下を実行し、コンパクション実施。

val tblPath = "users1"
spark.read
 .format("delta")
 .load(tblPath)
 .repartition(2)
 .write
 .option("dataChange", "false")
 .format("delta")
 .mode("overwrite")
 .save(tblPath)

ターミナル1の処理で使用しているデバッガで、以下のあたりにブレイクポイントをおいて確認した。

org/apache/spark/sql/delta/OptimisticTransaction.scala:595

val addedFilesToCheckForConflicts = commitIsolationLevel match {
  case Serializable => changedDataAddedFiles ++ blindAppendAddedFiles
  case WriteSerializable => changedDataAddedFiles // don't conflict with blind appends
  case SnapshotIsolation => Seq.empty
}

この場合、org.apache.spark.sql.delta.OptimisticTransactionImpl#readPredicates はこのタイミングでは空のArrayBufferだった。

readPredicatesに書き込みが生じるケース

以下の通り。

org/apache/spark/sql/delta/OptimisticTransaction.scala:239

def filterFiles(filters: Seq[Expression]): Seq[AddFile] = {
  val scan = snapshot.filesForScan(Nil, filters)
  val partitionFilters = filters.filter { f =>
    DeltaTableUtils.isPredicatePartitionColumnsOnly(f, metadata.partitionColumns, spark)
  }
  readPredicates += partitionFilters.reduceLeftOption(And).getOrElse(Literal(true))
  readFiles ++= scan.files
  scan.files
}

/** Mark the entire table as tainted by this transaction. */
def readWholeTable(): Unit = {
  readPredicates += Literal(true)
}

org.apache.spark.sql.delta.OptimisticTransactionImpl#filterFiles メソッドは主にファイルを消すときに用いられる。 DELETEするとき、Updateするとき、Overwriteするとき（条件付き含む）など。

org.apache.spark.sql.delta.OptimisticTransactionImpl#readWholeTable メソッドはストリーム処理で書き込む際に用いられる。書き込もうとしているテーブルを読んでいる場合はreadPredicatesに真値を追加する。

Double count of dstat

2021-04-09

Knowledge ManagementMonitering

dstat

参考
メモ

参考

メモ

dstatのtotalが2倍？になる？という話があり簡単に確認。

結論

ディスク単位のI/Oを total に入れるべきなのだが、正規表現上の仕様により、 xvda1 などのパーティション単位のI/Oも total に足されている。

実は、パーティションの値を取り除く正規表現ではあるのだが、当時の実装（※）としては xvd で始まるディスク名に対応できていなかったようだ。なお、その後、いくつか正規表現が改変されたような経緯がコミットログやGitHub Issueから見られた。

※CentOS7等で採用されたdstat0.7.2のリリース時期は2010年ころ

事象の確認

環境情報の確認。

[centos@ip-10-0-0-217 ~]$ uname -a
Linux ip-10-0-0-217.ap-northeast-1.compute.internal 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[centos@ip-10-0-0-217 ~]$ dstat --version
Dstat 0.7.2
Written by Dag Wieers <dag@wieers.com>
Homepage at http://dag.wieers.com/home-made/dstat/

Platform posix/linux2
Kernel 3.10.0-1127.13.1.el7.x86_64
Python 2.7.5 (default, Apr  2 2020, 13:16:51)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]

Terminal type: xterm-256color (color support)
Terminal size: 86 lines, 310 columns

Processors: 4
Pagesize: 4096
Clock ticks per secs: 100

internal:
        aio, cpu, cpu24, disk, disk24, disk24old, epoch, fs, int, int24, io, ipc, load, lock, mem, net, page, page24, proc, raw, socket, swap, swapold, sys, tcp, time, udp, unix, vm
/usr/share/dstat:
        battery, battery-remain, cpufreq, dbus, disk-tps, disk-util, dstat, dstat-cpu, dstat-ctxt, dstat-mem, fan, freespace, gpfs, gpfs-ops, helloworld, innodb-buffer, innodb-io, innodb-ops, lustre, memcache-hits, mysql-io, mysql-keys, mysql5-cmds, mysql5-conn, mysql5-io, mysql5-keys, net-packets, nfs3,
        nfs3-ops, nfsd3, nfsd3-ops, ntp, postfix, power, proc-count, qmail, rpc, rpcd, sendmail, snooze, squid, test, thermal, top-bio, top-bio-adv, top-childwait, top-cpu, top-cpu-adv, top-cputime, top-cputime-avg, top-int, top-io, top-io-adv, top-latency, top-latency-avg, top-mem, top-oom, utmp,
        vm-memctl, vmk-hba, vmk-int, vmk-nic, vz-cpu, vz-io, vz-ubc, wifi

[centos@ip-10-0-0-217 ~]$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  60G  0 disk
└─xvda1 202:1    0  60G  0 part /

dstat 0.7.2は2010年にリリースされたようだ。

1 2	$ git log -1 --format=%ai 0.7.2 2010-06-14 22:25:44 +0000

参考までにpcpのバージョン

1 2	[centos@ip-10-0-0-217 ~]$ pcp --version pcp version 4.3.2

ここから動作確認。

fioを実行。

1
2
3

[centos@ip-10-0-0-217 ~]$ fio -rw=randwrite -bs=16k -size=1000m -iodepth=32 -directory=/tmp -direct=1 -invalidate=1 -runtime=300 -numjobs=8 -name=iotest -ioengine=libaio -group_reporting

(snip)

裏でdstatを実行

[centos@ip-10-0-0-217 ~]$ dstat -td -D total,xvda                                                                                                                                                                                                                                                                     ----system---- -dsk/total----dsk/xvda-
     time     | read  writ: read  writ
09-04 08:40:50| 373k  315k: 187k  158k
09-04 08:40:51|   0    95M:   0    47M
09-04 08:40:52|   0    87M:   0    44M

(snip)

およそ2倍になっている。

pcp-dstatだと？

[centos@ip-10-0-0-217 ~]$ pcp dstat -td -D total,xvda
----system---- --dsk/xvda---dsk/total-
     time     | read  writ: read  writ
09-04 09:16:47|           :
09-04 09:16:48|   0    41M:   0    41M
09-04 09:16:49|   0    45M:   0    45M
09-04 09:16:50|   0    50M:   0    50M
09-04 09:16:51|   0    35M:   0    35M^

(snip)

ということで、2倍になっていない。

ちなみに、そもそもpcp-dstatは、上記のdstatとは全く異なる実装に見える。

doolだと？（2021/4/8時点のmasterブランチ）

[centos@ip-10-0-0-217 Sources]$ ./dool/dool -td -D total,xvda
-----system---- -dsk/total----dsk/xvda-
      time     | read  writ: read  writ
Apr-09 11:24:54| 577k 3307k: 289k 1653k
Apr-09 11:24:55|   0    66M:   0    33M
Apr-09 11:24:56|   0    25M:   0    13M
Apr-09 11:24:57|   0    44M:   0    22M^

(snip)

ということで、dstatと同様。

doolの登場

dstatの源流は今はメンテされておらず、 dool が開発されている。

Dool is a Python3 compatible clone of Dstat.

また dstatが開発終了した話に記載されているが、他にもpcp系列のdstatが残っている。

ただし、doolにおいても、正規表現は同じようなものだった。

When DeltaLog ID is created

2021-04-04

Knowledge ManagementStorage LayerDelta Lake

Delta Lake

参考
メモ
- 前提
- createRelationから確認する

参考

メモ

Delta LakeのDelta LogのIDがいつ確定するのか、というのが気になり確認した。

前提

Delta Lakeバージョン：0.8.0

createRelationから確認する

org.apache.spark.sql.delta.sources.DeltaDataSource#createRelation をエントリポイントとする。

ポイントは、DeltaLog がインスタンス化されるときである。

まず最初にインスタンス化されるのは以下。

org/apache/spark/sql/delta/sources/DeltaDataSource.scala:141

1	val deltaLog = DeltaLog.forTable(sqlContext.sparkSession, path)

org.apache.spark.sql.delta.DeltaLog は、 org.apache.spark.sql.delta.SnapshotManagement トレイトをミックスインしている。当該トレイトには、 currentSnapshot というメンバ変数があり、これは org.apache.spark.sql.delta.SnapshotManagement#getSnapshotAtInit メソッドを利用し得られる。

org/apache/spark/sql/delta/SnapshotManagement.scala:47

1	@volatile protected var currentSnapshot: Snapshot = getSnapshotAtInit

このメソッドは以下のように定義されている。

org/apache/spark/sql/delta/SnapshotManagement.scala:184

protected def getSnapshotAtInit: Snapshot = {
  try {
    val segment = getLogSegmentFrom(lastCheckpoint)
    val startCheckpoint = segment.checkpointVersion
      .map(v => s" starting from checkpoint $v.").getOrElse(".")
    logInfo(s"Loading version ${segment.version}$startCheckpoint")
    val snapshot = createSnapshot(
      segment,
      minFileRetentionTimestamp,
      segment.lastCommitTimestamp)

    lastUpdateTimestamp = clock.getTimeMillis()
    logInfo(s"Returning initial snapshot $snapshot")
    snapshot
  } catch {
    case e: FileNotFoundException =>
      logInfo(s"Creating initial snapshot without metadata, because the directory is empty")
      // The log directory may not exist
      new InitialSnapshot(logPath, this)
  }
}

ポイントは、スナップショットを作る際に用いられるセグメントである。セグメントにバージョン情報が持たれている。

ここでは3行目の

1	val segment = getLogSegmentFrom(lastCheckpoint)

にて org.apache.spark.sql.delta.SnapshotManagement#getLogSegmentFrom メソッドを用いて、前回チェックポイントからセグメントの情報が生成される。

なお、参考までにLogSegmentクラスの定義は以下の通り。

org/apache/spark/sql/delta/SnapshotManagement.scala:392

case class LogSegment(
    logPath: Path,
    version: Long,
    deltas: Seq[FileStatus],
    checkpoint: Seq[FileStatus],
    checkpointVersion: Option[Long],
    lastCommitTimestamp: Long) {

  override def hashCode(): Int = logPath.hashCode() * 31 + (lastCommitTimestamp % 10000).toInt

  (snip)

上記の通り、コンストラクタ引数にバージョン情報が含まれていることがわかる。

インスタンス化の例は以下の通り。

org/apache/spark/sql/delta/SnapshotManagement.scala:140

LogSegment(
  logPath,
  newVersion,
  deltasAfterCheckpoint,
  newCheckpointFiles,
  newCheckpoint.map(_.version),
  lastCommitTimestamp)

Power Grid Data

2021-02-12

Knowledge ManagementPower Grid Data

Power Grid Data

参考
メモ

参考

以下の資料参照。

メモ

電力データ活用に関連する、割と新しい情報をまとめた。

Mesh wifi for Home Network

2021-01-31

Knowledge ManagementHome Network

IPv6, WiFi, WiFi6

参考
メモ

参考

メッシュWiFiルータ

JPNE v6plus

So-net

au光

動作確認

ipv6 test

メモ

メッシュWiFi

メッシュWiFiとは、Elecomの Vol.83 メッシュ（Mesh）Wi-Fiって何？メリットと活用方法を紹介記事の通り。戸建ての家などでは、広く安定してカバーできるはず、ということで。

日本国内においてどの機器を使うか？については、メッシュルーターの選び方について整理したがわかりやすい。

個人的にはIPv6対応している点で、「Synology MR2200ac」が候補に上がった。仕様は MR2200ac を参照されたし。

JPNE v6プラス

v6プラス(IPv6/IPv4インターネットサービス) によると、

「v6プラス」は、NTT東西の次世代ネットワーク（NGN）を利用しインターネット接続を提供するISP事業者が、 IPv6及びIPv4の設備を持たずに、インターネット接続をお客さま(エンドユーザ)にご提供いただくためのサービスです。

とのこと。

Synology製Wi-FiルーターMR2200acでv6プラス接続設定によると、MR2200acでv6plusを利用する方法が記載されている。

auひかりのHGW（ホームゲートウェイ）

auひかりのホームゲートウェイはいらない? 知っておきたい不都合な真実にも記載の通り、

先ほどから触れてるとおり、auひかりはホームゲートウェイが無ければインターネットに接続することができません。その理由は、ホームゲートウェイ内に、KDDIの認証を取る機能があるからです。

とのこと。

そこで、自前のルータを利用したい場合は、 DMZ機能を利用して、ルータ機能をHGWと自前ルータの療法で動かす設定をすることもある。

au光で市販のルーターを使うが参考になる。ブリッジモードにせずDMZの下でルーターモードで利用するにはも参考になる。こちらはtp-linkのブログ。

so-net

So-net 光 with フレッツ S 東日本は、フレッツ光の契約と思われる。

So-net 光プラスの次世代通信 v6プラスは v6プラスを利用したサービスと思われる。 So-net 光プラスの次世代通信 v6プラスの対象サービスによると、 So-net 光プラスなどが対応している。その他フレッツ系のサービスが対応しているようだ。

IPv6の動作確認

ipv6 test にアクセスると良い。

Memo of How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh

2021-01-19

Knowledge ManagementData Mesh

Data Lake, Data Mesh

参考
メモ

参考

メモ

Zhamak DehghaniによるHow to Move Beyond a Monolithic Data Laketo a Distributed Data Mesh を読んで簡単にまとめた。

この文章では、ドメインが所有し、提供するデータプロダクトの相互利用に基づく「データメッシュ」の考え方を提唱するものである。固有技術そのものではなく、アーキテクチャ検討の前の「データを基礎としたサービス開発、ソフトウェア開発のためのデータの取り回し方」に関する示唆を与えようとしたもの、という理解。

Memo of Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics

2021-01-16

Knowledge ManagementStorage LayerDelta Lake

Delta Lake, Paper

参考
メモ

参考

Lakehouse A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics

メモ

Lakehouse A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics の論文を確認し、簡単なメモを作成した。

考え方を節異名しつつ、Delta Lake、Delta Engineを使用した際のTPC−DSの実行結果、クエリ実行コストの情報が記載されていた。また関連研究、参考文献も過去から現在のトレンドの背景を知る上で参考になるものが多い。

参考

公式ドキュメント

blog

サンプル

メモ

概要

動作確認

アカウント作成

（補足）公式チュートリアルのソースコード

プロジェクトディレクトリ作成

ファイル

（補足）ERROR: Could not find a version that satisfies the requirement pubnub>=4.5.1

参考

メモ

元ネタ

参考

メモ

CentOS

CentOS7

CentOS8 Stream

Fedora

参考

メモ

前提

動機

準備

簡単な動作確認

readPredicatesに書き込みが生じるケース

参考

メモ

結論

事象の確認

関連する実装は？

doolの登場

参考

メモ

前提

createRelationから確認する

参考

メモ

参考

メッシュWiFiルータ

JPNE v6plus

So-net

au光

動作確認

メモ

メッシュWiFi

JPNE v6プラス

auひかりのHGW（ホームゲートウェイ）

so-net

IPv6の動作確認

参考

メモ

参考

メモ