À lire avant de commencer

Vous pouvez répondre aux questions et mes les envoyer par mail aux formats Markdown avec comme sujet [BDA TD x] prénom nom depuis votre mail universitaire.

Par exemple, pour rendre le TD n°2, il me faudrait indiquer [BDA TD 2] Charles Paperman

Il faut impérativement respecter cette syntaxe et utiliser votre mail universitaire sinon le sujet sera considéré comme non rendu et vaudra 0 immédiatement.

Chaque TD doit être rendu à la fin de la séance, mais il est possible de soumettre une nouvelle version améliorée durant la semaine qui vient (jusqu’au début du cours de la semaine suivante). Les morceaux de codes peuvent être joint en PJ ou intégré au Markdown en respectant la syntaxe.

Les TD contiennent des questions à rédactions de code, à rédaction en Français, ou parfois de simples instructions à réaliser. Pour ces dernières vous pouvez indiquer les difficultés rencontrées et comment vous les avez contournées.

Les TD peuvent être notés pour constituer votre notre de contrôle continue. Chaque semaine un certain nombre d’étudiants seront tirés au sort pour être noté. Si vous êtes très content de votre rendu, vous pouvez me l’indiquer pour que je le note (et avoir une bonne note) si vous en êtes pas du tout content, vous pouvez me l’indiquer pour avoir un joker et ne pas être noté.

À la fin du semestre, tous le monde doit avoir au moins une note de TD noté aléatoirement mais il est possible d’en avoir plusieurs si on demande à être noté explicitement.

Objectif

1. Se familiariser avec la plateforme OpenStack.
2. Installer PostgreSQL depuis les dépôts sur plusieurs VM et configurer les accès distants.
3. Réaliser un microbenchmarque sur OpenStack pour avoir une idée des performances de PostgreSQL dans cet environnement.
4. Mettre en place un mécanisme de distribution des données Primary/Replica (Optionnel)
5. Mettre en place un mécanisme de distribution des données via les FDW (Peut être)

Utilisation d’OpenStack

1. Connectez vous à openstack et créez une instance Ubuntu avec le moins de ressources possibles. On utilisera éventuellement les ressources disponibles lors d’autres TP.

Pour cela Suivez le tutoriel présent sur la plateforme. Configurez votre console local pour pouvoir vous connecter en ssh. Pour une instance ubuntu avec les clefs ssh configurées correctement il suffit de faire: ssh ubuntu@[adresse-ip] où adresse-ip est l’adresse indiquée par la plateforme.

2. Créez vous un compte personnel sur cette machine avec un nom de votre choix et configurez-vous un accès ssh par clef. Dans la suite du TP, ce compte personnel sera noté $remote.

3. Créez un compte personnel cha pour moi sur cette machine avec la clef publique trouvable ici.

4. Ajoutez dans le fichier de rendu l’adresse IP de toutes vos VM qui seront crées durant le TP.

Installation et configuration des accès au serveur PostgreSQL

4. Installez PostgreSQL depuis les dépôts et vérifiez que vous pouvez vous y connecter via l’invité de commande psql avec l’utilisateur $remote.

5. Donnez à l’utilisateur de la base de donnée $remote le droit administrateur (superuser).

6. À l’aide de la documentation du fichier de configuration pg_hba.conf, donnez les droits de connexions sécurisés (par mot de passes) à PostgreSQL depuis des machines distantes pour l’utilisateur $remote. Vérifier que vous pouvez bien vous connectez à distance depuis votre machine locale.

7. Refaites les manipulations avec l’utilisateur cha et le mot de passe de connexion ILovePostgreSQL. N’oubliez pas de le rendre administrateur également.

Une application de micro-blogging

Nous allons créer une petite application de micro-blogging (un peu comme Twitter) en utilisant PostgreSQL. Vous pouvez télécharger le schéma SQL ici.

7. Créez une base de données microblog avec votre utilisateur et exécutez dans cette base de données le contenu du fichier microblog.sql.

cat microblog.sql | psql -h $remoteip -U $remote --dbname microblog

8. Lisez le fichier microblog.sql et expliquez brièvement les différentes fonctionnalité de cette base de données.

9. Est-ce qu’il est possible pour l’utilisateur common_user:

• de récupérer la totalité des messages publiés
• de récupérer la liste des utilisateurs inscrits
• de récupérer le mot de passe d’un utilisateur inscrit

Est-il possible pour l’utilisateur possédant la base de données

• de récupérer la totalité des messages publiés
• de récupérer la liste des utilisateurs inscrits
• de récupérer le mot de passe d’un utilisateur inscrit

10. A quoi sert la ligne:

CLUSTER messages_store USING idx_pub_date;

11. (Optionnelle, difficile) Proposez une nouvelle fonction qui permette de récupérer pour chaque uuid de la base de donnée un document JSON contenant les données associée. Par exemple, ça retournera pour un utilisateur son nom et ses 10 derniers message et pour un message, son auteur et sa date de publication, son contenu et les autres informations pertinentes.

12. Modifier la configuration de PostgreSQL pour autoriser l’utilisateur common_user à ce connecter (sans mot de passe)

Des robots pour le Benchmarking

Nous allons maintenant réaliser un benchmarking simple pour mesurer les performances du microblog. Pour ce faire, nous allons simuler des utilisateurs qui utilisent l’API exposé par la base de données.

13. En en utilisant(ou adaptant) du fichier api_microblog.py dans le langage de votre choix, écrivez un programme qui simule le comportement d’utilisateurs factices sur le blog.

for i in $(seq 0 1000); do
    rig | head -n1 >> names # generate random names
    head -c 100 /dev/urandom | md5sum | cut -f1 -d " " >> pass # generate random passwords
done
paste names pass > users
rm names pass
OLDIFS="$IFS" # Sauvegarde la variable d'environement $IFS. (Voire help read)
IFS=$(echo -e '\t') # Choisi les tabulation comme séparateur.
while read name password;
do
    echo "SELECT create_user('$name', '$password')" | psql -d microblog -U common_user -h $remote_ip -t > /dev/null &
done < users
IFS="$OLDIFS"
wait $(jobs -p)
echo "#Done#

14. Indiquer le nombre de transactions par secondes (TPS) en fonction du nombre de processus que vous lancez depuis votre machine. Vous pouvez également utiliser plusieurs machine pour pousser le serveur Postgres à sa limite.

15. Redimensionnez votre instance OpenStack pour ajouter des ressources de calculs, et comparer les résultats obtenus

PostgreSQL et la disponibilité (difficile)

Afin de garantir qu’une base de données reste disponible, il est possible de configurer plusieurs serveur PostgreSQL pour travailler ensemble.

1. Créer une nouvelle VM avec PostgreSQL installé.

Dans la suite on nomme la première machine $primary et la seconde $replica et leurs IP $primary_ip et la seconde $replica_ip.

2. Modifiez sur la VM primaire l’option de postgresql.conf:

wal_level=logical

2. On va créer une replication logique de la base de données primaire sur la secondaire. Pour ce faire:

• lisez la page d’introduction sur la replication logique
• lisez la page sur la publication
• lisez la page sur la sucription

3. Créez une publication dans la base de donnée primaire pour toute les tables et une souscription dans la base de donnée secondaire.

4. Vérifiez que cette dernière fonctionne bien en envoyant un message sur la base de donnée primaire et en requêtant la base de donnée secondaire.

5. D’après vous, où ce situe cette solution par rapport au Théorème CAP vu en cours?

Compiled the: dim. 07 janv. 2024 23:19:19 CET