search

hippware / cqerl

Native Erlang CQL client for Cassandra
http://matehat.github.io/cqerl
MIT License
0 stars 0 forks source link

readme

CQErl

Native Erlang client for CQL3 over Cassandra's latest binary protocol v4.

Usage · Connecting · Clusters · Performing queries · Query options · Batched queries · Reusable queries · Data types · Token aware policy

Installation · Compatibility · Tests · License

At a glance

CQErl offers a simple Erlang interface to Cassandra using the latest CQL version. The main features include:

CQErl was designed to be as simple as possible on your side. You just provide the configuration you want as environment variables. Under the hood, CQErl maintains a pool of persistent connections with Cassandra and select the client to use based on a hash of the requsting PID (and, optionally, the connected node if Token Aware Policy is enabled - see below). This ensures relatively even distribution of work amongst clients when there is a lot of concurrent activity (where distribution is most important).

Usage

Connecting

If you installed Cassandra and didn't change any configuration related to authentication or SSL, you should be able to connect like this

cqerl:add_group(["localhost"], [], 1).

Using environment variables

Groups of clients may be configured though the application config, for example:

  {cqerl, [
        {client_groups, [
            {client_group, [
                {name, cluster1},
                {hosts, ["10.1.1.107", "10.1.1.108", {"10.1.1.109", 6666}]},
                {opts, [{keyspace, user_db}, {ssl, true}]},
                {clients_per_server, 10}
             ]},
            {client_group, [
                {name, config_cluster},
                {hosts, ["10.1.1.107", "10.1.1.108", {"10.1.1.109", 6666}]},
                {opts, [{keyspace, config_db}]},
                {clients_per_server, 2}
             ]}
        ]}
  ]}

Doing so will fire up connection pools as soon as the CQErl application is started. Once cqerl has started, clients should be available immediately.

The name and opts fields are optional; hosts and clients_per_server must be included.

Application level options

There are several application environment variables that may be set to change query behaviour:

Performing queries

Performing a query can be as simple as this:

{ok, Result} = cqerl:run_query(my_keyspace, "SELECT * FROM users;").

% Equivalent to
{ok, Result} = cqerl:run_query(my_keyspace, <<"SELECT * FROM users;">>).

% Also equivalent to
{ok, Result} = cqerl:run_query(#cql_query{statement = <<"SELECT * FROM users;">>, keyspace = my_keyspace}).

It can also be performed asynchronously using

Tag = cqerl:send_query(my_keyspace, "SELECT * FROM users;"),
receive
    {cqerl_result, Tag, Result} ->
        ok
end.

Here's a rundown of the possible return values:

#cql_result{}

The return value of SELECT queries will be a #cql_result{} record, which can be used to obtain rows as proplists and fetch more result if available

{ok, _SchemaChange} = cqerl:run_query(test_keyspace, "CREATE TABLE users(id uuid, name varchar, password varchar)"),
{ok, void} = cqerl:run_query(Client, #cql_query{
    statement = "INSERT INTO users(id, name, password) VALUES(?, ?, ?);",
    values = #{
        id => new,
        name => "matt",
        password => "qwerty"
    },
    keyspace = test_keyspace
}),
{ok, Result} = cqerl:run_query(test_keyspace, "SELECT * FROM users;").

Row = cqerl:head(Result),
Tail = cqerl:tail(Result),
{Row, Tail} = cqerl:next(Result),
1 = cqerl:size(Result),
0 = cqerl:size(Tail),
empty_dataset = cqerl:next(Tail),
[Row] = cqerl:all_rows(Result),

#{name := <<"matt">>, password := <<"qwerty">>} = Row.

#cql_result{} can also be used to fetch more results, synchronously or asynchronously:


case cqerl:has_more_pages(Result) of
    true -> {ok, Result2} = cqerl:fetch_more(Result);
    false -> ok
end,

Tag2 = cqerl:fetch_more_async(Result),
receive
    {result, Tag2, Result2} -> ok
end.
#cql_schema_changed{}

#cql_schema_changed{} is returned from queries that change the database schema somehow (e.g. ALTER, DROP, CREATE, and so on). It includes:

  1. The type of change, either created, updated or dropped
  2. The name of the keyspace where the change happened, as a binary
  3. If applicable, the name of table on which the change was applied, as a binary
Providing options to queries

When performing queries, you can provide more information than just the query statement using the #cql_query{} record, which includes the following fields:

  1. The query statement, as a string or binary

  2. values for binding variables from the query statement (see next section).

  3. You can tell CQErl to consider a query reusable or not (see below for what that means). By default, it will detect binding variables and consider it reusable if it contains (named or not) any. Queries containing named binding variables will be considered reusable no matter what you set reusable to. If you explicitely set reusable to false on a query having positional variable bindings (?), you would provide values with in {Type, Value} pairs instead of {Key, Value}.

  4. You can specify how many rows you want in every result page using the page_size (integer) field. The devs at Cassandra recommend a value of 100 (which is the default).

  5. You can also specify what consistency you want the query to be executed under. Possible values include:

    • any
    • one
    • two
    • three
    • quorum
    • all
    • local_quorum
    • each_quorum
    • local_one

  6. In case you want to perform a lightweight transaction using INSERT or UPDATE, you can also specify the serial_consistency that will be use when performing it. Possible values are:

    • serial
    • local_serial
Variable bindings

In the #cql_query{} record, you can provide values as a map, where the keys match the column names or binding variable names in the statement, in lowercase.

Example:

% Deriving the value key from the column name
#cql_query{statement = "SELECT * FROM table1 WHERE id = ?", values = #{id => SomeId}},

% Explicitly providing a binding variable name
#cql_query{statement = "SELECT * FROM table1 WHERE id = :id_value", values = #{id_value => SomeId}},

