NewSQL - Revision history

Vincent.Mesnier: /* Abstract */

2015-10-24T14:22:31Z

Abstract

← Older revision		Revision as of 14:22, 24 October 2015
Line 18:		Line 18:

	=Abstract=		=Abstract=
			For decades, relational database management systems (RDBMS) were the best solution for storing and retrieving data. But because of the rapidly growing volume of data and changes in demand, major groups such as Google and Facebook have developed new technology as NoSQL or NewSQL to manage their data. This growth is faster than the growth of the storage capacity, which leads to the emergence of information management systems where the data is stored in a distributed way, but accessible and analyzed as if it resides on a single machine.In addition to solving the problem of data size, these solutions must also meet the massive performance requirements to ensure the speed of data processing (OLTP for example)
			So there are two new categories that is an alternative way to traditional RDBMS systems (NoSQL, NewSQL). Regarding NewSQL, this is not really a new format, but a new approach in the implementation of a database. In this presentation, we will focus on the NewSQL, it works and why you have been impleme

	=Synthése=		=Synthése=

Vincent.Mesnier: /* Conclusion */

2015-10-24T14:17:52Z

Conclusion

← Older revision		Revision as of 14:17, 24 October 2015
Line 92:		Line 92:
	NewSQL est plutôt destiné aux entreprises qui gèrent beaucoup de données (comme les grands groupes Google ou Amazon) et nécessitent une certaine évolutivité mais aussi plus de cohérence dans leurs données		NewSQL est plutôt destiné aux entreprises qui gèrent beaucoup de données (comme les grands groupes Google ou Amazon) et nécessitent une certaine évolutivité mais aussi plus de cohérence dans leurs données
	Au final, beaucoup d'entreprise font pas vraiment le choix entre ces technologies. Ils utilisent différentes technologie de stockage de données pour différents besoins (c'est ce qu'on appelle "Polyglot persistance). Par exemple Facebook utilise MySQL pour stocker les posts, informations de l'utilisateur et Cassandra (NoSQL) pour les messages privés		Au final, beaucoup d'entreprise font pas vraiment le choix entre ces technologies. Ils utilisent différentes technologie de stockage de données pour différents besoins (c'est ce qu'on appelle "Polyglot persistance). Par exemple Facebook utilise MySQL pour stocker les posts, informations de l'utilisateur et Cassandra (NoSQL) pour les messages privés
	[[Image:poly_ns.~~png~~\|center\|thumb\|300px\| polyglot Persistence]]		[[Image:poly_ns.jpg\|center\|thumb\|300px\| polyglot Persistence]]

Vincent.Mesnier: /* Synthése */

2015-10-24T14:16:51Z

Synthése

← Older revision		Revision as of 14:16, 24 October 2015
Line 87:		Line 87:
	Ci-dessous un petit tableau récapitulatif sur ces 3 technologies :		Ci-dessous un petit tableau récapitulatif sur ces 3 technologies :
	[[Image:comp2.png\|center\|thumb\|300px\| tableau récapitulatif]]		[[Image:comp2.png\|center\|thumb\|300px\| tableau récapitulatif]]

			==Conclusion==
			NewSQL est donc utiliser pour des stockages distribué et stocker potentiellement entièrement en mémoire, utilise en partie SQL comme langage de requête, et offre des capacité moderne et une architecture moderne qui correspond aux architectures d'aujourd'hui.
			NewSQL est plutôt destiné aux entreprises qui gèrent beaucoup de données (comme les grands groupes Google ou Amazon) et nécessitent une certaine évolutivité mais aussi plus de cohérence dans leurs données
			Au final, beaucoup d'entreprise font pas vraiment le choix entre ces technologies. Ils utilisent différentes technologie de stockage de données pour différents besoins (c'est ce qu'on appelle "Polyglot persistance). Par exemple Facebook utilise MySQL pour stocker les posts, informations de l'utilisateur et Cassandra (NoSQL) pour les messages privés
			[[Image:poly_ns.png\|center\|thumb\|300px\| polyglot Persistence]]

Vincent.Mesnier: /* Comparaison */

2015-10-24T14:08:41Z

Comparaison

