In Silico

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

Materials Projectのデータ一括取得：列形式の配布とmp-apiで読む

2026/10/3 （更新: 2026/10/11）

🤖 AIを使用して執筆

  • Materials Project
  • マテリアルズインフォマティクス
  • データ基盤
  • parquet
  • Delta
  • Arrow
  • LeMaterial
  • MPDataset
  • JSON
  • 列形式
  • mp-api
  • Alexandria
  • AWS
  • S3
  • column pruning
  • MongoDB
  • incar
  • Hugging Face
  • LeMat-Bulk
  • Open Data
  • predicate pushdown
  • Python
  • OQMD
目次
背景・問い・要点
背景

材料の計算結果を集めた公開データベースから、全材料のデータをまとめて取り出して使う研究者がいる。たとえば、狙ったバンドギャップを持つ候補を全材料から絞り込む。あるいは、全材料の計算結果を機械学習モデルの学習データにする。こうした使い方のために、材料データベースの中には、全件をまとめてダウンロードできるファイルを配っているものがある。

よく使われてきた配り方は、材料一件ごとの記録をJSON形式の文書として書き、それを多数まとめて圧縮したファイルである。本稿はこの配り方を文書型と呼ぶ。一件の文書には、結晶構造、エネルギー、計算の設定など多くの項目が入っている。全材料のバンドギャップだけが欲しい利用者も、ファイルを展開して全部の文書を読み込み、その後で必要な項目を選ぶことになる。使わない項目まで読むので、そのぶん時間とメモリを使う。

問い

全件を配る形式を、文書型のJSONから列形式の表に変えると、利用者が読む量はどう変わり、代わりに何が要るのか。

要点

Materials Project（MP）が2026年6月に中核データの一括配布をJSONの束から列形式の表へ変えたことで、全件を受け取る利用者も、必要な列を選び、条件に合う値を含まない行のかたまりを読み飛ばせるようになった。 文書型で読む量は件数と一件の項目数の積で決まり、列形式で読む量は読み込みのときに指定した列と条件で決まる。ただし代償が二つあり、一つは、mp-apiで全件を手元に落とす使い方では置く量が全件ぶんのまま残ることで、MPの計算記録を集めたtasksコレクションは10GBを超える1。もう一つは、項目の形が一件ごとに違うデータを、全行が同じ列を持つ表に収める変換で、MPの作り手はこれを作業中としている1。

モデル・例示

六件の材料の表で、読む値の数を数える

※ この節の数値は説明のための仮定で、測定値ではありません。

材料が6件あり、一件ごとに、材料ID・バンドギャップ・生成エネルギー・計算の設定の4つの項目を持つとする。値の総数は6×4で24である。利用者はバンドギャップが1eVより大きい材料の、バンドギャップの値だけを欲しいとし、該当する材料は3件とする。

文書型では、この利用者は24の値をすべて読む。文書は一件ずつ丸ごと書かれているので、バンドギャップの値だけを取り出すには、6件の文書を全部読み込み、それぞれから1項目を選ぶ。読む量は6×4のままで、欲しい項目が1つでも減らない。

列形式の表では、バンドギャップの値が6件ぶん続けて一か所に並ぶ。利用者が読み込みのときにバンドギャップの列だけを読むと指定すると、読むのはその6値で、残りの18値は読まない。さらに列形式のファイルは、行を何件かずつのかたまりに分けて置き、かたまりごとに各列の値の範囲を控えている。行を3件ずつ2つのかたまりに分け、後ろのかたまりのバンドギャップがすべて1eV以下なら、1eVより大きいという条件を読み込みのときに渡した利用者は、後ろのかたまりを読まずに飛ばす。読むのは前のかたまりの3値だけになる。24、6、3と、読む量は指定した列と条件で決まる。

