:orphan: |rss_image| **2018-12 - 1/1** :ref:`Blog ` :ref:`references (4) ` .. |rss_image| image:: feed-icon-16x16.png :target: ../_downloads/rss.xml :alt: RSS ---- .. index:: 2018-12 .. _ap-month-2018-12-0: 2018-12 - 1/1 +++++++++++++ .. blogpostagg:: :title: GraphFrames :date: 2018-12-29 :keywords: spark :categories: références :rawfile: 2018/2018-12-29_graph.rst Les graphes sont toujours compliqués en MapReduce, `GraphFrames `_. Ca n'a pas l'air trop mal `A Gentle Intro To Graph Analytics With GraphFrames `_ mais il est difficile de comprendre en quoi la solution se distingue d'un `neo4j `_. En fait, je ne suis pas sûr que ce type de solution permettent de résoudre tous les problèmes. Le coût réseau `Groute performance vs. Gunrock `_ est très important pour les graphes car il faut pouvoir accéder à n'importe quelle partie. Je crois plutôt à des grosses machines avec pas mal de coeurs et des librairies écrites en C++. Je m'interroge sur des trucs de ce style `Charm++ `_ ou `Presto: Distributed Machine Learning and Graph Processing with Sparse Matrices `_. Un autre article `High-Level Programming Abstractions for Distributed Graph Processing `_ à lire sans doute (ça aussi `MapReduce formulation of PageRank `_) `Lemon `_. J'ai trouvé ça aussi `teexgraph `_ mais le code n'a pas l'air terrible (double, pas float et autres défauts). Bref, pour les très gros graphes, la ruse a encore quelques beaux jours. ---- |rss_image| **2018-12 - 1/1** :ref:`2018-04 (4) ` :ref:`2018-12 (1) `