Aerospike sur la mémoire Cassandra?

Question

Je suis un peu un noob avec noSQL & ne peut pas décider pour Aerospike plus complet en mémoire Cassandra.

Cas d'utilisation: À utiliser pour plusieurs services dans notre université (de la plate-forme sociale à l'analyse financière interne à la journalisation réseau en passant par la messagerie en temps réel). Nos utilisateurs actifs quotidiens sont également constants (~ 5000). Donc, ma principale exigence n'est pas d'obtenir 1M + TPS, mais de réduire la latence et de maintenir la cohérence au service des données de l'utilisateur le plus rapidement possible. La base de données fonctionnerait sur 3 serveurs en métal nu avec un disque SSD de 256 Go 128 Go-Ram de 256 Go chacun connecté en 10 Gbits. Les données ne dépasseront pas Ram car la plupart des données seront archivées (vers un autre serveur ElacticSearch) tous les 6 mois.

Aussi, je ne me dérange pas de relever le défi et de faire un peu de sur-ingénierie & c'est très bien si le cluster est difficile à installer mais il devrait nécessiter peu ou pas de maintenance pendant des années.

Alors, en regardant l'aérospike DB en mémoire semblait un excellent choix. Puis j'ai été très excité pour aller très vite mais ensuite j'ai regardé Aerospike total garbage? & We use Aerospike heavily. It works just fine. Maintenant, cela m'a fait penser que c'était le meilleur choix pour moi?

Ou devrais-je aller pour complète en mémoire Cassandra qui est pas optimisé pour la table complète en mémoire & est encore moins performante que aérospike mais a un meilleur ajustement de modèle de données pour moi, n'a pas de problèmes de cohérence et essayé & testé (je suis intrigué par ScyllaDB mais il n'a pas de tables en mémoire)

Je voudrais avoir des réponses de personnes ayant une expérience de production avec Aerospike & Cassandra. Aussi s'il vous plaît dites-moi si je me trompe complètement.

Answer 1

Mon premier point est que ce n'est pas une question Stackoverflow valide. Lorsque vous cliquez sur Poser une question la Comment demander aux Etats bloc Is your question about programming?

L'article moyen est l'opinion mal écrit d'un utilisateur sans visage, sans données à sauvegarder les revendications. Oui, Aerospike a bugs, comme toutes les bases de données. GCE lui-même a bugs qui peut affecter une base de données distribuée telle que Aerospike. Je n'ai vu aucun problème dans le repo aerospike/aerospike-server sur GitHub parlant des problèmes de cet utilisateur sur GCE. En général, les personnes qui utilisent un produit logiciel en production signalent un bug qui les affecte gravement. L'absence d'un rapport de bug est une "mauvaise odeur" - est-ce FUD?

Aerospike est en effet utilisé pour haute performance à grande échelle par de nombreux customers. Je vais supposer que même si ledit blogueur moyen a réellement utilisé Aerospike en production, il n'était probablement pas à l'échelle des lectures 3Mtps et 1.5Mtps écrit que AppNexus voit pour leur installation Aerospike. Peut-être que la preuve qu'il s'agit d'une base de données clé-valeur appropriée pour un système de production est dans son utilisation actuelle par de vrais clients.

Répondons à votre question spécifique sur l'utilisation de Cassandra ou Aerospike pour un cas d'utilisation de valeurs-clés. Vous voulez probablement commencer avec des benchmarks de haute qualité comparant les deux, mais comment déterminez-vous si ceux-ci sont bien fait? Aerospike a publié un manifesto sur ce que devrait être l'analyse comparative de haute qualité des bases de données. Lorsque vous rencontrez un benchmark, lisez tout le long de la publication et vérifiez la taille des objets, le nombre d'objets, la taille de l'ensemble de données, la durée du test. Si le fournisseur chose a tiny data set et a exécuté leur test pendant quelques minutes, il n'est pas un cas-test valide.Il n'y a rien à apprendre de la façon dont la base de données fonctionnerait avec des charges réelles et durables, sur des tailles de données réalistes, pendant de longues périodes. Dans l'esprit du manifeste, Aerospike a publié un benchmark détaillé par rapport à Cassandra et ScyllaDB. Les deux montrent qu'Aerospike a toujours des latences plus faibles avec peu de variation, tandis que les autres bases de données ont des fluctuations de latence sauvages. Ceci est dû aux différences d'architecture entre l'architecture cache-première de NoSQL de première génération comme Cassandra (aussi Couchebase, MongoDB, etc.) et la conception hybrid-memory architecture d'Aerospike.

Dans une architecture antémémoire, la base de données recherche d'abord dans ses antémémoires en mémoire les clés et les objets, et ne va sur le disque qu'en cas d'échec de mise en cache. La base de données prend alors une grande pénalité de latence pour les données de pagination de SSD en mémoire, puis fonctionne sur cette mémoire. Ces bases de données attendent le majority of reads to come out of cache. Une fois que le taux de succès du cache est tombé dans une fourchette réaliste (et non dans les 80% à 95% espérés), une base de données antémémoire affichera les pics de latence en allant sur le disque. En conséquence, un cluster Cassandra a besoin de beaucoup de RAM sur de nombreux nœuds.

Dans le cas de aérospike, l'architecture mémoire hybride (HMA) maintient le primary index (métadonnées sur tous les objets) dans la DRAM, et repose sur optimizations around SSD performance pour récupérer les données directement à partir du disque à faible latence. Il existe un large éventail de performances entre différents SSD (voir Aerospike on Intel Optane), vous utiliserez donc les données de l'outil open source ACT pour comprendre les performances en lecture/écriture du SSD, tout en réalisant 95% des opérations. < = 1ms . HMA nécessite donc très peu de mémoire par nœud (64 Mo par objet multiplié par le facteur de réplication), ce qui se traduit par des clusters plus petits. Les données sont directement transmises par SSD, ce qui vous permet de bénéficier d'une latence constamment faible pour vos opérations, même à grande échelle.

Si vous stockez toutes vos données dans la mémoire, jetez un oeil à What's New in Aerospike 3.12? et What's New in Aerospike 3.11?, car elles incluent des optimisations pour un tel cas d'utilisation. Spécifiquement, voir sprigs et CPU pinning.