Tutoriel : créer des applications compatibles avec DynamoDB pour n’importe quel cloud (ou sur site)

Alternator est un projet open source qui permet aux équipes de créer des applications compatibles DynamoDB « exécutables n’importe où » avec ScyllaDB. Cela signifie que vous pouvez déployer où vous voulez : sur site ou sur n’importe quel cloud public.

Dans ce tutoriel, nous allons commencer par présenter le projet. Ensuite, nous verrons un exemple pratique de création d’un cluster ScyllaDB à un nœud et d’exécution de certaines opérations de base dessus.

L’objectif de ce projet est de fournir une alternative open-source à DynamoDB, déployable partout où un utilisateur le souhaiterait : sur site, sur d’autres clouds publics comme Microsoft Azure ou Google Cloud Platform, ou encore sur AWS (pour les utilisateurs qui souhaitent prendre avantage d’autres aspects de l’écosystème cloud leader du marché d’Amazon, tels que les puissantes instances i4). Les utilisateurs de DynamoDB peuvent conserver leur même code client inchangé. Alternator est écrit en C++ et fait partie de ScyllaDB.

Les trois principaux avantages que ScyllaDB Alternator offre aux utilisateurs de DynamoDB sont :

Coût : DynamoDB facture les transactions de lecture et d’écriture (RCU et WCU). Une solution gratuite et open source ne le fait pas.
Performances : ScyllaDB a été implémenté en C++ moderne. Il prend en charge des fonctionnalités avancées qui lui permettent d’améliorer considérablement la latence et le débit.
Ouverture : ScyllaDB est open-source. Il peut s’exécuter sur n’importe quel cluster de serveurs approprié, quel que soit l’emplacement ou la méthode de déploiement.

Configurer un cluster ScyllaDB

Si vous ne l’avez pas encore fait, téléchargez l’exemple depuis git :

git clone https://github.com/scylladb/scylla-code-samples.git

Aller dans le répertoire de l’alternateur exemple :

cd scylla-code-samples/alternator/getting-started

Ensuite, nous allons démarrer un cluster à un nœud avec l’alternateur activé.

Par défaut, ScyllaDB n’écoute pas les demandes d’API DynamoDB. Pour activer de telles demandes, nous allons définir l’option de configuration alternateur-port sur le port (8000 dans cet exemple), qui écoutera les demandes d’API DynamoDB.

L’alternateur utilise la fonction LWT de ScyllaDB. Vous pouvez en savoir plus à ce sujet dans la documentation.

docker run --name some-scylla --hostname some-scylla -p 8000:8000 -d scylladb/scylla:4.0.0 --smp 1 --memory=750M --overprovisioned 1 --alternator-port=8000

Attendez quelques secondes et assurez-vous que le cluster est opérationnel :

docker exec -it some-scylla nodetool status

[guy@localhost ~]$ docker exec -it some-scylla nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns    Host ID                               Rack
UN  172.17.0.2  79.82 KB   256          ?       1ccbb599-ce5c-4d72-9c3a-991e2567d0be  rack1

Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless
[guy@localhost ~]$

Dans cet exemple, nous utiliserons le langage Python pour interagir avec ScyllaDB avec le SDK Boto 3 pour Python. Il est également possible d’utiliser la CLI ou d’autres langages tels que Java, C#, Python, Perl, PHP, Ruby, Erlang ou JavaScript.

Ensuite, si vous ne l’avez pas déjà configuré, installez la bibliothèque Boto 3 Python qui contient également des pilotes pour DynamoDB :

sudo pip install --upgrade boto3

Dans les trois scripts (create.py, read.py et write.py), remplacez la valeur de « endpoint_url » par l’adresse IP du nœud.

Créer un tableau

Maintenant, nous allons utiliser le script create.py pour créer une table dans notre cluster nouvellement créé, en utilisant Alternator.

from __future__ import print_function
import boto3
dynamodb = boto3.resource('dynamodb',endpoint_url="http://172.17.0.2:8000",
                  region_name="None", aws_access_key_id='None', aws_secret_access_key='None')

table = dynamodb.create_table(
    BillingMode="PAY_PER_REQUEST",
    TableName="mutant_data",
    KeySchema=[
    {
        'AttributeName': 'last_name',
        'KeyType': 'HASH'
    },
    ],
    AttributeDefinitions=[
    {
        'AttributeName': 'last_name',
        'AttributeType': 'S'
    },
    ]
)

print("Finished creating table ", table.table_name ,". Status: ", table.table_status)

L’autorisation n’est pas dans le cadre de cette leçon, nous utiliserons donc « Aucune » et nous y reviendrons dans une prochaine leçon.

Nous définissons une table appelée « mutant_data » avec les propriétés requises telles que la clé primaire « last_name » qui est d’un type de données String. Vous pouvez en savoir plus sur les types de données Boto 3 ici.