Special cases include:

Also, when providing the value for a uuid-type column, you can give the value new, strong or weak, in which case CQErl will generate a random UUID (v4), with either a strong or weak number random generator.

Finally, when providing the value for a timeuuid or timestamp column, you can give the value now, in which case CQErl will generate a normal timestamp, or a UUID (v1) matching the current date and time.

Batched queries

To perform batched queries (which can include any non-SELECT DML statements), simply put one or more #cql_query{} records in a #cql_query_batch{} record, and run it in place of a normal #cql_query{}. #cql_query_batch{} include the following fields:

  1. The consistency level to apply when executing the batch of queries.
  2. The mode of the batch, which can be logged, unlogged or counter. Running a batch in unlogged mode removes the performance penalty of enforcing atomicity. The counter mode should be used to perform batched mutation of counter values.
  3. Finally, you must specify the list of queries.
InsertQ = #cql_query{statement = "INSERT INTO users(id, name, password) VALUES(?, ?, ?);"},
{ok, void} = cqerl:run_query(Client, #cql_query_batch{
  mode=unlogged,
  queries=[
    InsertQ#cql_query{values = #{id => new, name => "sean", password => "12312"}},
    InsertQ#cql_query{values = #{id => new, name => "jenna", password => "11111"}},
    InsertQ#cql_query{values = #{id => new, name => "kate", password => "foobar"}}
  ]
}).
Reusable queries

If any of the following is true:

the query is considered reusable. This means that the first time this query will be performed, CQErl will ask the connected Cassandra node to prepare the query, after which, internally, a query ID will be used instead of the query statement when executing it. That particular cassandra node will hold on to the prepared query on its side and subsequent queries that use exactly the same statement will be performed faster and with less network traffic.

CQErl can tell which query has been previously prepared on which node by keeping a local cache, so this happens transparently. Note that prepared queries are stored per-connection, so each client process will need to prepare its own copy of any given query (though this also occurs transparently).

Data types

Here is a correspondance of cassandra column types with their equivalent Erlang types (bold denotes what will used in result sets, the rest is what is accepted).

Cassandra Column Type Erlang types
ascii binary, string (only US-ASCII)
bigint integer (signed 64-bit)
blob binary
boolean true, false
counter integer (signed 64-bit)
decimal {Unscaled :: integer(), Scale :: integer()}
double float (signed 64-bit)
float float (signed 32-bit)
int integer (signed 32-bit)
timestamp integer (milliseconds, signed 64-bit), now, binary or string
uuid binary, new
varchar binary, string
varint integer (arbitrary precision)
timeuuid binary, now
inet {X1, X2, X3, X4} (IPv4), {Y1, Y2, Y3, Y4, Y5, Y6, Y7, Y8} (IPv6), string or binary

Connecting to older Cassandra instances

By default, this client library assumes we're talking to a 2.2+ or 3+ instance of Cassandra. 2.1.x the latest native protocol (v4) which is required to use some of the newest datatypes and optimizations. To tell CQErl to use the older protocol version (v3), which is required to connect to a 2.1.x instance of Cassandra, you can set the protocol_version option to the integer 3, in your configuration file, i.e.

[
  {cqerl, [
            {cassandra_nodes, [ { "127.0.0.1", 9042 } ]},
            {protocol_version, 3}
          ]},
]

or in a cqerl:add_group/3 call:

G = cqerl:add_group(["127.0.0.1:9042"], [{protocol_version, 3}, {keyspace, oper}], 1).

Installation

Just include this repository in your project's rebar.config file and run ./rebar get-deps. See rebar for more details on how to use rebar for Erlang project management.

Compatibility

As noted earlier, this library uses Cassandra's newest native protocol versions (v4, or v3 optionally), which is said to perform better than the older Thrift-based interface. It also speaks CQL version 3, and uses new features available in Cassandra 2.X, such as paging, parametrization, query preparation and so on.

All this means is that this library works with Cassandra 2.1.x (2.2+ or 3+ recommended), configured to enable the native protocol. This documentation page gives details about the how to configure this protocol. In the cassandra.yaml configuration file of your Cassandra installation, the start_native_transport need to be set to true and you need to take note of the value for native_transport_port, which is the port used by this library.

Token Aware Policy

This library implementes Token Aware Policy (TAP) for improved query efficincy. TAP allows the client to calculate which node(s) hold the data being read/written and use a direct connection to that node when available. By contrast, without TAP a node will be randomly chosen from all available and, if that node does not contain the data, it will forward on the query to the appropriate node, increasing load, network traffic and latency. If, for any reason, the TAP algorithm cannot determine or access the appropriate node, it will automatically fall back to non-TAP operation for that query.

The current TAP implementation has the following limitations:

cqerl:run_query(#cqerl_query{statement = "SELECT * FROM user WHERE id = ?",
                             values = #{id => 'user1'},
                             keyspace = user_db})

However this will not:

cqerl:run_query(user_db, "SELECT * FROM user WHERE id = 'user1')
cqerl:run_query(#cqerl_query{statement = "SELECT * FROM user_db.user WHERE id = ?",
                             values = #{id => 'user1'})

Named Groups

As an alternative to client groups that are selected based on keyspace, groups may also be assigned a name. This is done either by using cqerl:add_group/4 or by including the name attribute in the client_group configuration item.

Named groups are never automatically used by - instead

Changes from cqerl

This rework contains a number of compatability-breaking changes from the original cqerl. Specifically:

Tests

CQErl includes a test suite that you can run yourself, especially if you plan to contribute to this project.

  1. Clone this repo on your machine
  2. Edit test/test.config and put your own cassandra's configurations
  3. At the project's top directory, run make test

License

The MIT License (MIT)

Copyright (c) 2013 Mathieu D'Amours

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.