web-dev-qa-db-ja.com

なぜpandasでのマージpython 2012年のRでのdata.tableのマージよりも高速ですか？

最近、Pythonの pandas ライブラリに出会いました。 このベンチマーク によれば、非常に高速なメモリ内マージが実行されます。 Rの data.table パッケージ（分析用に選択した私の言語）よりも高速です。

なぜpandasは_data.table_よりもずっと速いのですか？それは固有の速度の利点のためですpythonはRよりも優れていますか、それとも気づいていないトレードオフがありますか？_data.table_で内部結合と外部結合を実行する方法はありますか？ merge(X, Y, all=FALSE)とmerge(X, Y, all=TRUE)に頼らずに？

Comparison

以下は、さまざまなパッケージのベンチマークに使用される Rコード と Pythonコード です。

pythonrjoindata.tablepandas
154
Zach

一意の文字列の数（levels）が大きい場合、Wesはdata.tableで既知の問題を発見したようです：10,000。

Rprof()は、呼び出しsortedmatch(levels(i[[lc]]), levels(x[[rc]])に費やされた時間のほとんどを明らかにしますか？これは実際には結合そのもの（アルゴリズム）ではなく、予備的なステップです。

キーの文字列を許可するための最近の取り組みは、R自身のグローバル文字列ハッシュテーブルとより緊密に統合することでその問題を解決するはずです。いくつかのベンチマーク結果はtest.data.table()によってすでに報告されていますが、そのコードはまだレベルに一致するレベルに置き換えるために接続されていません。

pandasは、通常の整数列でdata.tableよりも速くマージされますか？それは、アルゴリズム自体と要因の問題を分離する方法です。

また、data.tableは時系列マージを念頭に置いています。それに対する2つの側面：i）（id、datetime）などの複数列orderedキーii）高速優先結合（roll=TRUE）a.k.a.前回の観測値.

提示されているdata.tableとの比較で初めて見たので、確認するのに時間が必要です。

2012年7月にリリースされたdata.table v1.8.0からの更新

  • タイプ 'factor'の列のiレベルをxレベルに一致させる場合、内部関数sortmatch（）は削除され、chmatch（）に置き換えられました。この予備ステップは、因子列のレベル数が大きい場合（> 10,000など）に（既知の）大幅なスローダウンを引き起こしていました。 Wes McKinney（Python package Pandas）の著者）が示すように、このような4つの列を結合するテストで悪化しました。 、 例えば。

また、そのリリースでは：

  • 現在、文字列はキーで許可されており、ファクタリングよりも優先されます。 data.table（）およびsetkey（）は、文字をファクターに強制しなくなりました。要因は引き続きサポートされています。 FR＃1493、FR＃1224、および（部分的に）FR＃951を実装します。

  • 新しい関数chmatch（）および％chin％、文字ベクトルのmatch（）および％in％の高速バージョン。 Rの内部文字列キャッシュが使用されます（ハッシュテーブルは作成されません）。 ？chmatchの例では、match（）よりも約4倍高速です。

2013年9月現在、data.tableはCRANでv1.8.10であり、v1.9.0で作業しています。 [〜＃〜] news [〜＃〜]はライブで更新されます。

しかし、最初に書いたように、上記：

data.tableは時系列マージを念頭に置いています。それに対する2つの側面：i）（id、datetime）などの複数列orderedキーii）高速優先結合（roll=TRUE）a.k.a.前回の観測値.

したがって、2つの文字列のPandas等結合は、おそらくdata.tableよりも高速です。結合された2つの列をハッシュするように聞こえるので、data.tableはキーをハッシュしません。 data.tableの「キー」は、文字通りソート順です（SQLのクラスター化インデックスに似ています。つまり、RAMでのデータの順序です）。リストには、セカンダリキーを追加します。例えば。

要約すると、既知の問題が修正されたため、10,000以上の一意の文字列を使用したこの特定の2文字列テストで強調された明白な速度の違いは、それほど悪くないはずです。

116
Matt Dowle

理由pandasが速いのは、 高速ハッシュテーブルの実装-klib およびC /- Cython 回避するためにPythonベクトル化不可能な部分のインタープリターのオーバーヘッド。このアルゴリズムは私のプレゼンテーションで詳細に説明されています。 A内部を見るpandas design and development 。

data.tableとの比較は、Rのdata.tableの要点は、さまざまな列の事前に計算されたインデックスを含むことであるため、実際には少し興味深いです。データ選択とマージ。この場合（データベース結合）、pandasのDataFrameには、事前計算情報が含まれていないため、マージに使用されているため、「コールド」マージです。因数分解がこのアルゴリズムの最大のボトルネックであるため、結合キーの因数分解されたバージョンを保存していた場合、結合は非常に高速になります。

また、パンダのDataFrameの内部設計は、Rのdata.frame（内部的に配列のリストにすぎません）よりも、これらの種類の操作を受け入れやすいことを付け加える必要があります。

189
Wes McKinney

このトピックは2年前ですが、人々がPandasとdata.tableの比較を検索するときに着陸する可能性が高い場所のようです

これらの両方が時間とともに進化しているので、興味のあるユーザー向けに比較的新しい比較（2014年から）をここに投稿したいと思います。 https://github.com/Rdatatable/data.table/wiki/Benchmarks-： -グループ化

Wesおよび/またはMatt（ちなみに、それぞれPandasおよびdata.tableの作成者であり、上記の両方のコメントを持っている）がここに追加するニュースがあるかどうかを知ることは興味深いでしょうまあ。

-更新-

以下にjangoreckiが投稿したコメントには、非常に役立つと思われるリンクが含まれています。 https://github.com/szilard/benchm-databases

https://github.com/szilard/benchm-databases/blob/master/plot.png

このグラフは、さまざまなテクノロジーの集約および結合操作の平均時間を示しています（lower = faster;比較は2016年9月に最後に更新されました）。本当に教育的でした。

質問に戻って、R DT keyおよびR DT Rのdata.tableのキー付き/キーなしのフレーバーを参照し、このベンチマークではPythonのPandas（Py pandas）。

36
Merik