はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

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シリーズその３。 第１回は「Digdag Serverのインストール手順」 第２回は「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シリーズその２。 前回は「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エンコードした文字列を

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

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

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

前回の「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/ 合計

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

-- -- 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 4 inserted 5 inserted \. ＜略＞ としてあげればOKです。 なお、pg_dumpの出力形式をデフォルトから変更した場合には、psqlでは読み込めないのでpg_

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

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Apache SparkをYARN上で動かしていて、気づいたことのメモ。 ディスク容量が非常に小さいサーバをスレーブにしていた時に、ある程度Sparkアプリケーションを実行していると、NodeManagerのUnhealthy化が起きたので調査しました。 NodeManagerのUnhealthyとは YARNでは、各スレーブサーバで動作しているNodeManagerは自身のサーバでYARNコンテナの動作に利用するディスク領域のチェックを定期的に実行しています。パーミッションが適切か、ディスクの空き容量が十分余っているかを確認しており、デフォルトでは90%以上容量を使ってしまっていると、UNHEALTHYという状態であることをResourceManagerに通知し、新しいYARNコンテナの割り当てがされないようにします。 このあたりの仕様はHadoopのドキュメントに書いてあります。 ht

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

話題の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)からです。このトランザクションログは人間で読める形では保存さ