Transactions Properties in YCQL

General
1

Hi,

I have a few questions in regard to transaction properties in YCQL.

(1) How do you know if transactions is “enabled = true” because when I do a describe on the table, it does not reflect it.

(2) What is the best practice for transactions “enabled = true” since this properties can’t be alter after table creation?

  • Meaning, can’t create a secondary index if it is false

(3) Would that be any performance impact if we always create table with “WITH transactions = { ‘enabled’ : true }”

NOTE: I’m using CQLSH (Cassandra’s native CLI), not sure if that will cause any indifferenct.

Regards,
Tommy

2

With the query below:

ycqlsh> select * from system_schema.tables where keyspace_name='ybdemo';

 keyspace_name | table_name | bloom_filter_fp_chance | caching | cdc  | comment | compaction | compression | crc_check_chance | dclocal_read_repair_chance | default_time_to_live | extensions | flags        | gc_grace_seconds | id                                   | max_index_interval | memtable_flush_period_in_ms | min_index_interval | read_repair_chance | speculative_retry | transactions        | tablets
---------------+------------+------------------------+---------+------+---------+------------+-------------+------------------+----------------------------+----------------------+------------+--------------+------------------+--------------------------------------+--------------------+-----------------------------+--------------------+--------------------+-------------------+---------------------+---------
        ybdemo |        emp |                   null |    null | null |    null |       null |        null |             null |                       null |                    0 |       null | {'compound'} |             null | 13563f8c-997e-a298-de46-0c05025e00a7 |               null |                        null |               null |               null |              null | {'enabled': 'true'} |    null

If you think you might need indexes in the future.

Transactions help with multi-shard queries. Single-shard queries are always transactional. The difference would be in multi-shard queries (they will become transactional). You also won’t be able to use user enforced secondary indexes [docs] document YCQL CREATE INDEX WITH transactions · Issue #6082 · yugabyte/yugabyte-db · GitHub

Not in performance but it will miss some features like JSOB columns etc.