Connecter MySQL HeatWave vers Excel, Google Sheets, l'IA et REST

OCI est privé, AWS est public, et cela influence l'emplacement de l'agent.

HeatWave est vendu comme un seul produit mais se déploie sous deux formes, et cette différence détermine votre emplacement d'installation plutôt que vos paramètres de connexion.

• Sur OCI, un système de base de données HeatWave réside au sein de votre VCN et n'est pas accessible depuis Internet. Installez l'agent sur une instance Compute de ce même VCN et configurez-le pour qu'il pointe vers le point de terminaison privé.
• Sur AWS, HeatWave expose un point de terminaison TLS public. L'agent peut s'exécuter partout où il est accessible, y compris sur votre propre matériel.
• Dans les deux cas, l'agent n'établit que des connexions sortantes. Aucune règle entrante n'est à ajouter, aucun port d'entrée à ouvrir sur le VCN et aucun VPN n'est établi entre votre réseau et le nôtre.
• Les paramètres de connexion eux-mêmes restent identiques. Même port, mêmes champs, même pilote. — seuls le point de terminaison et l'emplacement judicieux de l'agent diffèrent.

TLS est la case à cocher, et elle est activée par défaut.

Il est important d'être précis à ce sujet, car les deux configurations de déploiement de HeatWave présentent une exposition réellement différente.

• L'utilisation du protocole SSL est activée par défaut et, lorsqu'elle est activée, la connexion est chiffrée. — l'agent demande à MySQL une session TLS requise.
• Désactivez cette option et l'agent tentera une connexion non chiffrée. Rien ici ne modifie ce comportement en fonction du point de terminaison ; la case à cocher constitue donc l'intégralité du mécanisme.
• Cela a une importance capitale sur AWS, où le point de terminaison est public. Sur Internet, l'activation du protocole TLS est, en pratique, indispensable.
• Le chiffrement ne constitue pas une vérification de certificat. L'agent requiert TLS mais ne valide pas la chaîne de certificats du serveur ; il faut donc le considérer comme une protection contre l'écoute clandestine plutôt que comme une preuve de l'identité du serveur auquel vous avez accédé.

En dessous, il y a MySQL, et c'est là l'essentiel.

Le moteur d'analyse de HeatWave est développé par Oracle. Query Streams utilise une connexion MySQL.

• L'agent se connecte à un pilote MySQL standard et exécute des requêtes SQL classiques en lecture seule. Le chemin d'exécution des requêtes n'a rien de spécifique à HeatWave.
• MySQL ne possède pas de couche de schéma distincte ; c’est donc la base de données qui sert de qualificatif. C’est ce que représente une référence inter-sources.
• Les requêtes inter-bases de données sur une connexion HeatWave fonctionnent de la même manière que sur n'importe quel serveur MySQL, de sorte qu'une seule connexion peut atteindre plusieurs bases de données.
• Il est judicieux de créer un utilisateur en lecture seule. Les flux de requêtes n'écrivent pas, mais la meilleure façon de garantir cela est de le faire au niveau de la base de données plutôt que dans l'outil.

-- MySQL ordinaire, lecture seule, sur TLS SELECT c.name, COUNT(o.id) AS orders, SUM(o.amount) AS revenue FROM customers AS c JOIN orders AS o ON o.customer_id = c.id WHERE o.placed_at >= NOW() - INTERVAL 30 DAY GROUP BY c.name ORDER BY revenue DESC;