Le modèle de données DynamoDB est similaire à celui de ScyllaDB. Les deux bases de données ont une clé de partition (également appelée « clé de hachage » dans DynamoDB) et une clé de clustering facultative (appelée « clé de tri » ou « clé de plage » dans DynamoDB), et les mêmes notions de lignes (que DynamoDB appelle « éléments ») à l’intérieur des cloisons. Il existe certaines différences dans le modèle de données. L’une d’entre elles est que dans DynamoDB, les colonnes (appelées « attributs »), autres que la clé de hachage et la clé de tri, peuvent être de n’importe quel type et peuvent être différentes dans chaque ligne. Cela signifie qu’ils n’ont pas besoin d’être définis à l’avance. Vous pouvez en savoir plus sur la modélisation des données dans Alternator dans des leçons plus avancées.

Dans cet exemple simple, nous utilisons un cluster ScyllaDB à un nœud. Dans un environnement de production, il est recommandé d’exécuter un cluster d’au moins trois nœuds.

De plus, dans cet exemple, nous enverrons les requêtes directement à notre nœud unique. Dans un environnement de production, vous devez utiliser un mécanisme pour distribuer différentes requêtes DynamoDB à différents nœuds ScyllaDB, afin d’équilibrer la charge. Plus d’informations à ce sujet dans les prochaines leçons.

Exécutez le script :

python create.py

[guy@localhost getting-started]$ python create.py
Finished creating table  mutant_data . Status:  ACTIVE
[guy@localhost getting-started]

Chaque table Alternator est stockée dans son propre espace de clés, que ScyllaDB crée automatiquement. La table xyz sera dans l’espace de clé alternateur_xyz. Cet espace de clés est initialisé lors de la création de la première table Alternator (avec une requête CreateTable). Le facteur de réplication (RF) pour cet espace de clés et toutes les tables Alternator est choisi à ce stade, en fonction de la taille du cluster : RF=3 est utilisé sur les clusters avec trois nœuds actifs ou plus. RF=1 serait utilisé si notre cluster est plus petit, comme c’est le cas dans notre cas. L’utilisation d’un cluster ScyllaDB de moins de trois nœuds n’est pas recommandée pour la production.

Exécution de requêtes de base

Ensuite, nous allons écrire et lire certaines données de la table nouvellement créée.

from __future__ import print_function
import boto3
dynamodb = boto3.resource('dynamodb',endpoint_url="http://172.17.0.2:8000",
                  region_name="None", aws_access_key_id='None', aws_secret_access_key='None')

response = dynamodb.batch_get_item(
    RequestItems={
        'mutant_data' : { 'Keys': [{ 'last_name': 'Loblaw' }, {'last_name': 'Jeffries'}] }
    }
)
for x in response:
    print (x)
    for y in response[x]:
        print (y,':',response[x][y])

Dans ce script, nous utilisons l’opération batch_write_item pour écrire des données dans la table « mutant_data ». Cela nous permet d’écrire plusieurs éléments en une seule opération. Ici, nous écrivons deux éléments à l’aide d’un PutRequest, qui est une requête pour effectuer l’opération PutItem sur un élément.

Notez que, contrairement à ScyllaDB (et Apache Cassandra d’ailleurs), dans DynamoDB, les écritures n’ont pas de niveau de cohérence configurable. Ils utilisent CL=QUORUM.

Exécutez le script pour écrire les deux éléments dans la table :

python write.py

[guy@localhost getting-started]$ python write.py
('Finished writing to table ', 'mutant_data')
[guy@localhost getting-started]$

Ensuite, nous lirons les données que nous venons d’écrire, toujours en utilisant une opération par lots, batch_get_item.

from __future__ import print_function
import boto3
dynamodb = boto3.resource('dynamodb',endpoint_url="http://172.17.0.2:8000",
                  region_name="None", aws_access_key_id='None', aws_secret_access_key='None')

response = dynamodb.batch_get_item(
    RequestItems={
        'mutant_data' : { 'Keys': [{ 'last_name': 'Loblaw' }, {'last_name': 'Jeffries'}] }
    }
)
for x in response:
    print (x)
    for y in response[x]:
        print (y,':',response[x][y])

La réponse est un dictionnaire dont le résultat est les deux entrées que nous avons écrites précédemment.

Exécutez la lecture pour voir les résultats :

[guy@localhost getting-started]$ python read.py
Responses
mutant_data : [{u'first_name': u'Bob', u'last_name': u'Loblaw', u'address': u'1313 Mockingbird Lane'}, {u'first_name': u'Jim', u'last_name': u'Jeffries', u'address': u'1211 Hollywood Lane'}]
ResponseMetadata
RetryAttempts : 0
HTTPStatusCode : 200
HTTPHeaders : {'date': '19 Apr 2020 17:30:23 GMT', 'content-length': '219', 'content-type': 'application/json', 'server': 'Seastar httpd'}
[guy@localhost getting-started]$

DynamoDB prend en charge deux niveaux de cohérence pour les lectures, « cohérence éventuelle » et « cohérence forte ». Vous pouvez en savoir plus sur les niveaux de cohérence de ScyllaDB ici et ici. Sous le capot, ScyllaDB implémente des lectures fortement cohérentes avec LOCAL_QUORUM, tandis que des lectures cohérentes à terme sont effectuées avec LOCAL_ONE.

Davantage de ressources

Conclusion

Dans cette leçon, nous avons appris les bases d’Alternator, l’API open source DynamoDB ScyllaDB. Nous avons vu comment créer un cluster, s’y connecter, écrire des données et lire des données.