Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Microsoft sort SQL Server 2014 CTP 2
Et vante ses nouvelles capacités In-Memory permettant d'accélérer 30 fois les performances

Le , par Hinault Romaric

20PARTAGES

2  0 
Microsoft a profité de son salon Pass Summit 2013 dédié à SQL Server pour dévoiler la CTP 2 de sa plateforme de gestion de données moderne SQL Server 2014.

SQL Server 2014 est conçu autour de trois objectifs majeurs : offrir un système de base de données « In-Memory », de nouvelles capacités Cloud pour simplifier l’adoption du Cloud Computing pour les bases de données SQL et faciliter la mise sur pied de nouveaux scénarios hybrides.

Le concept « In-Memory » consiste à mettre en cache les données traitées par les applications plutôt que, par exemple, faire des appels à un serveur. SQL Server 2014 CTP 2 apporte de nouvelles capacités « in-memory online transactional processing » (OLTP, anciennement connu sous le nom de code Hekaton).

OLTP est une couche de base de données et de calcul permettant le traitement de volumes massifs de données en temps réel, en mémoire vive, afin de fournir les résultats immédiats d’analyses et de transactions. Selon une fiche technique publiée par Microsoft, OLTP revendique des performances 10 à 30 fois meilleures pour les applications SQL Server.


Par ailleurs, les procédures (écrites en Transact SQL) qui opèrent sur les tables en mémoire sont compilées en code natif. La combinaison In-Memory et l’exécution du code natif permet une accélération considérable des opérations.

SQL Server 2014 CTP 2 offre également de nouvelles capacités de reprise après sinistre et des solutions de sauvegarde avec Windows Azure. Ces fonctionnalités permettent aux utilisateurs de sauvegarder directement leurs bases de données dans Windows Azure et de bénéficier en plus de la possibilité d’exécuter des fichiers de base de données dans le Cloud. Ce qui permet une réduction du temps de latence et une meilleure disponibilité.

Le SGBDR tire également parti des nouvelles fonctionnalités de Windows Server 2012 R2 pour offrir une évolutivité accrue pour les applications de base de données dans un environnement physique ou virtuel.

SQL Server 2014 CTP 2 est une version de test, qui peut cependant être utilisée dans un environnement de production.

Télécharger SQL Server 2014 CTP 2

Source : Microsoft

Et vous ?

Que pensez-vous des nouvelles capacités In-Memory de SQL Server 2014 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Sirus64
Membre éclairé https://www.developpez.com
Le 18/10/2013 à 20:01
Que pensez-vous des nouvelles capacités In-Memory de SQL Server 2014 ?
Le concept existe ailleurs c'est intéressant qu'il soit intégré à SQL Server. Il faut maintenant voir à l'usage si cela n'entraine pas une trop grande augmentation des demandes de mémoire (RAM). C'est une fonctionnalité à utiliser avec parcimonie.

Pour répondre aux commentaires plus haut : non In-Memory n'est pas une cache... Lisez dont le white paper avant de dire des c±@£¤¢£¤ !

Réf. : white paper - http://download.microsoft.com/downlo...hite_Paper.pdf
1  0 
Avatar de iberserk
Membre expert https://www.developpez.com
Le 29/10/2013 à 6:31
Sql server a toujours géré le cache revenez sur terre! c'est le principe même de fonctionnement de tout SGBD...

