Oracle R Enterprise (#1)

Lorsque je teste une fonctionnalité, j’aime bien utiliser plusieurs approches afin de voir les forces et faiblesses de chacune. Dans le cadre d’analyses statistiques avec Oracle, cela revient généralement à comparer une implémentation basée sur SQL/ODM avec son homologue basée sur R.

Ici, dans la continuité des billets précédents, je me suis demandé s’il existait des packages R permettant de réaliser un COUNT(DISTINCT) avec l’algorithme d’HyperLogLog. Je n’en ai pas trouvé.

Néanmoins, lors de mes investigations, j’ai rencontré un problème beaucoup plus épineux…

Pour réaliser le COUNT(DISTINCT) des données de la table LOG_CONTRIBS, j’ai essayé au préalable de la charger dans une session R via ROracle:

> library(ROracle)
Loading required package: DBI
> ora = Oracle()
> cnx = dbConnect(ora, username="c##raf", password="Password1#", dbname="//clorai2-scan:1521/pdb_iotst04")
> wiki_contribs <- dbGetQuery(cnx, "select * from LOG_CONTRIBS")
...

… et j’ai attendu, attendu, attendu…

En effet, par défaut, R fonctionne de manière autonome en traitant les données en mémoire. Donc, ici la fonction dbGetQuery réalise le rapatriement vers le client de l’ensemble des données de la table LOG_CONTRIBS pour peupler le dataframe wiki_contribs.
Malheureusement, cette table est relativement volumineuse:

SQL> SELECT bytes / POWER (1024, 3) GB
  2    FROM user_segments
  3   WHERE segment_name = 'LOG_CONTRIBS';

        GB
----------
    3.8125

SQL>

Cette approche est tout à fait valide lorsqu’on manipule de petits jeux de données mais elle devient inopérante à mesure que les volumes augmentent.

Par curiosité, j’ai taché de suivre sur ma machine l’allocation de la mémoire virtuelle du processus rsession au fur et à mesure du chargement de la table. Pour cela, j’ai utilisé une collecte perfmon dont le paramétrage apparaît dans les deux copies d’écran ci-dessous:


Le résultat est un fichier csv: DataCollector01 dont les données ont été représentées… avec R 😉

> Rsession <- read.csv2("C:/PerfLogs/Admin/Suivi VM R/S1401037_20170222-000001/DataCollector01.csv", encoding="UTF-8", sep=",")
> names(Rsession) <- c("Dt","VMSize")
> 
> Rsession$Dt <- strptime(Rsession$Dt, "%m/%d/%Y %H:%M:%OS")
> Rsession$VMSize <- Rsession$VMSize/(1024^3)
> 
> summary(Rsession)
       Dt                          VMSize       
 Min.   :2017-02-22 10:37:58   Min.   : 0.3463  
 1st Qu.:2017-02-22 10:48:07   1st Qu.: 2.4995  
 Median :2017-02-22 10:58:16   Median : 4.6035  
 Mean   :2017-02-22 10:58:24   Mean   : 4.7239  
 3rd Qu.:2017-02-22 11:08:25   3rd Qu.: 6.7383  
 Max.   :2017-02-22 11:22:28   Max.   :11.2029  
> 
> library(ggplot2)
> 
> ggplot(data=Rsession, aes(x=Dt, y=VMSize)) +
+   geom_line(color="blue") + 
+   xlab("Heure") + 
+   ylab("Taille en GB") + 
+   theme_classic()+
+   ggtitle("Evolution de la mémoire virtuelle du processus rsession") +
+   theme(plot.title = element_text(hjust = 0.5)) +
+   theme(panel.grid.major = element_line(linetype = "dotted")) + 
+   scale_y_continuous(breaks = seq(0, 12),limits = c(0,11.5))
> 

On voit donc que la taille de la mémoire virtuelle du processus a augmentée jusqu’à atteindre 11.2GB:

Ma machine disposant de 8GB de RAM, cela signifie qu’une partie de l’allocation provenait de l’espace de swap.

Il a fallu environ 40 minutes pour que le dataframe wiki_contribs soit peuplé. Cela-dit à ce stade, l’interface RStudio était complètement gelée et il m’était impossible de travailler sur ce dataframe…

Pas d’autre choix que d’interrompre le processus:

On comprend dès lors la grande limitation de la version communautaire de R. Les données de travail sont récupérées localement ce qui s’avère non scalable. Dans la même veine, R travaille de manière sérielle et ne propose pas, par défaut, de parallélisation des algorithmes.

C’est la raison d’être de l’offre Oracle R Entreprise qui permet de s’affranchir de ces problèmes. En effet, les données restent au sein de la base Oracle (pas de rapatriement au niveau du client) et des moteurs R sont instanciés directement sur le serveur de base de données. Une couche d’abstraction entre le client R et la base permet de transformer le code R en SQL de manière transparente.

Ce sera l’objet des prochains articles!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

× 8 = sixty four