記事・メモ一覧

スキーマをコピーする方法はない。 代わりに以下の方法で同じ効果を得る。 スキーマ名Aをスキーマ名Bに変更する スキーマ名Bの状態でpg_dumpする スキーマ名Bをスキーマ名Aに変更する スキーマ名Bを作成する pg_dumpしたファイルをリストアする Statementは以下の通り。 $ psql -U user -d dbname -c \'ALTER SCHEMA old_schema RENAME TO new_schema\' $ pg_dump -U user -n new_schema -f new_schema.sql dbname $ psql -U user -d dbname -c \'ALTER SCHEMA new_schema RENAME TO old_schema\' $ psql -U user -d dbname -c \'CREATE SCHEMA new_schema\' $ psql -U user -q -d dbname -f new_schema.sql $ rm new_schema.sql [arst_adsense slotnumber=\"1\"]

どのようにテーブル設計するとパフォーマンスを得られるか. 公式がベストプラクティスを用意している. Redshiftのベストプラクティスが先にあってER図が後なのか、 ER図に対してベストプラクティスを適用するのか、 実際は行ったり来たりするようなイメージ. ER図とは別に何を考慮すべきなのか読み進めていく. [arst_toc tag=\"h4\"] ソートキー テーブル作成時に1つ以上の列をソートキーとして設定できる. 設定するとソートキーに準じたソート順でディスクに格納される. ソートキーに関するベストプラクティスは以下の通り. 最新のデータを得たい場合はタイムスタンプ列をソートキーにする. 1つの列に対してwhere句による範囲指定or等価指定をおこなう場合はその列をソートキーにする. ディメンションテーブルを頻繁に結合する場合は結合キーをソートキーにする. ファクトテーブルを中心にディメンションテーブルが4つある構造があるとする. ファクトテーブルにはディメンションテーブルのPKが入り関連している. また、ファクトテーブルに日付カラムがあり、常に最新のレコードが欲しいとする. ベストプラクティスによると、 各テーブルの各カラムに以下のようにソートキーを設定する. 分散スタイル クエリの実行を複数のクラスタ（コンピューティングノード、スライス）で実行するために、 それらに1)データを配信して 2)計算させて 3)結合、集計する というステップが必要になる。 最後のステップ3を達成するために、データの再び配ることが必要となる。 全体として最適となるように、1),2),3)の効率を高める必要があるが、 あらゆるデータ、条件について同じ戦略で最高の効率を得ることはできず、 設計者が戦略を指定するパラメタとなっている。 この戦略を分散スタイルと呼んでいる. 分散スタイルとして以下の3通りが用意されている. 各々だけ読むとさっぱり意味がわからないが、結局のところ再分散のコストをいかに減らすか、 というところに着目すると合点がいく. EVEN 分散 特定の列に含まれている値と関係なくラウンドロビンで複数のスライス間で行を分散させる. テーブルが結合に関与していない場合や、キー分散、ALL分散のどちらが良いかわからない場合に指定する. キー分散 キー分散のキーとは結合キーのこと. 特定の列に含まれている値に従って複数のスライスに行を分散させる.キーが同じということは「同じデータ」であり「同じデータ」達を同じスライスに分散させる意味がある. 共通の列からの一致する値が同じスライスにまとめられるよう努力する. ALL 分散 テーブル全体のコピーが全てのノードに分散される. EVEN分散、キー分散によってテーブルの一部が各ノードに配置されているときにALL分散を行うことでテーブルが関与しているあらゆる結合で全ての行が確実にコロケーションされる. 何が嬉しいのかわかりづらいが、EVEN分散やキー分散では、クエリ実行に伴って、再び必要なデータをコピーする(再分散する)必要が発生する可能性が生じる.ALL分散であればその可能性がなくなる. AUTO 分散 (デフォルト) テーブルデータのサイズに基づいて最適な分散スタイルを割り当てる. まず小さなテーブルにALL分散を設定し,テーブルが大きくなるとEVEN分散に切り替える. 分散スタイルを明示的に設定しないとAUTO分散になる. まず、ファクトテーブル関連する1つのテーブルの共通の列に基づいて分散させる. 関連するテーブルの選び方の観点は大きさで最もレコード数が大きいテーブルを選択する. 以下の構造では、ファクトテーブルとディメンションテーブル1が dim1_keyというキーを使って結合している. そこで, ファクトテーブルのdim1_key、ディメンションテーブル1のdim1_keyを分散キーとして採用する.(緑) ここまでで、dim1_keyの値が一致するレコードが同じスライスにコロケーションされる. キー分散に使うキーは1組のみ. 残りのテーブルについてはEVEN分散かALL分散を用いる. 選び方は上記の通り. テーブルのサイズが小さいのであれば、ALL分散により再分配の可能性がなくなり選びやすい. 圧縮エンコーディング 通常のRDBのように行方向の固まりを記録する場合、各列の値は型や値の傾向がまちまちであるため、 一様に圧縮しようとしても高い圧縮率を得られない. 対して、列方向の固まりを記録する場合、各列の型は同じだし値の傾向が似ていることが多いため、 高い圧縮率を得られる可能性がある. ただし、値の傾向により圧縮アルゴリズムを選択する必要がある. 公式で挙げられているアルゴリズム. 結局試してみないとわからない、というのはある. (Zstandard強すぎないか？) raw エンコード 圧縮をおこなわない. ソートキーが設定されているときはrawエンコードが設定される BOOLEAN、REAL,DOUBLE PRECISION型もraw. AZ64 エンコード Amazon 独自の圧縮エンコードアルゴリズム より小さなデータ値のグループを圧縮し、並列処理に SIMD (Single Instruction Multiple Data) 命令を使用する 数値、日付、および時刻データ型のストレージを大幅に節約する バイトディクショナリエンコード バイトディクショナリエンコード ディスク上の列値のブロックごとに、一意の値の個別のディクショナリを作成する 列に含まれる一意の値の数が制限されている場合に非常に効果的 列のデータドメインが一意の値 256 個未満である場合に最適 CHAR 列に長い文字列が含まれる場合に特に空間効率が高まる VARCHAR 列に対しては、LZO などの BYTEDICT 以外のエンコードを使用する デルタエンコード 列内の連続する値間の差を記録することにより、データを圧縮 日時列にとって非常に有用 差が小さいときに特に有用 LZO エンコード 非常に長い文字列を格納する CHAR および VARCHAR 列、特に製品説明、ユーザーコメント、JSON 文字列などの自由形式テキストに適している Mostly エンコード 列のデータ型が、格納された大部分の値で必要なサイズより大きい場合に有用. たとえば、INT2 列などの 16 ビット列を 8 ビットストレージに圧縮できる ランレングスエンコード 連続して繰り返される値を、値と連続発生数 (実行の長さ) から成るトークンに置き換える データ値が連続して繰り返されることが多いテーブルに最適 たとえば、テーブルがこれらの値でソートされている場合など Text255 および Text32k エンコード 同じ単語が頻繁に出現する VARCHAR 列を圧縮する場合に有用 Zstandard エンコード 多様なデータセット間で非常にパフォーマンスのいい高圧縮比率を提供 製品説明、ユーザーのコメント、ログ、JSON 文字列など、長さがさまざまな文字列を保存する CHAR および VARCHAR 列に対して有用 圧縮エンコーディングをテストするためには、 各アルゴリズムで差が出るように大量のデータを用意する必要がある. 公式には、テストするために大量のデータを用意することは難しいので デカルト積ででっち上げる手法が案内されている. 例えば、こんな感じにデータをでっちあげる. create table cartesian_venue( venueid smallint not null distkey sortkey, venuename varchar(100), venuecity varchar(30), venuestate char(2), venueseats integer ); insert into cartesian_venue select venueid, venuename, venuecity, venuestate, venueseats from venue, listing; このうち、venunameに対して各エンコーディングアルゴリズムを適用して格納するデータを作る. create table encodingvenue ( venueraw varchar(100) encode raw, venuebytedict varchar(100) encode bytedict, venuelzo varchar(100) encode lzo, venuerunlength varchar(100) encode runlength, venuetext255 varchar(100) encode text255, venuetext32k varchar(100) encode text32k, venuezstd varchar(100) encode zstd); insert into encodingvenue select venuename as venueraw, venuename as venuebytedict, venuename as venuelzo, venuename as venuerunlength, venuename as venuetext32k, venuename as venuetext255, venuename as venuezstd from cartesian_venue; 知りたいことは、encodingvenueの各列で実際に使われているディスク容量. 以下のようにして各列で使用される1 MBのディスク ブロック数を比較するらしい. rawが203に対してBYTEDICTが10. つまりBYTEDICTにより20:1の圧縮率を得られた例. select col, max(blocknum) from stv_blocklist b, stv_tbl_perm p where (b.tbl=p.id) and name =\'encodingvenue\' and col < 7 group by name, col order by col; col | max -----+----- 0 | 203 1 | 10 2 | 22 3 | 204 4 | 56 5 | 72 6 | 20 (7 rows) まとめ 公式のベストプラクティスを追ってみた. 面倒だけれども結構力技で出来ているなという印象. 与えられたスタースキーマからある程度決まったやり方でパラメタを選択できそう. 実データでやったら迷うことは必至w ソートキーと分散スタイルの選択は分散コストに影響する. 圧縮エンコーディングの選択はディスクストレージに影響する. 理解したら実際に試行錯誤していくしかないイメージ.

概要 各論に入る前に総論。 MPPでクエリ実行するために必要な制限事項を設計/実装するために、 とりあえず、何故その制限事項が必要なのかを理解しておく必要がありそう。 [arst_toc tag=\"h4\"] 並列処理 MPP(Massively Prallel Processing). シンプルで安価なプロセッサを多数集積して一台のコンピュータとする手法. 各ノードの各コアは、同じコンパイル済みクエリセグメントをデータ全体の一部分に対して実行する。 テーブルの行をコンピューティングノードに分配し分散処理する。 列指向 通常のアプリケーションとデータウェアハウスではクエリで取得したいデータが異なる. 通常のアプリケーションは行の大方の列が欲しい一方で、データウェアハウスは行の中の一部の列が欲しい。 データウェアハウスが1行の全ての列を取得する方式を使用すると、ほとんどの列は無駄になってしまう. ある行の1列にだけ関心がある状況で15行分欲しい場合、行指向であれば100回、列指向であれば5回のディスクI/O。 データ圧縮 列指向で同じ列のデータを取る場合、同じ列に入るデータの乱れ方には傾向があるはずなので、データ圧縮が効きやすい。 データ圧縮によりディスクI/Oがさらに減少する。 クエリオプティマイザ MPP対応のクエリオプティマイザ。複数のコンピューティングノードで並列処理するための最適化が走る。 結果のキャッシュ リーダーノートでキャッシュする必要性があるクエリと結果をキャッシュする。 サイズの大きなクエリ結果セットはキャッシュしない。 キャッシュするか否かは、キャッシュ内のエントリ数とAmazon Redshiftクラスターのインスタンスタイプが含まれる。

やはりAWSの公式のドキュメンテーションは読みやすいので、 公式を上から順に舐めていくスタイルで理解していく。 今回は一番最初のアーキテクチャ概要。 [arst_toc tag=\"h4\"] アーキテクチャ 大きなデータを扱おうとする何かは分散アーキテクチャで解決しようとする。 と言っても、大抵は\"代表するノード\"と\"ワーカーノード\"のセットなのでデジャブ感がある。 ちなみにTableauServerが内部設計を細かく書いていて面白かった。 以下、Amazon Redshiftのアーキテクチャを表す図. (公式) Amazon Redshiftは複数のクラスタから構成される。 クラスタはリーダーノードと複数のコンピューティングノードから構成される。 クライアントアプリケーションからは唯一リーダーノードと呼ぶノードを参照できる。 コンピューティングノードはクライアントアプリケーションから見えない場所に配置されリーダーノードが代表してコンピューティングノードを操作する。 リーダーノード クライアントアプリケーションは PostgreSQL用の JDBC/ODBCドライバを使用してリーダーノード通信できる。 実行計画に基づいてコードをコンパイルしコンパイル済みのコードをコンピューティングノードに配布してからデータの一部を各コンピューティングノードに割り当てる。 コンピューティングノード コンパイル済みのコードを実行し中間結果をリーダーノードに返送する。 中間結果はリーダーノードで最終的に集計される。 コンピューティングノードのCPU、メモリ、ストレージはノードのタイプによって異なる。ノードの数、種類を増強することでスケールアップできる。 ノードスライス コンピューティングノードはスライスに分割されている。 各スライスにはノードのメモリとディスク容量の一部を割り当てられている。 リーダーノードがスライスへのデータ分散を管理し、クエリ、データベース操作のワークロードをスライスに分配する。 スライスは並列処理を行って操作を完了する。 内部ネットワーク リーダーノードとコンピューティングノードの間はプライベートで非常に高速なネットワーク。 コンピューティングノードは独立したプライベートネットワークに配置される。 RDBとの互換性 Amazon Redshift は PostgreSQLを大規模データ用に拡張したミドルウェアである。 標準的なRDBMSと同様にデータの挿入、削除、トランザクション処理を実行できる。行指向から列指向に拡張されており、行指向を前提としたクエリは苦手。

Hello World. docker-composeを使ってコンテナ間の繋がりを定義してみるデモに超速で入門する。 ゼロから書くと不要な時間を要するので、こちらを参考にさせていただいた。 写経する中でポイントを咀嚼していく。 ~/dockercompose_test というディレクトリを作成し、 その中で作業する。 docker-compose.yml 構成を記述する設定ファイル。ymlで書く。 ansibleでymlには慣れているので嬉しい。 version: \"3\" services: db: image: mysql:5.7 #container_name: \"mysql57\" volumes: - ./db/mysql:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: root_pass_fB3uWvTS MYSQL_DATABASE: wordpress_db MYSQL_USER: user MYSQL_PASSWORD: user_pass_Ck6uTvrQ wordpress: image: wordpress:latest #container_name: \"wordpress\" volumes: - ./wordpress/html:/var/www/html - ./php/php.ini:/usr/local/etc/php/conf.d/php.ini restart: always depends_on: - db ports: - 8080:80 environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_NAME: wordpress_db WORDPRESS_DB_USER: user WORDPRESS_DB_PASSWORD: user_pass_Ck6uTvrQ ルートはservices. 名称の理解がフワフワだが、コンテナをサービスと読んでいることが多いくらいの認識. 配下に db と wordpress が存在する。おなじみの構成を定義している。 db dbの定義についてパラメタを追っていく. パラメタ 値 説明 image mysql57 pull してくるイメージを書く. mysql57という名前のイメージをpullする. volumes - ./db/mysql:/var/lib/mysql コンテナ内の/var/lib/mysql を ホストの./db/mysql にマウントする(で良いか?) restart always 再起動ポリシー(コンテナ終了時に再起動するための仕組み)を設定する.再起動ポリシーを設定しておくことで、Dockerデーモンの起動時やホストOSの起動時に自動的にコンテナを開始できる。 alwaysの他にいくつかあるか今はスキップ. environment MYSQL_ROOT_PASSWORD: root_pass_fB3uWvTSMYSQL_DATABASE: wordpress_dbMYSQL_USER: userMYSQL_PASSWORD: user_pass_Ck6uTvrQ コンテナの環境変数を定義する. 環境変数名はコンテナ依存. wordpress wordpressの定義についてパラメタを追っていく. パラメタ 値 定義 image wordpress:latest pull してくるイメージを書く. wordpressという名前のイメージをpullする. バージョンは最新. volumes ./wordpress/html:/var/www/html./php/php.ini:/usr/local/etc/php/conf.d/php.ini コンテナ内のディレクトリをホストのディレクトリにマウントする.マウント先を定義する. restart always 再起動ポリシーをalwaysに設定.内容はdbと同じ. depends_on - db サービスの依存関係を定義する.要は起動する順番を定義する. wordpressのdepends_onにdbを設定することで,wordpressよりも先にdbを起動できる.dbの起動が完了するまで待ってくれるという意味ではない! Control startup and shutdown order in Compose. ports 8080:80 コンテナの80番をホストの8080にマップする. http://localhost:8080 とかするとコンテナの80番が開く. environment WORDPRESS_DB_HOST: db:3306WORDPRESS_DB_NAME: wordpress_dbWORDPRESS_DB_USER: userWORDPRESS_DB_PASSWORD: user_pass_Ck6uTvrQ wordpressコンテナの環境変数を設定する.環境変数はコンテナ依存. docker compose up 以下で定義したdocker-compose.ymlに基づいて構築が始まる. -dはDetachedMode. これによりバックグラウンドで実行される. $ docker-compose up -d ホストで http://localhost:8080 を開くと以下の通り. 永続化の確認 言語を設定しwordpressのインストールを完了させる. db(MySQL)に加えられた変更はホストにマウントされたファイルに反映される. 以下により環境を停止した後, 再度upしたとしても, ホストにマウントされたファイルへの変更が反映され, インストール済みの状態で立ち上がる. $ docker-compose down $ docker-compose up -d まとめ docker-compose を使った WordPress環境構築のデモに超速で入門した. 一緒にコンテナを永続化するデモにも入門した.

最小の手数でHello world. とりあえず最小の手数でwordpressを起動してみる。 イメージのダウンロード docker pullでMySQLとWordPressのイメージをダウンロードする。 イメージはサービス単位。 \"MySQL\"を実現するためのOSとミドルウェア。 \"WordPress\"を実現するためのOSとミドルウェア。例えばWebサーバも含んでいる。 まずはMySQL。 $ docker pull mysql:5.7.21 5.7.21: Pulling from library/mysql 2a72cbf407d6: Pull complete 38680a9b47a8: Pull complete 4c732aa0eb1b: Pull complete c5317a34eddd: Pull complete f92be680366c: Pull complete e8ecd8bec5ab: Pull complete 2a650284a6a8: Pull complete 5b5108d08c6d: Pull complete beaff1261757: Pull complete c1a55c6375b5: Pull complete 8181cde51c65: Pull complete Digest: sha256:691c55aabb3c4e3b89b953dd2f022f7ea845e5443954767d321d5f5fa394e28c Status: Downloaded newer image for mysql:5.7.21 docker.io/library/mysql:5.7.21 次にWordPress。何も指定しないと最新が落ちる様子。 $ docker pull wordpress Using default tag: latest latest: Pulling from library/wordpress bb79b6b2107f: Pull complete 80f7a64e4b25: Pull complete da391f3e81f0: Pull complete 8199ae3052e1: Pull complete 284fd0f314b2: Pull complete f38db365cd8a: Pull complete 1416a501db13: Pull complete be0026dad8d5: Pull complete 7bf43186e63e: Pull complete c0d672d8319a: Pull complete 645db540ba24: Pull complete 6f355b8da727: Pull complete aa00daebd81c: Pull complete 98996914108d: Pull complete 69e3e95397b4: Pull complete 5698325d4d72: Pull complete b604b3777675: Pull complete 57c814ef71bc: Pull complete ed1877bc3d14: Pull complete 673ead1d3971: Pull complete Digest: sha256:46fc3c784d5c4fdaa46977debb83261d29e932289a68739f1e34be6b27e04f87 Status: Downloaded newer image for wordpress:latest docker.io/library/wordpress:latest MySQLコンテナを起動 コンテナ(イメージ)を起動する。 $ docker run --name test-mysql -e MYSQL_ROOT_PASSWORD=test-pw -d mysql 013a2eb6b5b1c0b0f61e85cace6540ec036be80c9f85e8c9b5ed3e114a4cc8e8 パラメタは以下の通り。 Option Value 説明 --name test-mysql コンテナに名前を付ける。この例であれば test-mysql -e MYSQL_ROOT_PASSWORD=test-pw コンテナの環境変数を設定する。MYSQL_ROOT_PASSWORDという環境変数としてtest-pwを設定 -d - DetachedMode(Background)を指定する。指定がない場合Foregroud. WordPressコンテナを起動 WordPressコンテナを起動する。 $ docker run --name test-wordpress --link test-mysql:mysql -d -p 8080:80 wordpress a1301075d3667de7eddd9edc0c46edaeb4346a5c46ef444538c9cf9987f31471 パラメタは以下の通り。 Option Value 説明 --link test-mysql:mysql コンテナを連携させる。書式は --link [コンテナ名]:[エイリアス]。test-mysqlがコンテナ名(前述)で、mysqlがそのエイリアス。 -p 8080:80 HostとGuestのポートマッピング。Hostの8080をGuestの80にマッピングする。 Hostの8080にWordPressコンテナ内の80がマップされた。 http://localhost:8080/ でWordPressの言語選択画面が表示される。 非同期で起動したコンテナにアタッチ docker execで非同期に起動したWordPressコンテナ内のディレクトリにアクセスできる。 この例だと/var/www/html。 ゴニョゴニョいじると変更が反映される。 $ docker exec -it test-wordpress /bin/bash root@a1301075d366:/var/www/html# もちろん、コンテナを落とすと変更は失われる。 まとめ DockerでWordPressを動かすデモに超速で入門した。

型 基本型 全ての変数はオブジェクト。用意されている型は以下の通り。 数値型は int と double。 int IS num, double IS num となる num型がある。 論理型は bool 文字列型は String リストは　List<T> 連想配列は Map<K, V> Runes,Symbolもあり Gneric型とdynamic Generic型がある。 List list = [1, 2, 3]; List list2 = [\'a\', 100, 3.14]; int, double など, どの型を使うか想定はあるが Dart言語で表現できない場合に dynami型を使う。 何型となるか想定がない場合, 全ての型の基底型である Objectを使う。 型推論 var で宣言して, 式の評価時に型を決める。 以下, x はforEachで初めて int であることが決まる。 var hoge = \"hogehoge\"; [1, 2, 3].forEach((x) => print(x*2)); 変数 Non Null By Default (NNBD) NNBDがOFFの場合、変数のデフォルト値は Null。 変数に Null を代入できるし, 変数は Nullになる可能性がある。 NNBDがONの場合、あえて指定しなければ Nullにすることはできない。 int x = Null; //コンパイルエラー int? x = Null; //OK FlutterでNNBDを有効にするには、 プロジェクトディレクトリの下にある analysis_options.yaml を書き換える。 analyzer: enable-experiment: - non-nullable finalとconst finalを付けると変数宣言時以外で値が書き換わらないことを保証できる。 変数が指しているメモリが書き換わらないことは保証していないので、 例えば以下のようにfinalなListの要素を書き換えることはできる。 final List l = [1,2,3]; l[1] = 10; //OK constを付けると値がコンパイル時に確定していることを表せる。 finalに加えて変数が指しているメモリが書き換わらないことも保証する。 const List l = [1,2,3]; l[1] = 10; //ng 可視性識別子 Dartには可視性識別子はない。プレフィックスとして _ を書くと可視性が下がる. 関数 基本形とシンタックスシュガー 関数の書き方。 戻り値の型 functionName(引数の型 引数) { return 戻り値; } 戻りが式の場合、まとめて書ける。 戻り値の型 functionName(引数の型 引数) => 式; void main() { print(getReverseValue(true).toString()); print(getReverseValue2(true).toString()); } bool getReverseValue(bool x) { return !x; } bool getReverseValue2(bool x) => !x; 名前付きパラメータ 引数に名前を付けて、呼ぶときに名前毎に値を渡せる。 名前付きパラメータは任意となる。 戻り値の型 functionName({引数の型 引数1, 引数の型 引数2}) { return 戻り値; } functionName(引数1: hoge, 引数2: fuga); void main() { print(myFunction(param1: 100, param2: \"hoge\")); print(myFunction(param1: 500)); // param2は任意だが myFunction内で参照してエラー } String myFunction({int param1, String param2}) => param1.toString() + param2;

ubuntuの場合、postgresユーザのホームディレクトリは /var/lib/postgresql 。 例えば .pgpass をここに置くと、postgres ユーザで psql を実行した場合でも読んでくれる。 ホームディレクトリが無い理由 プログラムを実行するために作成されたユーザとコンソールログインするユーザは扱いが違う。 例えば nginx、mysql のように PostgreSQL の実行ユーザである postgres のホームディレクトリは、 PostgreSQL の maintainer が決める。 /home/postgres というディレクトリは作られない。 PostgreSQLは, root の代わりに postgres ユーザを使ってり様々な処理をおこなう. ホームディレクトリはどこ？ PostgreSQLのインストールディレクトリがホームディレクトリ。 ubuntuの場合、PostgreSQLは /var/lib/postgresql にインストールされていて、 /var/lib/postgresql がホームディレクトリ。 データディレクトリの調べ方 PostgreSQLのデータベースファイルのレイアウトによると、 データディレクトリに全てのファイルが格納される。 postgres の起動パラメタとして データディレクトリ が指定されている。 (-D) 以下の例だと、/var/lib/postgresql/9.5/main。 $ ps ax | grep postgres | grep -v postgres: 1377 ? S 0:01 /usr/lib/postgresql/9.5/bin/postgres -D /var/lib/postgresql/9.5/main -c config_file=/etc/postgresql/9.5/main/postgresql.conf 10600 pts/0 T 0:00 sudo -s -u postgres 11930 pts/0 S+ 0:00 grep --color=auto postgres 別の方法として、psql から SHOW data_directory を実行することで データディレクトリを得られる。 やはり、/var/lib/postgresql/9.5/main。 $ sudo -s -u postgres $ psql postgres=# SHOW data_directory; data_directory ------------------------------ /var/lib/postgresql/9.5/main (1 row) ホームディレクトリの下の階層にデータディレクトリが出来ている。 /home/以下が作られないユーザについて(Stackoverflow) Why Directory for postgres user does not appear inside the HOME directory in linux with other users? [closed] That there is a dedicated user for PostgreSQL is a security measure, so the DB processes can run with that user\'s (limited) priviledges instead of running as root. Whether or not you can actually log on with that user, and what that user\'s home directory should be, is the decision of the package maintainer / the Linux distribution in question. Since the postgresql user should not be (ab-) used as just another user (with own desktop settings, user data etc.), I wouldn\'t question the wisdom of not giving it a home, but rather why he is enabled to log in in the first place. Edit: Being ignorant of the fine print of PostgreSQL, and a bit confused by the wording of your question, I argued the general case. Ignacio pointed out that you had to actually break the system (unlock the user\'s password with root priviledges) to even be able to log in as postgresql user. So the answer can be phrased even simpler: The user does not have a directory in /home because you are not supposed to ever log in as that user. It\'s for running the database processes without root priviledges, nothing else. (Note that you could, using the same technique, log in as user man, or user lp, or user mail. You could, but it wouldn\'t make sense, and unlocking those user\'s passwords actually weakens the security of your system.)

セッション毎にプロセスが動いている。 pg_terminate_backend()を使ってプロセスを落とせば良い。 動いているプロセスを落とせばセッションは切れる。 killで落とすと上手くいかないので注意。 基本形 基本形は以下の通り。 $ sudo -s -u postgres $ psql postgres=> select pg_terminate_backend({プロセスID}); 通常、セッションは複数存在するため、切りたいセッションのプロセスIDを選択して pg_terminate_backend()に渡す必要がある。 自分以外全部切る 生きているセッションをpg_terminate_backend()(後述)を使って探し、 pg_terminate_backend()に食わせて落とす。 自分自身のpidは pg_backend_pid() で得られる。 $ sudo -s -u postgres $ psql postgres=> SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = \'DB名\' AND pid pg_backend_pid(); datnameはTypoではない! 動的統計情報ビュー 上で使っているpg_stat_activityは動的統計情報ビューというビルトインのビューの一つ。 27.2.2. 統計情報の表示。 サーバ当たり１行の形式で、 状態や現在の問い合わせ等のプロセスの現在の活動状況に関連した情報を表示する。 取れるデータ達は以下の通り。PostgresSQLのバージョンによって異なるが、 よく使いそうなものは変わらなそう。使う場合には要注意。 postgres=> d pg_stat_activity; View \"pg_catalog.pg_stat_activity\" Column | Type | Modifiers ------------------+--------------------------+----------- datid | oid | ; バックエンドが接続するデータベースのOID datname | name | ; バックエンドが接続するデータベースの名前 pid | integer | ; バックエンドのプロセスID usesysid | oid | ; バックエンドにログインしたユーザの識別子 usename | name | ; バックエンドに接続したユーザの名前 application_name | text | ; バックエンドに接続したアプリケーションの名前 client_addr | inet | ; バックエンドに接続したクライアントのIPアドレス client_hostname | text | ; client_addrの逆引き検索により報告された、接続クライアントのホスト名 client_port | integer | ; クライアントがバックエンドとの通信に使用するTCPポート backend_start | timestamp with time zone | ; プロセスが開始、つまりクライアントがサーバに接続した時刻 xact_start | timestamp with time zone | ; プロセスの現在のトランザクションが開始した時刻 query_start | timestamp with time zone | ; 現在有効な問い合わせが開始した時刻 state_change | timestamp with time zone | ; stateの最終変更時刻 wait_event_type | text | ; he type of event for which the backend is waiting wait_event | text | ; Wait event name if backend is currently waiting, otherwise NULL. state | text | ; Current overall state of this backend backend_xid | xid | ; もしあれば、このバックエンドの最上位のトランザクション識別子 backend_xmin | xid | ; 現在のバックエンドのxmin query | text | ; バックエンドの最も最近の問い合わせテキスト backend_type | text | ; Type of current backend

以下の項目についてオンラインヘルプをまとめてみた. 工数1日程度の理解なのと無理やり1行に詰めた感は否めないのですが, そもそも自分用なのでご容赦を... ハードウェア要件 ソフトウェア要件 ライセンス サーバプロセス 分散環境と高可用性 データソース 1. 全ての技術仕様. https://www.tableau.com/ja-jp/products/techspecs 1. ハードウェア最小要件 1. 最低要件 RAM 16GB, CPU x64 空きディスク容量 15GB, コア数は物理コア. HTは考慮されない. 1. 本番シングル RAM 32GB, CPU x64 8コア 2.0GHz以上 空きディスク容量 50GB. 1. 本番マルチ 運営に聞いてね. 1. ソフトウェア要件 1. サポートするOS WindowsServer2012,2012R2,2016,2019, AmazonLinux2, RHEL7.3,CentOs7.3+,Debian9+,OracleLinux7.3,ubuntu16.04LTS,18.04LTS 1. ブラウザ Chrome(Windows,Mac,Android),MS Edge,IE11,FireFox,Safari, + Tableau Mobile 1. メールアラートのオプション STMPをセットアップする必要あり. TLS有効化によりSMTP TLSを透過的に使用可. 1. ウイルス対策の懸念事項 TableauServerのインストールや使用に干渉する可能性あり. 公式がプログラムフォルダ,データフォルダを除外する案内を実施. 1. TCPポート.TSM=8850,TS GW=80.TS GWをSSLとする場合443. 1. 専用サーバーの目的と利点. パフォーマンス. セキュリティ. 相互運用性. https://help.tableau.com/current/guides/everybody-install/ja-jp/everybody_admin_install.htm 1. クラウドで稼働させる際の検討事項. オンプレミスと比較してハードウェアコスト不要.アップタイム,信頼性,耐故障性が良い. AWS,Azure,GCP,AlibabaCloud(?)の4環境のガイドあり. 1. ライセンス発行 1. ライセンスタイプはコア毎,ユーザ毎の2種類.ユーザライセンスの場合,\"ライセンス\"-\"サイトロール\"-\"パーミッション\"によるアクセシビリティマトリクス(的なもの)を作れる. 1. ライセンスタイプ=>Creator,Explorer,Viewer.の3種類. 1. Creator=>コンテンツ作成,データソース設計,サイトロールとパーミッション設計.パブリッシュ.PrepBuilder.管理者向け.TableauServerを管理. 1. Explore=>PrepBuilderNG.パブリッシュNG.既存のデータソースの使用,既存のデータソースを使ったダッシュボードの作成.TableauServerのコンテンツを管理. 1. Viewer=>パブリッシュ済みのダッシュボードを表示する.自分でダッシュボードを作らない. 1. サイトロール=>サイトに対してユーザが持つことができる最大のアクセスレベル.サイトロールの最大の権限をユーザが利用できるかはコンテンツに設定されているパーミッションによる. 1. Creatorライセンスを使用するサイトロール 1. サーバ管理者=>TableauServerでのみ使用可能.OnlineではNG.全てのコンテンツに対して無制限のアクセス権. 1. サイト管理者Creator=>Onlineでも可能.サイトレベルのアクセス権を除く.サイトが用意された前提で全てのアクセス権. 1. Creator=>管理者以外では最大のアクセスレベル.ブラウザでの外部データへの接続など 1. Explorerライセンスを使用するサイトロール 1. サーバ管理者=>TableauServerでのみ使用可能.OnlineではNG.管理者ユーザ作成時にサーバで認証された最大のライセンスタイプがExploreの場合,CreatorではなくExploreのサーバ管理者になる. 1. サイト管理者Explorer=>Onlineでも可能.既存のデータソースを使用して既存のワークブックの編集・保存をおこなえる. 1. Explorer(パブリッシュ可能)=>既存のデータソースを使用してWebからワークブックをパブリッシュする. 単なるExploreに記述された特記事項ができる. 1. Explore=>Webからワークブックに埋め込まれたデータソースから新しいスタンドアロンデータソースを保存できない.もちろん新規にデータソースを作成できない. 1. Viewerライセンスを使用するサイトロール 1. Viewer=>既存のパブリッシュ済みのビューを表示する.データへの接続,コンテンツの作成,編集,パブリッシュ,データアラートの設定などできない. 1. ライセンスなし 1. サインインできない. CSVからのインポート時, ユーザ追加時に利用可能なライセンスが無い場合.など. 1. コンテンツをパブリッシュできる人物 => サーバ管理者,サーバ管理者Creator,Creator, Explore(パブリッシュ可能),サイト管理者Explore 1. サーバプロセス 1. TableauServiceManager(TSM).インストール後の初期構成.設定変更.トポロジ変更.継続的な(日常的な?)構成管理.バックアップの復元,ログ圧縮,管理タスクの実行など. 1. TableauServer実行に開始(running),停止じに停止(stopping). 1. アプリケーションサーバ. WebアプリケーションおよびREST APIを処理.参照と検索をサポート. 1. \"データに聞く(AskData)\". 1. バックグラウンダー => 抽出の更新,サブスクリプション,\"今すぐ実行\",tabcmdから実行するタスクなどを実行. 1. キャッシュサーバ => クラスタ全体でクエリと結果を分散/共有. アプリケーションサーバ,データサーバがリクエスト. 1. クラスタコントローラ => 各種コンポーネントの監視,障害検出,フェイルオーバーの実行. 1. データエンジン => データ抽出を作成.クエリを処理する. 1. データサーバ => データソースへの接続を管理する. 1. データソースプロパティ => 「データに聞く」等のクライアントサービスに,パブリッシュされたデータソースのメタデータを提供する. 1. ElasticServer => 「データに聞く」がデータをインデックスするために使用する. 1. ファイルストア => ローカル,SAN,NASなどストレージを抽象化する. 1. ゲートウェイ => ブラウザ, TableauDesktop,その他のクライアントから, TableauServerへの全ての要求を処理する. Webサーバ. 1. 内部データソースプロパティ => データソースプロパティとのみ通信する. 1. メッセージングサービス => TableauServerのマイクロサービス間の通信をサポート. 1. メトリクスサービス => メトリクスデータの読み書き. 1. リポジトリ => 実体はPostgreSQL. TableauServerのメインデータベース.ワークブックとユーザのメタデータを保存. Tableau Catalogが有効な場合,コンテンツと外部アセットのメタデータを保存. 1. SAMLサービス => TableauServerとSAML IdP間のプロキシ. 1. 検索と参照 => コンテンツのメタデータを高速に検索する.フィルター,取得,表示を処理する. 1. Tableau Prep Conductor => フローの実行,接続の認証資格情報の確認,フロー失敗時のアラート送出. 1. VizQLサーバ => ビューを読み込み,レンダリング,クエリを計算. 1. 一緒にデータエンジンもインストールするプロセス => アプリケーションサーバ,バックグラウンダー,データサーバ 1. Tableauマイクロサービスコンテナ. コンテナ内に複数のプロセス. 全部実行中=>running, 一部実行中=>degraded, 全て停止=>error,インタラクティブ,非インタラクティブの2種類. 1. TSMプロセス. TSMの初期化完了=>running. TableauServerが停止しても走り続ける. 1. 管理エージェント => 構成/トポトジの変更がないか調整サービスを監視する.新しい構成を各サービスに提供 1. 管理コントローラ => TSMへの要求を処理.構成とトポトジの変更,サービスプロセス全体のワークフローを調整. REST APIのエンドポイント(HTTPS) 1. クライアントファイルサービス => 複数のノード間で共有ファイル(認証関連の証明書,キー,OpenID,SAML,Kerberos等のファイル)を管理. 1. 調整サービス => 唯一の参照元.?? 1. サービスマネージャ => 不明 ?? 1. ライセンスマネージャ => ライセンスを扱う?? 1. メンテナンスプロセス. 通常stopped. ジョブ開始時にrunning,上部終了時にstopped. 1. データベースメンテナンス => TableauServerリポジトリの保守操作. 1. バックアップ/復元 => TableauServerリポジトリ, および, ファイルストアに保管されているデータのバックアップおよび復元操作. 1. サイトのインポート/エクスポート => クラスタ間でTableauServerを移行. 1. 分散環境と高可用性環境におけるプロセス 1. 本番環境の推奨は8コア以上. 1. バックグラウンダープロセスを専用のコンピュータで実行.(バックグラウンダーはCPUを大量に使用する) 1. VizQLとバックグラウンダーを分ける. 1. 抽出を頻繁におこなう可能性がある場合 => バックグラウンダーを増やす 1. ファイルストアと同じノードにあるデータエンジンはビューのクエリに使われる. バックグラウンダーが重いことでビュー操作がモタつくのを回避するため、ファイルプロセスとバックグラウンダーを分ける. 1. リポジトリ(pgsql)とファイルストアをファイルコントローラと同じノードに配置 => TableauServerのバックアップにかかる時間を短縮 1. フェイルオーバー 1. ファイルストア,リポジトリをフェイルオーバー対応させる=>最大3大のコンピュータが必要.1台は\"最初のノード\",2,3台は追加ノード. 1. 複数のゲートウェイ.3台のコンピュータ+ロードバランサ.ゲートウェイプロセスを全ノードにインストールしてロードバランサをゲートウェイに向ける.1ロードバランサx3ノード. 1. 高可用性 => 最初のノードの実行プロセスを少なく. 2,3台目を多く. 1. データソース 1. 接続情報を記録する.ライブか抽出か? 計算,セット,グループ,bin,パラメタ,カスタムフィールド. サーバの場所,認証資格,アクセストークン,セキュリティ情報... 1. なぜパブリッシュ(管理/共有)するのか? 各クライアント毎に似て非なる設定が増えるのを回避.サーバ側で抽出結果をサーバに残すアーキテクチャをとれる=>ネットワークトラフィックが減る. 1. サーバ側でコネクションを設定する. 例)MySQL. サーバ側にODBCドライバをインストールしてODBC経由でMySQLに接続する. 例)ファイル => Excelなど. 例)キューブ =>Oracle Essbase,Teradata OLAPなど 1. 抽出とライブ.抽出とはスナップショット.ライブとは都度取得.データソースに都度クエリを投げる.