← Older revision		Revision as of 14:08, 24 October 2015
Line 79:		Line 79:
	Exemple : Une banque peut utiliser SGBDR pour stocker l'historique de toutes les transactions de la clientèle car les transactions sont vraiment important pour une banque, mais la banque va également utiliser NoSQL pour l les erreurs de serveur et recueillir le comportement des utilisateurs.		Exemple : Une banque peut utiliser SGBDR pour stocker l'historique de toutes les transactions de la clientèle car les transactions sont vraiment important pour une banque, mais la banque va également utiliser NoSQL pour l les erreurs de serveur et recueillir le comportement des utilisateurs.
	Si nous devons placer NewSQL sur le graphique, il se placerai en haut à droite.		Si nous devons placer NewSQL sur le graphique, il se placerai en haut à droite.
	[[Image:comp1.png\|center\|thumb\|300px\| ~~catégorie~~]]		[[Image:comp1.png\|center\|thumb\|300px\| comparaison]]

	Alors, est-ce aujourd’hui la fin des bases de données relationnelles? Pas forcément car elles ont prouvé leur efficacité pendant plus de 30 ans. De la même façon que les fichiers indexés sont encore là, les applications existantes continueront de fonctionner sur les bases de données relationnelles. Mais dans certains environnements, notamment les environnements virtualisés et le cloud, stocker la donnée de façon distribuée sur un ensemble de machines peut constituer un avantage décisif.		Alors, est-ce aujourd’hui la fin des bases de données relationnelles? Pas forcément car elles ont prouvé leur efficacité pendant plus de 30 ans. De la même façon que les fichiers indexés sont encore là, les applications existantes continueront de fonctionner sur les bases de données relationnelles. Mais dans certains environnements, notamment les environnements virtualisés et le cloud, stocker la donnée de façon distribuée sur un ensemble de machines peut constituer un avantage décisif.

	Est ce que NewSQL est un concurrent de NoSQL ? Non, pas forcément car NoSQL a des avantages de flexibilité qui lui son propre mais le faite que SQL soient beaucoup utiliser permet à NewSQL de se démarquer.		Est ce que NewSQL est un concurrent de NoSQL ? Non, pas forcément car NoSQL a des avantages de flexibilité qui lui son propre mais le faite que SQL soient beaucoup utiliser permet à NewSQL de se démarquer.

			Ci-dessous un petit tableau récapitulatif sur ces 3 technologies :
			[[Image:comp2.png\|center\|thumb\|300px\| tableau récapitulatif]]

Vincent.Mesnier: /* Synthése */

2015-10-24T14:07:00Z

Synthése

← Older revision		Revision as of 14:07, 24 October 2015
Line 72:		Line 72:
	*Middleware : Ces systèmes fournissent une couche "sharding"qui permet de diviser automatiquement les bases de données sur plusieurs nœuds.		*Middleware : Ces systèmes fournissent une couche "sharding"qui permet de diviser automatiquement les bases de données sur plusieurs nœuds.
	[[Image:cat.png\|center\|thumb\|300px\| catégorie]]		[[Image:cat.png\|center\|thumb\|300px\| catégorie]]

			==Comparaison==
			Les principaux éléments permettant d'opposer et de choisir ces technologies (relationnel, NoSQL, newSQL) sont la cohérence des données et la scalabilité.
			On peut dire qu'on choisira plus un système relationnel si on n'a besoin d'une forte cohérence des données et si notre système ne nécessite pas de forte monté en charge (capacité du système à maintenir ses fonctionnalisées en cas de forte demande)
			Le noSQL est plutôt adapté pour une scalabilité horizontal (rajouter des serveurs en parallèle) et si on a besoin de moins de cohérence.
			Exemple : Une banque peut utiliser SGBDR pour stocker l'historique de toutes les transactions de la clientèle car les transactions sont vraiment important pour une banque, mais la banque va également utiliser NoSQL pour l les erreurs de serveur et recueillir le comportement des utilisateurs.
			Si nous devons placer NewSQL sur le graphique, il se placerai en haut à droite.
			[[Image:comp1.png\|center\|thumb\|300px\| catégorie]]

			Alors, est-ce aujourd’hui la fin des bases de données relationnelles? Pas forcément car elles ont prouvé leur efficacité pendant plus de 30 ans. De la même façon que les fichiers indexés sont encore là, les applications existantes continueront de fonctionner sur les bases de données relationnelles. Mais dans certains environnements, notamment les environnements virtualisés et le cloud, stocker la donnée de façon distribuée sur un ensemble de machines peut constituer un avantage décisif.

			Est ce que NewSQL est un concurrent de NoSQL ? Non, pas forcément car NoSQL a des avantages de flexibilité qui lui son propre mais le faite que SQL soient beaucoup utiliser permet à NewSQL de se démarquer.

Vincent.Mesnier: /* Synthése */

2015-10-24T13:50:06Z

Synthése

