sans vouloir du tout polémiquer je voudrais mettre un bémol la dessus et voudrais partager mon expérience. Dans ma boite on fait du monitoring et de l'analyse de données remontées par différentes sortes d'équipements. Ça va de capteurs infrarouges et de fermeture de porte, à des équipements réseaux en passant par des métriques de serveurs ou des montres connectées.
Mais globalement on stocke des données simples : un timestamp => une série de valeurs. Quand on a commencé on m'a parlé de hadoop, de spark, de datalake, que lorsque j'aurais plusieurs centaines de tera de données j'allais avoir des problèmes pour accéder à mes données et les traitées.
N'y connaissant pas grand chose je me suis renseigné et j'ai trouvé que niveau mise en place et admin c'était très lourd. Surtout hadoop. Bref je n'ai pas fait ce choix. Je suis bêtement parti sur un postgres, car c'est simple, robuste, performant, standard (vive le sql (en fait non vive les orm :))), que les ressources humaines sont plus simple à trouver etc. Et franchement je ne regrette pas. Nous avons plusieurs centaines de tera de données, nous insérons plusieurs dizaines de giga par jours et tout va bien. Ca reste du postgres. Petite subtilité par contre. Nous utilisons un plugin dans postgres : timescaledb. Et pour aggrandir le disque dans postgres sans se prendre la tête notre postgres tourne dans ceph.
Honnêtement je suis très content de nos choix. Ceph est vraiment extra ordinaire. Je dirais la même chose de postgres. Ça marche tellement bien que en tant qu'admin c'est frustrant il n'y a pratiquement rien à faire. Alors je me suis mis à faire du dev.
En ce moment nous testons l'intégration de notre architecture dans kubernetes et istio. Et ça c'est la cerise sur le gâteau. Je crée une branche dans git. Je pousse dans gitlab. Et la j'ai une version complète et totale de l'application avec la totalité des données (merci les snaphosts de ceph), avec une url dédié, le monitoring. La totalité. Et ce en quelques dizaines de secondes. J'adore mon métier !
Bref tout ça pour dire que oui hadoop spark h20 etc c'est sûrement très bien. Cependant de mon expérience une bonne vieille db avec un peu de partitionning c'est simple et ça fait le taf.
oau
ps : et surtout y'a pas de java !!! Oui désolé je n'ai eu que de très mauvaise expérience avec java. Je sais que c'est très bien. Mais j'y arrive pas. Mais quand même, prochaine étape : kafka.
[^] # Re: Bien pour des données en volume raisonnable
Posté par oau . En réponse au journal Bibliothèques Python utiles à l'analyse des données. Évalué à 5.
Bonjour,
sans vouloir du tout polémiquer je voudrais mettre un bémol la dessus et voudrais partager mon expérience. Dans ma boite on fait du monitoring et de l'analyse de données remontées par différentes sortes d'équipements. Ça va de capteurs infrarouges et de fermeture de porte, à des équipements réseaux en passant par des métriques de serveurs ou des montres connectées.
Mais globalement on stocke des données simples : un timestamp => une série de valeurs. Quand on a commencé on m'a parlé de hadoop, de spark, de datalake, que lorsque j'aurais plusieurs centaines de tera de données j'allais avoir des problèmes pour accéder à mes données et les traitées.
N'y connaissant pas grand chose je me suis renseigné et j'ai trouvé que niveau mise en place et admin c'était très lourd. Surtout hadoop. Bref je n'ai pas fait ce choix. Je suis bêtement parti sur un postgres, car c'est simple, robuste, performant, standard (vive le sql (en fait non vive les orm :))), que les ressources humaines sont plus simple à trouver etc. Et franchement je ne regrette pas. Nous avons plusieurs centaines de tera de données, nous insérons plusieurs dizaines de giga par jours et tout va bien. Ca reste du postgres. Petite subtilité par contre. Nous utilisons un plugin dans postgres : timescaledb. Et pour aggrandir le disque dans postgres sans se prendre la tête notre postgres tourne dans ceph.
Honnêtement je suis très content de nos choix. Ceph est vraiment extra ordinaire. Je dirais la même chose de postgres. Ça marche tellement bien que en tant qu'admin c'est frustrant il n'y a pratiquement rien à faire. Alors je me suis mis à faire du dev.
En ce moment nous testons l'intégration de notre architecture dans kubernetes et istio. Et ça c'est la cerise sur le gâteau. Je crée une branche dans git. Je pousse dans gitlab. Et la j'ai une version complète et totale de l'application avec la totalité des données (merci les snaphosts de ceph), avec une url dédié, le monitoring. La totalité. Et ce en quelques dizaines de secondes. J'adore mon métier !
Bref tout ça pour dire que oui hadoop spark h20 etc c'est sûrement très bien. Cependant de mon expérience une bonne vieille db avec un peu de partitionning c'est simple et ça fait le taf.
oau
ps : et surtout y'a pas de java !!! Oui désolé je n'ai eu que de très mauvaise expérience avec java. Je sais que c'est très bien. Mais j'y arrive pas. Mais quand même, prochaine étape : kafka.