Green IT et les bases de données

Green IT et les bases de données Christophe Villeneuve @hellosct1
@[email protected] Capitole du Libre 2024

Atos open source - afup – lemug.fr – mariadb –
drupal – mozilla - firefox – lemugfr - sumo – webextensions – VR – AR – XR - Cause commune 93.1 FM - TechSpeaker - Lizard - eyrolles – editions eni – programmez – linux pratique – webriver – elephpant - CommonVoice – Sécurité - Cybersécurité Christophe Villeneuve • Consultant Open Source • Dresseur animaux

@hellosct1 – Capitole du libre 2024 Aujourd’hui • Consommation des
données • Astuces pour les requêtes • Autour de son fonctionnement

@hellosct1 – Capitole du libre 2024 • Consommation des données
• Astuces pour les requêtes • Autour de son fonctionnement

@hellosct1 – Capitole du libre 2024 Etude 2022 ADEME +
ARCEP • analysent les impacts liés aux équipements et infrastructures sur l’ensemble de leur cycle de vie https://infos.ademe.fr/magazine-avril-2022/faits-et-chiffres/numerique-quel-impact-environnemental/

@hellosct1 – Capitole du libre 2024 Optimiser les requêtes SQL
• Processus visant à garantir que vos requêtes fonctionnent efficacement • But pour la base de données – Réduction des temps de chargement – Réduction de la consommation de ressources – Améliorations des performances de votre base de données • Aide les équipes de données les performances médiocres des requêtes – Identifier – Améliorer • Objectif – Aaméliorer l'efficacité et les performances de la base de données – Minimiser le temps de réponse de vos requêtes en utilisant au mieux les ressources de votre système. • Réduire le temps de réponse • Temps d'exécution du CPU réduit • Amélioration du débit .

@hellosct1 – Capitole du libre 2024 Checklist Eco-design • Définir
les priorités d’un projet web https://collectif.greenit .fr • But – pour l’eco-design WEB • Checklist – TOP 100 – 5 niveaux de priorité https://collectif.greenit.fr/ecoconception-web/2022-05-Ref-eco_web-checklist.v4.pdf • Points d’attention – HTML – Langage – CSS – Javascript – Hébergement – Base de données – ...

@hellosct1 – Capitole du libre 2024 Partie dédiée : base
de données • Web eco-design checklist V3 V4 Description Priorité 74 N/A Eviter d'écrire SELECT * FROM... 1 64 16 Mettre en cache les données calculées souvent utilisées 4 76 17 Eviter le transfert de grandes quantités de données 3 N/A 23 Réduire le volume de données stockées au strict nécessaire 4 73 24 Ne se connecter à une base de données que si nécessaire 3 N/A 25 Favoriser le "Request collapsing" 2 N/A 29 Utiliser la version la plus récente du langage 3 17 62 Choisir un format de données adapté 4 72 64 Eviter d'effectuer des requêtes SQL à l'intérieur d'une boucle 3 75 64 Optimiser les requêtes aux bases de données(Limiter le nombre de résultat) 3 92 72 Mettre les caches entièrement en RAM 2 N/A 78 Définir une politique d'expiration et suppression des données 4 93 79 Stocker les données dans le cloud 2 90 92 Optimiser l'efficacitré énégétique des serveurs 2 91 93 Installer le minimum requis sur le serveur 3 87 94 Provolégier une électricité à plus faibles inpacts environnementaux 3 106 N/A Désactiver les logs binaires MariaDB / MySQL... 2

@hellosct1 – Capitole du libre 2024 Soutenir les technologies vertes
• Les préoccupations ESG – Environnementales – Sociales – en matière de Gouvernance • Les changements fondés sur les critères ESG – Entraîner une réduction des coûts et une efficacité accrue – Réduire l'empreinte carbone. • Objectifs : – Moins de machines nécessitent moins de place. – Les petites salles d'ordinateurs nécessitent moins d'énergie – Les technologies plus récentes permettent une utilisation économe en énergie du CPU

