Amazon Web Services ブログ

Category: Database

PostgreSQL 12 – いくつかの新機能のご紹介

 PostgreSQL コミュニティは毎年、PostgreSQL 12 のメジャーリリースを一貫して続けています。PostgreSQL 12 は、JSON データをクエリする新しい方法、インデックスの拡張、パーティション化されたテーブルでのパフォーマンスの向上などの機能を導入し、すでに堅牢な機能の管理を簡素化しながら、新たに開発する機会を設けています。 この記事では、PostgreSQL 12 の素晴らしい新機能のいくつかを詳しく見ていきます。それらを既存の開発および運用プラクティスに組み込む方法を探っていきます。これらの機能の一部は透過的で、PostgreSQL 12 にアップグレードするだけでご利用いただけます。他の部分については、ご利用いただくには既存のアプリケーションまたはプロセスへの変更を加えていただく必要があります。これらの新機能の利点を取り上げ、さらにこのような機能を既存のアプリケーションに適応させる方法の例をご紹介します。 インデックスの改善 PostgreSQL のデフォルトのインデックスタイプは B ツリーです。B ツリーインデックスは、ほとんどのタイプのデータをプライマリキーである整数から E メールアドレスである文字列へインデックスを付けるために使用します。テーブルが大きくなると、対応するインデックスも大きくなります。B ツリーインデックスが大きくなると、データ構造のバランスを保つ必要があります。そうすることで、特定のリーフページがいっぱいになったときにページが必ず分割されるようにします。ほとんどの場合、PostgreSQL はこれらのページを中央で分割することで、新しく分割された各ページに同じ量のデータと空き領域ができるようにします。テーブルに追加されるデータがややランダムである場合は、中央で分割するのが理想的です。ただし、データに重複するインデックスエントリが多数ある場合は、途中で分割すると大量の空き領域が未使用になる可能性があります。PostgreSQL 12 は、B ツリーインデックスページを分割するロジックを変更して、重複するインデックスエントリのコンテキストを使用し、いくつかの圧縮技術を用いています。これらを改善することで、インデックスのデータに応じて、一部の B ツリーインデックスが PostgreSQL 12 で 40% も小さくなる可能性があります。 古いバージョンの PostgreSQL からアップグレードされたデータベースは、古い B ツリー形式のままです。新しい B ツリー形式を利用するには、PostgreSQL 12 でインデックスを作成する必要があります。PostgreSQL には、指定されたテーブルのすべてのインデックスを再構築する REINDEX コマンドがありますが、REINDEX コマンドは、多くの本番環境で禁止ロックを取得します。 postgres=# REINDEX TABLE events; postgres=# SELECT locktype, transactionid, mode, […]

Read More

Amazon RDS for PostgreSQL のバージョン 9.4 から移行する

歴史的にPostgreSQL コニュニティーでは、年に一度メジャーバージョンをリリースし、それをもって古いメジャーバージョンのエンドオブライフ (EOL) とするポリシーです。これにより、バージョンとアップデートがいつ行われたのか、将来的にも日付で良く分かるようになっています。コミュニティーのこの EOL ポリシーは、メジャーバージョンをその初期リリースから 5 年間サポートするのが目的です。5 年後には、メジャーバージョンは不具合修正を含むマイナーバージョンを 1 つリリースしてから EOL と扱われ、その後はサポートされなくなります。PostgreSQL のすべてのバージョンの最終リリース日は、コミュニティーの Web サイトで見ることができます。直近では、メジャーバージョン 9.4 が 2020 年 2 月 13 日に EOL に達しました。 何が起こるのか PostgreSQL コミュニティーからの追加不具合修正、特にセキュリティに関連する修正が行われなくなります。すべての PostgreSQL 9.4 インスタンスをアップグレードするには、今がちょうど良い機会です。2020 年 2 月 15 日に Amazon Relational Database Service (RDS) はコンソールからの PostgreSQL 9.4 インスタンスの新規作成サポートを 停止したため、PostgreSQL の新しいバージョンを使った方が良いでしょう。既存の PostgreSQL 9.4 スナップショットからのリストアと、9.4 インスタンスのリードレプリカ作成は、2020 年 4 月 […]

Read More

Amazon DynamoDB への CSV 一括取り込みの実装

