Forum du club des développeurs et IT Pro - Autres SGBD https://www.developpez.net/forums/ Vos questions sur les autres SGBD fr Fri, 17 Apr 2026 09:32:01 GMT vBulletin 15 https://forum.developpez.be/images/misc/rss.png Forum du club des développeurs et IT Pro - Autres SGBD https://www.developpez.net/forums/ Dites bonjour à GoogleSQL : Google a discrètement abandonné le nom ZetaSQL et rebaptisé son projet open source https://www.developpez.net/forums/showthread.php?t=2181924&goto=newpost Wed, 04 Feb 2026 15:35:51 GMT *Dites bonjour à GoogleSQL :... Dites bonjour à GoogleSQL : Google a discrètement abandonné le nom ZetaSQL et rebaptisé son projet open source d'analyse et d'analyse syntaxique SQL « GoogleSQL »

Google a récemment mis à jour ses documents destinés au public afin d'utiliser le nom GoogleSQL, soulignant que le dialecte est commun à tous les produits. Le changement de nom du package open source vient compléter cette harmonisation. L'objectif principal est de réduire la confusion et de permettre aux ingénieurs d'identifier plus facilement la technologie, qu'ils soient clients de Google Cloud, membres du personnel interne ou contributeurs open source.

Google a officiellement renommé son projet open source ZetaSQL « GoogleSQL ». Cette mise à jour unifie la marque pour le dialecte SQL, l'analyse et les bibliothèques d'analyse syntaxique utilisées dans les services internes de Google, les plateformes cloud et la communauté externe de développeurs. GoogleSQL est le dialecte SQL standard pour les principaux services tels que BigQuery et Spanner.

Bien que les ingénieurs de Google aient appelé en interne le composant linguistique « GoogleSQL », l'entreprise n'utilisait pas à l'origine ce nom pour les descriptions externes des produits. Par conséquent, alors que le référentiel open source donnait accès à la même base SQL, il fonctionnait sous la bannière ZetaSQL, ce qui le séparait de la terminologie utilisée dans la documentation commerciale.

Google a récemment mis à jour ses documents destinés au public afin d'utiliser le nom GoogleSQL, soulignant que le dialecte est commun à tous les produits. Le changement de nom du package open source vient compléter cette harmonisation. L'objectif principal est de réduire la confusion et de permettre aux ingénieurs d'identifier plus facilement la technologie, qu'ils soient clients de Google Cloud, membres du personnel interne ou contributeurs open source.

Pour les développeurs, cette mise à jour ne nécessite aucune migration technique immédiate. Google précise qu'il s'agit principalement d'un changement de marque par rapport à ZetaSQL ; la technologie sous-jacente, les fonctionnalités et l'équipe d'ingénieurs restent les mêmes. Le référentiel open source continuera à fonctionner sous le nouveau nom. Cette unification clarifie la relation entre les outils open source et les moteurs d'entreprise. Elle confirme que l'analyseur syntaxique disponible sur GitHub prend en charge le dialecte SQL exact utilisé dans BigQuery et Spanner. En consolidant la terminologie, Google vise à renforcer l'écosystème et à améliorer l'accessibilité pour sa base d'utilisateurs.

Nom : 1.jpg Affichages : 41201 Taille : 55,9 Ko

Présentation de SQL dans BigQuery

GoogleSQL est un langage de requête structuré (SQL) conforme à la norme ANSI, qui inclut les types d'instructions compatibles suivants :

- Les instructions de requête, également appelées instructions de langage de requête de données (Data Query Language), constituent la méthode principale d'analyse des données dans BigQuery. Elles analysent une ou plusieurs tables ou expressions, et renvoient des lignes de calculs de résultats. Les instructions de requête peuvent inclure la syntaxe pipe.

- Les instructions de langage procédural sont des extensions procédurales de GoogleSQL qui vous permettent d'exécuter plusieurs instructions SQL dans une seule requête. Les instructions procédurales peuvent utiliser des variables et des instructions de flux de contrôle, et peuvent avoir des effets secondaires.