← Older revision		Revision as of 13:50, 24 October 2015
Line 71:		Line 71:
	*MySQL Engine : La deuxième catégorie sont fortement orienté moteurs de stockage optimisé pour SQL. Ces systèmes fournissent la même interface de programmation que SQL, mais adaptent mieux que cette intégration.		*MySQL Engine : La deuxième catégorie sont fortement orienté moteurs de stockage optimisé pour SQL. Ces systèmes fournissent la même interface de programmation que SQL, mais adaptent mieux que cette intégration.
	*Middleware : Ces systèmes fournissent une couche "sharding"qui permet de diviser automatiquement les bases de données sur plusieurs nœuds.		*Middleware : Ces systèmes fournissent une couche "sharding"qui permet de diviser automatiquement les bases de données sur plusieurs nœuds.
			[[Image:cat.png\|center\|thumb\|300px\| catégorie]]

Vincent.Mesnier: /* Synthése */

2015-10-24T13:49:18Z

Synthése

← Older revision		Revision as of 13:49, 24 October 2015
Line 65:		Line 65:
	Deuxièmement, les besoins ont aussi évolué dû à l'émergence du BigData et des réseaux sociaux qui manipule un grand nombre de données. Par exemple Facebook stocke par moi 135 milliard de messages ou encore Twitter stocke 7 TB de données par jour.		Deuxièmement, les besoins ont aussi évolué dû à l'émergence du BigData et des réseaux sociaux qui manipule un grand nombre de données. Par exemple Facebook stocke par moi 135 milliard de messages ou encore Twitter stocke 7 TB de données par jour.
	NoSQL permet d'offrir une bonne évolutivité et de bonne performance mais ne respecte pas les propriété ACID ce qui peut être un frein pour les entreprises.		NoSQL permet d'offrir une bonne évolutivité et de bonne performance mais ne respecte pas les propriété ACID ce qui peut être un frein pour les entreprises.

			==Catégories==
			Comme le NoSQL, il existe plusieurs types de catégorie. Elles sont basées sur les différentes approches adoptées par le fournisseur de preserver l'interface SQL et d'aborder les problèmes de performance et d'évolutivité
			*New design : Dans ce cas là, les bases de données sont souvent écrits à partir de zéro avec une architecture distribuée à l'esprit, et comprennent des composants tels que le contrôle distribué de la concurrence, contrôle de flux, et le traitement de requêtes distribuées. Elle est utilisé pour fonctionner dans un cluster de noeuds distribués sans partage (shared-nothing) dans lequel chaque noeud possèdent un sous ensemble de donnée.
			*MySQL Engine : La deuxième catégorie sont fortement orienté moteurs de stockage optimisé pour SQL. Ces systèmes fournissent la même interface de programmation que SQL, mais adaptent mieux que cette intégration.
			*Middleware : Ces systèmes fournissent une couche "sharding"qui permet de diviser automatiquement les bases de données sur plusieurs nœuds.

Vincent.Mesnier: /* Synthése */

2015-10-24T13:35:25Z

Synthése

← Older revision		Revision as of 13:35, 24 October 2015
Line 60:		Line 60:
	En revanche, c'est une technologie assez récente et plutôt jeune et n'a pas encore pu faire suffisamment ses preuves. Par conséquent, les entreprises sont encore réticentes à		En revanche, c'est une technologie assez récente et plutôt jeune et n'a pas encore pu faire suffisamment ses preuves. Par conséquent, les entreprises sont encore réticentes à
	l'adoption de cette toute nouvelle architecture		l'adoption de cette toute nouvelle architecture

			==Pourquoi ? ==
			Cette technologie a vu le jour pour plusieurs raison. Premièrement, elle tire partie des évolution du matériel et des architectures distribuées. Ce qui faut savoir c'est que SQL est une technologie assez vieille ( à peu prés 30 ans). SQL a bénéficié de quelques évolutions mais reste basé sur le matériel de l'époque.
			Deuxièmement, les besoins ont aussi évolué dû à l'émergence du BigData et des réseaux sociaux qui manipule un grand nombre de données. Par exemple Facebook stocke par moi 135 milliard de messages ou encore Twitter stocke 7 TB de données par jour.
			NoSQL permet d'offrir une bonne évolutivité et de bonne performance mais ne respecte pas les propriété ACID ce qui peut être un frein pour les entreprises.

Vincent.Mesnier: /* Caractéristiques */

2015-10-24T13:29:40Z

Caractéristiques

