1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
Execution Profiles
==================
Execution profiles aim at making it easier to execute requests in different ways within
a single connected ``Session``. Execution profiles are being introduced to deal with the exploding number of
configuration options, especially as the database platform evolves more complex workloads.
The legacy configuration remains intact, but legacy and Execution Profile APIs
cannot be used simultaneously on the same client ``Cluster``. Legacy configuration
will be removed in the next major release (4.0).
An execution profile and its parameters should be unique across ``Cluster`` instances.
For example, an execution profile and its ``LoadBalancingPolicy`` should
not be applied to more than one ``Cluster`` instance.
This document explains how Execution Profiles relate to existing settings, and shows how to use the new profiles for
request execution.
Mapping Legacy Parameters to Profiles
-------------------------------------
Execution profiles can inherit from :class:`.cluster.ExecutionProfile`, and currently provide the following options,
previously input from the noted attributes:
- load_balancing_policy - :attr:`.Cluster.load_balancing_policy`
- request_timeout - :attr:`.Session.default_timeout`, optional :meth:`.Session.execute` parameter
- retry_policy - :attr:`.Cluster.default_retry_policy`, optional :attr:`.Statement.retry_policy` attribute
- consistency_level - :attr:`.Session.default_consistency_level`, optional :attr:`.Statement.consistency_level` attribute
- serial_consistency_level - :attr:`.Session.default_serial_consistency_level`, optional :attr:`.Statement.serial_consistency_level` attribute
- row_factory - :attr:`.Session.row_factory` attribute
When using the new API, these parameters can be defined by instances of :class:`.cluster.ExecutionProfile`.
Using Execution Profiles
------------------------
Default
~~~~~~~
.. code:: python
from cassandra.cluster import Cluster
cluster = Cluster()
session = cluster.connect()
local_query = 'SELECT rpc_address FROM system.local'
for _ in cluster.metadata.all_hosts():
print(session.execute(local_query)[0])
.. parsed-literal::
Row(rpc_address='127.0.0.2')
Row(rpc_address='127.0.0.1')
The default execution profile is built from Cluster parameters and default Session attributes. This profile matches existing default
parameters.
Initializing cluster with profiles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. code:: python
from cassandra.cluster import ExecutionProfile
from cassandra.policies import WhiteListRoundRobinPolicy
node1_profile = ExecutionProfile(load_balancing_policy=WhiteListRoundRobinPolicy(['127.0.0.1']))
node2_profile = ExecutionProfile(load_balancing_policy=WhiteListRoundRobinPolicy(['127.0.0.2']))
profiles = {'node1': node1_profile, 'node2': node2_profile}
session = Cluster(execution_profiles=profiles).connect()
for _ in cluster.metadata.all_hosts():
print(session.execute(local_query, execution_profile='node1')[0])
.. parsed-literal::
Row(rpc_address='127.0.0.1')
Row(rpc_address='127.0.0.1')
.. code:: python
for _ in cluster.metadata.all_hosts():
print(session.execute(local_query, execution_profile='node2')[0])
.. parsed-literal::
Row(rpc_address='127.0.0.2')
Row(rpc_address='127.0.0.2')
.. code:: python
for _ in cluster.metadata.all_hosts():
print(session.execute(local_query)[0])
.. parsed-literal::
Row(rpc_address='127.0.0.2')
Row(rpc_address='127.0.0.1')
Note that, even when custom profiles are injected, the default ``TokenAwarePolicy(DCAwareRoundRobinPolicy())`` is still
present. To override the default, specify a policy with the :data:`~.cluster.EXEC_PROFILE_DEFAULT` key.
.. code:: python
from cassandra.cluster import EXEC_PROFILE_DEFAULT
profile = ExecutionProfile(request_timeout=30)
cluster = Cluster(execution_profiles={EXEC_PROFILE_DEFAULT: profile})
Adding named profiles
~~~~~~~~~~~~~~~~~~~~~
New profiles can be added constructing from scratch, or deriving from default:
.. code:: python
locked_execution = ExecutionProfile(load_balancing_policy=WhiteListRoundRobinPolicy(['127.0.0.1']))
node1_profile = 'node1_whitelist'
cluster.add_execution_profile(node1_profile, locked_execution)
for _ in cluster.metadata.all_hosts():
print(session.execute(local_query, execution_profile=node1_profile)[0])
.. parsed-literal::
Row(rpc_address='127.0.0.1')
Row(rpc_address='127.0.0.1')
See :meth:`.Cluster.add_execution_profile` for details and optional parameters.
Passing a profile instance without mapping
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We also have the ability to pass profile instances to be used for execution, but not added to the mapping:
.. code:: python
from cassandra.query import tuple_factory
tmp = session.execution_profile_clone_update('node1', request_timeout=100, row_factory=tuple_factory)
print(session.execute(local_query, execution_profile=tmp)[0])
print(session.execute(local_query, execution_profile='node1')[0])
.. parsed-literal::
('127.0.0.1',)
Row(rpc_address='127.0.0.1')
The new profile is a shallow copy, so the ``tmp`` profile shares a load balancing policy with one managed by the cluster.
If reference objects are to be updated in the clone, one would typically set those attributes to a new instance.
|