- Les instructions LDD (langage de définition de données) vous permettent de créer et de modifier des objets tels que les suivants : Ensembles de données, Tables, y compris leur schéma et les types de colonnes, Clones et instantanés de table, Vues, Fonctions, Index, Engagements, réservations et attributions de capacité, Règles d'accès au niveau des lignes

- Les instructions LMD (langage de manipulation de données) vous permettent de mettre à jour, d'insérer et de supprimer des données dans vos tables BigQuery.

- Les instructions LDD (langage de contrôle de données) vous permettent de contrôler les ressources système BigQuery telles que l'accès et la capacité.

- Les instructions TCL (Transaction Control Language) vous permettent de gérer les transactions pour les modifications de données.

- Les instructions de chargement et les instructions d'exportation pour gérer les données entrantes et sortantes de BigQuery.

Voici l'annonce de Google :

ZetaSQL est rebaptisé GoogleSQL

Nous sommes ravis d'annoncer un changement mineur, mais important : le projet open source connu sous le nom de ZetaSQL a été officiellement renommé GoogleSQL (https://github.com/google/googlesql). Cette décision permet d'unifier le nom de notre puissant dialecte SQL et de nos bibliothèques d'analyse et d'interprétation sous une seule et même bannière, que vous l'utilisiez dans le cloud et les services internes de Google ou dans le cadre de la communauté open source.

Depuis des années, GoogleSQL est le dialecte SQL standard de nombreux services Google tels que BigQuery et Spanner. À l'origine, bien que nous appelions le composant linguistique GoogleSQL en interne, nous n'utilisions pas ce nom pour décrire le dialecte dans nos produits destinés au grand public. Depuis, nous avons commencé à utiliser le nom GoogleSQL dans nos produits et notre documentation destinés au grand public, afin de souligner qu'il s'agit du même dialecte partagé par tous les produits.

Aujourd'hui, nous renommons également le package open source afin de souligner qu'il prend en charge le même dialecte SQL que celui utilisé dans BigQuery, Spanner et d'autres produits. L'objectif de l'open source a toujours été de permettre aux développeurs extérieurs à Google de tirer parti de la même base SQL robuste et conforme. Avec ce changement de nom, nous souhaitons réduire la confusion et permettre à chacun de trouver et de discuter plus facilement de cette technologie exceptionnelle. Que vous soyez ingénieur interne, client Google Cloud ou développeur open source, vous utilisez GoogleSQL.

Il s'agit principalement d'un changement de marque. La technologie, les fonctionnalités et l'équipe qui la soutient restent les mêmes. Le référentiel open source continuera à prospérer, arborant désormais fièrement le nom GoogleSQL. Nous pensons que cette unification renforcera l'écosystème GoogleSQL, le rendant plus accessible et plus compréhensible pour notre communauté croissante d'utilisateurs et de contributeurs.

Nous sommes enthousiasmés par ce nouveau chapitre de GoogleSQL dans le monde open source et nous nous réjouissons de poursuivre notre collaboration et notre innovation avec la communauté.

Source : Annonce de Google

Et vous ?

:fleche: Pensez-vous que cette annonce est crédible ou pertinente ?
:fleche: Quel est votre avis sur le sujet ?

Voir aussi :

:fleche: Google affirme que son agent LLM « Big Sleep » a découvert une vulnérabilité zero-day exploitable dans SQLite. L'entreprise estime que l'IA pourrait être l'avenir de la détection de bogue dans les logiciels

:fleche: SQL à 50 ans : comment ce vétéran de la technologie continue-t-il à prospérer dans un paysage en constante mutation ? Une leçon sur la façon de rester pertinent en matière de données

:fleche: Le Big Data serait mort, d'après Jordan Tigani, ingénieur fondateur de Google BigQuery, alors que pour IDC, le marché du Big Data enregistrera une forte croissance dans les années à venir
Images attachées
 
]]> Autres SGBD Alex https://www.developpez.net/forums/d2181924/bases-donnees/autres-sgbd/dites-googlesql-google-discretement-abandonne-nom-zetasql-rebaptise-projet-open-source/ Comment nous avons remplacé Elasticsearch et MongoDB par Rust et RocksDB, par Radar https://www.developpez.net/forums/showthread.php?t=2178725&goto=newpost Wed, 20 Aug 2025 14:11:14 GMT *Comment nous avons remplacé... Comment nous avons remplacé Elasticsearch et MongoDB par HorizonDB avec Rust et RocksDB pour améliorer les performances, par Radar

