Bonjour à tous
 
Dans le cadre d'un projet perso que je suis en train de monter, je peux éventuellement être amené à créer une "petite table" qui pourrait contenir jusqu'à 20 millions d'entrées pour commencer, et qui d'ici quelques années pourrait monter à 200 millions
Chaque ligne va contenit un index (8 octets)
une signature (20 octets)  
une taille (2 octets)
 
ce qui fait un total de 30 octets utils par ligne  
 
Chaque colonne doit être indexée car je dois pouvoir faire des recherches tres rapides suivant chaque critère.
 
Question : ça reste envisageable, ou je vais droit dans le mur et je dois penser à changer ma structure, quitte à rendre mon projet beaucoup moins flexible ?

Quel type de projet peut utiliser de 20 000 000 à 200 000 000 d'entrées  

c'est pas la question
pour tout te dire, la table est destinéee à sauvegarder la signatures de blocs d'octets, normalement de taille maximum 64ko (d'ou les 2 octets)
la signature sera un hash de type SHA.

pas d'avis ?

As tu calculé le poids que ca represente?
 
En fonction de l'index, je dirais 650 Mo pour les 20 millions d'enregistrement au plus. Apres, a toi de faire le calcul.
 
Maintenant, est-il necessaire de passer par une base pour faire çà?

le poids me gene pas ...  
la table se prendra au pire 2 requete en //  
et niveau place, il y a 600Go de libre sur le serveur ...  
 
Maintenant, si tu as une autre idée pour me permettre de trouver l'ID en fonction de la signature et de la taille ...

Tu as deux infos à stocker : signature / taille.
 
Apparement si tu les met dans la même table c'est qu'il y a une raison.
Mais comme on ne sait pas à quoi correspondent cette signature et cette taille (nature de la relation), je vois pas en quoi on pourrait commenter la structure que tu adoptes. Il va falloir développer un peu ton "problème" si tu veux de l'aide pertinente.
 
Je serais curieux de savoir les exigences souhaitées en matière de perfs et donc comment est dimensionnée la (future) machine qui fait tourner ça

La machine en premier abord va être un A64 2.4Ghz avec 512Mo ou 1Go de RAM  
sur un raid5 composé de 3 ou 4 disques (si j'ai le courage d'acheter le dernier .
 
Le serveur sera dédié à de la sauvegarde, et les blocs en question sont les blocs sauvegardés. Le soft que je développe est donc un ensemble client/seveur de sauvegarde.  
Le serveur sauvegarde les fichiers par blocs (en moyenne 64k, mais pas toujours) et se sert de la signature pour reconnaitre un bloc déjà sauvegardé. Vu la probabilité d'avoir une collision en md5 et en sha, on peut imaginer que signature unique = bloc unique. (même si ce n'est pas rigoureusement exacte, c'est un risque tout à fait prenable) (je pense prendre pour ma signature : le md5 + quelques caractères du sha... peut être tous ... d'ou les 20 octets pour la signature. Je pourrais éventuellement prendre plus. Mais je pense qu'ajouter quelques caractères d'un autre hash complétement différents permettent de diviser grandement le nombre de collisions)
Un fichier sauvegardé sera une suite d'id de bloc.  
Si je sauvegarde un fichier qui a été modifié, il n'y aura que quelques blocs à sauvegarder à nouveau.  
L'intéret des signatures est déviter d'encombrer le réseau, et de pouvoir backuper des machines distantes (ce qui va être util dans mon cas). En effet, les machines se contentent d'envoyer les signatures et cela me suffit pour savoir si je connais déjà le bloc ou pas.
 
Je destine le serveur en premier lieu à chez moi, ou j'ai déjà 1To à backuper (d'ou les 20M blocs). Et puis avec le temps, il va peut être servir à d'autres taches, d'autres machines.  
 
1Go pour une base, ça me semble pas si gros que ça... moi ce qui me fait "peur" , c'est le  nombre de lignes. Je ne connais pas la robustesse de MySQL, mais il est écrit sur le site qu'on peut faire des bases de 64To ... donc j'ai encore de la marge.  
En plus, quand je vois au boulot, on a souvent des grosses bases. J'ai déjà vu (OK, c'était du Oracle ...) une base avec une table d'environ 1To ...

MySQL n'est pas gené par une tres grosse volumetrie. Par contre, ton systeme de fichier doit supporter les tres gros fichiers. Il va te falloir de la memoire vive en quantité raisonnable pour stocker l'index.
 
Maintenant je n'arrive pas trop à voir comment va fonctionner ton systeme. Qui va decouper les fichiers par blocs de 64ko pour faire les MD5 et comparer? Est-ce le serveur? Si c'est le cas, je ne vois pas du tout l'interet de la chose. Où sont stocker les paquets? Les gardes-tu par 64ko, ou les regroupes-tu sur le serveur?
Si c'est coté client. N'est-il pas plus de reperer les fichier modifié depuis le dernier backup? Et de n'envoyer que ceux-là...

