サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
夏の料理
qiita.com/bwtakacy
これで、Pythonの実行環境や関連ライブラリもまとめて1つのexeファイルにまとめてくれる。 ただし、PyInstallerが解決できない依存関係があったりすると、作ったexeファイルがエラーを吐く。 その場合は、--onefileオプションを使わずにビルドして、以下の2点を1つずつ解消していくとよい。 Pyinstallerでうまくexe化できないとき *.so not found が出る 依存している外部ライブラリのバイナリを取り込めていない。直接参照しているものはPyInstallerが自動で取り込んでくれるようだが、間接的に参照しているものは考慮してくれない様子。 --add-binary オプションで明示的に取り込むように指定すればよい。 Pathの指定の仕方が特殊なので注意 パスの指定の仕方が正しく記述できているはずなのにうまく配置されない キャッシュが残っていて悪さをしてい
配列 -> レコード 配列が入っているカラムをそれぞれ別レコードに変換したい 例えばtblテーブルのtime_rangesカラムに以下のような配列が入っているとする。 ["16:00~16:30","16:30~17:00","17:00~17:30","17:30~18:00","18:00~18:30","18:30~19:00","19:00~19:30","19:30~20:00","20:00~20:30","20:30~21:00","21:00~21:30"]
rdsdb=> CREATE DATABASE testdb WITH OWNER test; CREATE DATABASE rdsdb=> \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+-------------+----------+-------------+-------------+----------------------------- postgres | bwtakacyaws | UTF8 | en_US.UTF-8 | en_US.UTF-8 | rdsadmin | rdsadmin | UTF8 | en_US.UTF-8 | en_US.UTF-8 | rdsadmin=CTc/rdsadmin rdsdb | bwt
Amazonの音声アシスタントAmazon Echo、すっごい欲しいのですが日本では技適が通っておらず、輸入できないらしい。 会社内で詳しい人に「でも欲しいっすね〜」と聞いたら、「自作する手がある」という答えをいただいたのでやっちゃいました。 Amazon EchoとAVSとRaspberry Pi AVS(Alexa Voice Service)というAmazon Echoの裏側で動作している人工知能技術を利用した音声認識、自然言語サービスがあり、開発者向けという制限の下に、マイクとスピーカを接続したデバイスで動作させることができます。 また、サンプルアプリが公開されていて、以下のプラットフォームで動作させることができるようです。 Raspberry Pi Linux Mac Windows Raspberry Pi + Conexant 2-Mic Development Kit fo
Digdagシリーズその3。 第1回は「Digdag Serverのインストール手順」 第2回は「DigdagのSecret機能を使う」 Digdagでワークフローを書いた際にやりたくなるのが、成功・失敗の通知です。そのやり方を試行錯誤した結果をまとめます。 Digdagでのワークフロー定義 まずはおさらい。 Digdagではタスクと呼ばれる処理の単位をつなげてワークフローを定義することができます。 例えば、シェル実行、pythonスクリプト実行、Rubyスクリプト実行のタスクを順番に実行するワークフロー定義は、こんな感じで書けます。 timezone: UTC +step1: sh>: tasks/shell_sample.sh +step2: py>: tasks.MyWorkflow.step2 param1: this is param1 +step3: rb>: MyWorkfl
Digdagシリーズその2。 前回は「Digdag Serverのインストール手順」 DigdagにはDBの接続パスワードやWebサービスのAPI Keyなどの情報をセキュアに扱う機能としてsecretというものがある。これを使うと、パスワードなどの情報が平文でワークフロー定義ファイルに書く必要がなくなるし、ログに平文で出力されることもなくなる。 Digdag Secret機能を有効化する。 デフォルトでは無効になっている。 有効にするには、設定ファイルに digdag.secret-access-policy-file : operatorごとのsecretへのアクセスポリシーを定義したファイル digdag.secret-encryption-key: secretをDigdag ServerがDBに保存する時に暗号化するキー。128bitのAES鍵をBASE64エンコードした文字列を
Digdag Serverをインストールする手順をまとめる。 環境は、 CentOS 7.2 OpenJDK 1.8.0_111 Digdag Serverとは Digdag Serverは以下の機能を持っている。 REST API server:クライアントとの応答を行う Task Agent:ワークフローの各タスク実行を行う Workflow executor:ワークフローの実行管理を行う Schedule executor:ワークフローのスケジュール管理を行う REST API server以外は機能を起動させないことも可能。 Digdagのダウンロード $ curl -o /usr/local/bin/digdag --create-dirs -L "https://dl.digdag.io/digdag-latest" $ chmod +x /usr/local/bin/digd
PostgreSQL JDBC Driverを使ってクエリを投げる際に過去にハマった点をメモしておきます。 PreparedStatementの性能傾向が変わる? PreparedStatementオブジェクトを作ってクエリを繰り返し実行していると、ある時点から急にクエリ性能が良くなる場合があります。 これは、PostgreSQL JDBC Driverの仕様で、一定回数以上同じPreparedStatementオブジェクトでクエリ実行を繰り返すと、PostgreSQLサーバ側にクエリがキャッシュされてさらに高速化されるためです。 つまり、PostgreSQL JDBC Driverを使っている場合、PreparedStatementによるクエリ実行の最適化には2段階あって クライアント側の最適化 クライアント側 + PostgreSQLサーバ側の最適化 となっています。 特に、Postg
fdisk -l Disk /dev/sda: 10.7 GB, 10737418240 bytes, 20971520 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト Disk label type: dos ディスク識別子: 0x000c8887 デバイス ブート 始点 終点 ブロック Id システム /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 20971519 9972736 8e Linux LVM Disk /dev/sdb: 8589 MB, 8589934592 bytes, 1
AnsibleでPostgreSQLをインストールする手順も調べたのでメモしておく。前回のPuppetでのPostgreSQLインストール方法の姉妹編である。 環境は * CentOS 7.2 * Ansible 2.0.2.0 Ansibleのインストール Pythonの2.6 or 2.7が必要らしい。
GitHubでPull Requestを綺麗にマージする方法を知ったので試してみたときのメモ。 背景と問題意識 今まで「Merge pull request」ボタンを押してたけど、コミットログ上で「Merge pull request...」というコミットが入ってしまうのが気になっていた。 このやり方だと、それが起きないのでコミットログが綺麗になるし、送られたパッチをまとめたり修正を追加したりも自由にできるので、いいことづくし。 PRのコミットをローカルに取り込む GitHub上のPRのURLを調べて、末尾に.patchをつけたURLを使って以下のコマンドを実行する。
Cloudera Engineering BlogにてCDH5.5にDistCpの高速化が実装されたと紹介されていたので、試してみました。 リンク先の説明を読んだ限り、2つのHDFS Snapshot間の差分情報を使って 削除・名前変更はDistCpを使わずに反映 新規作成・変更されたファイルだけをDistCpで同期 することで、高速化を図っているようです。 試した環境は、 CentOS: 7.2 (64bit) CDH 5.7.0 (擬似分散) です。 HDFSの準備 今回は、 同期元ディレクトリ:/user/hadoop/source 同期先ディレクトリ:/user/hadoop/target という状況とします。 [hadoop@localhost ~]$ hdfs dfs -mkdir source [hadoop@localhost ~]$ hdfs dfs -mkdir tar
前回の「Kerberosインストール手順」の続き。 当初の目的であるHadoopのKerberos化を行う手順を整理する。 Hadoopのインストール 過去記事参照。 今回利用するのはCDH5.6.0。 JCE Policyのインストール AES暗号化をJavaから利用するために、Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy FilesをOracleからダウンロードしてインストールする。 インストール方法は添付のREADME.txtに従う。 # cd UnlimitedJCEPolicyJDK8-2/ # ls README.txt US_export_policy.jar local_policy.jar # ll /usr/java/latest/jre/lib/security/ 合計
HadoopをKerberos化するために頑張った手順。まずはKerberosのインストール編。 環境 CentOS 7.2 準備 ドメイン名の設定 nmcliを使って、ドメイン名を設定します。今回はKerberosのレルムをEXAMPLE.COMにするので、それの小文字版にします。 # nmcli c modify enp0s3 ipv4.dns-search example.com # systemctl restart NetworkManager # cat /etc/resolv.conf # Generated by NetworkManager search example.com nameserver 220.152.38.233 nameserver 220.152.38.201
として出力結果をパイプでファイルに書き出します。 ファイルの中身を見てみると、以下のような形でその時のデータベースの状態がSQLを使って再現できるような情報として記録されています。 -- -- PostgreSQL database dump -- <略> -- -- Name: foo; Type: TABLE; Schema: public; Owner: postgres; Tablespace: -- CREATE TABLE foo ( a integer NOT NULL, b text ); <略> -- -- Data for Name: foo; Type: TABLE DATA; Schema: public; Owner: postgres -- COPY foo (a, b) FROM stdin; 1 inserted 2 inserted 3 inserted
pg_rewindとは Streaming Replicationを使ってマスタ-スタンバイ構成のPostgreSQLを運用している場合、フェイルオーバやスイッチオーバが発生してマスタが切り替わった後に、古いマスタを再度組み込む際に役立つコマンドです。 百聞は一見に如かず。 レッツトライ。 Streaming Replication構成の作成 1号機の設定 postgresql.confに以下を記載します。 pg_rewindのためにwal_log_hintsを有効にしておきます。データチェックサム有効で代用できるみたいですが今回はこれで。 listen_addresses = '*' wal_level = hot_standby max_wal_senders = 3 wal_keep_segments = 30 max_replication_slots = 3 hot_standb
この記事は PostgreSQL Advent Calendar 2015 - Qiita の9日目です。 8日目は osapon さんに書いていただきました。 この記事では、PostgreSQLを運用する上で役立つかもしれないツールの一つ pg_repack を紹介したいと思います。 pg_repackとは pg_repack はPostgreSQLの拡張ツール(エクステンション)の一つで、肥大化したテーブルやインデックスを再編成し、さらに指定したインデックスにしたがってレコードを並び替えることができます。 PostgreSQLの CLUSTER や VACUUM FULL コマンドと違って、pg_repackは処理の間対象テーブルへの排他ロックを保持し続けないため、オンライン中に動作させることができます。 どういうことなのか、説明していきますね。 テーブルやインデックスの肥大化 Pos
最近になって、ようやく手元の環境をCentOS 6系からCentOS 7系に移行しています。 ファイルシステムのデフォルトがext4からxfsになったとか、systemdとか色々と大きな変更点がありますが、自分が普段からよく使っているコマンドで結構な変更がされていて少し戸惑ったのでメモ。 プロセスのPID確認にpgrepコマンドを多用していました。 pgrep -fl postgres $ pgrep -fl postgres 22727 su - postgres 22760 /usr/local/pgsql/9.5dev/bin/postgres 22761 postgres: logger process 22763 postgres: checkpointer process 22764 postgres: writer process 22765 postgres: wal wr
PostgreSQLのエラーレベルはメッセージごとに固定だと長らく勘違いしていた話。 マスタ接続失敗時のエラー Streaming Replication構成でスタンバイから以下のようなメッセージがログに出力されていました。 FATAL: could not connect to the primary server: could not connect to server: No route to host このメッセージが出たときにはマスタを落としていたので、メッセージが出ること自体は問題ではないですが、接続失敗でFATALになることがやや気になったので、調査しました。 ソースコード上だとFATALではなくERROR ? メッセージでgrepすると、出力している場所は特定できました。
Apache SparkをYARN上で動かしていて、気づいたことのメモ。 ディスク容量が非常に小さいサーバをスレーブにしていた時に、ある程度Sparkアプリケーションを実行していると、NodeManagerのUnhealthy化が起きたので調査しました。 NodeManagerのUnhealthyとは YARNでは、各スレーブサーバで動作しているNodeManagerは自身のサーバでYARNコンテナの動作に利用するディスク領域のチェックを定期的に実行しています。パーミッションが適切か、ディスクの空き容量が十分余っているかを確認しており、デフォルトでは90%以上容量を使ってしまっていると、UNHEALTHYという状態であることをResourceManagerに通知し、新しいYARNコンテナの割り当てがされないようにします。 このあたりの仕様はHadoopのドキュメントに書いてあります。 ht
embulk使ってみました。そして、速さを求めてpg_bulkloadとの組み合わせにトライしてみました。 使ったバージョンは embulk : 0.7.5 PostgreSQL : 9.5alpha2 embulkのインストール 公式ドキュメント通りにコマンドを叩けばOKです。 PostgreSQL出力用プラグイン 以下のコマンドでインストールします。
hadoop 2.7.1をソースコードからビルドするための手順メモです。環境はCentOS7(64bit)です。 JDK インストール OracleのサイトからJDKのインストール用RPMをダウンロードしてきます。それを適当な場所においてrpmコマンドでインストールします。 # rpm -ivh jdk-8u51-linux-x64.rpm 準備しています... ################################# [100%] 更新中 / インストール中... 1:jdk1.8.0_51-2000:1.8.0_51-fcs ################################# [100%] Unpacking JAR files... rt.jar... jsse.jar... charsets.jar... tools.jar... localedata.j
話題のApache Sparkでこんなことも出来るという話。Sparkのマニュアルを読んでいて見つけたので、試してみました。試した環境は CentOS 7.1 Apache Spark 1.4.1 PostgreSQL 9.4.4 です。 Apache Spark Sparkの説明は割愛。 高速な分散処理基盤であるApache SparkはHadoopやCassandraといったデータストアだけでなく、RDBMSに格納されたデータを取り出して処理することもできます。 なので、既存のデータを移行せずにSparkの高速処理の恩恵を受けることが出来ます。 PostgreSQLのテーブルをSparkにロード JDBC接続を利用するので、PostgreSQLのJDBC Driverが必要です。 今回はお手軽にspark-shellで操作することにして、
さて、前回の続きです。 前回はPostgreSQLのバックアップ手法を紹介・比較しました。 前回述べなかったのですが、物理バックアップには大きな利点があります。それは、データベースのバックアップとWALファイルのバックアップを組み合わせることで、リカバリする時点を自由にコントロールできるという点です。 リカバリの違い 論理バックアップは特定の時点のデータをSQLの形で抜き出してくる方法でした。そのため、論理バックアップからデータを復旧した場合、バックアップを取得した時点のデータの状態に戻ります。当たり前ですね。 一方、物理バックアップはデータベースの実体のファイル自体をバックアップするものでした。オンライン・バックアップを行った場合は、これだけだとバックアップ中の変更が把握できないので、バックアップ中に発生したWALファイルから変更情報を読みだして反映することで、バックアップが完了した時点
PostgreSQL 9.4から実装されているLogical Decodingについて調査した結果をまとめます。 個人的にかなりアツい機能なのですが、ネット上に日本語の情報がほとんどない?ので紹介も兼ねています。 Logical Decodingとは PostgreSQLに対して実施された変更を横から抽出するための機能です。 将来的に、 論理レプリケーション:特定データベース、特定テーブルのみレプリケーションetc. PostgreSQLサーバ間で更新を伝播しあうことで、マルチマスタなDBサーバクラスタを実現 PostgreSQLから更新差分を引き出して、他業務のDBやHadoopなどに効率的にデータ連携 といった進化をしていくと期待されています。 変更情報を抜き出してくるのは、PostgreSQLのトランザクションログ(WAL)からです。このトランザクションログは人間で読める形では保存さ
このページを最初にブックマークしてみませんか?
『qiita.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く