Stocker un grand nombre de fichiers, ou des fichiers larges, dans une DB relationnelle est une très mauvaises idée, ça n'a jamais été désigné pour ça.
Ici il s'agit de couchDB donc pas de relationnel.
Mettre des fichiers dans une DB revient plus ou moins a serializer chaque fichier dans un gros blob binaire géant avant de le mettre lui même dans un fichier. C'est une terrible idée.
Je me sens un peu bête, je ne vois pas vraiment le problème. Il n'y a pas vraiment de sérialisation (ce n'est pas une transformation). Il faut bien sûr que ta base sache gérer correctement des champs de cette taille, mais si la base que tu utilise le propose en quoi c'est aussi terrible que ça ?
Mais là ça revient a perdre tous les avantages d'utiliser une DB ....
C'est indexé comme toutes tes autres données, c'est répliqué de la même façon que le reste de tes données, ça se backup comme le reste de tes données, tu y accède de la même façon que le reste de tes données,...
La manière dont ta base traite tes données ne te concerne pas trop. Qu'est-ce que tu perds dans le fait que la base le stocke à part ?
Un fichier c'est un bloque de données non-structurées, tu as pleins de choses pour gérer ça et il y a une littérature fournie sur la gestion des données non-structurées dans les bases de données (SQL ou pas). Un FS est une solution, mais ce n'est pas forcément celle qui t'arrange le plus. Pour reprendre l'exemple que je connais pour Apple et iCloud, les fonctionnalités de réplications de cassandra sont très pratiques pour eux et le fait de découper le fichier un chunk qui doit donc être agrégé avant d'être rapatrié est vraiment très pratique pour eux (au lieu de télécharger un bloc de 1Gio d'un serveur à un autre, ils récupèrent par exemple ×ばつ10Mio depuis potentiellement 100 serveurs différents).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Migration
Posté par barmic . En réponse à la dépêche Nextcloud, le fork d'ownCloud. Évalué à 3.
Ici il s'agit de couchDB donc pas de relationnel.
Je me sens un peu bête, je ne vois pas vraiment le problème. Il n'y a pas vraiment de sérialisation (ce n'est pas une transformation). Il faut bien sûr que ta base sache gérer correctement des champs de cette taille, mais si la base que tu utilise le propose en quoi c'est aussi terrible que ça ?
C'est indexé comme toutes tes autres données, c'est répliqué de la même façon que le reste de tes données, ça se backup comme le reste de tes données, tu y accède de la même façon que le reste de tes données,...
La manière dont ta base traite tes données ne te concerne pas trop. Qu'est-ce que tu perds dans le fait que la base le stocke à part ?
Un fichier c'est un bloque de données non-structurées, tu as pleins de choses pour gérer ça et il y a une littérature fournie sur la gestion des données non-structurées dans les bases de données (SQL ou pas). Un FS est une solution, mais ce n'est pas forcément celle qui t'arrange le plus. Pour reprendre l'exemple que je connais pour Apple et iCloud, les fonctionnalités de réplications de cassandra sont très pratiques pour eux et le fait de découper le fichier un chunk qui doit donc être agrégé avant d'être rapatrié est vraiment très pratique pour eux (au lieu de télécharger un bloc de 1Gio d'un serveur à un autre, ils récupèrent par exemple ×ばつ10Mio depuis potentiellement 100 serveurs différents).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)