Cassandra - nombreux petits ou moins gros nœuds?

Question

Je vais héberger ma base de données Cassandra sur Google Cloud. Les instances sont au prix d'une façon linéaire sens 1cpu avec 2gb ram est de 1 $, 2cpu avec 4gb est de 2 $, 4cpu avec 8 Go est de 4 $ et ainsi de suite.

Je décide de la taille de mes instances et je ne suis pas sûr de ce que la norme est? Je pensais utiliser moins d'instances plus grandes (8cpu, 64gb) par opposition à plus léger comme (2cpu, 4 gb). Mon processus de pensée est avec plus d'instances que chaque nœud transportera moins de données globales, ce qui aurait un impact moindre si les nœuds échouaient. De même, le nombre de ces instances plus petites aurait moins de frais généraux, car il accepterait moins de connexions.

Ce sont des pros, mais voici quelques inconvénients que je peux penser: 1) Chaque instance sera moins utilisée 2) Frais généraux JVM Cassandra + sur tant d'exemples peuvent additionner et être beaucoup de frais généraux. 3) J'utiliserai des disques SSD locaux, contrairement aux SSD persistants, qui sont beaucoup plus chers, ce qui signifie que chaque instance aura besoin de son propre SSD local, ce qui augmentera les coûts.

Voici quelques raisons pour lesquelles je peux penser, y a-t-il d'autres avantages/inconvénients entre choisir des instances plus petites plutôt que plus grandes pour une base de données Cassandra (peut-être même des nœuds en général)? Existe-t-il des meilleures pratiques associées au choix des tailles de serveur Cassandra? PS: J'ai ajouté le tag 'Java' parce que Cassandra est construit en utilisant JAVA et fonctionne sur la JVM et aimerait voir si la JVM a des avantages/inconvénients.

Answer 1

Je pense que vous avez touché certains des points de compromis, mais voici quelques autres:

1. Comme la quantité de données stockées sur une augmentation unique de nœud, le coût de bootstrapping (ajout de nouveaux noeuds) augmente. Par exemple, vous obtiendrez des temps d'amorçage raisonnables en stockant 100 Go par nœud, mais le processus prendra des éons avec 10 To par nœud.
2. L'utilisation du SSD le rend moins important, mais envisagez d'utiliser des disques physiques distincts pour votre journal de commit et vos données.
3. Les configurations avec moins de 4 cœurs ou moins de 8 Go de mémoire ne sont généralement pas recommandées, mais votre consommation peut varier.