12/31 (木)
SQL DB と JDBC メタデータ情報
SQL を問い合わせ言語として使うリレーショナルデータベース・データウェアハウスであっても、細かい部分ではいろいろ違いがある。 JDBC ドライバーは java.sql.DabataseMetaData を使うと、これらの差を吸収可能な情報を提供してくれそうなのだが、実際にはあまり正確な情報を返してくれない。
まず SQL DB ごとに階層構造が異なっている。 またテーブル名などの識別子を囲う文字も SQL DB 毎に異なっている。
- Oracle DB は1台のデータベースサーバーを使って、複数の店子を処理できるように複数の「データベース(インスタンス)」を持つことが出来るようになっている。 1つのデータベースにはそこにアクセスするユーザー毎の名前空間である「スキーマ」が存在し、テーブルはスキーマの下に作成される。 SQL 文の中でテーブルは "schema"."table" の形式で指定することができるが、接続時に決めたデータベース以外のデータベースのテーブルにアクセスすることはできない。 つまりテーブルの完全な修飾名は2階層になる。
- Microsoft SQL Server も1台のデータベースサーバーを使って、複数の「データベース」を持つことができる。 データベースの下には「スキーマ」が存在し、テーブルはスキーマの下に作成される。 SQL 文の中ではテーブルは `database`.`schema`.`table` の形式で指定することができ、異なるデータベースのテーブルに同時にアクセスすることができる。 つまりテーブルの完全な修飾名は3階層になる。
JDBC はこれらを吸収するために catalog → schema → table という階層を設け、その情報を java.sql.DabataseMetaData を使って返す。
- DabataseMetaData#getCatalogTerm を使うと catalog が実際のデータベース製品の用語で何にあたるのかが取得できる。
- DabataseMetaData#getSchemaTerm を使うと schema が実際のデータベース製品の用語で何にあたるのかが取得できる。
- DatabaseMetaData#isCatalogAtStart を使うとテーブルの完全修飾名にカタログ名が現れる場合は true を、そうでない場合は false を得ることができる。
- DabataseMetaData#getIdentifierQuoteString を使うと、SQL 識別子を引用する際に使う文字を取得できる。
ただ実際に調べてみると、DabataseMetaData はあまり正しく実装されていないように見える。 赤字 の部分は怪しい。
項目 | getCatalogTerm | getSchemaTerm | isCatalogAtStart | getIdentifierQuoteString | 完全修飾名 | 考察 |
---|---|---|---|---|---|---|
Oracle DB | schema | false | " | "schema"."table" | ||
Microsoft SQL Server | database | schema | true | " | `database`.`schema`.`table` | getIdentifierQuoteString が " を返すのはおそらくバグ。 |
IBM Db2 | database | schema | true | " | "location"."schema"."table" | 仕様上は最上位の部分はデータベース名ではなくロケーション名を指定することになっている。 データベース名とロケーション名が同一かどうかは分からない。 |
SAP HANA | CATALOG | SCHEMA | false | " | "SCHEMA"."table" | |
PostgreSQL | Database | Schema | true | " | "Schema"."table" | isCatalogAtStart が true を返すのはおそらくバグ。 |
MySQL | database | true | ` | `database`.`table` |
schema にあたるものがないのに catalog があるのは JDBC の意図とはズレていると思われる。
おそらく MySQL の database は catalog ではなく schema にし、isCatalogAtStart が false を返すべきであろう。
|
|
Vertica | catalog | schema | true | " | "catalog"."schema"."table" | |
Teradata | database | true | " | "Database"."table" | isCatalogAtStart が true を返すのはおそらくバグ。 |
|
PrestoDB | catalog | schema | true | " | "catalog"."schema"."table" | |
Teiid | Virtual Database | Schema | false | " | "schema"."table" |
12/28 (月)
商用データベースの開発用無償版
最近の商業 RDBMS や DWH は容量制限などをつけた上で開発評価用のバージョンを無償提供していることが多い。 12月5日の日記に書いたように Docker コンテナで配布するのが流行りだが、それ以外にも伝統的な Linux にインストール可能なパッケージとして配布したり VMware などの仮想マシンイメージで配布している場合もある。 これらをまとめてみる。
製品名 | 提供バージョン | パッケージ | VM イメージ | Docker イメージ |
---|---|---|---|---|
Oracle DB | Oracle DB 19c | あり(Windows, Linux, etc) | あり | なし Docker ファイルは配布 |
Microsoft SQL Server | SQL Server 2019 | あり(Windows, Linux) | ? | あり(MCR) |
IBM Db2 | Db2 11.5 | あり | あり | あり(Dockerhub) |
SAP HANA | SAP HANA 2.0 Express Edition | ? | あり | あり(Dockerhub、Dockerhub) |
Vertica | Vertica 10 | あり(Linux) | あり | あり(Dockerhub) |
Teradata | Teradata Vantage Express | なし | あり | なし |
MarkLogic | MarkLogic 10.0 | あり(RHEL/CentOS 7, Windows, Mac OS X) | なし | あり(Dockerhub) |
12/23 (水)
年賀状を書いた
例年、年が明けてから年賀状を作成するが、今年は年内に、しかも元旦に配送可能な時期に年賀状を書き上げた。
追記: 12/24
年賀状は筆王を使ってネットプリントしているのだが、これまで使っていた筆王のバージョンでは年賀状の宛名面のフレームが変わったので宛名が正しく印刷されないキャンセルしてくれというメールが来た。
筆王のバージョンを新しくしてから再ネットプリントする。
追記: 12/31
どうも筆王の住所録を先祖返りさせてしまっていたようで、発送した年賀状が次々と戻ってくる。 「配達準備中に調査しましたが、あて所に尋ねあたりません」と赤いスタンプが押してある。
12/21 (月)
MarkLogic の WebDAV サーバー機能
MarkLogic は WebDAV サーバーを持っているが、自作の WebDAV クライアントで接続するテストをするとエラーになった。
PROPFIND メソッドの結果が以下のようになっているが、<D:creationdate/>
のように値がない XML 要素が登場するようだ。
<D:multistatus xmlns:D="DAV:"> <D:response> <D:href>/</D:href> <D:propstat> <D:prop> <prop:directory xmlns:prop="http://marklogic.com/xdmp/property"/> <guid xmlns="http://webdav.example.com/">58f7abc5-e6ba-469f-b946-f8da525d963b</guid> <prop:directory xmlns:prop="http://marklogic.com/xdmp/property"/> <D:creationdate/> <D:displayname>/</D:displayname> <D:getcontentlanguage>en-US</D:getcontentlanguage> <D:getcontenttype>application/x-unknown-content-type</D:getcontenttype> <D:getetag/> <D:lockdiscovery/> <D:resourcetype> <D:collection/> </D:resourcetype> <D:source/> <D:supportedlock> <D:lockentry> <D:lockscope> <D:exclusive/> </D:lockscope> <D:locktype> <D:write/> </D:locktype> </D:lockentry> <D:lockentry> <D:lockscope> <D:shared/> </D:lockscope> <D:locktype> <D:write/> </D:locktype> </D:lockentry> </D:supportedlock> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
12/19 (土)
[MyPC] 自宅 PC を Intel Core i5-2400 から AMD Ryzen 5 3600 へ
テレワークは自宅PCから行っているが、HDDをSSDに置換してから速度は大幅に改善した。 ただテレワークは、自宅 PC (Windows 10)から作業用の VM (Windows 10) を立ち上げて、そこから VPN を貼り VMware Horizon Client 経由で会社の仮想デスクトップに繋げる。 その仮想デスクトップ上で Skype for Business なり Teams なりで多人数の会議をすると、CPU の使用率が跳ねあがって音が途切れ途切れになることが多い。
自宅 PC はベースが 2011 年に購入した Intel Core i5-2400 なので、ここからの強化するのは無理がある。 そこでマザーボードごと交換することに決めた。
秋葉原のドスパラで、AMD Ryzen 5 3600 とマザボ―ド・メモリなど一式買ってくる。 古い VGA は AGP なので新しいマザボ―ドには刺さらない。 一緒に VGA も購入する。
ゲームとかしないので交換による効果は体感できないが、マザーボードのLEDが赤く光っている。
前 | 後 | |
---|---|---|
CPU | 4コア、4スレッド | 6コア、12スレッド |
メモリ | 8GiB | 32GiB |
12/5 (土)
商用データベースの Docker コンテナ
最近は商用 RDBMS や DWH であっても開発向けには無料で利用できるソフトも多い。 ただそのようなデータベースであってもインストールには結構手間取るので Docker コンテナが配布されているとありがたい。
Microsoft SQL Server
Microsoft SQL Server は Microsoft Container Registry(MCR) からコンテナを pull することができる。
sudo docker pull mcr.microsoft.com/mssql/server:2019-latest sudo docker run -e "ACCEPT_EULA=Y" \ -e "SA_PASSWORD=YourStrong@Passw0rd" \ -p 1433:1433 \ --name sql1 -h sql1 -d \ mcr.microsoft.com/mssql/server:2019-latest
デフォルトではユーザー名で SA に対して、SA_PASSWORD 環境変数で設定したパスワードが設定されている。 docker exec で乗り込み、sqlcmd コマンドで操作できる。
sudo docker exec -it sql1 /bin/bash /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P "<YourStrong@Passw0rd>"
JDBC でアクセスする場合は、jdbc:sqlserver://(host):1433/ に対して、ユーザー SA、パスワード YourStrong@Passw0rd でアクセスする。
IBM Db2
IBM Db2 は Dockerhub からダウンロードできる。
sudo docker run -d -it \ --privileged=true \ -p 50000:50000 \ -e "LICENSE=accept" \ -e "DB2INST1_PASSWORD=choose-an-instance-password" \ -e "BLU" \ -e "SAMPLEDB" \ -v db-storage-dir:/database -e DBNAME=testdb \ --name ibmdb2 \ ibmcom/db2
灰色の部分は定義してもしなくてもよい。
デフォルトで環境変数 DBNAME で指定した名前のデータベースが作成される(上のコマンドでは testdb)。 db2inst1 というデータベースが作成され、db2inst1 というユーザーで choose-an-instance-password で指定したパスワードでアクセスできる。
JDBC でアクセスする場合は、jdbc:db2://(host):5000/testdb に対して、ユーザー db2inst1、パスワード choose-an-instance-password でアクセスする。
Docker コンテナ内の Db2 に対して接続してコマンドを入力するには、以下のように実行する。
sudo docker exec -it ibmdb2 /bin/bash su - db2inst1
その後、db2 コマンドを実行する。
- db2 LIST DB DIRECTORY … データベースの一覧の表示
Vertica
Vertica は Docker Hub に dataplatform/docker-vertica でコンテナが配布されている。
sudo docker run -p 5433:5433 \ -d \ --name vertica \ dataplatform/docker-vertica
デフォルトでは docker というデータベースが用意されており、dbadmin というユーザーでアクセスができる(パスワードは空)。 起動後は docker exec で乗り込んだ後で vsql コマンドを使う。
sudo docker exec -it vertica /bin/bash /opt/vertica/bin/vsql docker dbadmin
JDBC でアクセスする場合は、jdbc:vertica://(host):5433/docker に対して、ユーザー dbadmin、パスワードは空でアクセスする。
データベースを新規作成したい場合には、docker exec で乗り込んだ後に dbadmin ユーザーに switch user した後で admintools を使う。 テキストUIのツールが稼働して設定変更ができる。
sudo docker exec -it vertica /bin/bash su - dbadmin admintools
MarkLogic
MarkLogic は開発者として登録すると Linux や Windows 用の制限付きのバイナリをダウンロード出来るが、Dockerhubからのコンテナイメージの配布も行っている。 こちらは Docker へのユーザー登録が必要となる。
sudo docker run -d -it \ -p 8000:8000 \ -p 8001:8001 \ -p 8002:8002 \ -e MARKLOGIC_INIT=true \ -e MARKLOGIC_ADMIN_USERNAME=jane_doe \ -e MARKLOGIC_ADMIN_PASSWORD=q7vZxtzA2h \ -v ~/data:/var/opt/MarkLogic \ --name marklogic1 store/marklogicdb/marklogic-server:10.0-5.1-dev-centos
8001 番のポートにアクセスすると Admin Interface にアクセスできる。
SAP HANA
SAP HANA は Dockerhub からコンテナイメージの配布を行っている。 こちらも Docker へのユーザー登録が必要となる。
- SAP HANA, express edition (database services)
- SAP HANA, express edition (database and application services)
ただしメモリの関係でうちのマシンでは動かせない。
おまけ: PrestoDB
PostgreSQL と MySQL のダミーデータベースが入った PrestoDB コンテナを作成して Docker Hub に登録している。
sudo docker run -ti \ --tmpfs /run \ --tmpfs /run/lock \ -v /sys/fs/cgroup:/sys/fs/cgroup:ro \ -p 13306:3306 \ -p 15432:5432 \ -p 18080:8080 \ --name presto \ nminoru/presto
ポート番号やパスワードは https://github.com/nminoru/misc/tree/master/docker/presto を参照。