• [^] # Re: Migration

    Posté par . En réponse à la dépêche Nextcloud, le fork d'ownCloud. Évalué à 3.

    Plus, c'est chiant quand tu veux voir tes données, si t'as pas prévu une table "binary_data" pour isoler les données des méta-données, tu devras bien faire "select (id, date_created...) from media" et pas select * sinon merci la purge.

    Il faut évidement que ce soit bien fait :)

    On est globalement d'accord. Les bases relationnelles et toutes les techno qui vont avec (les ORM par exemple) ne savent globalement pas traiter des blob binaires un tout peu gros (c'est utile pour des truc vraiment petits éventuellement comme du une favicon). Les bases en elle-même savent faire des choses là dessus (comme séparer les blobs sur un espace différent et te les présenter comme une même table (comme une vue) et ne charger les blob que si tu l'a vraiment demandé). Mais rien autour ne permet d'en tirer vraiment parti, tu parlais d'hibernate, je ne suis même pas sûr que JDBC puisse correctement gérer ça (ne pas s'attendre à recevoir toute la ligne en une seule fois par exemple).

    Ça oblige à avoir beaucoup de place sur les serveurs de données. Exit la BDD sur SSD, ou alors une baie de SSD hors de prix, ou alors tu devras configurer ta BDD pour qu'elle mette cette table sur des disques moins chers. Donc soit te manger une pénalité de latence pour l'accès aux métadonnées si elles ne sont pas séparées, soit séparer le binaire comme dit plus haut, mais alors un peu réinventer le "je mets mes données ailleurs que dans la BDD".

    Je ne connais pas vraiment la problématique SSD ou pas (en terme de prix). Pour parler de ce que je connais avec cassandra, il te demande d'avoir son dossier de stockage sur SSD et il est là pour encaisser des Tio de données.

    Bref ça se réfléchis et je n'ai aucune idée de la pertinence de Couch là dessus.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)