►
From YouTube: Serving Trillion-Record Table on TiKV - Yi Wu, PingCAP
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Serving Trillion-Record Table on TiKV - Yi Wu, PingCAP
TiKV is a distributed, transactional key-value database that is based on the design of Google Spanner and HBase. It excels in horizontal scalability and can easily scale to 100+ terabytes of data.<br <br In this talk, Yi Wu will take a deep dive into the architecture of TiKV and the recent development of the TiKV project. Additionally, they will introduce the new Titan storage engine and multithreaded raft store introduced in TiKV 3.0 in-depth and detail how the new features helped TiDB serve 1.6 trillion rows and more than 200 terabytes of data within a single cluster.
https://sched.co/bRVh
A
A
But
it
is
simpler
to
manage
and
it
does
not
depend
on
the
any
distributed
file
system.
The
project
is
right
now
a
cnc
cf
incubating
project
and
we
are
trying
to
move
this
attackery
to
graduation
stage
this
year.
Takeaway
has
over
thousand
github
stars,
and
it's
right
now
have
around
250
contributors.
A
This
is
a
picture
showing
the
overall
architecture
of
thai
kv
in
the
front
end
tyqui
provides
a
simple
transactional
kv
api.
It
also
exposes
the
co-processor
api,
which
handles
push-down
aggregation
requests
from
time
db.
It
has
a
transaction
layer
which
handles
distributed,
transaction
and
multi-version
concurrency
control.
A
A
The
full
key
range
is
split
into
small
areas
and
each
of
this
area.
It
we
call
it
a
region,
and
the
region
is
the
yield
need
for
a
rough
replication
in
taipei,
and
by
default
each
region
will
have
three
replicas
and
those
replicas
will
be
scattered
around
in
different
types
of
windows
and
when
the
world
changes,
some
of
the
regions
can
get
more
traffic
than
the
other
region,
and
some
regions
can
grow
oversized
and
taike
will
rely
on
another
component
to
do
load
balance,
which
is
the
placement
driver
or
pd.
A
In
this
use
case,
as
you
can
see,
the
the
data
size
is
really
huge
is
currently
having
a
500
tech
by
data
and
the
insights
is
still
growing
and
the
cluster
has
over
200
type
nodes
about
the
use
case.
The
reading
history
of
the
users
is
used
to
filter
the
recommendations,
so
a
user
won't
see
an
article
that
he
already
reappeared
in
the
recommendation
list
and
also
the
the
data
is
used
to
change
models
to
personalize
the
recommendation
to
the
users.
A
This
is
the
overall
architecture
for
the
use
case.
At
the
very
front
end,
the
cherry
has
a
proxy
layer,
and
then
there
is
the
reddish
cache
layer
that
handles
the
large
volume
of
reach
effect.
The
cache
is
the
right
root
cache.
The
right
will
hit
the
underlying
database,
which
is
tidbit
and
tidbit
used
high
kv,
as
the
underlying
storage
layer
and
the
cache
layer
also
subscribe
to
tidbit
changes.
A
They
see
nearly
no
impact
to
the
overall
healthiness
of
the
use
case
due
to
the
high
availability
provided
by
hiv
and
also
as
the
the
the
data
size
growth
who
also
moved
to
use
the
cross
cloud
provider
deployment
and
during
this
transition
tachyv
is
being
very
stable
for
them.
So
they
are
currently
very
happy
with
target
v
in
in
in
the
reading
history
use
case,
but,
as
they
add
more
use
case
to
their
system,
they
want
to
expand
the
feature
set.
A
So
they
are
building
a
next
generation
infrastructure
for
the
same
use
case
this.
This
new
infrastructure
is
called
a
data
table
store
this.
The
data
table
store
is
still
based
on
high
qv
and
from
the
tiger
dashboard
of
this
cluster,
and
you
can
see
the
data
size
is
right
now
at
around
70
megabytes,
and
it
consists
of
around
100
tech
windows
and
the
data
side.
A
It
provides
a
negative
y
column
data
model
and
the
data
in
it
can
be
can
have
schema
or
be
schema
free
and,
most
importantly,
the
data
level
store
is
still
based
on
high
quality,
so
who
can
still
enjoy
the
availability
and
scalability
provided
by
thai
dairy
and
also
they
make
use
of
some
of
the
typical
features.
For
example,
the
transaction
and
secondary
index
support
are
all
based
on
high-grade
transactions.
A
Now
this
is
the
overall
architecture
of
the
data
table
store.
We
won't
go
into
detail
here,
but,
as
you
can
see,
technique
is
still
being
used
as
the
storage
layer
and
most
of
the
other
nodes
are
statics,
and
this
is
a
demonstration
of
the
y
column
data
model
provided
by
table
store
and
as
juju
switched,
their
traffic
from
the
existing
reading
history.
A
Let's
talk
about
a
transaction
in
a
in
tactical
which
a
transaction
is
proved
to
be
very
useful
for
the
for
the
service
use
case.
It
simplify
the
the
application
logic.
They
don't
need
to
re-implement
transaction
in
their
application
layer
so
to
have
transaction,
because
data
in
thai
tv
are
split
into
small
regions
and
those
rough
leaders
for
each
of
the
regions
can
be
on
different
types
of
nodes.
So
to
run
a
transaction,
we
need
to
do
a
distributed
transaction
over
multiple
rough
groups,
and
this
is
done
entirely
using
the
percolator
model.
A
This
is
an
example
of
the
percolator
model.
It
is
basically
a
two
phase
coming
protocol
and
in
this
model,
all
the
data
are
split
into
three
columns:
the
data
column,
the
log
column
and
the
right
column,
and
in
titley
we
use
logsdb's
column
family
to
implement
those
columns,
and
in
this
example,
we
have
a
transaction
writing
to
two
keys,
a
and
b
and
for
each
transaction.
A
A
It
turns
out
that
it
only
required
require
a
very
simple
change
so
for
pessimistic
transaction
and-
and
we
have
an
extra
locking
phrase
and
during
the
locking
phrase
we'll
place
the
lock
to
all
the
keys
in
this
transaction
and
the
log
will
have
a
special
flag,
which
you
know
that,
which
signifies
that
this
law
is
a
personistic
lock
and
in
the
pre-phrase
the
personistic
block
is
turned
into
a
optimistic
law.
The
the
log
format
it
is
the
same
as
in
optimistic
transactions,
so
that
and
the
rest.
A
The
the
flow
for
for
for
prewrite
and
commit
phrase
are
the
are
the
same
as
a
optimistic
transaction.
In
this
way
of
pessimistic
transaction
and
ultimately,
automatic
transaction
entity
are
compatible
with
each
each
other.
So
you
can
have
two
clients
connected
to
the
same
targary
cluster
and
one
client
doing
a
passive,
pessimistic
transaction
and
one
client
doing
automatic
transaction,
and
it's
perfectly
perfectly
fine
for
personal
transaction.
We
also
implement
a
deadlock
detection
so
for
deadlock
detection
we
will
in
a
tight
kv
cluster.
A
A
So
that's
it
for
our
transaction,
and
another
thing
I
want
to
talk
about
is
follow
already
that
we
recently
add
to
thai
followery
is
an
optimization
in
the
rock
protocol
to
reduce
a
re-latency
and
to
understand
what
it
is.
We
need
some
basic
background
knowledge
for
the
rough
product
loss
is
a
consensus
algorithm
and
a
consensus
algorithm
basically
have
two
goals.
The
first
one
is
to
ensure
an
agreement
on
just
stay
among
all
the
nodes
in
a
classroom
in
for
thai
tv,
the
shear
state
is
the
state
of
the
data
source
in
target.
A
Another
goal
of
a
consensus
algorithm
is
to
recover
the
cluster
from
slower
failures,
autonomously,
so
rough.
The
rough
algorithm
achieve
these
two
goals
by
doing
a
lot
replication
and
I'm
going
to
use
techyv
as
an
example
to
explain
how
replication
works.
So
when
the
client
wants
to
write
a
piece
of
data,
they
will
send
a
request
to
the
corresponding
rough
group
leader.
The
leader
will
translate
the
request
into
a
log
end
sheet
and
then
start
the
dot
replication.
A
The
the
log
replication
consists
of
two
steps.
The
first
step
is
the
coming
log
in
this
step.
The
leader
will
append
the
log
entry
to
its
local
log
and,
at
the
same
time,
it
will
broadcast
the
message
to
replicate
the
law
entry
to
all
its
followers
and
once
it
make
sure
that
the
log
energy
it
has
been
replicated
to
a
majority
of
the
replicas,
it
proceeds
to
the
next
step,
which
is
apply
log.
The
content
of
the
log
n
sheet
will
be
applied
to
the
local
state
machine
on
the
leader
for
thai
kv.
A
A
So
when
a
client
wants
to
read
a
piece
of
data,
it
sends
a
request
to
one
of
the
nodes
in
in
the
rough
group
and
in
case,
if
it
hits
a
follower
in
the
rough
group,
the
follower
will
need
to
send
a
read
index
request
to
the
leader.
The
leader
will
then
look
at
is
committed
in
committed
index,
which
is
the
latest,
which
is
the
index
of
the
latest
log
entry
that
that
has
been
that
that
has
been
committed.
A
So
this
is
a
demonstration
of
their
plan
use
case,
they
plan
to
add
a
data
warehouse
in
their
system,
but
this
data
warehouse
is
in
a
different
data
center
and
what
they
plan
to
do.
Instead
of
building
a
etl
pipeline
to
stream
the
data
from
a
thai
kv
cluster
to
the
data
warehouse,
what
they
plan
to
do
is
to
have
the
data
warehouse
participate
in
the
rough
replication
of
the
type
cluster
and
then
for
reads
on
the
data
warehouse
they
will
use
the
following.
A
There
are
some
benefits
for
this
setup.
One
of
them
is,
of
course,
the
oil
ap
workloads
will
will
now
hit
the
data
warehouse
where,
where
the
query
can
be
better
handled
and
also
by
using
follow
read
across
data
center,
traffic
can
be
reduced
and
also
since
the
data
warehouse
participates
in
the
rough
replication,
you
can
play
the
role
of
of
one
replica
in
the
system,
and
so
so
for
zhukou.
A
They
can
reduce
one
replica
in
the
thai
kv
cluster
in
their
main
data
center
to
reduce
cost,
and
this
usage
is
very
creative
and
we
are
looking
forward
to
see
how
it
goes
in
in
the
future
development.
And
that's
it.
That's
it
for
my
presentation
and
if
you
want
to
know
more
about
heckely
here
are
a
few
more
links
and
we
will
always
be
available
on
taiqui's
leg
channel.
For
any
questions,
thank
you.
A
A
A
A
A
So
the
next
question
is
when
running
in
multiple
data
centers,
how
are
transactions
dealt
with
so
right
now?
So
I
think
this
question
is
mostly
for
type
type
type
kv
and
idb,
and
so
I
think
so
so
right
now
we
don't
have
a
special
handling
for
for
vendetta
data
in
multiple
data
centers.
So
we
still
use
the
same
calculator
model
for
for
running
the
transaction,
so
yeah.
So
so
so
they
still
need
to
go.
Go
over
the
data
centers
we
still
incur
across
data
and
center
traffic
for.