24、6、3の三つの数から言えることを、性質として三つに分ける。

  1. 読む量の決まり方。 文書型で読む量は件数×一件の項目数で、欲しい項目の数によらない。列形式で読む量は必要な列数×条件に合うかたまりの行数で、読み込みのときに列と条件を渡したときだけ減る。全件の全項目を使う利用者には差が出ない（どちらも24）。
  2. 置く量。 表に変えても、手元に置く値は24のままである。読む量が減っても、全件を手元に置く使い方である限り、置く量は減らない。
  3. 表の制約。 表は全行が同じ列を持つ。例では、計算の設定という項目の中の項目名が材料ごとに違うなら、その材料の記録はそのままでは表に入らず、列を揃える変換が要る。元のデータが不揃いなほど、この変換は増える。

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

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

2026年6月8日に本番化した版v2026.04.13で、中核のデータ製品はAWSのファイル保存サービスS3の上のDeltaテーブルに置かれるようになった4。表を列形式で保存するファイル形式がparquetで、大きなデータセットは一つのparquetファイルに収まらないことが多いと作り手は書く1。v2026.04.13より前の2025年6月の版v2025.06.09でも、フォノンのバンド構造と状態密度をparquetで効率よく保存できる新しいスキーマが入っている4。配る側では、多数のファイルを一つの表として管理する層がファイルの上に要り、この層を担う仕組みをオープンテーブルフォーマット（open table format、OTF）と呼ぶ5。MPが選んだOTFはDeltaで、作り手はこの選択が将来変わりうると書き添えている5。読む側では、列形式のデータをメモリ上で扱うライブラリArrowが、複数のparquetファイルを一つの表として読む1。

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

移行の告知と、移行先の使い方を説く解説頁は、列形式へ移した理由を述べていない。AWSのOpen Dataで配ることについては、MPは使いやすくすること、ダウンロードを大きく改善すること、自前のサーバーの負荷を減らすことを理由に挙げる3。一方でMPは、Open DataのJSONのデータを移行の候補と位置づける頁で、JSONはストリーミングにも部分的な取得にも向かないと書く7。その頁は、バンドギャップなどで材料を絞るのに要る列は3つでも、JSONのファイルは丸ごと落としてから絞るほかないという例を示す7。列形式の利点については、クラウドでは転送と読み出しの効率がそのまま費用に効くと述べる文献が多い、と解説頁が紹介する5。また、MPは同じ解説の別の頁で、parquetとDeltaの形で公開したことにより、mp-apiのPythonクライアントでは用意されていないことがある処理を利用者が自分で組めるようになった点を、利点として挙げる8。

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」とまとめる5。parquetでは、読む側が要らない列を読み込みの前に外せる5。

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

全件を手元に置く使い方では、必要な列や条件を指定して読んでも、全件ぶんの保存容量が必要になる。tasksコレクションの全件は、効率のよいparquet表現でも10GBを超え、mp-apiのMPDatasetはこの全件を手元にダウンロードする1。一方でMPは、S3に置いたままのtasksの表と状態密度の表を外部の問い合わせエンジンDuckDBで条件を付けて読み、結果だけを手元のparquetファイルに書き出す例も示している8。その例で手元に残るのは、GGA+Uで計算された六方晶の材料の状態密度のデータ、約3800件である8。この読み方では、問い合わせの速さがネットワークの速さに縛られると作り手は注記する8。ただしS3を直接読むとmp-apiの保護が外れ、データごとの利用条件とアクセス制限は利用者が自分で確かめることになる8。Deltaへ移したのと同じ版v2026.04.13で材料IDの内部表記は英字へ移り始めており、S3から直接読む利用者は、mp-149のような従来の形のIDへの読み替えを自分で行う必要がある4。

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

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

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

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

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

これとは別に、出典ごとの計算条件の違いを、LeMat-Bulkは行を混ぜて使ってよいかの問題として扱う。計算条件から見て他の行と混ぜてよいかを列cross_compatibilityで示し、混ぜてよい行をPBEなど汎関数ごとの分割に、揃わない行を別の分割non_compatibleに分けて配り、既定はPBEの分割である10。2025年4月17日付の更新履歴の項は、Ybという元素の計算条件の一つをMPと同じものへ変えること、力の大きい構造の除外、MPの2020年版の補正方式に合わせたエネルギー補正の付与を記録するが、その版を「NOT YET RELEASED」と記す10。その版ではYbの条件をMPに合わせた結果、Ybを別の条件で計算しているAlexandriaやOQMDとは揃わなくなり、Ybを含む材料はどれも、他の出典と混ぜてよいことを示すcross_compatible=Trueを持たないと更新履歴は書く10。ただし配られているデータは2024年12月の初版のままで、列の定義にエネルギー補正の列は無く、既定の分割にはYbを含みcross_compatible=Trueを持つ行が残っている10。エネルギー補正について、同じカードは、MPの2020年版の補正方式をデータセット間でまだ揃えておらず、補正の統一は今後の予定だと注記する10。力の大きい構造については、カードの方法節は更新履歴と逆のことを書いており、利用者が項目forcesで容易に絞れるので除外しなかったという10。