この記事は、Amazon DynamoDB へのデータの取り込みに今日どのようなソリューションが存在するかを再検討するとともに、Amazon S3 バケットから DynamoDB テーブルへの CSV ファイルの一括取り込みのための能率化されたソリューションについて説明して、AWS アカウントへの簡単なデプロイメントのために、このソリューションの AWS CloudFormation テンプレートを提供します。 Amazon DynamoDB は、規模を問わず 1 桁台のミリ秒でのパフォーマンスを実現する key-value /ドキュメントデータベースです。今日、AWS の何十万人ものお客様が、モバイル、ウェブ、ゲーミング、アドテクノロジー、IoT、および低レイテンシーのデータアクセスを必要とするその他アプリケーションのために DynamoDB の使用を選択しておられます。一般的なユースケースは、DynamoDB へのデータの一括取り込みの実装です。大抵の場合、このデータは CSV 形式であり、すでに Amazon S3 内に保存されている場合があります。この一括取り込みは移行取り組みを迅速化するための鍵であり、取り込みのパイプラインジョブを設定する必要性を軽減し、全体的なコストを削減して、Amazon S3 からのデータの取り込みをシンプル化します。 この記事では、DynamoDB に加えて、ソリューションを作成するために AWS の以下のサービスを 200~300 レベルで使用します。 Amazon S3 AWS Lambda AWS CloudFormation 前提条件 この記事のソリューションを完成させるには、以下が必要です。 AWS アカウント。 DynamoDB、Amazon S3、Lambda、および AWS CloudFormation にアクセスできる IAM ユーザー。 DynamoDB […]

Read More

AWSも提言を行った、農水省DX室の「デジタル地図」構想がプレスリリースに至りました