Une autre question. Si une fichier est modifié, son decoupage le sera aussi. Du coup les MD5 seront differents. Et seront inserés dans la table. Comment vas-tu supprimer les anciens enregistrements dans la table qui n'ont plus lieu d'etre? Et comment lies-tu les paquets entre eux.?

> MD5 ... SHA1 ... (même si ce n'est pas rigoureusement exacte, c'est un risque tout à fait prenable)
 
Pour 200 millions d entrées il y a un risque énorme!
Tu doit changer de méthode!
Un serveur de sauvegarde ne doit tolérer AUCUN risque!

Comme le précise cinocks, c'est quoi l'interêt de découper par bloc ?
 
A part saturer un peu plus la BP (en transmettant X signatures au lieu d'une seule par fichier) je vois pas  
 
Tel que je le comprends et corrige moi si je me trompe :
 
Tu découpes un fichier X en bloc de 64ko. Tu associes une signature à chaque bloc. Tu interroges la BDD : "la signature existe-t-elle ?". Si oui tu ne fait rien. Si non tu crée une nouvelle entrée avec le contenu du bloc et sa signature. C'est ça ?
 
Sur quels critères sont supprimé les blocs obsolètes ?
Comment reconstitues-tu un fichier à partir des seules signatures
La base est-elle destinée à ne sauver les données que d'un client ?

 
Pour répondre précisement à la question du topic :
 
Mysql 5 peut gèrer des tables jusquà 64 TB
http://dev.mysql.com/doc/refman/5.0/en/table-size.html
 

Vous avez déjà utilisé un logiciel peer2peer??
 
Ce genre de truc, avoir un SHA1 pour identifier 1 fichier produit des collisions, aussi ils utilisent un arbre pour découper et stocker un fichier, chaque noeud possède le SHA1 des sous-noeuds. Ça necessite de réimplémenter SHA1, et là encore ce n est pas parfait.
 
voir ``tiger hash tree``. http://en.wikipedia.org/wiki/Hash_tree

pour répondre  
déjà , c'est un soft pour utilisation perso... perso = mon LAN et tous les PCs de ma famille/amis qui voudront backuper leur fichiers.
 
Ensuite, une problématique existe : le serveur de sauvegarde n'est pas forcément relié avec une grosse bp aux clients, voir un bp faible pour certains (ul à 16ko/s)
 
Je vais être un poil plus strict, et on va dire que je vais utiliser une signature noté SIGN qui est la concaténation du MD5 et du SHA256  
La probabibilité de collision sur une signature de ce type me semble tres tres réduite ...  
 
Quand un client veut sauvegarder un fichier,  
1) il releve le nom du fichier, sa taille, sa date de derniere modif en ms, et calcul une signature tres rapide FastSIGN (genre algo SIGN sur les 64ko de début et de fin du fichier), et demande au serveur si il connait ce fichier
 
Le serveur a la table qu'il faut pour cette recherche. Cela est fait en une simple requete. Si le fichier est trouvé, pas la peine de le sauver.
Si il n'est pas trouvé, mais qu'il existe un fichier de nom différent et/ou de date différente, mais de même taille et de même FastSIGN, alors le serveur informe le client qui fait l'étape 2. Sinon, il passe directement au step 3.
 
2) Le client, si il sait qu'il y a un potentiel fichier qui pourrait être le même. il calcul la FullSIGN (sur tout le fichier) et l'envois au serveur. Celui ci regarde si le candidat qu'il avait repéré possède effectivement la même signature FullSIGN (donc hash sur tout le fichier)
Si c'est le cas, le fichier est identifé, sinon, le fichier est inconnu
 
3) Donc apres un éventuel 2, on arrive ici si on a un fichier qui n'est pas connu.
Le client coupe alors le fichier en bloc de 64ko (ou - si fin de fichier et autre traitement spéciaux) et demande pour chaque bloc si le serveur connait un bloc de cette taille ayant la même signature SIGN. Si c'est le cas, le bloc est considéré comme le même, et il n'est pas transféré.  
Si le bloc est inconnu, alors il est transféré et inscrit dans la table.
Intéret => on ne retransmet que les blocs inconnus.
Exemple : un fichier de mail, même de plusieurs Go, ne change que tres peu tous les jours... On evite un re ul complet du fichier alors que peut être un seul bloc de 64ko est finalement différent.  
 
Le nouveau fichier ainsi backupé est marqué en base comme ayant la FullSIGN et la FastSIGN déjà calculée, et comme étant la suite des blocs relevés.

