Avis BDD sur nas ou ssd?

Bonjour à tous, je me pose une question qui me tourne depuis quelques jours, niveau base de données, le mieux est de rester sur celle d’origine sachant que je suis en ssd ou externaliser si possible, je fais un essai sur mariadb via mon nas ds120j, j’ai même l’impression que tout est plus réactif, maintenant est ce une idée, je ne sais pas, et cela est t’il mieux que la bdd de base ?
Merci d’avance.

Salut.
La vraie question c’est plutôt : pourquoi faire ?
Passer sur du mariadb est-il plus stable, plus rapide c’est très subjectif… Personnellement moi j’y crois pas. On parle même pas des perfs ssd versus nas…
Est-ce plus compliqué à gérer : par définition oui.
Ça ajoute quelques choses ? A l’utilisateur moyen : rien.

Dans l’hypothèse où il y a un gain à faire c’est sur la configuration du record… Et c’est parfaitement adapté à ce la base standard

1 « J'aime »

Salut Pulpy, j’avais pensé que ça limité les lectures écritures sur le ssd, ont sais que sais mauvais aussi bien pour une sd qu’un ssd qui est conçu pareil avec des mémoires flash.
L’avantage à mes yeux de la bdd sur nas, c’est dans un premier temps, libérer le système de la gestion de la bdd, ensuite sur mes premiers tests hier, Ha était effectivement bien plus rapide et vif par rapport à sql de base sur ssd.
Ensuite le nas lui est conçu pour des lectures écritures permanente, il est en local et ça répond très rapidement contrairement à ce que tu pense, clairement plus rapide que le ssd, et ce n’ai pas placebo. Je ne pourrais pas d’ailleurs l’expliquer, mais je peux faire une vidéo de comparaison des temps de réponse si ça vous intéresse. :wink: Mais clairement à l’œil le système est plus rapide à répondre.
Ensuite j’arrive au deuxième points que tu énumère, la compatibilité qui effectivement n’ai pas certifié à 100%.
Je suis revenu à la bdd de base pour cette raison, et j’avais peur de perdre des enregistrements en cas de mise à jour dsm, car la effectivement plus rien pour enregistrer.
Donc pour conclure, j’y vois l’avantage de la rapidité, mais d’autres inconvénients énumérer, d’où cette question de savoir comment les menbres procéder.
Car sur le forum international, beaucoup ont externaliser leur bdd sur mariadb via nas. Donc j’ai essayé pour me faire une idée, et maintenant, je creuse la question. :wink:

Bonjour,

Quel est le sens de votre question ? qu’attendez-vous comme réponse de la part des participants de ce forum ?

Ces types de comparaison sont toujours des discussions sans réel définition des conditions de tests, ni de définition du sujet de la comparaison, nous parlons de rapidité, de temps de réponse, de sécurité etc…

Si votre solution répond aux besoins que vous avez défini, n’est pas là la réponse à cette question :slight_smile:

mcp

Il y a plusieurs points sur lesquels je ne suis pas d’accord

  1. Le ssd c’est fait pour écriture en quantité (comme un disque dur) alors que ce n’est pas vraiment le cas pour une carte sd. D’ailleurs ton nas pourrait parfaitement faire le job en utilisant du ssd c’est ce qui se fait en entreprise. Aujourd’hui, c’est juste qu’un disque mécanique est juste plus abordable quand il s’agit d’avoir de la place

  2. Pour comparer la performance entre la base d’origine et ta base externalisée il faut aussi comparer à contenu égal. En créant la partie mariadb, tu pars de 0 (base vide) donc forcément c’est au début plus rapide que la base d’origine qui elle n’est vide… Après quelques jours (10 par défaut) ça sera moins le cas. De plus, la chaîne d’accès est simple d’un côté cpu-ssd (base d’origine) versus cpu-lan-cpu-ssd (mariadb).
    À noter que, même si techniquement mariadb est plus performant pour les requêtes comme c’est pas l’usage principal sous HA : bof… Pour de l’écriture séquentielle et à quantité réduite sqlite c’est très bien. Et dans un cas comme dans l’autre on est loin de faire des choses compliquées avec les données de ha…

  3. Les 2 types de bases sont parfaitement compatibles dans HA. D’ailleurs si c’était pas le cas le forum international en question contiendrait sans doute plus de problème par rapport à ça.

  4. Pour que ça fonctionne parfaitement bien, je maintiens que la première étape c’est de faire le tri de ce que l’on met en base.

1 « J'aime »

Merci pour ton retour qui me conforte par rapport à tout ce que j’ai pu lire sur le forum international. :wink:

Salut,

C’est clair, comme on l’a déjà dit souvent, gérer le recorder est plus important que le type de base.
Sur un SSD en plus il ne devrait pas y avoir de souci d’I/O. Et sinon la gestion du commit_interval du recorder peut avoir aussi un gros impact, surtout si tu gardes beaucoup de sensors qui se mettent à jour toutes les secondes.

Tu conseillerais quoi en commit_interval pour un ssd ?
Je garde principalement toutes mes entitées énergétique.
Il y a un moyen de connaître les entitées qui prennent beaucoup de place ? J’ai installé sqllite Web, il y a pas une ligne de commande pour savoir ce qui est gourmand ? :thinking:
Merci d’avance.

Bonjour,

un simple « SELECT entity_id, COUNT(*) as count FROM states GROUP BY entity_id ORDER BY count DESC » pour la table states, vous donnera la liste de vos entités et le nombre d’enregistrement pour chacune.

mcp

2 « J'aime »

Salut.
Plein de sujets qui expliquent comment faire