Chez Radar, la performance est une fonctionnalité. Notre plateforme traite plus d'un milliard d'appels API par jour provenant de centaines de millions d'appareils à travers le monde. Nous fournissons une infrastructure et des solutions de géolocalisation, notamment des API pour :

  • Géocodage : API de géocodage direct, de géocodage inversé et de géocodage IP avec une couverture mondiale.
  • Recherche : API de saisie semi-automatique d'adresses, de validation d'adresses et de recherche de lieux.
  • Routage : API de distance, de matrice, d'optimisation d'itinéraire, de correspondance d'itinéraire et d'itinéraires.
  • Conformité en matière de géolocalisation : détection de la juridiction actuelle, de la distance par rapport à la frontière, des zones d'exclusion réglementaires, etc.

Mais à mesure que nos produits et nos données évoluent, nos défis techniques évoluent également.

Pour soutenir cette croissance, nous avons développé HorizonDB, une base de données géospatiale écrite en Rust qui consolide plusieurs services de localisation en un seul binaire hautement performant. Avec HorizonDB, nous sommes en mesure de prendre en charge tous les cas d'utilisation ci-dessus avec une excellente empreinte opérationnelle :

  • Gérer 1 000 QPS par cœur.
  • Maintenir une latence médiane de géocodage direct de 50 ms.
  • Maintenir une latence médiane de géocodage inverse inférieure à 1 ms.
  • Évoluer de manière linéaire sur du matériel standard.

Pourquoi nous avons remplacé Mongo et Elasticsearch

Avant HorizonDB, nous répartissions le géocodage entre Elasticsearch et des microservices pour le géocodage direct, et MongoDB pour le géocodage inverse.

L'exploitation et la mise à l'échelle de cette pile étaient coûteuses : Elasticsearch diffusait fréquemment les requêtes à tous les shards et nécessitait des mises à jour par lots orchestrées par le service, tandis que MongoDB ne disposait pas d'une véritable ingestion par lots, nécessitait un surprovisionnement et ne disposait pas d'une fonctionnalité fiable de restauration en masse pour les données erronées.

L'architecture

Nos objectifs pour ce service étaient les suivants :

  1. Efficacité : le service peut fonctionner sur des machines standard, dispose d'une mise à l'échelle automatique prévisible et constitue la source unique de vérité pour toutes nos entités géographiques.
  2. Opérations : les ressources de données peuvent être créées et traitées plusieurs fois par jour, les modifications peuvent être déployées et annulées facilement, et le service doit être simple à utiliser.
  3. Expérience des développeurs : les développeurs doivent pouvoir exécuter le service localement, et les modifications doivent pouvoir être écrites et testées facilement.

Avec ces objectifs à l'esprit, nous avons créé HorizonDB à l'aide de RocksDB, S2, Tantivy, FSTs, LightGBM et FastText.

Les ressources de données sont prétraitées à l'aide d'Apache Spark, ingérées dans Rust et stockées sous forme de ressources versionnées dans AWS S3.


Nom : 1.jpg Affichages : 41236 Taille : 37,4 Ko
Figure 1 : Le serveur HorizonDB est un processus multithread unique qui interroge simultanément différentes « couches » et reclassifie les candidats de manière uniforme.

Rust

