マテリアルズインフォマティクス・材料

Materials Projectが中核データの一括配布を列形式の表へ

2026/10/3

🤖 AIが執筆しています

MPは中核データを、列形式のファイルの集まりを一つの表にして配る

Materials Project（MP）は、材料の計算結果を集めた公開データベースである。MPはこれまで、条件と項目を指定して絞り込めるAPIの問い合わせ²と並んで、全件のデータをAWSの公開データセットの枠組みであるOpen Dataでも配ってきた³。そのファイルは文書型である。計算結果から作ったコレクションは、一行に一件のJSONを書いたファイルを版ごとに圧縮して置き、計算の出力を解析した記録は、多くを材料IDごとにgzip圧縮したJSONで置いて、一行に一件の形へまとめ直している途中である³。MPの内部でも、すべてのデータ製品は、JSONに似た文書を一件ずつ保存するデータベースであるMongoDBに保存されてきた¹。

2026年6月8日に本番化した版v2026.04.13で、中核のデータ製品はAWSのファイル保存サービスS3の上のDeltaテーブルに置かれるようになった⁴。表を列形式で保存するファイル形式がparquetで、大きなデータセットは一つのparquetファイルに収まらないことが多いと作り手は書く¹。配る側では、多数のファイルを一つの表として管理する層がファイルの上に要り、この層を担う仕組みをオープンテーブルフォーマット（open table format、OTF）と呼ぶ⁵。MPが選んだOTFがDeltaである⁵。読む側では、列形式のデータをメモリ上で扱うライブラリArrowが、複数のparquetファイルを一つの表として読む¹。

MPが公開する利用者向けのPythonクライアントmp-apiには、この変更を扱う機能が加わった⁴。加わった機能の中心がMPDatasetで、tasksコレクション（個々の計算の記録を集めたコレクション）なら丸ごと手元にダウンロードし、Arrowでメモリを節約しながら少しずつ読む¹。MPの一覧では、tasksのほかsummaryやthermoなど23のデータ製品がこの形とmp-apiの連携に対応し、分子のデータなどは移行の途中である⁶。

列形式へ移した理由そのものを、MPは移行の告知でも解説頁でも述べていない。MPが理由を書いているのはAWSのOpen Dataで配ることについてで、使いやすくすること、ダウンロードを大きく改善すること、自前のサーバーの負荷を減らすことを挙げる³。列形式の利点については、クラウドでは転送と読み出しの効率がそのまま費用に効くと述べる文献が多い、と解説頁が紹介するにとどまる⁵。一方、MPは同じ解説の別の頁で、parquetとDeltaの形で公開したことにより、mp-apiのPythonクライアントでは用意されていないことがある処理を利用者が自分で組めるようになった点を、利点として挙げる⁷。

MPの解説は必要なものだけ読むことを、実測は全件ぶんの容量を示す

MPの解説頁が利用者に押さえてほしいと書く発想は二つで、どちらも列形式の表で読む量を、必要な列と条件に合う行だけに減らすものである。predicate pushdownは、絞り込みの条件に合わない行のかたまりを読む前に飛ばす仕組みである。列形式のファイルは行を何件かずつのかたまりに分けて置き、かたまりごとに各列の値の範囲を控えているので、条件に合う値を含まないかたまりは読まずに済む。column pruningは、必要な列だけを読む仕組みである。作り手はこの二つを「the most important concepts to understand and keep in mind are predicate pushdown and column pruning , or in lay-terms reading only what you need」とまとめる⁵。parquetでは、読む側が要らない列を読み込みの前に外せる⁵。

読む量が減るのは読み込みのときに列と条件を渡したときだけだ、という条件は、MPDatasetの使い方の注意として現れる。MPDatasetは従来の問い合わせの戻り値と同じように振る舞うので既存のコードはそのまま動くが、添字で一件ずつ読むと最適でないという警告が出る¹。作り手は同じ絞り込みを二通りで示す。Pythonで全件を回す書き方には「this will finish, eventually」と注記し、条件と列をArrowに渡す書き方は普通のマシンで長くても数秒と書く¹。列と条件を渡して読んだ後も、列形式の表からPythonのオブジェクトへ戻すこと自体に時間がかかる。作り手が示したところでは、r2SCANで計算した非金属の4万2千件の構造を、材料の構造を扱うPythonライブラリpymatgenの形へ戻すと、変換が2回かかり、秒のオーダーで終わる¹。作り手は、PyArrowの書き方は最初は不慣れでも、Pythonオブジェクトへの変換をできる限り遅らせ、Arrowの計算エンジンを使うことで得る性能の利得は学習の手間に見合うと書く¹。この学習の手間は使い方に慣れれば薄れるので、一時的な代償である。