← Older revision		Revision as of 13:29, 24 October 2015
Line 48:		Line 48:
	*Utiliser la distribution et la réplication des données pour assurer la scalabilité et la résilience des données.		*Utiliser la distribution et la réplication des données pour assurer la scalabilité et la résilience des données.
	==Caractéristiques==		==Caractéristiques==
			Le NewSQL est une architecture qui reprend donc les avantages du NoSQL et comble son principal désavantage. Il palie à l'éventuel cohérence des données de ce dernier grâce au support de transaction ACID via un langage pour les requêtes le SQL.
			Ci-dessous quelques-unes de ces caractéristiques:
			*Le SQL comme langage commun de requétage
			*Transaction ACID
			*Un mécanisme qui évite la pause de verrous lors d'opérations concurrentes de lecture avec les opérations d'écritures. La lecture en temps réel en est ainsi facilitée (moins de perte de temps).
			*Une architecture qui a de meilleures performances par nœud que les solutions classiques de type SGBDR.
			*Architecture distribuée
			*la plupart utilise des base de données en mémoire

			Au vu de ce qui précède, on peut penser que ce type d'architecture sera celle adoptée demain en entreprise.
			En revanche, c'est une technologie assez récente et plutôt jeune et n'a pas encore pu faire suffisamment ses preuves. Par conséquent, les entreprises sont encore réticentes à
			l'adoption de cette toute nouvelle architecture

Vincent.Mesnier at 13:24, 24 October 2015

2015-10-24T13:24:50Z

← Older revision		Revision as of 13:24, 24 October 2015
Line 23:		Line 23:
	Depuis l'émergence du BigData et des base de donnée NoSQL, les besoins des entreprises ont changé et même si NoSQL répond parfois à ces nouveaux besoins, il apparait que cette technologie sacrifie la plupart du temps la forte cohérence des données si chère au modèle relationnel, au bénéfice de la haute disponibilité et de la scalabilité horizontale. En revanche, cela ne plait pas à tout les entreprises.. Certaines ne peuvent simplement pas se passer de transactions ACID (par exemple: les banques). De plus, le développeur sera conduit à "jongler" avec l'éventuelle cohérence des données. De plus, chaque système de gestion de base de données NoSQL vient avec son propre langage de requête (manque de standard dans les interfaces).		Depuis l'émergence du BigData et des base de donnée NoSQL, les besoins des entreprises ont changé et même si NoSQL répond parfois à ces nouveaux besoins, il apparait que cette technologie sacrifie la plupart du temps la forte cohérence des données si chère au modèle relationnel, au bénéfice de la haute disponibilité et de la scalabilité horizontale. En revanche, cela ne plait pas à tout les entreprises.. Certaines ne peuvent simplement pas se passer de transactions ACID (par exemple: les banques). De plus, le développeur sera conduit à "jongler" avec l'éventuelle cohérence des données. De plus, chaque système de gestion de base de données NoSQL vient avec son propre langage de requête (manque de standard dans les interfaces).
	Durant l'année deux-milles onze, un groupe de recherche nommé "451 Research" a analysé le problème évoqué ci-dessus et défini le nom "ScalableSQL" (avant de s'appeler NewSQL) pour une base de données regroupant les avantages du NoSQL et des SGBDR classique.		Durant l'année deux-milles onze, un groupe de recherche nommé "451 Research" a analysé le problème évoqué ci-dessus et défini le nom "ScalableSQL" (avant de s'appeler NewSQL) pour une base de données regroupant les avantages du NoSQL et des SGBDR classique.
			[[Image:ns.png\|center\|thumb\|300px\| NewSQL]]


Line 40:		Line 41:

	En effet, NewSQL se positionne comme 1 stockage distribué (les ressources ne sont pas toutes sur la même machine) conçue dans le prolongement de NoSQL. De plus, la plupart des solutions NewSQL proposent un stockage en mémoire (cache distribué sur plusieurs machine). Ce système est utilisé quand une faible latence est critique.		En effet, NewSQL se positionne comme 1 stockage distribué (les ressources ne sont pas toutes sur la même machine) conçue dans le prolongement de NoSQL. De plus, la plupart des solutions NewSQL proposent un stockage en mémoire (cache distribué sur plusieurs machine). Ce système est utilisé quand une faible latence est critique.
	[[Image:distrib_NewSQL.png\|center\|thumb\|300px\| ~~Architecture~~ base de données]]		[[Image:distrib_NewSQL.png\|center\|thumb\|300px\| base de données distribuée]]

	L’architecture NewSQL n’est donc pas totalement nouvelle mais reprend de ces expériences antérieures plusieurs caractéristiques tout en faisant des choix qui lui sont propres.		L’architecture NewSQL n’est donc pas totalement nouvelle mais reprend de ces expériences antérieures plusieurs caractéristiques tout en faisant des choix qui lui sont propres.