La suppression de blocs est anecdotique ... quand le disque sature, je ferais une purge des vieux backups, quitte à mettre sur CDs pour archivage. Même si ça prend 1 jour, c'est pas mortel

 
je vais lire ça

Il y a des logiciels très efficaces pour faire ça, et qui ne risquent pas de perte de données, ils peuvent même tourner en environnement hostile, crypter et compresser, utiliser différentes voies réseau ftp, ssh... voir ``man mirror`` pour un exemple.

Vu comme ça ca semble beaucoup moins fantaisiste que dans le post initial
 
Par contre comme le souligne qulequ'un au dessus. Les index vont te bouffer pas mal de mémoire.  
 
Pose toi la question (voire fait le test) :
Est-ce que ca serait pas plus intéressant d'augmenter la taille des blocs de manière à réduire la taille des index et donc accélérer la comparaison des signatures client/serveur.
 
D'autant plus vrai si tu dois indexer pour chaque enregistrement un FastSIGN ET un FullSIGN.

j'ai un FastSIGN (hash sur une petite partie du fichier) et un FullSIGN (hash sur tout le fichier) pour chaque fichier (qui coté serveur sont en fait une suite logique de blocs connus)
Ces 2 signatures sont dans table fichier, utilisée lors de l'étape 1 / 2  
 
j'ai une seule signature pour chaque bloc, de type FullSIGN, dans la table bloc, utilsée à l'étape 3
 
Pour la taille des blocs, effectivement ... ça peut être intéressant...  
Genre 1Mo, je divise mon nombre de blocs par 16, ça peut déjà être pas mal  
Mais en contre partie, le pov gars qui ul à 16ko/s, il va plus en chi...
Le pb c'est que si je dépasse 64ko, je gagne 1 octet sur le champ taille de bloc dans ma table des blocs, donc sur chaque ligne Bon OK, on est plus a un octet
 
En fait, j'ai besoin d'un index sur les signatures... on peux imaginer qu'il est restreint aux 5 premiers caractères ... ça fait déjà beaucoup plus lég.

 
ouais mais c'est plus drole de le coder soit même
 
Il y aura aussi une fonctionnalité de compression (pour économiser la bp et la place disque sur le serveur).
Et puis, coté client de restauration, je pense faire un FTP virtuel. J'ai commencé à regarder, ça a l'air faisable. Au début, je voulais faire un pseudo serveur NFS que l'on monte sur sa babasse pour voir les fichiers, mais ça me semble trop chaud. (si quelqu'un veut m'aider )
Donc je pars sur un FTP, en lecture seule. Apres autentification, on voit le contenu du serveur de sauvegarde  (les différents backups dispo, les différents fichiers, etc...) comme sur un ftp normal. On peut prendre un fichier comme sur un FTP normal ... sauf que derriere tout ça, c'est tout compressé, coupé par bloc et tout
 
et on peut meme faire du FTPfs ...

> ouais mais c'est plus drole de le coder soit même
 
Entièrement d accord, à ce moment là renseigne toi comment sont fait les logiciels, et essaye de les copier et de les améliorer, mais franchement tu aura beau ajouter autant de codes de contrôles SHA1+MD5+CRC+taille+tout ce que tu veut, ça ne sera jamais 100% sécurisé comme le demanderai une application de sauvegarde.
 
Le choix de départ: mettre des fichiers dans une BDD mysql, est inadapté: mysql n est pas fait pour stocker des fichiers comme un système de fichier.  
 
Oriente toi plutot vers un système à base de zips ou de tars, et stocke une arborescence de fichiers plutot que des fichier comme ça allez hop!
 
Enfin, je dis ça, c est à toi de voir. J ai déjà lu sur php.net que quelqu un se plaignait qu en utilisant MD5 sur les identifiants des internautes il avait eu des collisions et avait préféré changer. Ça arrive plus souvent qu on ne le pense, et surtout ça ne prévient pas.

Il y a un autre système auquel tu pourrais t inspirer: CVS.

je ne sauve pas les données en base ... j'ai des fichiers à coté. ce que je sauve en base, c'est toutes les info sur les données. J'ai jamais dit (et j'ai jamais eu envie) de sauver les données elle même en base. Comme dit plus haut, une ligne fait une 100aine d'octets à tout casser pour un bloc de 64ko.  
 
Ensuite, mêmes les applis existantes font des concessions . Tu regardes par exemple TINA, il ne rebackup pas tout. Pareil que moi, il doit utiliser une signature ou autre chose, et il ne restransfert pas toutes les données.

> il doit utiliser une signature ou autre chose
 
autre chose: le path et le nom du fichier

moi aussi ... quand je dis nom de fichier, j'entends nom absolu