Discussion :

[Just-Soft]

Bonjour

Dans un salon où j'avais exposé un projet qui tourné sous firebird un des visiteurs m'avait demandé : est-ce que firebird prend en charge le bigdata ? et avec quels outils ?

alors je redirige la question vers vous ... car j'étais perplexe et j'avais pas de réponse assez convaincante.

Merci d'avance.

[SergioMaster]

Bonjour,

tout dépend de ce que l'on entend par le terme BigData
en terme de volume : Firebird 2.5 n'arrive qu'à 32 TB pour une DB , je n'ai rien trouvé en ce qui concerne Firebird 3.
en terme de capacité analytique, je ne sais pas trop ce que cela veut dire ... donc joker

Ma réponse rapide aurait donc été NON c'est un SGBD relationnel , pas NOSQL mais ce n'est pas une argumentation très convaincante (pour cela il faudrait que j'ai quelque expertise en BigData ce qui, je pense, ne sera jamais le cas)

[freud]

Bonsoir,

Firebird 2.5 n'arrive qu'à 32 TB pour une DB, je n'ai rien trouvé en ce qui concerne Firebird 3.

Pas de gros changement par rapport à FB 2.5 juste que ca été augmenter jusqu'à 64 TB et pour atteindre cette limite ça dépendra de la taille de la page comme quoi que c'est théorique.

Maximum database size is increased to 232 pages (previously 231 pages).
The new limit is 16TB|32TB|64TB, depending on the page size.

Firebird 3.0.3 Release Notes

[SergioMaster]

@Freud Merci, je n'avais pas pensé une seconde à trouver l'information dans ce chapitre

[SQLpro]

Le "big data" concerne des données très volumineuses qui doivent faire l’objet de processus tels que :

• la capture de données,
• le stockage de données,
• l'analyse de données,
• la recherche,
• le partage,
• le transfert,
• la visualisation,
• l'interrogation,
• la mise à jour,
• la confidentialité
• ...

Il s'agit donc plus d'un traitement analytique et statistique (OLAP) que d'un traitement transactionnel comme c'est le cas des SGBD Relationnel. Les SGBDR sont dédiés à la manipulation des données de gestion et non pas à l'analyse des données. Pour ce faire il faut des bases de type OLAP qui stockent les données différemment (compression systématique, pas de stockage des NULLs, pré-calculs des agrégats, cache de résultat...)

En fait on doit parler d'OLAP et de Data Mining à grande échelle.

Les volumes attendus sont très importants, commençant par le To pour aller à plusieurs Po...
La variété de la structure de l'information est aussi très disparate : données structurées (tables de type "big table"), semi structurées (XML, JSON) , pas du tout structurées (emails, fichiers texte) faisant l'objet de "text mining"...
Et le système doit impérativement être véloce... Pour ce faire il faut implémenter des algorithme de type "map-reduce" c'est à dire d'un maillage du stockage des données sur de nombreux serveurs ce qui permet d'envoyer les requêtes en parallèle sur l'ensemble des serveurs (phase de mapping de la requête) puis de concaténer les résultats (phase de réduction - reduce) afin de générer le résultat final.

Les domaines les plus concernés sont l'analyse prédictive et comportementale... Quelques exemples : météorologie, traitement du génome, analyse prophylactique, simulation de processus physique (exemple fusion nucléaire)...

En ce moment par exemple je travaille avec deux clients sur le traitement du génome dans le domaine agricole, et les volumes attendus et les temps de réponse des SGBDR traditionnels montrent rapidement leurs limites, même si certains encapsulent des techniques d'accélération très efficaces (notamment l'indexation verticale et les tables "in memory").

Alors inutile de dire que FireBird est à des années lumières de l'ensemble de ces concepts.

Il faudrait au moins lui ajouter :
0) un moteur de stockage OLAP
1) un moteur de requête massivement parallèle
2) des algorithmes de data mining et text mining
3) du cache de résultats
4) du pre processing automatique (pré calculs d'agrégats)
5) un système de maillage des serveurs (pour faire la partie "map" de map-reduce, par exemple via le langage Pig Latin sur Hadoop)
6) un système de gestion du parallélisme via des files d'attente (pour faire la partie "reduce" de map reduce, voir Pig Latin)
7) de la compression de données
8) des types intégrés XML et JSON, GEOMETRY, GEOGRAPHY et les méthodes de manipulation qui vont avec (XQuery/XPath... JSonPath/JsonQuery..., méthodes OGC pour le spatial)
9) de l'indexation full text et de la recherche sémantique
10) de l'indexation verticales (columnstore)
11) des tables "in memory"
12) un langage d'interrogation analytique tel que MDX, XMLA, MAQL, SAQL...
13) un langage de calculs statistique (comme le langage R)
13) un langage permettant d'ajouter des fonctionnalités de types UDF propres aux autres langages (Pig Latin, MDX, MAQL...)
14) un ETL

Et enfin, tout ceci dans le cloud, car le prix d'une telle solution est inenvisageable, même pour de très grande entreprises... Pour information, j'ai un client qui travaille dans le domaine de la santé en ligne et ses analyses se font sur un groupe de plus de 1000 serveurs en parallèle. Heureusement il ne les as pas acheté... Il les loue simplement chaque fois qu'il en a besoin...

Bref, il ne m'a pas semblé que Firebird proposait quoi que ce soit de la liste ci avant.

Pour Information dans un SGBDR comme SQL Server on trouve :
0) un moteur de stockage OLAP (SSAS)
1) un moteur de requête massivement parallèle (SSAS / SQL Server)
2) des algorithmes de data mining et text mining (SSAS)
3) du cache de résultats (SSAS)
4) du pre processing automatique (pré calculs d'agrégats) (SSAS)
5) un système de maillage des serveurs (pour faire la partie "map" de map-reduce, par exemple via le langage Pig Latin sur Hadoop) --> via Azure
6) un système de gestion du parallélisme via des files d'attente (pour faire la partie "reduce" de map reduce, voir Pig Latin) --> via Azure
7) de la compression de données (SSAS / SQL Server)
8) des types intégrés XML et JSON, GEOMETRY, GEOGRAPHY et les méthodes de manipulation qui vont avec (XQuery/XPath... JSonPath/JsonQuery..., méthodes OGC pour le spatial) (SSAS / SQL Server)
9) de l'indexation full text et de la recherche sémantique (SQL Server)
10) de l'indexation verticales (columnstore) (SQL Server)
11) des tables "in memory" (SQL Server)
12) un langage d'interrogation analytique tel que MDX, XMLA (QL Server)
13) un langage de calculs statistique (comme le langage R) (SQL Server)
13) un langage permettant d'ajouter des fonctionnalités de types UDF propres aux autres langages (Pig Latin, MDX, MAQL...) (SQL Server / SSAS via Python)
14) un ETL (SSIS)

Bref, à part la partie map-reduce qu'il faut faire dans le cloud (ou bien simuler via Service Broker), tout peut se faire dans une instance SQL Server doté des moteurs SQL Server, SSAS (SQL Server Analysis Services) et SSIS (SQL Server Integration Services), ces modules étant inclus dans les versions standard et Enterprise...

A +