14,90 € TTC
p.06 Côté livres…
p.10 Auto-encodeur variationnel avec Keras
p.29 Introduction au dossier
p.30 Hadoop : l’écosystème Big Data
p.42 Big Data avec Apache Cassandra
p.56 Analyse de données avec Spark
p.68 Open Data : utilisation de données publiques
p.84 Stockage efficace de données sous PostgreSQL
p.92 Base de données orientée graphe : Neo, puissance 4
p.98 Contrôler un serveur avec des SMS
Big Data ou juste Data ?
Ce terme qu’on entend partout (tout comme le malheureux « la data ») n’est pas uniquement un buzzword, mais le définir clairement est délicat d’un point de vue technique. La masse de données n’a cessé d’augmenter depuis les toutes premières heures de l’informatique. Le PDP-7 sur lequel a été créé UNIX dans les années 70 n’avait que 8192 mots de 18 bits en guise de mémoire, le premier IBM PC en 1981 pouvait supporter 256 Ko de RAM et très récemment, il était encore impensable d’utiliser plus de 2 Go de RAM. Il en va de même pour le stockage, les images, les bases de données, les volumes de transferts, les métadonnées... Tout grossit, tout devient de plus en plus big.
Mais si les capacités des machines suivent une évolution similaire, alors pourquoi parler de Big Data ? Pourquoi pas Big Computing ? Ou Big Reality ?
Le Big Data ne qualifie pas vraiment l’évolution du volume de données, ni même du volume de traitements ou de stockages qui progressent de concert naturellement, organiquement. Non, ce sont les principes, les méthodologies, les critères décisionnels et les fonctionnalités clés des architectures qui doivent évoluer. Le Big Data n’est pas une problématique de volume, mais une simple réalité à laquelle il faut s’adapter par de bons choix techniques.
Les articles qui composent ce numéro vous présenteront précisément quelques-uns de ces choix, aussi importants que captivants, et vous permettront de voir, vous aussi, les choses en grand !
Bonne lecture.
La rédaction
GNU/Linux Magazine s'adresse aux professionnels et aux particuliers désireux de mieux maîtriser les techniques et problématiques liées à la programmation et à l’utilisation de solutions open source. Tous les deux mois avec ses articles techniques, la publication couvre les thématiques suivantes : programmation système, algo, bas niveau, sécurité du code, développement web...
Lorsque les données « pleuvent » de différentes sources, le volume est tel qu’il faut adapter ses outils pour pouvoir les stocker et les utiliser.
Stocker des données dans une base PostgreSQL est assez simple : un CREATE TABLE, et c’est parti pour les insertions. Cependant, même si un CREATE TABLE semble assez simple, réfléchir à la construction de cet ordre SQL est important. Le type des données et l’ordre des colonnes jouent un rôle important sur la volumétrie de la table, et donc sur ses performances.
Il ne sera pas question du nouvel opus de la matrice ici, mais de Neo4j qui revient encore plus fort dans sa version 4.Dans de précédents numéros (voir [2] et [3]), je vous ai présenté les BDDDTG (les bases de données de type graphe), et plus spécifiquement Neo4j [1]. L’acronyme est de moi, les trois derniers caractères me rappelleront toujours l’effet produit par la découverte des graphes après des années d’utilisation de bases dites relationnelles.