出典10件

  1. Materials Project「Arrow Datasets & the MPDataset Interface」（2026-09-28 取得）. https://docs.materialsproject.org/materials-project-data-lakehouse/arrow-datasets — MPDatasetの使い方、tasks全件が10GBを超えること、incarのような不均質な項目を表に収める課題が作業中であること。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16

  2. Materials Project「Querying Data」（2026-09-30 取得）. https://docs.materialsproject.org/downloading-data/using-the-api/querying-data — APIの問い合わせで、条件と返す項目を指定して絞り込めること。 ↩

  3. Materials Project「AWS Open Data」（2026-09-28 取得）. https://docs.materialsproject.org/downloading-data/aws-opendata — データ製品の一覧をAWSのOpen Dataでも全件まとめて配る理由と、版ごとのgzip圧縮JSONLや材料IDごとのJSONで置く形。 ↩ ↩2 ↩3

  4. Materials Project「Database Versions」（2026-09-28 取得）. https://docs.materialsproject.org/changes/database-versions — 版v2026.04.13が2026年6月8日に本番化し、中核データがS3上のDeltaテーブルへ移り、mp-apiに対応機能が加わったこと、2025年6月の版でフォノン用のparquetのスキーマが入ったこと。 ↩ ↩2 ↩3 ↩4

  5. Materials Project「Arrow, Parquet, and OTFs」（2026-09-28 取得）. https://docs.materialsproject.org/materials-project-data-lakehouse/arrow-parquet-and-otfs — 必要なものだけ読むpredicate pushdownとcolumn pruning、列形式の利点の紹介、表形式にDeltaを選び将来変わりうるとしたこと。 ↩ ↩2 ↩3 ↩4 ↩5

  6. Materials Project「Supported Data Products」（2026-10-02 取得）. https://docs.materialsproject.org/materials-project-data-lakehouse/supported-data-products — Parquet/Deltaとmp-apiに対応した23のデータ製品と、移行途中の分子データなどの一覧。 ↩

  7. Materials Project「Legacy json Data on AWS Open Data」（2026-10-07 取得）. https://docs.materialsproject.org/downloading-data/aws-opendata/working_with_parquet — Open DataのJSONのデータを移行の候補とし、JSONは部分的な取得に向かないと書くこと、絞り込みにもJSONのファイルを丸ごと落とす例。 ↩ ↩2

  8. Materials Project「Leveraging External Query Engines」（2026-09-30 取得）. https://docs.materialsproject.org/materials-project-data-lakehouse/leveraging-external-query-engines — S3上の表をDuckDBで直接読み約3800件の状態密度を書き出す例と、速さがネットワークに縛られmp-apiの保護が外れる注意。 ↩ ↩2 ↩3 ↩4 ↩5

  9. Alexandre Duval ほか「LeMaterial: an open source initiative to accelerate materials discovery and research」Hugging Face, 2024. https://huggingface.co/blog/lematerial — MP・Alexandria・OQMDの統合と、出典ごとに形式が違う課題。 ↩ ↩2 ↩3 ↩4

  10. LeMaterial「LeMat-Bulk」dataset card（2026-09-28 取得）. https://huggingface.co/datasets/LeMaterial/LeMat-Bulk — OQMDのIDや応力の形の揃え直し、混ぜてよい行を示すcross_compatibility列、Ybの条件を変えた未公開の版の記録、補正の未統一と力の大きい構造の扱いの食い違い、配布が2024年12月の初版のままのこと。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。