農林水産省(以下「農水省」)様より、”「デジタル地図」を活用した農地情報の管理に関する検討会』取りまとめ” が公開されました(2020年3月下旬公開、以下「取りまとめ」)。2019年秋以降、本検討会へはAWSメンバーも参加して各種の提言を行って参りました。以下、AWSパブリックセクターより、本「取りまとめ」の意義や要点を解説しながら、農林水産政策分野やデジタル地図に関連するAWSのサービスや事例をご紹介させていただきます。   ❖「デジタル地図」検討会設置の目的 農水省では、現状の”農地情報は各施策の実施機関ごとに個別に収集・管理されている”こと、つまりは情報が散在していることに起因し、 1)農業者は、同様の情報でも実施機関ごとに個別に申告、 2)実施機関ごとに、農地情報を独立したデータベースで管理、 3)現地確認も実施機関ごとに実施しているため、情報の整合性を保つための突合作業等は大きな負担となっており、また、整合性が取れていないケースもあるといった状態 ────といった問題があることを特定しました。 これらの問題意識から出発し、農水省DX室は今回の「デジタル地図」を活用した農地情報の管理に関する検討会の設置を決め、約半年間に渡り活動を重ねてきました。この、先進技術と政策の融合を目指した取り組みに関しては、「農地情報をデジタル地図に 農水省が一元化」と題して日経新聞など各種メディアでも報じられていたところです。 検討会での主な論点となったのは、「農地情報の一元的な管理を可能とする技術的環境が整備されつつある」なか、いかにして「農地情報の正確性と整合性を確保しつつ、農業者や実施機関等の関係者の負担軽減を図ることができる」か──という点です。特に、「幅51cmもの、農地転用に関する分厚い書類」「2,136時間&57,300枚が、経営所得安定対策の申請受付等に費やされる」「7,200経営体が22,000筆のデータを個別にPDF化し打ち込み」といった全国の農業関係者が直面する困難がデータポイントで列記される「第2章 現状と課題」は圧巻です。 これらの負担を先端技術により解決することを目指した本検討会においては、クラウドを活用することで高水準で実現することができる”拡張性”・”信頼性”・”柔軟性”・”堅牢性”・”可用性” 等の観点から整理をいただき、”システムの構築・運用に当たっての原則”として記載をいただいております。詳しくは、「取りまとめ」の“第5章 デジタル地図のシステム要件”をご参照ください。 (参考) ↓:「取りまとめ」文書中の、システムの構築・運用の原則 こうした方向性のもと取りまとめられた今回の農水省DX室のイニシアティブが、以下サイトにてプレスリリースされました: ”「デジタル地図」を活用した農地情報の管理に関する検討会』取りまとめについて”   ❖ AWSからの提言:クラウドが「デジタル地図」の有効活用を加速する 農水省の「取りまとめ」には、幾つもの政策的・技術的に踏み込んだ内容が記載されており、以下のとおりAWSからの提言と合致する論点も盛り込まれています: オンプレからクラウドへの転換:「従来のオンプレミス[・・中略・・]では、限られたネットワーク内でしかGIS[注:地理情報システム]上の地図情報の閲覧、編集ができなかったが、クラウドベースのGISを活用することにより、インターネット接続による地図情報の閲覧、編集が格段と容易になる」との記載にて、クラウドベースでの技術のメリットを明記いただいています。 ”地図”に関連し、DX室にも紹介させていただいた、高精度地図データ配信にAWSの機械学習モデルを活用した株式会社ゼンリンデータコム様の事例に関しては、こちらをご覧ください。 拡張性の高いデータベース:「データベース管理については、将来的なデータ項目の追加や、レコード数やアクセス数の増大等によるアクセス速度の低下防止に対応できるようにすることが重要であるが、データ項目の柔軟な加除やシステムの高速化を可能とするNoSQL等の新しいデータベース管理手法も活用可能となってきている」との記載にて、新型のDBMS採用を模索する方向性を明記いただいています。NoSQLデータベースを含む、AWSのデータベースサービスの全容に関してはこちらをご参照ください。 超大規模データのオープン化:「国や地方自治体において、様々なデータをリアルタイムで集約し、データに基づいた多元的な分析を行うことで、農業施策に反映させることで、課題の的確な把握・対応を可能とする。また、集約されたデータをオープン化することで、研究機関等による多様なデータ分析に基づいた政策提言を容易にする」との記載にて、オープンデータ化の方向性を明記いただいています。オープンデータを加速するAWSの取り組みに関してはこちらをご覧ください。特に、公的機関向けにストレージ費用をAWSが負担する「AWS Public Dataset Program」は現在、「衛星画像」「地理情報」「気候」等のカテゴリーを設け、NOAA(アメリカ海洋大気庁)等が収集した、合計で120を超えるDatasetを公開しております(2020年3月現在)。 パブリッククラウドとLGWANとの接続:「地方自治体においては関係業務がLGWAN環境で行われる一方、現場におけるインターネット環境でのタブレット等による農地情報の閲覧、編集のニーズがあることを踏まえ、LGWANとインターネットのハイブリッド方式を採用」「LGWANとパブリッククラウドの接続のあり方に関しては現在総務省において検討が進んでおり、その結果を踏まえ、必要な検討を行う」との記載にて、農業関係者皆様にとっての高い利便性確保のための整理が待たれる旨、明記いただいています。 AWSは、クラウドが次世代の農業をサステナブルかつ、魅力的な産業へと進化させていくことに強くコミットしています。自身も農業の盛んな米国ケンタッキー州の出身であると回顧することから始まるテレサ・カールソン(AWS Worldwide パブリックセクターのバイスプレジデント)のブログも併せてご参照ください:”Mission: Technology-enabled, sustainable agriculture”。   ❖ 提言させていただいたAWSのサービス 今回の農水省の検討会では、以下のAWSサービスが特に「デジタル地図」の構想と親和性が高いものと判断し、提言に盛り込ませていただきました。 データレイク構築の要となる“Amazon S3(Simple Storage Service)”:様々なデータを分析し正しい意思決定を行うためには、規模にかかわらず、全ての構造化データと非構造化データを長期間、安全に保存することが可能な「データレイク」を構築する必要があります。Amazon S3を活用いただくことが、圧倒的低コストでのデータレイク構築のための近道です。 軌道衛星からのデータを受信する “AWS Ground Station”:天気予報、地表画像撮影、通信、放送など軌道衛星からのデータを、独自の地上基地局を管理することなくご活用いただけます。AWS Grand Stationで受信されたデータは、AWSグローバルインフラストラクチャ(世界規模の低遅延ファイバーネットワーク)を経由し、Amazon S3等へ蓄積し利活用が可能です。 Amazon DynamoDBなど多種多様なデータベース:データ処理を高速、低コストで実現するためには、アプリケーションや利用ユースケースに最適なデータベースを無理なく選択する必要があります。AWSが提供しているデータベースは、一般的な利用ユースケースをほぼ網羅するデータベースが7分類あり、AWS上で簡単に相互連携することで、高速、低コストなデータ処理を実現可能です。 ”Amazon […]

