Nous évaluons toujours Cassandra pour notre magasin de données. En tant que test très , j'ai inséré une valeur pour 4 colonnes dans la famille Colonne Keyspace1 / Standard1 sur ma machine locale représentant environ 100 octets de données. Ensuite, je l'ai lu aussi vite que je pouvais par la clé de rangée. Je peux le lire à 160 000 heures / seconde. Super.
Puis j'ai mis dans un million d'enregistrements similaires tout avec des clés sous la forme de x.y où x dans (1..10) et y dans (1..100 000) et je serais interrogé pour un enregistrement aléatoire. La performance est tombée à 26 000 questions par seconde. Cela reste bien au-dessus du nombre de requêtes que nous devons supporter (environ 1 500 / sec)
Enfin, j'ai mis dix millions d'enregistrements de 1,1 à 10.1000000 et interrogé au hasard pour l'un des 10 millions d'enregistrements. La performance est abyssante à 60 questions par seconde et mon disque se débattre comme un fou.
J'ai également vérifié que si je demande un sous-ensemble des données, disons les 1 000 enregistrements entre 3 000 000 et 3 001 000, il revient lentement au début, puis au moment de la mise en cache, il accélère jusqu'à 20 000 requêtes par seconde et mon disque s'arrête devenir fou.
J'ai lu partout que les gens stockent des milliards de disques à Cassandra et les récupèrent à 5-6k par seconde, mais je ne peux pas obtenir nulle part près de cela avec seulement 10 millions de disques. Une idée de ce que je fais mal? Y a-t-il un certain paramètre que je dois passer des défauts par défaut? Je suis sur une boîte noyau overclockée I7 avec 6gigs de RAM, donc je ne pense pas que ce soit la machine.
Voici mon code pour récupérer des enregistrements que je reproche à 8 threads pour demander une valeur d'une colonne via la touche de ligne:
colonne de colonne cp = nouvelle colonne de colonne ();
cp.column_family = "standard1";
cp.column = utf8encoding.getbytes ("site");
Clé de chaîne = (1 + srand.next (9)) + "." + (1 + srand.next (1000000));
CinummorSuperColumn Logline = Client.get ("Keyspace1", clé, CP, consistenceendencyvel.one);
Merci pour toutes les idées
4 Réponses :
On dirait que vous n'avez pas assez de RAM pour stocker tous les enregistrements en mémoire.
Si vous échangez sur le disque, vous avez des problèmes et que les performances devraient diminuer de manière significative, surtout si vous êtes une lecture aléatoire.
Vous pouvez également essayer d'analyser d'autres alternatives populaires, comme Redis ou Voltdb .
Nous ne pouvons absolument pas les adapter à la mémoire, mais 10 mil dossiers ne semblent pas beaucoup. Comment les gens traitent-ils de milliards d'enregistrements?
La clé est de garder autant que possible dans la RAM, pas sur le disque. Pour gérer des milliards d'enregistrements, vous les distribueriez sur plusieurs machines et utilisez-les dans son ensemble. Voici un très bel article [1] sur la manière dont cela est atteint à Riak, une autre solution populaire NOSQL. Un grand nombre des aspects abordés dans l'article s'appliquent également à Cassandra, car ils sont construits sur les mêmes idées fondamentales. [1]: wiki.basho.com/display/riak/an+ Introduction + à + Riak
Les lectures purement aléatoires concernent le comportement pire des cas pour la mise en cache que votre système d'exploitation (et Cassandra si vous configurez la clé ou la cache de la ligne) essaie de faire.
Si vous regardez Contrib / py_stress dans la distribution de la source Cassandra, il dispose d'une STDEV configurable pour effectuer des lectures aléatoires, mais avec certaines touches plus chaudes que d'autres. Ce sera plus représentatif de la plupart des charges de travail du monde réel.
Malheureusement, nous aurons des visiteurs au hasard arrivant sur notre site à intervalles aléatoires - il n'y a pas de distribution que nous sauverrons à l'avance pour obtenir plus de succès de cache. Sommes-nous simplement limités à la vitesse du disque dans ce cas?
Rien n'est vraiment aléatoire. Votre performance réelle est très probablement meilleure que vos tests. Cela étant dit, Cassandra utilise-t-il réellement toute la mémoire sur la boîte? 60 Reads / SEC est si horrible sur votre matériel qu'il est probablement que vous avez un problème d'installation (Eh bien, en fonction de la difficulté de vos disques). Aussi, assurez-vous que Cassandra n'utilise pas l'échange comme s'il s'agissait de mémoire physique - qui crée un problème de performance pathologique avec Cassandra et le système d'exploitation tente de manière indépendante d'optimiser les pages en mémoire de manière concurrente.
ajoutez plus de nœuds de Cassandra et donnez-leur beaucoup de mémoire (-XMS / -XMX). Plus vous avez des instances Cassandra, les données seront partitionnées à travers les nœuds et beaucoup plus susceptibles d'être en mémoire ou plus facilement accessibles à partir du disque. Vous serez très limité avec essayer d'accabler un processeur de classe de travail unique. Vérifiez également le paramètre par défaut -xms / -xmx. Je pense que la valeur par défaut est de 1 Go.
Voltdb peut certainement gérer ce niveau de performance de lecture ainsi que les écrit et fonctionne à l'aide d'un groupe de serveurs. En tant que solution en mémoire, vous devez construire un cluster assez important pour contenir toutes vos données en RAM.