Il s'agit ici d'un nouveau mécanisme très avancé de transactionnel in memory, ORACLE en est vert car très a la bourre la dessus, il ne parvient qu'a faire du inmemory en read only...
1  0 
Avatar de iberserk
Membre expert https://www.developpez.com
Le 29/10/2013 à 10:37
Je parle bien de tous les caches (qui n'est pas du in memory...) (plan, procédure, données).

SQL SERVER fait toutes ses opérations en mémoire puis met a jour les pages physiques (disque).

Si vous avez de nombreuses requêtes qui renvoi toujours la même chose c'est a votre code client de gérer cela via les mécanisme très simple à mettre ne place en .net par exemple avec les dépendances de clé de cache SQL (une petite recherche sur SqlCacheDependancy....).
1  0 
Avatar de MacDev
Membre régulier https://www.developpez.com
Le 18/10/2013 à 8:21

Cela veut dire, que SQL serveur gerera enfin le cache ? (Comme mysql , Postgresql et Oracle )
Ce n'est donc pas une innovation?
0  0 
Avatar de imikado
Rédacteur https://www.developpez.com
Le 29/10/2013 à 10:42
Je vous demande, si comme certains autres SGBD (postgresql/mysql/mariaDb), on peut dire : tel requete est en cache au niveau de sqlserver, et vous me répondez de le gerer dans .net

Je n'utilise pas .net pour communiquer avec sqlserver, mais php

Pour information, voila la page en question concernant mysql:
http://dev.mysql.com/doc/refman/5.0/...ery-cache.html
0  0 
Avatar de zaventem
Membre chevronné https://www.developpez.com
Le 29/10/2013 à 11:04
Ca n'a aucun sens de dire qu'une requête est en cache.
SQL server va tenter de garder en mémoire les données les plus utilisée aussi longtemps que possible. Le cache en question est beaucoup plus proche conceptuellement du cache du processeur que de celui du navigateur web. Maintenant si la mémoire disponible est remplie et que l'on exécute un requête qui demande de charger 1Go de donnée en mémoire, 1Go d'autre données seront éliminée (de la mémoire!) d'où l’importance de connaitre les mécanismes en jeu pour ne pas faire n’importe quoi n'importe quand (où alors se sortir continuellement le porte-feuille pour acheter du matériel supplémentaire)

A la lecture de la doc mise en lien, bien évidemment que SQL server le fait nativement depuis très longtemps; il s'agit dans cette discution de gérer l'intégrité transactionnelle sur des objet in memory. On joue ici à un tout autre niveau!
0  0 
Avatar de imikado
Rédacteur https://www.developpez.com
Le 29/10/2013 à 11:21
Citation Envoyé par zaventem Voir le message
Ca n'a aucun sens de dire qu'une requête est en cache.
Et pourtant

Citation Envoyé par zaventem Voir le message

A la lecture de la doc mise en lien, bien évidemment que SQL server le fait nativement depuis très longtemps; il s'agit dans cette discution de gérer l'intégrité transactionnelle sur des objet in memory. On joue ici à un tout autre niveau!
Un exemple simple, on a volontairement executé une requete avec des critères non indexés sur une table assez volumineuse ( qui nous retournait au final une dizaine de lignes):
Première execution : 27s,
deuxième execution 18s
Où est le cache ?? on s'attendait à avoir sur la seconde (ré-éxécutée tout de suite après sur un serveur non solicité) en temps entre 1 et 2 secondes maximum

De plus mysql gère ça intelligement:
Note: The query cache does not return stale data. When tables are modified, any relevant entries in the query cache are flushed.

Note : Le cache de requêtes ne retourne pas de données périmées. A chaques fois que les données sont modifiées, les entrées correspondantes dans le cache sont effacées.
0  0 
Avatar de iberserk
Membre expert https://www.developpez.com
Le 30/10/2013 à 9:07

Première execution : 27s,
deuxième execution 18s
Et bien le cache est de (sortons les calculettes...) 9 secondes...
De plus mysql gère ça intelligement:
Ne vous enflammez pas :-) mysql vous retourne la deuxième exécution en 1 seconde? J'en doute....

Note : Le cache de requêtes ne retourne pas de données périmées. A chaques fois que les données sont modifiées, les entrées correspondantes dans le cache sont effacées.
Tout comme SQL SERVER... les données sont bien gardées en mémoire et non lues sur le disque.
0  0 
Avatar de imikado
Rédacteur https://www.developpez.com
Le 30/10/2013 à 10:17
Citation Envoyé par iberserk Voir le message
Et bien le cache est de (sortons les calculettes...) 9 secondes...
C'est de la mauvaise foi ou un quiproquo: si il y a un cache, il ne devrait pas mettre 18 secondes la deuxieme fois pour me sortir une dizaine de ligne

Citation Envoyé par iberserk Voir le message

Ne vous enflammez pas :-) mysql vous retourne la deuxième exécution en 1 seconde? J'en doute....
Je vais voir pour un POC et vous donner des informations concrètes sur le sujet
0  0 
Avatar de iberserk
Membre expert https://www.developpez.com
Le 30/10/2013 à 10:57
BOnjour,

Il n'y a aucun soucis Michael, on ne parle pas du même genre de cache c'est tout...

Mysql, si je comprends bien fourni un mécanisme ou le résultat même de la requête est mis en cache, en cas de nouvelle demande, la requète n'est même pas executé, le résultat est retourné tel quel.

Cela n'existe pas dans SQL SERVER... étant très tatillon sur le vocabulaire je vous ai naturellement répondu que la mise en cache existe sur SQL SERVER, ce que je maintiens... mais il sagit de la mise en cache des DONNEES non du résultat d'une requète.

Je rejoint zaventem, ce que propose ici MICROSOFT est un mécanisme extremement puissant capable d'accélérer les données transactionnées (INSERT/update/delete) tout en mémoire avec des gains allant de X20 a X100...c'est du jamais vu , même sous ORACLE
0  0