Read More

GTID ベースのレプリケーションを使用したフォールバックオプションで Amazon Aurora MySQL へ移行する

本番アプリケーションを移行する場合、多くの場合、フォールバックオプションを備えていることが重要です。このブログ記事では、グローバルトランザクション識別子 (GTID) ベースのレプリケーションを使用して、Amazon RDS MySQL ワークロードを Amazon Aurora MySQL に移行する方法を説明します。また、問題が発生した場合にフォールバックメカニズムを使用する方法についても説明します。 GTID ベースのレプリケーションの詳細については、「Amazon Aurora for MySQL 互換エディションでグローバルトランザクション 識別子 (GTID) によるレプリケーションがサポートされるようになりました」をご覧ください。 この記事では、レプリケーショントポロジには、2 つのリードレプリカ (RDS MySQL リードレプリカと Aurora MySQL レプリカ) を持つマスター RDS MySQL インスタンスがあります。移行中に問題が発生した場合のフォールバックインスタンスとして RDS MySQL リードレプリカを使用し、元の RDS MySQL マスターが影響を受けないようにします。ただし、元の RDS MySQL マスターインスタンスをフォールバックオプションとして使用することもできます。移行が成功すると、Aurora MySQL レプリカが RDS MySQL レプリカインスタンスのマスターインスタンスになります。 GTID ベースのレプリケーションを使用する主な利点は、すべてのトランザクションに一意の識別子を割り当てられ、レプリケーショントポロジ内の各 MySQL サーバーがすでに実行したトランザクションを追跡できることにあります。GTID ベースのレプリケーションはトランザクションベースであるため、マスターとレプリカ間のデータの一貫性を簡単に判断できます。マスターでコミットされたすべてのトランザクションがレプリカにもコミットされている場合、2 つの間に一貫性があります。これにより、auto-positioning が可能になります。これは、binlog ファイルの名前または位置を指定することなく、レプリカがマスターインスタンスをポイントする機能です。 前提条件 このチュートリアルを実行するには、次の前提条件を満たしている必要があります。 […]

Read More

Amazon Redshift マテリアライズドビューを使用して AXS で Etleap モデルを高速化する

Amazon Redshift のマテリアライズドビュー機能は現在一般公開されており、2019 年 12 月からプレビュー中のお客様およびパートナーにメリットをもたらしてきました。当社のお客様の AXS は、米国、英国、欧州、および日本のライブエンターテインメント会場向けのチケット販売、データ、およびマーケティングの分野における主要なソリューションプロバイダーです。Amazon Redshift パートナーである Etleap は、AWS 用に構築された抽出、変換、ロード、および変換 (ETLT) のサービスです。AXS は Etleap を使用して、ファイルサーバー、Amazon S3、リレーショナルデータベース、アプリケーションなどのさまざまなソースから Amazon Redshift にデータを取り込みます。これらの取り込みパイプラインは、適切な列タイプおよび並べ替えキーと分散キーを使用して、データを分析および構造化し、Amazon Redshift テーブルにロードします。 Etleap モデルでダッシュボードのパフォーマンスを改善する データを分析するために、AXS は通常、複数のソースから発生する大きなテーブルに対してクエリを実行します。AXS による Amazon Redshift の使用形態の 1 つとして、インタラクティブなダッシュボードを強化することを挙げることができます。ダッシュボードのロード時間を短縮するために、AXS は、ダッシュボードが使用するクエリに対する部分的な回答を事前にコンピューティングします。これらの部分的な回答は、行数の点において、当該回答が基づくテーブルよりも数桁小さくなります。ダッシュボードは、事前にコンピューティングされた部分的な回答を保持する Amazon Redshift テーブルをクエリすることによって、ベーステーブルを直接クエリする場合よりもはるかに高速にロードできます。 Etleap は、models と呼ばれる機能を通じて、このような事前コンピューティングの作成と管理をサポートしています。モデルは、SELECT クエリと更新時期のトリガーで構成されます。トリガーの例は、ベーステーブル、つまりモデルを定義する SELECT ステートメントが使用するテーブルへの変更です。このようにして、モデルはベーステーブルとの一貫性を保つことができます。 次のスクリーンショットは、2 つのベーステーブルの依存関係を持つ Etleap モデルを示しています。 Etleap は、モデルを Amazon Redshift のテーブルとして表します。モデルテーブルを作成するために、Etleap は、CREATE TABLE […]

