Est-ce que quelqu'un sait s'il existe une implémentation de client/pilote YCSB disponible pour l'analyse comparative VoltDB? Ou même des publications de référence/blog/article/projet de recherche? Pouvons-nous utiliser les charges de travail TPC pour l'analyse comparative VoltDB?YCSB pour VoltDB
Merci beaucoup à tous.
Développeur VoltDB ici.
Il n'y a pas de pilote YCSB officiel bien que plusieurs utilisateurs aient effectué une analyse comparative en utilisant le cadre YCSB. Il y a un peu d'inadéquation d'impédance entre YCSB et VoltDB. YCSB est conçu pour fonctionner avec les magasins de colonnes à plage partagée. VoltDB est un magasin relationnel haché avec un support riche pour la logique côté serveur.
Cela se manifeste comme un problème de trois façons.
Le premier est que YCSB nécessite des balayages de plage. Vous pouvez effectuer des analyses de plages efficaces dans un magasin de hachage fragmenté si vous avez une certaine connaissance de la distribution de clés et pouvez normaliser les clés afin de les utiliser de manière utile. Voici un exemple de la façon dont vous le feriez dans Cassandra.
Ce n'est pas insurmontable, mais cela demande réflexion.
Le deuxième problème est que le modèle de magasin de colonnes ne correspond pas bien au modèle de données relationnel. Je peux gagner un peu de vitesse et d'efficacité de mémoire en emballant de petites cartes dans une seule rangée avec un blob et en le réécrivant lorsque des paires k/v sont ajoutées/mises à jour. C'est comme ça que Redis gère les petites cartes.
Pour les clés plus grandes avec plusieurs/plus grandes paires k/v, il est logique de dénormaliser et de permettre à la base de données de gérer la mémoire. Avec un peu de travail, vous pouvez créer une API de procédure stockée qui le fait de manière transparente.
Encore une fois ce n'est pas insurmontable, mais ce n'est pas trivial non plus.
Le troisième problème est que YCSB est écrit sous l'hypothèse que toute la logique existe sur le client et que le serveur devra matérialiser toutes les données pour le client. Cela signifie que votre application réelle écrite contre VoltDB pourrait être plusieurs fois plus rapide et plus efficace. Plus rapide car la logique côté serveur peut éliminer plusieurs allers-retours vers le client et plus d'espace car la prise en charge des transactions vous permet d'éviter d'écrire votre application de manière structurée. YCSB vous donnera une idée générique de la façon dont VoltDB fonctionne et évolue, mais il y a des avantages non négligeables à écrire votre application d'une manière qui convient au modèle de données relationnelles et l'accent mis par Volt sur la logique côté serveur. .
En ce qui concerne le TPC-C. VoltDB a été conçu spécifiquement pour un benchmark TPC-C. Je dis "j'aime" parce que ce n'est pas officiel et cela diffère de TPC-C de plusieurs façons. La différence la plus significative est que les transactions de nouvelle commande n'utilisent qu'un seul entrepôt (et non les entrepôts 1-10 requis pour quelques% des nouvelles commandes). Ceci est important car cela permet à l'indice de référence de se répartir parfaitement sans aucune transaction distribuée.
Le test de référence VoltDB TPC-C n'est pas fourni avec la distribution mais est disponible au github.
Un autre développeur VoltDB ici, qui vient de passer par le processus de mise en œuvre d'un pilote YCSB. La source de ce pilote peut être trouvée sur GitHub, au https://github.com/VoltDB/voltdb/tree/master/tests/test_apps/ycsb.
Un peu de détails au sujet de notre mise en œuvre:
YCSb travaille avec un format de colonne large, les clés de chaîne de cartographie à un certain nombre de champ k chaîne binaire/v correspondances. La création d'un pilote qui gère cela de manière flexible, c'est-à-dire qui gère des configurations YCSB arbitraires, ne permet pas l'utilisation directe d'un schéma relationnel fixe. Pour résoudre ce problème, nous avons adopté une approche de type «petite carte», c'est-à-dire que pour chaque clé, nous comprimons tous les champs en une seule tâche telle que des lignes entières YCSB sont traitées à des paires k/v. Cela rend la présomption implicite (douce) que le nombre de champs pour chaque rangée sera relativement faible (disons, < = 50), ce qui semble raisonnable compte tenu des résultats publiés de l'YCSB. Une logique supplémentaire pourrait être ajoutée au niveau de la procédure stockée pour traiter le cas d'un grand nombre de champs par ligne, mais étant donné l'utilisation existante du cas-test, cela semble être une complexité inutile. En outre, nous avons interprété l'opération «scan» comme signifiant «parcourir les données dans un ordre déterministe, à partir de cette clé». Dans le monde réel, les données signifient quelque chose et peuvent (ou peuvent ne pas) posséder un ordre significatif. Dans le monde de YCSB, il n'y a pas de raison particulière de préférer un ordre plutôt qu'un autre. Par conséquent, nous imposons un ordre artificiel sur les partitions VoltDB; combiné avec l'ordre intrapartition imposé par l'index de clé primaire, ceci impose un ordre total sur l'ensemble des données. Pour les lecteurs intéressés, la mise en œuvre côté client de cette opération utilise une variante quelque peu nouvelle du modèle «courir partout» utilisé dans certains de nos exemples.
Les résultats publiés de nos tests peuvent être vus à https://voltdb.com/blog/voltdb-in-memory-database-achieves-best-in-class-results-running-in-the-cloud-on-the-ycsb-benchmark-3/. Comme mon collègue l'indique ci-dessus, bien que très solide, les résultats de ce benchmark vont en fait sous-estimer les performances de VoltDB car il ne tire pas parti des optimisations disponibles en regroupant la logique dans les invocations de procédures stockées.