Un langage compilé conçu par Mozilla pour la programmation système. L'équipe a apprécié de nombreux aspects de Rust :

  • Compilation et sécurité de la mémoire sans ramasse-miettes : le système de types forts de Rust et la concurrence sûre et expressive sous la forme de Rayon et Tokio nous permettent d'écrire du code performant sans sacrifier la lisibilité. Rust facilite la gestion de la mémoire sans ramasse-miettes, ce qui nous permet de gérer de grands index de données en mémoire avec une latence prévisible.

  • Abstractions d'ordre supérieur : bon nombre de nos ingénieurs travaillent avec des langages de haut niveau où les opérations de liste expressives, la gestion des valeurs nulles et la correspondance de motifs sont monnaie courante. Rust dispose de ces primitives, ce qui permet à notre équipe d'avancer rapidement et d'exprimer clairement la logique, ce qui est important lorsqu'il s'agit de logique complexe telle que le classement des recherches.

  • Multithread et non multiprocessus : HorizonDB devant récupérer des centaines de Go de données à partir de SSD, il est plus efficace d'avoir un seul processus pouvant exploiter le même espace d'adressage mémoire que notre langage de couche API TypeScript déployé sur Node.js, qui consacre un nouveau processus à chaque cœur.

RocksDB

Un arbre LSM (Log-Structured Merge) en cours de traitement, qui sert de stockage principal pour nos enregistrements. Il est incroyablement rapide, avec des temps de réponse généralement de l'ordre de la microseconde (même avec un ensemble de données beaucoup plus volumineux, il est plus rapide que d'autres solutions hautes performances).

S2

S2 est la bibliothèque d'indexation spatiale de Google qui projette un arbre quadratique sur une sphère, transformant les recherches O(n) point-dans-polygone en recherches en temps constant pouvant être mises en cache. Lors de l'écriture de HorizonDB, nous avons écrit des liaisons Rust pour la bibliothèque C++ de Google que nous rendrons bientôt open source.

FST

Les FST sont une structure de données offrant une compression efficace des chaînes de caractères et des requêtes de préfixe. Cet article de blog d'Andrew Gallant décrit en détail comment cela est réalisé. Nous avons constaté que 80 % de nos requêtes étaient bien formées et nous voulions trouver un moyen efficace de mettre en cache ces « chemins heureux ». Grâce aux FST, nous avons pu mettre en cache des millions de ces chemins heureux sur plusieurs Mo de mémoire et souvent renvoyer des candidats de préfixe en quelques millisecondes.


Nom : 2.jpg Affichages : 2211 Taille : 29,2 Ko
Figure 2 : Un FST représente de manière compacte un corpus de mots en compressant les préfixes et suffixes courants. Les FST sont également capables d'encoder des valeurs numériques qui peuvent être récupérées lors du parcours, ce qui nous permet de compresser des métadonnées telles que la latitude et la longitude à des fins de classement.

Tantivy

Une bibliothèque d'index inversé en cours de traitement similaire à Lucene.

Nous avons décidé d'utiliser un index en cours de traitement plutôt qu'un service externe tel qu'Elasticsearch ou Meilisearch pour plusieurs raisons :

  • Qualité de la recherche : afin d'améliorer notre rappel pour des cas d'utilisation tels que la validation d'adresses, nous « élargissons » souvent nos mots-clés de recherche de manière dynamique. Cela se traduirait par l'envoi de plusieurs requêtes sur le réseau si nous utilisions un service externe.

  • Simplicité opérationnelle : tout se trouve dans le même processus, ce qui facilite considérablement la mise à l'échelle des serveurs de recherche. Le mappage mémoire nous permet d'utiliser efficacement du matériel standard avec des index volumineux. Nous avons trouvé cela beaucoup plus simple que la mise à l'échelle d'Elasticsearch, où il était très difficile de régler les paramètres JVM et d'essayer de saturer le CPU sans augmenter la latence.



Nom : 3.jpg Affichages : 2211 Taille : 31,4 Ko
Figure 3 : un index inversé (par opposition à un index direct classique comme dans une base de données SQL) permet de trouver de manière performante les documents pertinents en fonction des termes recherchés. Les identifiants des documents peuvent être compressés à l'aide de techniques telles que le codage delta. La requête « Central Park » peut être traitée de manière performante en interrogeant et en combinant les documents renvoyés par les termes « central » et « park ».

FastText

