Messages entre utilisateurs
Fermé
parousky
Messages postés
325
Date d'inscription
mardi 11 septembre 2012
Statut
Membre
Dernière intervention
20 février 2022
-
1 oct. 2014 à 19:49
JooS Messages postés 2465 Date d'inscription mardi 22 janvier 2008 Statut Membre Dernière intervention 8 juin 2016 - 5 oct. 2014 à 01:24
JooS Messages postés 2465 Date d'inscription mardi 22 janvier 2008 Statut Membre Dernière intervention 8 juin 2016 - 5 oct. 2014 à 01:24
A voir également:
- Messages entre utilisateurs
- Comment récupérer les messages supprimés sur whatsapp - Guide
- Comment savoir si quelqu'un lit mes messages sur whatsapp - Guide
- Messages reçus aujourd'hui - Forum Gmail
- Messages ephemeres whatsapp - Guide
- Mes messages le bon coin - Forum Réseaux sociaux
2 réponses
JooS
Messages postés
2465
Date d'inscription
mardi 22 janvier 2008
Statut
Membre
Dernière intervention
8 juin 2016
228
2 oct. 2014 à 17:57
2 oct. 2014 à 17:57
Salut,
Si ta plateforme ne contient pas un nombre trés élevé d'utilisateurs (donc peu de messages échangés), alors la méthode classique (base de données relationnelle) peut faire l'affaire sans pour autant risquer de saturer la base de données.
Maintenant si le nombre d'utilisateurs est assez grand et que le nombre total de messages échangés peut rapidement (vélocité) dépasser "on va dire" le milliard de message, alors faut penser à autre chose.
Parmi les autres solutions, il existe ce qu'on appelle les bases de données NoSQL, en résumé c'est des bases de données qui sacrifient la structure des données (non relationnelles) pour gagner en performance, elle sont également distribués sur plusieurs serveurs (d'ou la puissance de traitement).
Par exemple, chez Facebook, afin de gérer les milliards de messages instantanés qui sont échangés chaque jour, ils utilisent HBase pour les stocker.
Donc théoriquement, plus la masse de données augmente, plus on augmente le nombre de serveurs, mais bon, leur implémentation reste un peu difficile et coûteuse, généralement seul les grandes entreprises ou les entreprises spécialisées peuvent se permettre d'implanter ce genre de service.
Cependant, ce service existe dans le Cloud, et ça reste une meilleure alternative pour les particuliers et les petites entreprises, donc tu peux allouer un service de stockage en ligne chez une entreprise(fournisseur) spécialisée !
Voila, l'entreprise en question va s'occuper de gérer tes données (peu importe leur masse), et tu pourras accéder à ces données via une API proposé par ce même service.
Si ta plateforme ne contient pas un nombre trés élevé d'utilisateurs (donc peu de messages échangés), alors la méthode classique (base de données relationnelle) peut faire l'affaire sans pour autant risquer de saturer la base de données.
Maintenant si le nombre d'utilisateurs est assez grand et que le nombre total de messages échangés peut rapidement (vélocité) dépasser "on va dire" le milliard de message, alors faut penser à autre chose.
Parmi les autres solutions, il existe ce qu'on appelle les bases de données NoSQL, en résumé c'est des bases de données qui sacrifient la structure des données (non relationnelles) pour gagner en performance, elle sont également distribués sur plusieurs serveurs (d'ou la puissance de traitement).
Par exemple, chez Facebook, afin de gérer les milliards de messages instantanés qui sont échangés chaque jour, ils utilisent HBase pour les stocker.
Donc théoriquement, plus la masse de données augmente, plus on augmente le nombre de serveurs, mais bon, leur implémentation reste un peu difficile et coûteuse, généralement seul les grandes entreprises ou les entreprises spécialisées peuvent se permettre d'implanter ce genre de service.
Cependant, ce service existe dans le Cloud, et ça reste une meilleure alternative pour les particuliers et les petites entreprises, donc tu peux allouer un service de stockage en ligne chez une entreprise(fournisseur) spécialisée !
Voila, l'entreprise en question va s'occuper de gérer tes données (peu importe leur masse), et tu pourras accéder à ces données via une API proposé par ce même service.
parousky
Messages postés
325
Date d'inscription
mardi 11 septembre 2012
Statut
Membre
Dernière intervention
20 février 2022
6
4 oct. 2014 à 20:28
4 oct. 2014 à 20:28
D'accord, merci beaucoup pour ta réponse !
Je pense m'orienter vers le stockage dans une base SQL. Et quel est l'ordre de grandeur de l'espace maximal d'une base SQL pleine à craquer ?
Et sinon, pour mon site, j'aimerai que l'utilisateur voit les messages qu'il a envoyé et ceux qu'il a reçu, alors je pensais à stocker les messages dans la base avec les colonnes "Expediteur" - "Destinataire" - "Contenu du message" - "Lu"
où "Lu" est égal à zéro tant que le destinataire n'a pas ouvert le message.
Mais ça m'a l'air bien compliqué, ne serait-ce qu'afficher les messages d'une même conversation entre l'utilisateur et une personne au même endroit !
As-tu déjà utilisé la base SQL pour les messages ?
Penses-tu que mon idée soit bonne ?
Merci d'avance !
Je pense m'orienter vers le stockage dans une base SQL. Et quel est l'ordre de grandeur de l'espace maximal d'une base SQL pleine à craquer ?
Et sinon, pour mon site, j'aimerai que l'utilisateur voit les messages qu'il a envoyé et ceux qu'il a reçu, alors je pensais à stocker les messages dans la base avec les colonnes "Expediteur" - "Destinataire" - "Contenu du message" - "Lu"
où "Lu" est égal à zéro tant que le destinataire n'a pas ouvert le message.
Mais ça m'a l'air bien compliqué, ne serait-ce qu'afficher les messages d'une même conversation entre l'utilisateur et une personne au même endroit !
As-tu déjà utilisé la base SQL pour les messages ?
Penses-tu que mon idée soit bonne ?
Merci d'avance !
JooS
Messages postés
2465
Date d'inscription
mardi 22 janvier 2008
Statut
Membre
Dernière intervention
8 juin 2016
228
5 oct. 2014 à 01:24
5 oct. 2014 à 01:24
Cela dépend du système de gestion de la base de données en question : MySQL, PostgreSQL, Oracle, SQL Server ...
Si tu parles de l'espace de stockage, alors pour MySQL par exemple, les limitations sont généralement imposées par le système d'exploitation (système de fichiers), sous Windows et avec NTFS, le taille d'une table peut atteindre les 2TB ... voir plus
Si tu parles de performances des requêtes, ce qui me semble être plus important, alors ça dépend de pleins de choses !
Du matériel : Processeur, DD ...
Du SGBDR !
Du modèle relationnel de ta base de données : normalisée ou pas, "profondeur" des relations (trop de jointures).
De l'utilisation des indexes, et biensure de la taille des données chargées ... !
Mais bon, si tu recherches un nombre de lignes maximum (théorique ou pratique), tu ne trouvera pas de résultat concluant !
Tu vas par exemple trouvé des tests fait sur une table de 5 colonnes, avec une requête SELECT simple, et le testeur prétend que les performances sont toujours stables au delà du milliard de lignes !
Mais ce n'est pas une référence, chaque base de données est conçu différemment, avec différent type et nombre de colonnes, parfois on a besoin de faire 2 ou 3 jointures afin d'extraire l'information qu'on recherche, et je peux te garantir que faire une requête SELECT sur une table contenant 1 milliard de lignes n'est pas similaire à faire une requête SELECT avec jointure entre deux tables de 50 millions de lignes chacune, la seconde peux prendre plus de temps à s'exécuter.
Voila, tu ne pourra jamais faire quelque chose de parfait, d'ou le besoin de faire des mises à jour, donc essayes en premier temps de respecter les normes dans tout ce qui est conception et implémentation, après, tu pourras pensé et prévoir des solutions au jour ou ta base de données sera saturé.
Si tu parles de l'espace de stockage, alors pour MySQL par exemple, les limitations sont généralement imposées par le système d'exploitation (système de fichiers), sous Windows et avec NTFS, le taille d'une table peut atteindre les 2TB ... voir plus
Si tu parles de performances des requêtes, ce qui me semble être plus important, alors ça dépend de pleins de choses !
Du matériel : Processeur, DD ...
Du SGBDR !
Du modèle relationnel de ta base de données : normalisée ou pas, "profondeur" des relations (trop de jointures).
De l'utilisation des indexes, et biensure de la taille des données chargées ... !
Mais bon, si tu recherches un nombre de lignes maximum (théorique ou pratique), tu ne trouvera pas de résultat concluant !
Tu vas par exemple trouvé des tests fait sur une table de 5 colonnes, avec une requête SELECT simple, et le testeur prétend que les performances sont toujours stables au delà du milliard de lignes !
Mais ce n'est pas une référence, chaque base de données est conçu différemment, avec différent type et nombre de colonnes, parfois on a besoin de faire 2 ou 3 jointures afin d'extraire l'information qu'on recherche, et je peux te garantir que faire une requête SELECT sur une table contenant 1 milliard de lignes n'est pas similaire à faire une requête SELECT avec jointure entre deux tables de 50 millions de lignes chacune, la seconde peux prendre plus de temps à s'exécuter.
Voila, tu ne pourra jamais faire quelque chose de parfait, d'ou le besoin de faire des mises à jour, donc essayes en premier temps de respecter les normes dans tout ce qui est conception et implémentation, après, tu pourras pensé et prévoir des solutions au jour ou ta base de données sera saturé.
