Discussion :

[valentin1993]

Bonjour à toutes et à tous,

Je me permets de poser ma question sur cette section qui me semble adaptée à ma problématique : SQL ou NoSQL ?
Je suis actuellement entrain de réaliser un projet informatique à l'aide du Framework Django couplé à une SGBD : MySQL.

Le principe est le suivant :

Mon application génère un certains nombre de documents, d'infos sur des animaux, ... avec une volumétrie de BDD qui augmentera très rapidement avec le temps (pourrait compter peut-être 1 milliard d'entrées assez rapidement).
Pour le moment, j'utilise MySQL car c'est le seul SGBD que je connaisse et qui pour mon développement me permet de gérer une centaine d'entrées. Néanmoins, j'ai plusieurs objectifs à remplir :

- Mon application va être implémentée dans plusieurs institutions indépendantes qui doivent gérer leurs données localement
- Chaque jour, un batch permettra de synchroniser la BDD locale de chaque institution vers un "Datacenter" qui regroupera toutes les informations de ces institutions (ainsi une requête de création stockera le résultat en local avant d'être poussé vers une BDD globale)
- Dans mon application, la consultation des données issues de sa propre institution se fera sur la BDD locale, sinon pour avoir des infos provenant des autres institutions cela se fera sur la BDD globale
- Possibilité de Big Data (Hadoop, ...) sur la BDD globale


A l'heure actuelle, j'ai développé l'équivalent d'une institution sur mon serveur de développement avec :

- Application codée en Django / HTML-CSS / Javascript
- Base de données MySQL


Je me suis un peu penché sur le NoSQL qui me permettra d'effectuer les opérations suivantes :

- Optimisation de la BDD pour une volumétrie de données très importante
- Réplication
- Possibilité de Big Data

--> MongoDB est sûrement le moteur NoSQL que je vais utiliser, mais j'ai plusieurs questions :


- Puis-je garder ma BDD locale en MySQL et ma BDD globale en MongoDB ?
- Si oui, dois-je utiliser des outils comme Tungsten Replicator pour passé de l'un à l'autre ? Possibilité de convertir données MySQL vers NoSQL et vice-versa ?
- Me conseilleriez-vous plutôt d'autres moteurs NoSQL ? (A savoir que c'est pour du stockage d'informations sur des animaux, formulaires, ...)

Merci beaucoup si vous avez pris le temps de lire jusqu'ici et j'attends avec beaucoup d'impatience de pouvoir en discuter avec vous !

[SQLpro]

Si vos données sont structurées à l'origine il est parfaitement stupide d'utiliser du NoSQL qui est conçu pour des données non structurée.

La question de la volumétrie est peu importante. La plupart des SGBD relationnels actuels (je parle pas d'ersatz comme MySQL qui n'a rien à voir avec le relationnel) ont des bases qui dépassent les 100 To et pour certains le péta octet (exemple Pann Starr : https://fr.wikipedia.org/wiki/Pan-STARRS).

Pour ce qui est du "voyage" des données entre les sites de production et le site central, mieux vaut que l'outil utilisé aient soit intégré au SGBD.

A mon sens, pour votre projet le mieux serait d'utiliser SQL Server :
1) version gratuite EXPRESS pour les site de production de l'info
2) version Standard ou Enterprise (payante) pour le central
3) utiliser au choix l'un des outils de réplication intégré :
- réplication transactionnelle
- service broker

A +

[valentin1993]

Si vos données sont structurées à l'origine il est parfaitement stupide d'utiliser du NoSQL qui est conçu pour des données non structurée.

Effectivement, quand j'ai commencé à développer mon projet, j'ai structuré au maximum mes données. Par exemple, chaque animal possède une fiche identité. Dès que je fais un acte de naissance, je fais appel aux clés étrangères pour reprendre les informations sur l'animal mère, etc ... Donc toutes les données sont structurées et relativement bien liées les unes aux autres.

En réalité, c'est sur les données finales que je souhaite faire du Big Data et j'ai pu dégager 3 possibilités :

