本Honda Tech Blogにて5月19日に公開した『ソフトウェアエンジニアがHondaに転職して感じたこと4選』は、しかるべき確認手順を経ずに記事が公開されたため当該記事を削除しました。予告なく当該記事を削除したことで、本ブログをご覧いただいている読者の皆様にご不便をおかけして申し訳ございません。 今後の運営改善に努めてまいります。

# Backgroud システムの規模やアーキ設計により、複数以上のデータベースを使用することはあります。その場合、データの重複管理を避けるため、異なるデータベースに存在するテーブルを結合しデータ検索するのはよくあります。 # MySQL 同一のMySQLインスタンスでは、DB跨ぐデータ検索は簡単にできます 。例えば、下記のSQL文でそれぞれの販売と仕入れDBから一括データ検索できます。 select    db_sales.products.id,    db_sales.products.name,    db_suppliers.stockroom.amount from db_sales.products left join db_suppliers.stockroom on db_sales.products.id = db_suppliers.stockroom.id;   インスタンスも異なる場合、MySQLでは、 The FEDERATED Storage Engine を使えば、リモートホストのDBからデータをローカルに持ってきて、ローカルDBでテーブルJOINは可能になります。詳細に関しては、下記のMySQLのオフィシャルサイトにご参照ください。また、Google先生に聞けば、Qiitaなどにも、たくさんの記事があるので、ここでは割愛します。FEDERATEDテーブルのパフォーマンスを検証しておりませんが、多い方から速度遅いと評価されているので、あまり期待しないほうが良いでしょう。 dev.mysql.com   # Amazon Aurora 近年クラウドに特化したAWSのAuroraを使うのは主流となり、高性能、完全互換性、移行容易などで評価されていますが、Aurora MySQLは The FEDERATED Storage Engine を現時点では対応していないことに注意しましょう。同一Aurora MySQLインスタンスであれば、通常のSQL文でDB跨ぐデータ検索はできますが、ほとんどの場合、マルチインスタンスだったり、マルチアカウントだったりするアーキ設計のため、DB跨ぐデータ検索したい時のソリューションは限られています。 ここでは、３つの選択肢を皆さんと共有します。ただし、下記のいずれも高速のデータ検索に向いていないので、処理速度に重視の方は、自ら検証してください。 1. インナーAPIにてアプリコード内でデータ結合 APIでそれぞれのDBインスタンスからデータ抽出し、アプリのメモリ上にデータ結合するのは、なかなか難しい（ありえない）と思っている方も多いかもしれませんが、実は、データ分析に強いPythonの世界では、非常に一般的で、データの結合は１行のコードだけでできるものです。もちろん、Pandasを使わないといけません。LambdaでAurora DBからデータ抽出し結合した上、フロントエンドアプリへ返す場合、お試しの価値があると思います。 例えば、上記の販売と仕入れDBの例で、Pythonの場合、下記のイメージです。 import pandas as pd import numpy as np conn_str_db_sales = "..." #詳細を省略 conn_str_db_suppliers = "..." #詳細を省略 # 販売のデータフレームに販売データ読み込み sql_products = "SELECT id, name FROM products" df_sales = pd .read_sql( sql_products , conn_str_db_sales ) # 仕入れのデータフレームに在庫データ読み込み sql_stockroom = "SELECT id, amount FROM stockroom" df_suppliers = pd .read_sql( sql_stockroom , conn_str_db_suppliers ) # d f_salesとdf_suppliersをleft_join結合 df_amounts = pd .merge( df_sales , df_suppliers , how="left") 2. Amazon Redshift 単一のAmazon Redshiftクラスタで、異なるデータベースからデータクエリするやり方は、下記のオフィシャルサイトで説明されているので、詳細を割愛しますが、ここで共有したいのは、Redshiftでもデータベースから直接データ検索し結合するのは高速ではないため、一度S3にデータをアウトプットし、S3にてデータ分析するのは、かなり速度を期待できます。もちろん、S3でのデータ分析は、Amazon Athenaも良いツールですが、RedshiftとAthenaの特徴を別途Google先生に聞いてください。 docs.aws.amazon.com 3. Aurora PostgreSQL Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQLのどちらでも、Federated クエリをサポートしています。ユースケースも含め、詳細についてAmazon DatabaseBlogにご参照ください。 雑談ですが、MySQLに比べるとPostgreSQLはより便利な機能が多いので複雑になるため読み出し速度が劣化するイメージが強いですが、最新のバージョンではその性能差はどんどん縮小されています。特にJSON形式の読み書き更新はPostgreSQLで勝っています。とはいえ、MySQLは読み出しが早い、PostgreSQLは書き込みが早いの考え方はまだ変わっていません。MySQLとPostgreSQLの使い分けについて、AWSでも丁寧に説明があるので、 ここの比較ページ に参考してください。   aws.amazon.com  

皆さん、こんにちは。 本田技研工業株式会社（以下「Honda」）のデジタルサービス ソフトウェア内製化チームとデジタルプラットフォーム開発チームがテックブログを開設しました！ こちらのブログでは、利用している技術や開発、イベント情報などを中心に発信していきますので、よろしくお願いいたします。 はじめに これまでのクルマ開発はハードウェアで価値を提供していましたが、近年はソフトウェアで価値を提供する考え方「 SDV（Software Defined Vehicle） 」が注目されています。 SDVでは、ソフトウェア技術によりユーザーに合わせてパーソナライズ化することで、乗り心地やUI、走り方などが『乗れば乗るほど進化』 することを可能にしていきます。 HondaもSDVに注力しています。 最新のデジタル技術とモビリティをコネクテッドし、価値創出に取り組んでいます。 このブログで発信予定の内容 このブログでは、デジタルサービス ソフトウェア内製化チームとデジタルプラットフォーム開発チームを中心としたメンバーで様々なテーマを発信していきます。 ・使用技術（AWS、プログラミング、開発技術など） ・日常での思考（チームビルディング、ワイガヤなど） ・イベント情報　など Hondaの個人単位での発信が見られる貴重な機会ですので、お見逃しなく！ まとめ ここまでご覧いただき、ありがとうございました！ これから試行錯誤しつつ更新していきますので、よろしくお願いいたします。 関連サイトもぜひご覧ください。   ■デジタルサービス ソフトウェア内製化チームのQiitaテックブログ 本田技研工業株式会社 (Honda) - Qiita   ■デジタルプラットフォーム開発チームのメンバーが登壇したTECHPLAY Honda×AWSが仮想空間でクルマをつくる──車載ソフトウェア開発体制"Digital Proving Ground"爆速開発がスタート！～前編～ - TECH PLAY Magazine