Read More

Amazon DocumentDB (MongoDB 互換) で $dateFromString と executionStats を使用する

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージドのドキュメントデータベースサービスです。Amazon DocumentDB では、JSON データの保存、クエリ、およびインデックスの作成を簡単かつ直感的に行うことができます。Amazon DocumentDB を初めて使用する場合は、「Amazon DocumentDB (MongoDB 互換) でのランプアップ」をご覧ください。 Amazon DocumentDB では、MongoDB との互換性の改善を続けています。このブログを執筆している時点で、Amazon DocumentDB には 2 つの新機能を新たにサポートしています。 $dateFromString は、ドキュメントに対して強力な集計を作成できる集計パイプライン演算子です executionStats モード (explain() 用) は、クエリプラン内の各ステージの詳細な実行統計を提供します。 Amazon DocumentDB のサポートされている MongoDB API と集計パイプライン機能の詳細については、「サポートされている MongoDB API、オペレーション、およびデータ型」をご参照ください。 この投稿では、$dateFromString と executionStats のユースケースについて解説し、サンプルコードを介してこれらの新機能の使用方法をご紹介します。 $dateFromString $dateFromString 集計パイプライン演算子は、文字列形式の日付を DATE データ型に変換できます。$dateFromString は $dateToString の逆演算子です。 $dateFromString のしくみを理解するために、この投稿では、ビデオゲーム内で発生したイベントの日時を記録するサンプルデータセットを使用しています。ビデオゲームはイベントを文字列として記録しますが、アプリケーションはイベントフィールドを DATE データ型として分析できる必要があります。文字列から日付への変換を実行するには、$dateToString 集計演算子を使用します。 […]

Read More

Amazon Neptune を使った投資相関性のグラフ表示

Amazon Neptune を使い投資相関性のグラフを保存しクエリすると、新たな視野で関連性を分析できます。EDGAR (Electronic Data Gathering Analysis and Retrieval) は、米国証券取引委員会 (SEC) が提供するパブリックなオンラインデータベースです。この EDGAR は、法律により SEC への書類提出が義務付けられた法人向けに、データ収集、評価、インデックス付、受理、書類転送などを自動で処理するものです。これらの法人には、登録投資アドバイザー、銀行、保険会社、ヘッジファンドなどや、これらの顧客向けに投資を裁量するその他のグループなど、投資管理を行う企業が含まれます。 こういった関連の書類には、次に挙げるような多種のデータナゲットが記載されます。 その債権を公共で販売したことのある、株式会社や事業に関するデータ。 以下を含む役員報酬: その企業の年ごとの委任勧誘状。 その企業のフォーム 10-K 年次報告書。 その企業が有価証券を公開で販売するために提出した有価証券発行届出書。 米国内で、1 億 USD 以上の試算を長期にわたり保有および管理している企業内の投資マネージャーからの、投資ポジションレベルに関する公開書類。このマネージャーが保持するポートフォリオ内にある、すべての米国内公開済みの株式有価証券を含み、保有率、対象企業の符丁 (ティッカーシンボル)、株式発行者名などを詳細に記載する。 これらのデータナゲットは、各事業体からの提出ごとに、個別な事象として保持されます。ただ、EDGAR では、これらすべてのイベントを 1 つに結び付け、関連性やパターンを表示することはできません。 今回の記事では、EDGAR からの資料を Neptune 内で結合および処理し、その関連性を明らかにしながら、他のイベントでも繰り返し利用可能なモデルを作成するための方法をご紹介します。 データベースオプション 現代の技術者には、データ処理に関する多くの選択肢が与えられています。次の表に、一般的なデータカテゴリーとユースケースのいくつかを示します。 リレーショナル キーと値 ドキュメント インメモリー グラフ 時系列 参照整合性 高スループット 任意の属性での、ドキュメント保存と高速アクセスによるクエリ ミリ秒のレイテンシーでのキーによるクエリ 各データの関連性の素早く簡単な生成とその間の移動 時間的に連続したデータの収集、保存、および処理 ACID トランザクション 低レイテンシー 読み出しと書き込み […]

