During the Distributed SQL Summit I've explained how YugabyteDB writes the SQL transaction provisional records to the IntentsDB and then to the RegularDB. For the demo, I started, in a Docker container, a single-node YugabyteDB cluster with TEST_docdb_log_write_batches enabled to log the write operations:
docker run -it \
-p7000:7000 -p9000:9000 -p15433:15433 -p5433:5433 \
yugabytedb/yugabyte:latest bash
yugabyted start --ui=false --listen=0.0.0.0 \
--tserver_flags="\
TEST_docdb_log_write_batches=true,\
yb_enable_read_committed_isolation=true,\
tserver_enable_metrics_snapshotter=false\
"
tail -n 1000 -F /root/var/logs/tserver/yb-tserver.*log.INFO.* |\
grep -vE '(DEBUG: Closing|Time spent)' &
I tailed the logfile in the background and this is what you see during the demo:
Transaction Internals: Fast Path versus Multi-Shard - YouTube
While SQL transactions can be complex, especially in distributed systems, NoSQL databases tend to avoid them, and certain NewSQL databases may not ensure glo...
youtube.com
If you want to reproduce it, here are the commands I've run.
Lab: non-transactional on colocated
ysqlsh -h $(hostname)
create database franck with colocation=true;
\c franck
create table cities (name text primary key, country text)
;
insert into cities values ('Geneva','Switzerland')
;
Lab: delete is transactional
delete from cities
;
Lab: SQL transactions
begin transaction
;
insert into cities values ('Geneva','Switzerland')
;
insert into cities values ('Lausanne','Switzerland')
;
commit
;
Lab: secondary index
insert into cities values ('Geneva','Switzerland')
;
create index cities_country on cities(country)
;
insert into cities values ('Lausanne','Switzerland')
;
Lab: non transactional
set yb_disable_transactional_writes = on
;
insert into cities values ('Lausanne','Switzerland')
;
Reminder: this is not to be used in production. The parameters that start with TEST are used for regression tests. You can use it in a lab to understand how it works.
Top comments (0)