読む量が減っても手元に置く量は減らないことを示す実測は、ディスク容量である。tasksコレクションの全件は、効率のよいparquet表現でも10GBを超え、mp-apiのMPDatasetはこの全件を手元にダウンロードする¹。全件を手元に置く使い方である限り、形式を変えても全件ぶんのデータを置くことになる。一方でMPは、S3に置いたままのtasksの表と状態密度の表を外部の問い合わせエンジンDuckDBで条件を付けて読み、結果だけを手元のparquetファイルに書き出す例も示している⁷。その例で手元に残るのは、GGA+Uで計算された六方晶の材料の状態密度のデータ、約3800件である⁷。この読み方では、問い合わせの速さがネットワークの速さに縛られると作り手は注記する⁷。ただしS3を直接読むとmp-apiの保護が外れ、データごとの利用条件とアクセス制限は利用者が自分で確かめることになる⁷。

表に収める変換は、MPでは作業中で、LeMaterialでは出典ごとの形の揃え直しになる

MPのデータで、中身の形が一件ごとに違うために全行が同じ列を持つ表へそのままでは収まらない項目として、原典はincarを挙げる。incarは計算プログラムVASPの設定を並べた項目で、作り手は中身が極めて不均質な辞書だと書く¹。MongoDBの文書は項目の組み合わせを一件ごとに変えられるが、parquetの表は全行が同じ列を持ち、作り手はこの二つを相容れないと書く¹。incarに一様に厳密な型を付けるには、いったん文字列に変えて保存し、読んだ後で戻すほかなかった¹。戻す処理は、MPのデータ製品の型を定める文書モデルが引き受けるが、作り手は最良の性能のために、やはり戻しをできる限り遅らせるよう勧める¹。

作り手は、この相容れなさから来る課題を「consider this issue a work-in-progress」と書き、利用者が回避策を意識せずに済むよう対応を進めている¹。

複数のデータベースを一つの表にまとめると、全行が同じ列を持つ表に収めるための変換は出典ごとに項目の形を揃える作業になる。LeMaterialはEntalpicとHugging Faceが主導する共同プロジェクトで、MP・Alexandria・OQMDなどを統合・整形した一つの形式（670万件・7物性）を、Hugging FaceのデータセットLeMat-Bulkとして配る⁸。LeMaterialが課題に挙げるのは、MP・Alexandria・OQMDが「形式・パラメータ・範囲で異なる」ことである⁸。具体的には、形式や項目定義の不一致・両立しない計算といった統合の問題と、データベースにまたがる似た材料をつなぐ識別子の欠如である⁸。作り手はこの状態を「断片化した状況」と呼び、既存データを活かす妨げになると書く⁸。

形を揃える変換の例は、LeMat-Bulkの項目の説明に出ている。LeMat-BulkはOQMDの整数のIDを「oqmd-」付きの文字列に変え、OQMDが短い表記で持つ応力を3×3の形に直して、一つの表に収めている⁹。

これとは別に、出典ごとの計算条件の違いを、LeMat-Bulkは行を混ぜて使ってよいかの問題として扱う。計算条件から見て他の行と混ぜてよいかを列cross_compatibilityで示し、混ぜてよい行だけの分割を既定にする一方、全件の分割Allには揃わない行も残す⁹。2025年4月17日付の更新履歴の項（見出しは版を「NOT YET RELEASED」と記す）は、Ybという元素の計算条件の一つをMPと同じものへ変えたこと、力の大きい構造の除外、MPの2020年版の補正方式に合わせたエネルギー補正の付与を記録する⁹。MPの条件に合わせた結果、Ybを別の条件で計算しているAlexandriaやOQMDとは揃わなくなり、Ybを含む材料はどれも、他の出典と混ぜてよいことを示すcross_compatible=Trueを持たなくなった⁹。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。