@hellosct1 – Capitole du libre 2024 Indexation SQL (1/ •
Présence d’index ! • Assurer que vous utilisez efficacement – Les index pour cartographier vos tableaux. • Un index SQL – Une structure de données associée à une table ou une vue • Accélère la récupération des lignes de la table – sur la base des valeurs dans une ou plusieurs colonnes. Exemple : Principe d’un guide de référence pour votre base de données Facilite le moyen de localiser les lignes (sans scanner une table entière)

@hellosct1 – Capitole du libre 2024 Indexation SQL : différent
type d’index • Index groupé: – Les index en grappes commandent physiquement les colonnes en fonction de leurs valeurs réelles, de sorte qu'elles ne sont utiles que lorsque les valeurs de colonne sont en ordre séquentiel ou trié. • Index non groupé: • Les indices non groupés créent deux colonnes, l'une pour l'indice et l'autre pour la valeur, généralement utilisée pour la cartographie ou le glossaire. • Index plein texte: • Les index en texte intégral vous permettent de rechercher à travers des colonnes qui sont lourdes. • Indice unique: • Un index unique assure, vous l'avez deviné, que les valeurs dans les colonnes indexées à travers le tableau sont uniques. • Index de recouvrement: • Un index de recouvrement est conçu pour « couvrir » une requête en incluant toutes les colonnes nécessaires pour satisfaire la requête dans l'index. • Index filtré: • Un index filtré est un indice non groupé avec une clause WHERE, de sorte qu'il ne comporte qu'un sous-ensemble de lignes dans le tableau. • Index spatiaux: • Les indices spatiaux sont des indices spécialisés utilisés pour les données spatiales. • Index de colonnenstore • Les index Columnstore organisent les données par colonnes, ce qui peut être bénéfique pour les requêtes analytiques.

@hellosct1 – Capitole du libre 2024 Index SQL (3/

@hellosct1 – Capitole du libre 2024 Exemple SELECT * FROM
customers WHERE customer_id IN ( SELECT customer_id FROM orders WHERE order_date >= DATEADD(day, -30, GETDATE()) );

@hellosct1 – Capitole du libre 2024 Index SQL : non
groupés • Index non groupés – colonnes distinctes • l'une pour l'indice • l'autre qui pointe vers la valeur. • Utilsiation – Cartographier des tables ou même tout type de glossaire. • Comportement – Certaines valeurs de colonne qui pointent vers un emplacement spécifique • Effet – Index pointe directement sur les données. • Exemple – Si deux indices→ les index en cluster sont la voie à suivre. – Résultat : Plus rapide et consomma moins de mémoire pour fonctionner

@hellosct1 – Capitole du libre 2024 Index SQL : texte
intégral • Index en texte intégral – Permettent de rechercher à travers des colonnes avec beaucoup de texte – comme ceux qui contiennent des articles ou du contenu de l'e-mail. • Ce type d'index – mémorise la position des termes trouvés dans le champ indexé – Rend beaucoup plus facile à trouver

@hellosct1 – Capitole du libre 2024 Index SQL

@hellosct1 – Capitole du libre 2024 Choisir les bons types
de jointures • Constat : – Utilisation du mauvais type peut ralentir votre ensemble de données de manière importante. • Plusieurs types de jointures – Jointure intérieure • Inner joins ne renvoie que les enregistrements correspondants des deux tables que vous rejoignez. – Jointure externe • Outer joints retour fait correspondre et des lignes inégalées à partir des deux tables que vous rejoignez. C'est moins fréquent, alors assurez-vous de vouloir utiliser cette adhésion. – Jointure à gauche • La requête contient toutes les valeurs dans le premier tableau et seulement les tables correspondantes dans le second. – Jointure à droite : • la requête contient toutes les valeurs du deuxième tableau et seulement les enregistrements correspondants du premier.

@hellosct1 – Capitole du libre 2024 Exemple de jointure SELECT
DISTINCT c.* FROM customers c JOIN orders o ON c.customer_id = o.customer_id WHERE o.order_date >= DATEADD(day, -30, GETDATE());

@hellosct1 – Capitole du libre 2024 Jointure : LEFT JOIN
SELECT Profile.customer_name, Profile.customer_email, Address.home_state FROM customers.customer_profiles profile LEFT JOIN customers.customer_addresses address ON profile.customer_id = addresses.customer_id

@hellosct1 – Capitole du libre 2024 INNER JOIN SELECT Customer_orders.customer_id,
Order_details.order_id, Order_details.order_date FROM customers.customer_orders customer_orders INNER JOIN orders.order_details order_details ON customer_orders.customer_id = order_details.customer_id AND customer_orders.customer_order_id = order_details.order_id

@hellosct1 – Capitole du libre 2024 Jointure en illustrations

@hellosct1 – Capitole du libre 2024 Sous requetes (1/2) •
Eviter d'utiliser des sous-requêtes – dans vos modèles ou des rapports. • Les expressions de table communes – sont un moyen plus stratégique de séparer votre code en des requêtes plus petites, – Signifie que vous pouvez les valider au fur et à mesure. • Intérêt : – c'est juste un moyen plus efficace d'optimiser votre requête SELECT * FROM customers WHERE customer_id IN (SELECT customer_id FROM orders WHERE order_date >= DATEADD(day, -30, GETDATE()) );

@hellosct1 – Capitole du libre 2024 Sous requetes (2/2) SELECT
MAX(customer_signup) AS most_recent_signup FROM (SELECT customer_name, customer_phone, customer_signup FROM customer_details WHERE YEAR(customer_signup)=2023) → WITH 2023_signups AS ( SELECT customer_name, customer_phone, customer_signup FROM customer_details WHERE YEAR(customer_signup)=2023 ), Most_recent_signup AS ( SELECT MAX(customer_signup) AS most_recent_signup FROM 2023_signups ) SELECT most_recent_signup FROM Most_recent_signup

@hellosct1 – Capitole du libre 2024 Exists au lieu de
IN (1/2) • IN – Valeur est comparée à une liste de valeurs renvoyées • par une sous-requête utilisant l'opérateur IN • Utilisation d'IN peut ralentir – les performances des requêtes – Scan complet de la table sur la sous-requête

@hellosct1 – Capitole du libre 2024 Exists au lieu de
IN (2/2) • Utilisation de IN SELECT * FROM customers WHERE customer_id IN ( SELECT customer_id FROM orders WHERE order_date >= DATEADD(day, -30, GETDATE() )); SELECT * FROM customers c WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id AND o.order_date ≥ DATEADD(day, -30, GETDATE()) ); • Utilisation de EXISTS

@hellosct1 – Capitole du libre 2024 GROUP BY (1/2) •
Regroupés les données • But : – Regrouper des lignes à partir d'une ou plusieurs colonnes. • Pour optimiser les requêtes SQL – Utiliser GROUP BY • Quand c’est nécessaire. SELECT customer_id, COUNT(*) as order_count FROM orders GROUP BY customer_id;

@hellosct1 – Capitole du libre 2024 GROUP BY (2/2) •
Regroupés avec des jointures SELECT c.customer_id, c.first_name, c.last_name, o.order_count FROM customers c JOIN ( SELECT customer_id, COUNT(*) as order_count FROM orders GROUP BY customer_id) o ON c.customer_id = o.customer_id;

@hellosct1 – Capitole du libre 2024 Procédures stockés • Les
procédures stockées – Routines qui contiennent au moins une ou plusieurs instructions SQL – Exécutent une tâche ou un ensemble de tâches sur un serveur de base de données. Cela peut être utile pour plusieurs raisons, notamment: – Performances optimisées – Augmentation de la réutilisabilité du code – Renforcement de la sécurité – Amélioration de la lisibilité du code

@hellosct1 – Capitole du libre 2024 Plans d'exécution stockés •
Plan d'exécution, ou plan d'interrogation – est une représentation graphique • XML ou texte – Différentes performances d'opérations par le processeur de requête SQL. • Plusieurs types de plans d'exécution dans le serveur SQ – Plan estimé – Plan réel – Plan mis en cache • But : utiles pour fournir des informations sur – l'optimiseur de serveur SQL – le moteur d'interrogation.

@hellosct1 – Capitole du libre 2024 Conception et structure de
la base de données (1/3) • Une façon clé de concevoir – Votre base de données – Votre structure est de se concentrer • sur la normalisation des tableaux • Normalisation : – Processus d'organisation de vos données dans une base de données, – de création de tableaux • d'établissement de relations entre les tables.

la base de données (2/3) • Normaliser les données signifierait diviser le tableau ci- dessus en deux tableaux • Faire des ajouts ou des suppressions dans l'un ou l'autre tableau n'affecterait pas l'autre. La normalisation aide à affiner les données sans ajouter de doublons. • Partitionnement et le partage de données peuvent – Faciliter une maintenance plus gérable des données. – Le cloisonnement signifie diviser les données en sections plus petites et gérables pour fournir un accès plus rapide et une meilleure maintenance. – Sharding étend cela en distribuant les sections sur plusieurs serveurs ou clusters, favorisant l'évolutivité et la tolérance aux pannes.

la base de données (3/3) • Cloisonnement peut aider à améliorer – les performances de la base de données en isolant les données en sections plus petites et gérables. – Lors de l'exécution de requêtes • Lle système de base de données peut se concentrer sur des partitions spécifiques plutôt que de balayer l'ensemble des données, conduisant à une récupération et un traitement de données plus rapides. • Minimisent – les communications croisées ou utilisent la mise en cache pour réduire la latence • parti de schémas, d'index et de plans d'exécution optimisés

@hellosct1 – Capitole du libre 2024 Moniteur SQL de l'optimisation
de la requête (1/2) • Surveiller les performances des requêtes au fil du temps • Iidentifier les points d'étranglement pour réduire la latence et les temps d'exécution inutiles. • Les goulots d'étranglement du CPU peuvent être causés – Par un code inefficace – Forte simultanéité – Fuites de mémoire – Facteurs externes tels que la latence du réseau ou disque I/O • Possible exploiter les indices d'optimisation des requêtes, ou les instructions à l'optimiseur.

@hellosct1 – Capitole du libre 2024 Moniteur SQL de l'optimisation
de la requête (2/2) • Possible exploiter les indices d'optimisation des requêtes, ou les instructions à l'optimiseur. • Les types d'indices pourraient être – Table unique • Les conseils à une seule table sont indiqués sur une table ou une vue. INDEX et USE-NL sont des exemples de notes uniques. – Multi-table • Les conseils multi-tablement spécifient un ou plusieurs tableaux ou vues. LEADING est un exemple d'indice multi-table. Il est à noter que l'USE-NL (tableau1) n'est pas considéré comme un indice multi-table parce qu'il s'agit d'un raccourci pour USE-NL(table1) et USE-NL(table2). – Bloc de requête: • Les conseils de bornage de requêtes fonctionnent sur des blocs de requête uniques. STAR-TRANSFORMATION et UNNEST sont des exemples de conseils de blocs d'interrogation.

@hellosct1 – Capitole du libre 2024 Minimiser les caractères génériques
• L’utilisation des caractères comme % ou _ • Ralentissement performance → plus de ressources • Exemple • Solution – Possibilité d’ajouter un index SELECT * FROM event WHERE nom_ville >= 'T' AND nom_ville < 'U'; SELECT * FROM event WHERE nom_ville LIKE 'T%';

@hellosct1 – Capitole du libre 2024 Clause LIMIT ou TOP
(1/2) • Limiter le nombre de lignes retournées – dans les requêtes SQL • Résultat – Moins de données à traiter et à renvoyer en conséquence SELECT TOP 10 * FROM customers WHERE customer_id IN ( SELECT customer_id FROM orders WHERE order_date >= DATEADD(day, -27, GETDATE()) )

@hellosct1 – Capitole du libre 2024 Clause LIMIT ou TOP
(2/2) • Limiter le nombre de lignes retournées – dans les requêtes SQL • Résultat – Moins de données à traiter et à renvoyer en conséquence SELECT * FROM ville ORDER BY nom_ville ASC LIMTI 10 ;

@hellosct1 – Capitole du libre 2024 Structure d’une table (1/2)
DECLARE @tmpTableSizes TABLE ( tableName VARCHAR(100), numberofRows VARCHAR(100), reservedSize VARCHAR(50), dataSize VARCHAR(50), indexSize VARCHAR(50), unusedSize VARCHAR(50) )

@hellosct1 – Capitole du libre 2024 Structure d’une table (2/2)
INSERT @tmpTableSizes EXEC sp_MSforeachtable @command1="EXEC sp_spaceused '?'" SELECT tableName, CAST(numberofRows AS INT) 'numberOfRows', CAST(LEFT(reservedSize, LEN(reservedSize) - 3) AS INT) 'reservedSize KB', CAST(LEFT(dataSize, LEN(dataSize) - 3) AS INT) 'dataSize KB', CAST(LEFT(indexSize, LEN(indexSize) - 3) AS INT) 'indexSize KB', CAST(LEFT(unusedSize, LEN(unusedSize) - 3) AS INT) 'unusedSize KB' FROM @tmpTableSizes ORDER BY [reservedSize KB] DESC

@hellosct1 – Capitole du libre 2024 Defragmenter les tables •
Defrag les tables • Exemple OPTIMIZE TABLE users;

@hellosct1 – Capitole du libre 2024 Choisir Storage Engine •
InnoDB – Bon moteur de stockage de transactions générales, et le meilleur choix dans la plupart des cas. – C'est le moteur de stockage par défaut. • Aria – Amélioration plus moderne de MariaDB sur MyISAM – Faible encombrement et permet une copie facile entre les systèmes • MyISAM – Peu encombrant et permet une copie facile entre les systèmes. – MyISAM est le plus ancien moteur de stockage de MySQL. Il n'y a généralement que peu de raisons de l'utiliser, si ce n'est à des fins d'héritage. Aria est l'amélioration la plus moderne de MariaDB. https://mariadb.com/kb/en/choosing-the-right-storage-engine/

@hellosct1 – Capitole du libre 2024 Allocation Mémoire • MariaDB
utilise la mémoire – pour stocker différentes structures de données, – telles que • le cache des requêtes, • le cache des tables • le pool de tampons. • Tenez compte des éléments suivants lorsque vous allouez de la mémoire : – la taille de votre base de données – Le nombre de connexions simultanées – Les types de requêtes exécutées

@hellosct1 – Capitole du libre 2024 ANALYZE (1/ • Anciennement
: explain analyze • Améliore le fonctionne – Le traitement des requetes – Des tables – NoSQL (JSON) • SHOW ANALYZE [FORMAT=JSON] FOR <connection_id>; – Show analyze

@hellosct1 – Capitole du libre 2024 SHOW analyze (1/2) •
Problèmes avec 1 database • MariaDB met à disposition – avec l'ANALYSE de MariaDB pour les déclarations. • ANALYSE – exécute la requête et produit la sortie EXPLAIN, – Modifiée avec les données de l'exécution de la requête

@hellosct1 – Capitole du libre 2024 SHOW analyze (2/2) ANALYZE
SELECT * FROM orders, customer WHERE customer.c_custkey = orders.o_custkey AND customer.c_acctbal < 0 AND orders.o_totalprice > 200*1000

@hellosct1 – Capitole du libre 2024 ANALYZE (2/ • ANALYZE
format = JSON • Exemple ANALYZE FORMAT=JSON SELECT COUNT(*) FROM customer WHERE (SELECT SUM(o_totalprice) FROM orders WHERE o_custkey=c_custkey) > 1000*1000; EXPLAIN: { "query_block": { "select_id": 1, "r_loops": 1, "r_total_time_ms": 39872, "table": { "table_name": "customer", "access_type": "index", "key": "i_c_nationkey", "key_length": "5", "used_key_parts": ["c_nationkey"], "r_loops": 1, "rows": 150303, "r_rows": 150000, "r_total_time_ms": 270.3, "filtered": 100, "r_filtered": 60.691, "attached_condition": "((subquery#2) > <cache>((1000 * 1000))) "using_index": true }, https://mariadb.com/kb/en/analyze-format-json/

@hellosct1 – Capitole du libre 2024 Surveiller • Optimisation de
la requête SQL est essentielle – Pour améliorer les performances de la base de données – Optimiser vos requêtes SQL – Consommation – Surveillance continue des performances des requêtes. • Observabilité des données est essentielle – pour surveiller la santé de vos données au fur et à mesure que vous optimisez vos requêtes SQL.

@hellosct1 – Capitole du libre 2024 Grands principes • Parier
sur l’endurance – Allonger la durée de vie des serveurs • Viser la Sobriété – Sélectionner les fournisseurs • Eliminer le superflu – Réduire les volumes • S’équiper léger – Dimensionner correctement • Mutualiser – Regrouper les ressources

@hellosct1 – Capitole du libre 2024 Grands axes : Matériels
• Hébergement – Quel est le PUE du datacenter ? • Pression sur les datacenters (PUE) – Quel est la source d’energie du datacenter ? – DCIM : datacenter infra management • Matériel – Tout se joue à l’achat ! – Intégrer l’empreinte écologique dans les critères de choix – Exemple : • Les disques SSD consomme 5X moins et produisent moins de chaleur – Durabilité • Repenser « l’amortissement » ! • Amortissement comptable sur 3 ans • “Pousser” la durée de vie à 5 à 6 ans, voire 8

@hellosct1 – Capitole du libre 2024 Disque dur

@hellosct1 – Capitole du libre 2024 Grands axes : OS
• Préférez Linux ! – Linux / MariaDB • Fonctionne sur du matériel ancien, Rasberry PI – Pas obsolescence programmée dans les logiciels libres • Mutualisation du Stockage / Virtualisation • Dimensionner les ressources “au plus juste” • Protocole – XFS ou ZFS

@hellosct1 – Capitole du libre 2024 Grands axes : Base
de données • Optimiser – Optimiser la configuration ! – La config par défaut est minuscule – Réécrire les requêtes lentes ( EXPLAIN ) • Identifier les requêtes courtes mais très nombreuses • Nettoyer – taille sur disque > taille réelle – Surveiller la fragmentation de la base

@hellosct1 – Capitole du libre 2024 Grands axes : Application
/ SQL • Application : Minimisation – Tordre le coup à la “Mentalité Big Data” – Supprimer les champs inutiles – Limiter la profondeur d’historique (pour chaque table) – La réduction des volumes est bonne pour l’optimisation des perfs • Bonus : C’est un principe RGPD ! • Les données stockées doivent être adéquates, pertinentes et limitées – A ce qui est nécessaire au regard des finalités pour lesquelles elles sont traitées. • Données obsolètes, inactives ou archivables – Supprimer les index inutiles – Partionner – Archiver – Aggréger les données obsolètes – Externaliser les données “moins actives” • Attention: pour les index, un oubli peut couter cher en CPU • Piste à explorer : compression du FS : tradeoff entre CPU et Stockage

@hellosct1 – Capitole du libre 2024 Grands axes : Architecture
• Haute-Disponiblité – cluster HA = facteur 2 à 5 – A-ton besoin d’une haute dispo 99,99% ? – Quel est le bilan GES du PRA ? • microservices – macroconsommation – PostgreSQL est conçu sur des principes forts de mutualisation – 1 instance = N bases + N Schemas + N Roles – Déployer une instance par microservice est un contresens • Le cloud de Tartuffe • « Cachez cette polution que je ne saurais voir…. » • Le grand opérateur communiquent publiquement sur le Green IT – Mutualisation – Location / Flexibilité – Expertise (datacenters) / Rationalisation – Corrélation entre volumes et tarif

@hellosct1 – PHP Montreal #1 - 2024 Amélioration grâce a
MaxScale • Applique des filtres sur les flux • Masque des données • Réécriture de requête • Base de règles de filtrage • Type de requête • Fonction utilisée • Colonne sélectionnée • Fréquence des requêtes • Permet le BAN d’utilisateur et d’IP • Permet de multiplier les ports – en fonction des besoins (filtrage N3 possible)

@hellosct1 – PHP Montreal #1 - 2024 Diviser les schémas
• Le Sharding avec MaxScale [accounts_east] type=server address=192.168.56.102 port=3306 [accounts_west] type=server address=192.168.122.85 port=3306 [Sharded-Service] type=service router=schemarouter servers=accounts_west,accounts_east

@hellosct1 – PHP Montreal #1 - 2024 Maxscale : Aperçu
• Basic – Performance et évolutivité • Répartition lecture/écriture • Équilibrage de charge adaptatif • Lecture causale • Mise en cache des résultats de requête avec Redis – HA • Failover Automatique • Relecture des transactions – Plusieurs moniteurs • Environnements ColumnStore et Replicated. • Avancée – Cooperative locking • MaxScale HA • Multiple MaxScale Monitors in a Cluster • Security – Dynamic data masking – Query limitation – Limiting query results – Performance statistics – Central query logging

@hellosct1 – Capitole du libre 2024 A retenir • Beaucoup
de points importants • Standardisation… compliqué • Limiter les ressources – Cas par cas

Christophe Villeneuve @hellosct1 @[email protected] Merci

Green IT et les bases de données

Green IT et les bases de données

More Decks by hellosct1

Other Decks in Technology

Featured

Transcript