OK, j'ai cherché cela et lisez quelques points de vue sur la conservation des données binaires dans une base de données [MySQL]. Généralement, je considère cela une mauvaise idée et essayez de l'éviter, en favorisant les transferts de fichiers traditionnels et simplement de stocker une référence au fichier dans une base de données.
Cependant, je travaille sur un projet qui nécessite une synchronisation de base de données avec une base de données à distance / nuage, non seulement pour les fichiers, mais également pour les paramètres et autres contenus d'utilisateur. Pour cela, et d'autres raisons, j'ai estimé que cela pourrait être une situation appropriée pour le stockage binaire dans une base de données.
J'ai écrit un système général pour la synchronisation de la base de données qui fonctionne bien en utilisant la réflexion et le XML. J'ai aussi (contre mon instinct) intégré le stockage de fichiers dans ce système. Encore une fois, cela fonctionne bien - je bloque des fichiers dans des blobs de 64 ko et stockez-les dans une table, avec une référence fichier_id (liée à une table séparée contenant des métadonnées telles que le nom de fichier / Taille / MIME).
Cela me permet d'envoyer des bits et des morceaux comme et lorsqu'une connexion est disponible et me permet également de limiter chaque taille de demande afin de maintenir les choses en douceur.
Jusqu'à présent, je n'ai trouvé aucun problème avec cela et j'ai importé avec succès et transféré avec plus de 1 Go de données dans les deux sens (plus d'environ 10-15 fichiers / 16 000 lignes), mais je m'inquiète de son évolutivité - va-t-elle ralentir Une fois 20 Go de données de 20 Go et peut-on gérer MySQL à condition que mes requêtes soient bien structurées?
Une autre raison de mettre en place ma décision de stocker les données de la base de données était que je pensais que je pouvais simplement ajouter un autre périphérique de disque dur / stockage à MySQL si l'espace a été faible, dans l'espoir de la mise à l'échelle / de la réplication / etc.
J'apprécierais beaucoup de points de vue ou de commentaires quant à savoir s'il s'agit d'une bonne ou d'une bonne approche, et j'ai manqué des problèmes évidents que je suis susceptible de voir une fois utilisé dans un environnement de production?
Edit: J'ai oublié de mentionner, les tailles de fichiers pouvaient aller de 1kb à ~ 1GB
[rugueux] conclusion
Premièrement: Merci beaucoup à ceux qui ont contribué une réponse considérée. Choisir la réponse acceptée ici a été assez difficile car chacun a quelque chose de décent à offrir.
À la fin (malgré mes espoirs), j'ai décidé qu'un serveur de stockage PURE MySQL ne soit au mieux une solution OK (je ne peux toujours pas m'empêcher de vous demander pourquoi ils gênent les types de blob).
Comme alternative, je suis déchiré entre l'approche du système de fichiers @Nick Coons et la suggestion de @ Tadman d'un hybride à l'aide d'un moteur de base de données de clé / de la valeur de poids léger tel que levelDB. À condition que les aspects pratiques d'utilisation de niveau de niveau dans ce projet ne soient pas un problème, c'est probablement l'approche que je vais travailler vers.
J'ai accepté la réponse de Tadman sur cette base; Sa réponse était également la plus applicable et utile à ma situation.
Cela étant dit, et pour ceux qui sont intéressés: j'ai apprécié beaucoup de succès en utilisant uniquement MySQL jusqu'à présent. J'ai testé une table stockant plus de 15 Go de données binaires sans aucun effet secondaire négatif notable de l'insertion / la récupération de données à partir de grandes tables (avec des requêtes minutieuses). Cependant, je suis certain que cela reste très inefficace et que l'une des méthodes alternatives mentionnées sera nettement meilleure.
3 Réponses :
Je dois me demander pourquoi vous vous inquiétez même d'une base de données du tout, lorsque le calque que vous avez ajouté au sommet de la chunk, de stocker, de récupérer et de réassembler fonctionnerait également sur une structure de système de fichiers bien définie. Mysql veut toutes ses données sur un volume Single , ce n'est donc pas un cas d'ajout d'un autre lecteur chaque fois que vous en avez envie, et la réplication de grandes quantités de données binaires va être ralentiellement lente que le binaire Les journaux finiront par dupliquer la quantité de données dont vous avez besoin pour stocker.
L'approche la plus simple est souvent la meilleure. Le stockage dans le système de fichiers est probablement le meilleur moyen de le faire. Si vous avez besoin de garder un index de ce qui est stocké où, vous utiliseriez peut-être une base de données comme MySQL, mais il y a de nombreuses façons d'accomplir cette même tâche. Le plus basse technologie, mieux c'est. Par exemple, n'exclivez pas SQLite car une base de données intégrée fonctionne très bien sous la lecture de la lumière et de l'écriture, et A l'avantage d'être "juste un fichier" en matière de sauvegarde et de restauration.
Cela étant dit, qu'est-ce que vous faites des sons de manière méfiante similaire à niveau de niveau , donc avant Vous vous engagez à votre approche, vous devrez voir comment il est significativement différent d'un magasin de documents de grande valeur de cette variété.
Merci de votre réponse, vous soulevez des idées intéressantes. Le projet utilise déjà un environnement WAMP pour diverses autres tâches. J'ai donc pensé que je pouvais aussi bien utiliser ce qui était déjà là. Aussi, j'avais un coup d'œil sur Leveldb et ça a fière allure, mais je ne pense pas que ce soit parfait pour mes besoins à cette occasion: "Il n'a pas de modèle de données relationnel, il ne prend pas en charge les requêtes SQL, et il n'a aucun soutien pour les index ". Je ne peux pas m'empêcher de penser qui me fera plus de problèmes. La raison de l'utilisation de la base de données en premier lieu était que j'avais déjà configuré l'infrastructure pour les autres éléments de synchronisation.
Votre point sur les bûches binaires est tout à fait alarmante, alors je pense que je vais envisager de vous déplacer vers un système de fichiers «approprié» - pensez-vous qu'il serait toujours d'utiliser la synchronisation de la base de données à transférer, avant d'assembler à binaire de l'autre côté (puis supprimant le binaire de la base de données)? L'utilisation de la base de données me permet de conserver une piste précise dont les blocs de données ont et n'ont pas été reçus (il pourrait y avoir une possibilité qu'ils ne seront pas reçus dans l'ordre)
Les bases de données sont très bonnes pour stocker des données relationnelles bien définies. Ils sont affreux à stocker de grandes quantités de données binaires arbitraires. Ce que vous pouvez utiliser est un hybride, un magasin de données de niveaudb avec un index RDBMS construit sur le dessus. Leveldb est excellent pour stocker d'énormes quantités de données et peut être répliquée à l'aide d'outils standard tels que rsync .
Bonjour @tadman, merci pour votre contribution. J'ai eu un autre regard sur Leveldb et je vois que je pouvais utiliser MySQL pour le côté relationnel et stocker les clés / gammes de niveau de niveaudb sous forme de valeurs de référence à utiliser les deux. Est-ce le genre de chose que vous aviez à l'esprit? Néanmoins, j'ai eu la question que j'ai essentiellement besoin de dupliquer tout ce que je fais: j'ai besoin d'un système C # pour l'application de bureau dans un environnement WAMP et un équivalent PHP dans un environnement de lampe (hôte Web typique). Pardonne à mon ignorance, mais Afaik, de niveau de niveau n'est pas disponible par défaut sur la plupart des hôtes Web?
Il y a un certain nombre d'extensions de niveaux PHP que vous pouvez toujours ajouter, de sorte que cela ne devrait pas être un problème. J'espère que vous n'utilisez pas une sorte d'hébergement partagé atrocieux où vous avez un contrôle de zéro sur votre pile. Si LeveldB ne fonctionne pas, vous pouvez toujours gérer les fichiers manuellement, mais c'est juste beaucoup plus de travail. Leveldb va chunk, organisera et éliminera les données à mesure que vous ajoutez et supprimez des choses, et la compression transparente intégrée est une autre perche. Vous pouvez écrire tout cela vous-même, mais c'est beaucoup de travail. C'est comme Amazon S3 en tant que bibliothèque intégrée.
Cela semble idéal - ce serait la cerise sur le gâteau si vous pouviez me diriger dans la direction du meilleur de ces extensions? Et je ne veux certainement pas réinventer la roue: tout à fait de faire ce que les autres ont déjà fait mieux :)
J'ai trouvé cela aussi .. Je voulais juste m'assurer que je ne choisissions pas MySQL sur PDO, si vous savez ce que je veux dire - merci.
Cela ressemble à une bibliothèque complète de fonctionnalités vraiment, je serais donc à l'aise en l'utilisant.
Je pense que vous trouverez un manque de débat à ce sujet comme je l'ai fait quand j'ai commencé à regarder cela. J'ai tendance à me pencher vers le stockage dans le système de fichiers et à maintenir une référence. Cependant, cela ne veut pas dire qu'il n'y a jamais de temps pour stocker des données binaires dans une base de données.
Je dirais que simplement pour garder les choses de synchronisation n'est pas une raison en lui-même pour faire un argument pour stocker des données binaires dans une base de données. Il existe certainement des moyens de conserver des systèmes de fichiers en synchronisation de sorte que, comme une base de données soit conservée en synchronisation, c'est le système de fichiers.
L'essentiel est qu'il existe une quantité juste de débat sur ce sujet et vous devez aller avec ce qui fonctionne pour vous. Si ce que vous avez configuré fonctionne. Utilise le. Faites des performances et des tests de charge pour vous assurer que cela fonctionne. Si cela ne tient pas, changez-le.
Vous avez raison - j'ai trouvé beaucoup de débat à ce sujet. Mais c'est pourquoi j'ai demandé :) Depuis la publication, je fais plus de tests, et j'ai maintenant une table contenant environ 15 Go de données, avec certains fichiers. Tandis que 1,2 Go, et tout semble bien jusqu'à présent :) Mais, tenté comme je dois le laisser seul, les points soulevés dans les autres réponses me laissent un mauvais sentiment. En outre, en ce qui concerne votre deuxième paragraphe, j'ai opté pour cela simplement parce que j'ai déjà eu un moteur de sérialisation / synchronisation robuste, je peux ajouter des objets à assez facilement: donc un mélange de paresse et d'espoir que je suppose :)
Réponse courte: Je ne suis pas sûr qu'il y a une façon de répondre à cela. Vous avez mentionné des fichiers de 1kb à 1 Go à 1 Go. Je ne stockerais pas les données binaires dans une DB si cela se passe près de 1kb, laissez le long de 1 Go. Je peux stocker quelques octets de données binaires dans une DB si elle est accessoire, mais toute grande quantité de données, notamment qui n'a pas besoin d'être recherchée, doit être stockée dans le système de fichiers: lorsque vous stockez Données dans une DB, vous le stockez de toute façon sur un système de fichiers, vous venez d'ajouter une autre couche (la DB) au mélange. Il y a un coût pour cette couche, il faut donc avoir un avantage pour constituer la différence. Si vous stockez les données afin que vous puissiez effectuer une recherche en fonction de celui-ci ou de la joindre à d'autres données, cela a du sens. Mais les données de fichier, binaires ou non, ne sont généralement pas utilisées de cette manière. Exemple de mise en oeuvre: Il existe de meilleures méthodes pour distribuer des données de fichier que Entrez-le dans une DB, telle qu'un système de fichiers distribués (enregistrement dans GLUSTERFS, Moosefs, qui permettra tous deux en ajoutant simplement des disques durs supplémentaires, alors que MySQL ne le fera pas). Typiquement, je vais stocker le fichier Données dans le système de fichiers à l'aide d'un hachage SHA1 des données comme nom du fichier. Si le hachage est 98A75AF529F07B1EF7BE7400F51344B9F07B1EF7, alors je le stockerai dans cette structure de répertoire: c'est-à-dire, un répertoire de niveau supérieur composé des deux premiers caractères, une seconde Répertoire de niveau constitué des deux seconde-deux caractères, puis enfin le fichier avec le nom de la chaîne totale. De cette manière, je peux littéralement avoir des milliards de fichiers sans avoir tant dans un seul répertoire que le système est trop lent à fonctionner. puis je crée une table de base de données avec ces colonnes pour contenir les métadonnées: Lorsque j'ai besoin d'une structure de répertoire hiérarchique, je créerais également une table de répertoires et ajouterais un dir_id à la liste des colonnes ci-dessus. si je modifie le fichier représenté par Si j'en ai besoin pour être disponible sous une manière distribuée, je configurais la réplication MySQL, puis utilisez GLUSTERFS pour reproduire son système de fichiers sur plusieurs serveurs.
./98/a7/98A75AF529F07B1EF7BE7400F51344B9F07B1EF7 , je ne modifie pas ce fichier sur disque, je crée un nouveau (car le nouveau contenu du fichier serait représenté par un nouveau hachage SHA1) et créer une nouvelle entrée dans La table des fichiers où prev_id est égal à la fichier_id du fichier que j'ai édité. En d'autres termes, j'ai maintenant des versions.
Merci beaucoup pour cela, c'est une très bonne réponse. J'aime particulièrement votre méthode de stockage de fichiers suggéré. Il serait également agréable d'utiliser un système de fichiers distribué comme vous l'avez mentionné, mais malheureusement, nous ne travaillons pas avec des serveurs dédiés (au moins au moins). Je dois essayer de le rendre aussi compatible que possible avec des configurations d'hébergement Web partagées typiques, ce qui rend bien sûr difficile l'utilisation de tout ce qui a besoin d'installer sur le serveur. Mais encore une fois, merci pour la méthode du système de fichiers élégant :)
Si vous allez basculer, s'il vous plaît, pouvez-vous au moins fournir une explication afin que je puisse éviter la même erreur?