Précédent   Forum des professionnels en informatique > Bases de données > PostgreSQL
PostgreSQL Forum PostgreSQL. Avant de poster -> F.A.Q PostGreSQL Tutoriels PostGreSQL
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 15/01/2012, 10h32   #1
Membre éclairé
 
Inscription : avril 2009
Messages : 523
Détails du profil
Informations personnelles :
Âge : 35
Localisation : France, Somme (Picardie)

Informations forums :
Inscription : avril 2009
Messages : 523
Points : 305
Points : 305
Par défaut Quel SSD pour booster une base de données ?

bonjour,


quelqu'un a-t-il un conseil pro pour un SSD 64Go destiné à booster une base de données (postgresql81) sur un serveur ?
bien entendu, la sécurité prime sur le reste.
est-ce vrai que dans tous les cas, un SSD apportera un gain de x10 par rapport à un disque dur ?

Si quelqu'un a déjà fait l'expérience des gains en base de données avec un SSD, qu'il partage...

bien à vous
Michael REMY est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 16/01/2012, 17h37   #2
Membre Expert
 
Avatar de kain_tn
 
Homme
Inscription : mars 2005
Messages : 577
Détails du profil
Informations personnelles :
Sexe : Homme
Localisation : Canada

Informations forums :
Inscription : mars 2005
Messages : 577
Points : 1 209
Points : 1 209
Bonjour,

Je ne sais pas quel gain réel tu peux avoir avec un SSD mais il y a quelques années, j'avais obtenu un gain assez important en séparant l'écriture des données de celle des journaux de transaction. En gros je les avais mises sur deux grappes de RAID différentes et c'était vraiment efficace (grappe de RAID 10 en 15rpm pour les journaux et RAID 5 en 10rpm pour les données).

Pour expérimenter, j'avais commencé par créer une partition en RAM, et c'est en y écrivant les journaux de transaction que j'avais eu les meilleurs résultats.
__________________
Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!


Code C :
1
2
3
4
5
6
7
#include <stdio.h>
 
int main(int argc, char **argv) {
 
    printf("So long, and thanks for the fish, Dennis...\n");
    return 0;
}
kain_tn est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 17/01/2012, 11h42   #3
Rédacteur/Modérateur

 
Avatar de SQLpro
 
Homme Frédéric BROUARD
Expert SGBDR & SQL
Inscription : mai 2002
Messages : 10 959
Détails du profil
Informations personnelles :
Nom : Homme Frédéric BROUARD
Localisation : France

Informations professionnelles :
Activité : Expert SGBDR & SQL
Secteur : Conseil

Informations forums :
Inscription : mai 2002
Messages : 10 959
Points : 17 791
Points : 17 791
Bonjour,

Citation:
Envoyé par Michael REMY Voir le message
bonjour,


quelqu'un a-t-il un conseil pro pour un SSD 64Go destiné à booster une base de données (postgresql81) sur un serveur ?
bien entendu, la sécurité prime sur le reste.
est-ce vrai que dans tous les cas, un SSD apportera un gain de x10 par rapport à un disque dur ?

Si quelqu'un a déjà fait l'expérience des gains en base de données avec un SSD, qu'il partage...

bien à vous
Oui, vous allez obtenir un gain, mais au détriment de la fiabilité de la base. En effet, les SSD sont actuellement limités à environ 700 000 cycles d'écriture ce qui peut arriver vite avec le journal des transactions mais aussi sur les données, à cause des opérations de maintenance des index.

Vous pouvez aussi utiliser des cartes hybrides du genre fusionIO.

Néanmoins et comme vous le conseille kain_tn, le mieux est de ventiler vos IO sur différents disques PHYSIQUE et non sur des SAN avec des LUN taillée dans la masse. Ceci sera beaucoup moins cher et beaucoup plus fiable.
Par exemple mettre un RAID 10 (ou 0+1) avec 6 à 8 disques pour le journal et mettre un RAID 10 avec 4 <disque pour les data, fera divisé par 4 les temps de lecture et d'écriture... A condition que la carte RAID soit de bonne qualité (autorise les lectures asynchrones des disques en miroir).

A lire : http://blog.developpez.com/sqlpro/p8...t-le-stocakge/

Mais, vous aurez sans doute des gains beaucoup plus important (x100 souvent) en restructurant votre base et en l'indexant correctement, si elle est notablement mal modélisée (non respect des formes normales par exemple).

A lire : http://blog.developpez.com/sqlpro/p1...ances-petites/

A +
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
SQLpro est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 17/01/2012, 14h11   #4
Membre éclairé
 
Inscription : avril 2009
Messages : 523
Détails du profil
Informations personnelles :
Âge : 35
Localisation : France, Somme (Picardie)

Informations forums :
Inscription : avril 2009
Messages : 523
Points : 305
Points : 305
quelqu'un a-t-il déjà vu ou produit une perte de données sur un SSD ?

j'entends parlé souvenant de cela mais jamais un détail précis.

en gros une perte de données c'est quoi ? des données corrompues dans la base de données (chaines tronqués, indexes faux, incohérences..) ou bien c'est juste 5000oips au lieu de 6000iops ? Dans le second cas c'est pas grave du tout, dans le premier j'en conviens c'est catastrophique.

pourquoi n'y-a-t-il pas de perte de données en RAM quand la base est cachée ou sur une carte pci-e fusionIO ??

Le risque de cette potentielle perte de données est-il plus minimim voire nulle quand on a que 30 utilisateurs sur la base de moins de 1Go ?
Michael REMY est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 20/01/2012, 12h08   #5
Rédacteur/Modérateur

 
Avatar de SQLpro
 
Homme Frédéric BROUARD
Expert SGBDR & SQL
Inscription : mai 2002
Messages : 10 959
Détails du profil
Informations personnelles :
Nom : Homme Frédéric BROUARD
Localisation : France

Informations professionnelles :
Activité : Expert SGBDR & SQL
Secteur : Conseil

Informations forums :
Inscription : mai 2002
Messages : 10 959
Points : 17 791
Points : 17 791
Citation:
Envoyé par Michael REMY Voir le message
quelqu'un a-t-il déjà vu ou produit une perte de données sur un SSD ?
Oui, à deux reprises au moins, mais sur du SQL Server (environ 2000 transaction par minutes) SSD mort en moins d'un an
Citation:

j'entends parlé souvenant de cela mais jamais un détail précis.

en gros une perte de données c'est quoi ? des données corrompues dans la base de données (chaines tronqués, indexes faux, incohérences..) ou bien c'est juste 5000oips au lieu de 6000iops ? Dans le second cas c'est pas grave du tout, dans le premier j'en conviens c'est catastrophique.
Le SSD n'est pratiquement plus lisible.
http://blog.2ndquadrant.com/en/2011/...-sherr-sh.html
Citation:

pourquoi n'y-a-t-il pas de perte de données en RAM quand la base est cachée ou sur une carte pci-e fusionIO ??
Les ram des seveurs sont auto correctives. Fusion IO est une techno hybride
Citation:

Le risque de cette potentielle perte de données est-il plus minimim voire nulle quand on a que 30 utilisateurs sur la base de moins de 1Go ?
Plus d'utilisateur = plus de transaction. Sur le Serveur mentionné en début d'article on avait en moyenne plus de 5 000 users.

A +
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
SQLpro est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 23h38.


 
 
 
 
Partenaires

Hébergement Web