Read More

Bucardo を使用して従来の PostgreSQL データベースを Amazon RDS または Aurora PostgreSQL に移行する

 9.4 より前の PostgreSQL を使用している場合、サポートされていない PostgreSQL バージョンを使用していることになります。Amazon RDS または Amazon Aurora PostgreSQL でデータベースを移行または複製するためのオプションが制限されている場合があります。これは主に、9.4 よりも古いバージョンの PostgreSQL では論理複製を実行できないのが原因です。 Bucardo は、データの変更を非同期で複数のセカンダリまたは複数のマスターに複製できるオープンソースユーティリティです。これはトリガーベースのレプリケーションであり、より広範囲の移行や継続的なレプリケーションに対して一貫性と安定性が実証されています。Bucardo は、プライマリキーなしでテーブルの全ロードを実行できます。ただし、デルタデータの変更をプライマリから複製するには、セットアップを開始する前にプライマリキーを作成します。 この記事では、Bucardo をセットアップし、PostgreSQL 8.4 から PostgreSQL 9.6 にデータ変更を複製する方法を示しています。 前提条件 開始する前に、次のものが必要です。 Bucardo 用 Ubuntu 16.04 を使用する 1 つの EC2 インスタンス (Bucardo サーバー: 172.31.88.4) PostgreSQL 8.4.2 で RHEL 6 を使用する 1 つの EC2 インスタンス (PostgreSQL 8.4.2: 172.31.16.177) us-east-1 に […]

Read More

新しい AWS 認定で、AWS 専用データベースの専門知識を確認する

 本日、新しい AWS 認定データベース – 専門認定を発表します。これは、パフォーマンスの向上、コストの削減、革新を可能にする最適な AWS データベースソリューションを推奨、設計、保守することに関する個人の専門知識を確認するものです。この認定は、AWS 専用データベースの技術スキルを確認した最初の認定です。 新しい AWS 認定を創造するため、AWS は経験豊富な専門家と協力して、関連する役割または技術トピックの能力の基準を設定しています。この内容領域専門家は、認定を取得することで知識とスキルがあることを明確にします。シニアデータおよび情報アーキテクトの Neil Lesile 氏とシニアテクニカルプログラムマネージャーの Brian Millard 氏(両者 GE Core Technology) は、AWS データベースの内容領域専門家 (SME) として認定の開発に貢献しました。 Millard 氏は次のように述べています。「この認定は、クラウドデータベースの専門家として人を引き立てることができます。私たちの組織にとって、確固たる尊敬されるクラウドベースのチームを構築するには、認定で取り扱うスキルが必要です」 Leslie 氏は、この新しい認定により、「企業はデータベースの人材を簡単に特定し、データを保護し、変革の過程のコストを最小限に抑えるための適切な意思決定を確実に行えるようになります」と述べています。 データベースの経験と知識の深さは、拡張性やセキュリティなどの要件を満たすことができるチームを備え、ワークロードに適したデータベースを自信を持って選択したい AWS のお客様とパートナーにとって重要な能力です。 この認定は、さまざまなリレーショナルデータベースおよび非リレーショナルデータベースの専門知識を確認した最初の認定です。Esteh の所有者である Goran Opacic 氏は、さまざまな AWS データベースの経験に価値があると考えています。「長年、1 つのデータベースですべてのデータの問題を解決しようとしてきました。AWS は、同じセキュリティモデル、移行ツール、SDK などを使用して、これらの製品を 1 つのソリューションに混在させるのがいかに簡単かという点で目を開かせてくれました。そしてこれらが、AWS 認定データベース – 専門認定で成功するために必要なスキルです」 Opacic 氏はまた、AWS User Group Belgrade のコミュニティリーダーで、AWS データヒーローズの […]

Read More