- Solution 1 : Utiliser le moteur de MariaDB appelé Cassandra Engine permettant si j'ai bien compris de passer du SQL au NoSQL et donc de lancer après des process type Map/Reduce, Hadoop, ...
- Solution 2 : Utiliser MariaDB ColumnStore permettant de faire du Big Data depuis le SQL, intégration avec HDFS, requêtes SQL sur Hadoop, ...
- Solution 3 : Utiliser Sqoop ou Hadoop Applier for MySQL

Les solutions 1, 2 et 3 me semblent également bien classées et avec cet ordre de préférence. Qu'en pensez-vous ?

La question de la volumétrie est peu importante. La plupart des SGBD relationnels actuels (je parle pas d'ersatz comme MySQL qui n'a rien à voir avec le relationnel) ont des bases qui dépassent les 100 To et pour certains le péta octet (exemple Pann Starr : https://fr.wikipedia.org/wiki/Pan-STARRS).

Effectivement, je peux avoir une volumétrie très importante, des centaines de To jusqu'à peut-être des Po de données (imaginons le cas le plus poussé). Donc selon vous, si ma BDD est bien structurée, avoir des Po de données avec des requêtes de type SELECT, INSERT, .. il n'y aurait pas de problèmes de lenteur ? Sachant que côté Hardware, il y aura aucun problème : Grosse quantité de RAM, gros processeur (type Intel Xeon), ...
C'est marrant que tu ais pris Pan-STARRS comme exemple car j'ai travaillé dessus pendant mon stage de recherche de Master 2 en Astrophysique ainsi que le catalogue SMASH m'ayant permis de découvrir un nouvel amas globulaire SMASH1 l'année dernière (Je referme la parenthèse !)

Pour ce qui est du "voyage" des données entre les sites de production et le site central, mieux vaut que l'outil utilisé aient soit intégré au SGBD.

A mon sens, pour votre projet le mieux serait d'utiliser SQL Server :
1) version gratuite EXPRESS pour les site de production de l'info
2) version Standard ou Enterprise (payante) pour le central
3) utiliser au choix l'un des outils de réplication intégré :
- réplication transactionnelle
- service broker

A +

Entre temps, j'ai réfléchi à mon architecture et je pense effectuer des modifications. Je joins un schéma architectural qui résumera bien ce que je souhaite faire. Peut-être pourrais-je avoir votre avis dessus ?



Toutes les sociétés ont une BDD locale qui rassemble les paramètres d'authentification, infos société, le thème, ...
Sinon toutes les requêtes de création d'actes de naissance d'un animal, de fiches d'identité d'un animal, .. mais également de modifications, de consultations, ... sont faîtes vers une BDD globale à toutes les sociétés.
Puis je réplique la BDD avant d'appliquer des processus de Big Data dessus.

Qu'en pensez-vous ?

Merci d'avance du temps que vous consacrez à me répondre

[SQLpro]

Vous partez très mal, car vous mettez la charrue avant les boeufs... En effet, la question importante à se poser est celle de la volumétrie en premier et il faut être sérieux. Analyse du nombre d'informations collecté par unité de temps avec évolution de la volumétrie dans le temps. Après cette volumétrie se gère avec du parallélisme, du partitionnement de l'indexation, des vues indexées, de la compression de données...
Ensuite cela vous donnera le SGBD a utiliser :
Si le volume des données est majoritairement déstructure alors NoSQL
Si le volume est majoritairement structuré alors Relationnel

Ensuite il faudra choisir l'outil sachant que MySQL est totalement inapte à gérer des gros volumes que ce soit en SQL ou noSQL... C'est pour cela qu'il existe des outils ayant comme Oracle, DB2 ou SQL Server.

Enfin, le point clé, celui qui vous donnera le plus de fil à retordre, est celui de la réplication des données. Il existe quantité d'outils sur le marché, mais très peu sont fiables en toutes circonstances. Par exemple Service Broker est utilisé par la SNCF pour la remontée des données financières des guichets, ce qui concerne plusieurs milliers de postes (SGBDR SQL Server version Express gratuite) et n'a jamais connu de panne, ni de pertes de données, depuis son entrée en service en 2007...

Comme je ne voit pas à quoi peut vous servir le big data dans les éléments que vous m'avez donné, je ne peut que vous conseiller de ne pas y aller. Cela peut être un changement au final, lorsque vous aurez identifié clairement les données non structurées et ce que vous voulez en faire !!!