Afin d'améliorer la précision et la qualité de la recherche, nous avons mis en œuvre un modèle FastText formé à partir d'un mélange de notre corpus de géocodeurs et de nos journaux de requêtes. Avec FastText, nous pouvons représenter sémantiquement les mots d'une requête sous forme de vecteurs numériques, adaptés aux applications d'apprentissage automatique. FastText tolère les fautes de frappe et gère les mots hors vocabulaire grâce à l'utilisation de ngrams. Les vecteurs « proches » représentent des mots sémantiquement similaires, ce qui permet à nos algorithmes d'apprentissage automatique de comprendre la sémantique d'un mot donné dans une requête de recherche.

LightGBM

Nous avons formé plusieurs modèles LightGBM pour classer l'intention des requêtes et baliser certaines parties de nos requêtes en fonction de cette intention. Cela nous permet de « structurer » nos requêtes, améliorant ainsi les performances et la précision de la recherche. Par exemple, une requête considérée comme régionale, telle que « New York », peut ignorer la recherche d'adresse, tandis qu'une requête telle que « 841 broadway » nous permet d'ignorer la recherche de points d'intérêt et de régions.

Apache Spark

Avec Spark, nous sommes en mesure de traiter des centaines de millions de points de données en moins d'une heure, avec une évolutivité quasi linéaire. Nous devions souvent ajuster ou refactoriser les tâches pour obtenir des performances optimales lors des jointures ou des agrégations.

Comme nos données sont écrites dans S3, il devient facile d'inspecter les résultats via Amazon Athena, un déploiement hébergé d'Apache Presto qui peut lire les ressources de stockage d'objets à l'aide de SQL. DuckDB est un autre outil léger que nos ingénieurs utilisent pour inspecter ces ressources à la volée.


Résultats

HorizonDB a transformé à la fois les aspects opérationnels et développementaux de nos offres de géolocalisation. Nous avons obtenu des améliorations générales en termes de coût, de performances et d'évolutivité :

  • Notre service est désormais plus rapide, plus simple à utiliser et plus fiable.
  • Nos développeurs sont en mesure de réagir rapidement aux nouvelles fonctionnalités et aux modifications des données. Nous sommes capables d'ingérer et d'évaluer de nouvelles sources de données en moins d'une journée.
  • Nous avons fermé plusieurs clusters Mongo, un grand cluster Elasticsearch et plusieurs microservices géographiques, ce qui nous a permis d'économiser plusieurs dizaines de milliers de dollars en coûts mensuels.

Nous sommes satisfaits de nos choix de conception avec HorizonDB et sommes prêts à évoluer dans un avenir proche. Nous aborderons la manière dont nous avons conçu certaines fonctionnalités du système dans de futurs articles de blog.

Un grand merci à nos ingénieurs Bradley Schoeneweis, Jason Liu, Jacky Wang, Binh Robles, Greg Sadetsky, David Gurevich et Felix Li, qui ont travaillé d'arrache-pied pour faire de ce système une réalité.

À propos de Radar

Radar relie les mondes numérique et physique grâce à une infrastructure de localisation pour chaque produit et service. La société a été fondée en 2016 par Nick Patrick et Coby Berman, deux anciens collègues de Foursquare qui ont dix ans d'expérience dans la création et la vente de produits et services basés sur la localisation.

Source : Radar

Et vous ?

:fleche: Pensez-vous que cette déclaration est crédible ou pertinente ?
:fleche: Quel est votre avis sur le sujet ?

Voir aussi :

:fleche: Comment nous avons économisé 98 % des coûts du cloud en écrivant notre propre base de données, par Hivekit

:fleche: Redéfinir la base de données pour l'IA : pourquoi MongoDB a acquis Voyage AI, par Dev Ittycheria, PDG de MongoDB

:fleche: Elasticsearch est à nouveau open source, en ajoutant l'AGPL, conforme à l'OSI, comme troisième option, après trois ans où les produits d'Elastic ne possédaient qu'une double-licence non open source
Images attachées
   
]]> Autres SGBD Jeff Kao https://www.developpez.net/forums/d2178725/bases-donnees/autres-sgbd/avons-remplace-elasticsearch-mongodb-rust-rocksdb-radar/