【ITニュース解説】MongoDB vs MySQL: A Real-World Performance Showdown Using Disneyland Data

システムエンジニアを目指す上で、データベースの選択は非常に重要な判断だ。世の中には様々なデータベースが存在するが、特に人気の高いリレーショナルデータベースの代表格であるMySQLと、NoSQLデータベースとして広く使われるMongoDBは、それぞれの特徴や性能が大きく異なる。どちらが優れているかという単純な話ではなく、プロジェクトの要件やデータの種類によって適した選択は変わってくる。

ある大学の研究プロジェクトでは、このMongoDBとMySQLを実際のデータを使って比較し、そのパフォーマンスを詳細に分析した。ベンチマークテストは通常、抽象的なデータで行われがちだが、この研究ではディズニーランド・パリの実際のデータを使用することで、より現実的なシナリオでの性能を検証した点が画期的だ。使用されたデータは、37種類のアトラクションの待ち時間（2018年～2019年）、日々の入場者数（2018年～2022年）、気象条件（1999年～2022年）、そしてパークの運営スケジュール（2018年～2022年）という多岐にわたる情報だ。これらのデータは、高頻度なデータの書き込み、複数のデータ源にまたがる複雑な集計、時間の流れに沿った時系列分析、そして関連するデータ間の結合（JOIN）といった、実社会で直面するような課題を再現するのに非常に適していた。

比較を公平に行うため、同じハードウェア構成（RAM 20GB、CPU 6コア、HDDストレージ）を使用し、両データベースに同等のインデックスを設定した。インデックスは、データベースがデータを高速に検索するために使用する目次のようなもので、性能に大きく影響する。また、データベースの構造（スキーマ）にも工夫が凝らされた。MySQLでは、伝統的なリレーショナルデータベースのアプローチである「正規化」を採用し、天気情報などを別の表に分けて管理し、外部キーという仕組みで関連付けた。これはデータの重複を避け、整合性を保ちやすいが、データを取り出す際に複数の表を結合する「JOIN」操作が必要になる。一方、MongoDBでは、「ドキュメント指向」という考え方に基づき、天気データをアトラクションのデータなどに関連情報として「埋め込みドキュメント」として格納した。これにより、JOIN操作をせずに必要な情報を一度に取得できるメリットがある。そして、両データベースに対して、同じビジネスロジックに基づいたクエリ（データ要求）を実行し、その処理時間を比較した。

具体的なパフォーマンス結果を見ると、まずデータの書き込み（挿入）操作において、MongoDBが圧倒的な速さを見せた。天気データ、待ち時間、入場者数、スケジュールといったあらゆる種類のデータ挿入で、MongoDBはMySQLよりも50%から67%も高速だった。これは、リアルタイムでセンサーデータを取り込んだり、大量のログデータを記録したりするような、書き込みが頻繁に発生するシステムにおいて、MongoDBが非常に有利であることを示している。MongoDBの柔軟なスキーマと、JOINを必要としないデータ構造が、高速な書き込みに貢献していると言える。

次に、データの読み込み（分析クエリ）の性能を見てみよう。ここではクエリの種類によって勝者が大きく分かれた。 「アトラクションごとの平均待ち時間を計算する」という単純な集計クエリ（RQ1）では、MongoDBがMySQLよりも98.1%も高速で、MySQLが約52.6秒かかったのに対し、MongoDBはわずか1秒で完了した。これは、MongoDBが持つ「集計パイプライン」という機能が、このようなシンプルな集計処理に非常に最適化されていることを示している。 また、「待ち時間と気象条件の複雑な相関関係を分析する」クエリ（RQ3）では、さらに劇的な差が見られた。MongoDBがミリ秒単位で処理を終えたのに対し、MySQLは4時間以上かかっても処理が完了せず、途中でエラーになってしまった。これは、複雑な時系列データ分析において、MongoDBの構造が非常に効率的であることを示している。 「祝日と通常の日の入場者数を比較する」クエリ（RQ4）でも、MongoDBがMySQLより11.7%高速だった。

しかし、MySQLも劣っていたわけではない。「特定の気象条件と入場者数の関連性を分析する」というクエリ（RQ2）では、驚くべきことにMySQLがMongoDBよりも98%も高速だった。MongoDBが20.7秒かかったのに対し、MySQLはわずか413ミリ秒で完了したのだ。このクエリは、複雑な一時テーブルの作成や、複数のデータソース間の複雑な関連付けを必要とするもので、MySQLが長年の進化で培ってきた成熟したクエリ最適化技術が、このような複雑なリレーショナル操作で真価を発揮したことを示している。

これらの結果から、各データベースの技術的な強みが浮き彫りになる。MongoDBは、データを埋め込みドキュメントとして保持するため、テーブル間のJOIN操作が不要で、そのオーバーヘッドがない。また、複雑な分析処理を効率的に実行できる専用の集計パイプラインを持っており、ドキュメントベースのデータに適した柔軟なインデックス機能も高速処理に貢献する。さらに、厳格なスキーマ定義が不要であるため、データの書き込み時に構造の制約が少なく、高速なデータ取り込みを可能にする。

一方、MySQLは、何十年にもわたる開発によって洗練されたクエリ最適化機能を持ち、複雑な一時的なデータ操作や、複数のテーブルを効率的に扱うメモリ管理に優れている。特に、複数の関連するデータを厳密に管理し、それらの関係性を複雑に分析するようなシナリオでは、MySQLの強みが発揮される。

この研究の最も重要な学びは、どちらか一方のデータベースが常に優れているというわけではなく、「ワークロードの特性」、つまりデータベースに何をさせたいかによって最適な選択が異なる、という点にある。高頻度で大量のデータを記録するIoTシステムやリアルタイム分析、複雑な時系列分析、または頻繁にデータの構造が変わる可能性のあるプロジェクトでは、MongoDBが大きなメリットをもたらすだろう。一方で、複数の異なる種類のデータを厳密に管理し、それらの複雑な関係性を分析したり、既存のSQLベースのシステムとの連携が必要だったり、データの厳格な一貫性が最優先されるプロジェクトでは、MySQLのようなリレーショナルデータベースが適している。

データベースの選定は、最新のトレンドや個人的な好みだけで決めるべきではない。今回のディズニーランドデータを使った分析が示したように、書き込みが中心のアプリケーションではMongoDBが圧倒的な優位性を持つことがあり、複雑な分析クエリでは、そのクエリの種類によってパフォーマンスが大きく変動する。場合によっては、異なる種類のデータベースを組み合わせて、それぞれの得意分野を活かす「ハイブリッド」なアプローチも有効な選択肢となり得るだろう。アプリケーションの応答速度やユーザー体験に直接影響を与えるような、今回確認された98%といった大きな性能差は、システム設計において決して無視できない重要な要素だ。