Je vous conseille vivement de lire ce débat : https://www.developpez.net/forums/d1...gbd-sql-nosql/

A +

A +

[SQLpro]

De plus votre schéma montre des choses qui ne devrait pas y figurer... À quoi sert la réplication master slave dans le cadre du milieu , Si votre schéma est fonctionnel il n'a pas lieu d'y faire figurer les moyens de la haute disponibilité, sinon, il faut la faire figurer partout, y compris sur les serveurs clients...

En sus il existe des SGBDR intégrant du ColumnStore index et du stockage hybride (tables locales + tables dans le cloud) afin de fournir un tuyau direct vers du HADOOP. C'est le cas en particulier de SQL Server.
Car enfin, si vous voulez réellement faire du big data vous n'aurez pas d'autre choix que d'aller dans le coud !

A +

[valentin1993]

Je sais que la volumétrie sera comprise entre plusieurs centaines de téraoctets et un petaoctets. Je ne peux réellement chiffrer de manière exacte a volumétrie mais c'est un logiciel qui gère un peu "l'état civil" des animaux : création de différentes entrées dans la BDD (identité, naissance, décès, .. ).

Admettons qu'à un moment donné j'ai 30 millions d'animaux, donc j'aurais 30 millions de lignes dans une table nommée par exemple identité qui renseignera les informations sur l'animal (admettons 15 colonnes). Sur 30 millions de lignes, cela n'est pas énorme en terme de volumétrie. A cela, si j'ajoute 10 millions de lignes sur les différents actes, on obtient une BDD pas forcément extrêmement conséquente.

Initialement, les données sont structurées. Une fiche identité possède les mêmes colonnes (nom, taille, poids, date de naissance, ...) pour tous les animaux.
De plus, ma petite formation universitaire en MySQL (ou MariaDB) m'a fait opter pour ce choix.

Quand vous parlez d'outils à choisir à la place de MySQL, cela peut faire référence à MariaDB n'est-ce-pas ? Si oui, c'est effectivement vers cet outil que j'ai décidé de me diriger.
Attention juste à une chose, mon logiciel est développé à l'aide de Django disposant d'un ORM intégré. Je peux utiliser MySQL, MariaDB, sqlLite, ... mais pas forcément tous les SGBD (très peu de SGBD NoSQL par exemple).

Concernant la réplication, il n'y a qu'une seule et unique BDD que je souhaite répliquer : la BDD globale que je présente dans mon Datacenter.

Pour le Big Data, c'est un souhait de mon patron qui voudrait en faire par la suite et donc je dois pouvoir implémenter tous les outils afin de connecter MapReduce/HADOOP sur les données stockées par mon logiciel. Par là, j'entends de la prévision, exploitation statistique, ... sur l'ensemble de mes données qui sont initialement structurées. C'est pourquoi j'ai décidé d'opter pour MariaDB avec la possibilité d'utiliser ColumnStore, mais également le moteur Cassandra Engine pour obtenir des données destructurées à partir d'un SGBD relationnel.

Enfin, je n'ai jamais travaillé avec SQL Server, donc je ne connais pas du tout le principe, la possibilité de coupler à Django, etc ... Pour ce qui est du schéma, c'est plutôt une modélisation de mon projet avec des "aide-mémoires", ... Je sais que ce n'est pas rigoureux, mais c'est pour avoir une visualisation de ce que je souhaite mettre en place.

Veuillez donc me pardonner du manque de rigueur sur ce genre de choses

[SQLpro]

Attention juste à une chose, mon logiciel est développé à l'aide de Django disposant d'un ORM intégré. Je peux utiliser MySQL, MariaDB, sqlLite,

Vous allez directement au mur... MySQL ne sait pas gérer les fortes volumétries et les ORM sont la pire chose en matière de performance.

Maintenant faites ce que vous voulez. Cela permettra à nous autres spécialistes de vendre du service une fois que votre application, devenue inexploitable devra être sauvée...

A +

[valentin1993]

Vous êtes peut-être performant dans votre domaine, moi je débute dans celui-ci ..
Néanmoins si quelqu'un venait à poser des questions sur mes domaines de compétences, je n'aurais certainement pas sorti une telle réponse.
Faites du chiffre, tant mieux pour vous.
Mais je note la remarque ..

Bonne continuation