►
From YouTube: 2021-03-10 Database Scalability Working Group Weekly
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
I
hope
you
can't
hear
the
noise
that's
going
on.
There's
some
construction
works
in
my
apartment,
not.
B
A
A
Let's
give
it
one
more
minute,
I
think
eric
accepted.
C
A
Hello
good
morning,
hello,
janice,
let's
just
give
it
a
one
more
minute
for
eric.
A
So
well,
we
have
a
fully
packed
agenda
today,
so
I
might
not
just
get
the
end
kicked
off
and
while
waiting
for
eric
so
good
morning,
good
afternoon
good
evening,
everyone
today
is
2021
march
10th.
This
is
the
kickoff
meeting
of
the
database
scalability
working
group
first
item
jerry.
Would
you
mind
giving
us
a
quick
introduction
of
what
this
working
group
is
and
what
the
focus
will
be?
This
working
group
working
on.
D
More
than
hayek
and
what
I've
read
on
emr,
if
there
are
any
questions
or
comments
about
the
stuff,
that's
in
there,
I
still
have
to
flesh
out
the
shard
in
section,
but
I
will
try
to
finish
that
this
week,
then
I'm
all
yours,
but
I
think
it's
it's
worthwhile
trying
to
set
up
a
sort
of
a
target-
and
I
think,
looking
at
and
thinking
about
the
database
at
10x
current
size
is
probably
a
worthwhile,
a
reasonable
target
to
think
about.
So
that
puts
our
database
around.
D
I
don't
know
between
70
and
100
terabytes
give
or
take
depending
on
what's
in
there
or
not,
I
think
we're
approaching
hardware
limits.
We
won't
be
able
to
scale
much
farther
to
where
we
are
today
with
the
postgres
12
migration,
we'll
be
at
the
next
to
last
largest
hardware
platform
that
we
can
get
today
in
terms
of
virtual
cpus,
with
a
little
bit
less
memory
than
what
we
have
today.
We're
gonna
benchmark
that
and
all
that
beyond
that,
there's
only
one
other
hop.
So
we
expect
some
gains
from
post
wars
12.
D
We
expect
some
gains
from
additional
compute
capacity,
but
this
is
definitely
a
problem
that
we
need
to
start
solving.
I
know:
we've
we've
had
other
working
groups.
Thinking
about
this,
I
wanted
to
propose
a
an
approach.
That's
a
structural
on
several
potential
solutions.
There
isn't
one
single
solution
to
do
this:
you'll
notice
that
I've
avoided
calling
this
the
shouting
working
group
shouting
is
one
of
many
different
solutions
and
many
different
things
that
we
can
do.
A
Thank
you
jerry
any
questions
about
the
goal
of
this
working
group.
I
hope
everyone
got
the
chance
to
read
the
handbook
page
before
this.
A
Meeting:
okay:
let's
move
on
to
the
next
item;
actually
it's
not!
It's
just
extract
from
the
handbook
page
about
the
pla
for
this
group
initial
plan.
Everybody
can
read
through
that's
the
guideline
so
far
we
can
jerry
actually
articulated
how
we
execute
this
working
group.
Any
questions.
D
Okay,
what
I
wrote
there
is
based
on
on
how
I've
done
this
in
the
past,
so
it's
purely
based
on
what
I've
seen
other
engineers
do
in
solving
these
types
of
problems
around
this,
this
type
of
scale.
So
you
know,
but
I'm
open
to
certainly
other
other
approaches
to
tackling
this.
B
When
I
first
read
about
those
patterns,
I
thought
they
are
they're
great.
Those
are
good
patterns
for
sure
what
I
was
sort
of
concerned
about
is
that
I
think
we
really
need
to
find
specific
problems
and
then
try
to
solve
them
using
those
patterns
right
so
make.
B
I
would
love
to
make
this
really
a
specific
approach
using
specific
examples
and
then
sketching
those
those
solutions
or
those
patterns.
For
that
that's
that's.
My
only
thought
that
I
have
seen
those
patterns.
D
I
think
I
wanted
to
defer
that
to
this
working
group,
meaning
I
laid
the
sort
of
the
path
of
where
I
think
we
should
go
and
how
we
should
go,
and
I
and
discussions
with
various
people,
so
my
own
experience
in
terms
of
things
that
we've
experienced
here
try
to
to
pick
some
examples
of
either
work
that
it's
already
ongoing,
like
ci,
builds
or
other
things
that
we've
seen
in
recent
times
again.
This
is,
there
is
really
no
manual
for
this
problem.
D
Lots
of
people
are
solving
this
problem
and
everybody's
doing
it
their
own
way,
but
in
general,
these
are
the
patterns
that
either
from
experience
or
talking
to
folks
that
have
crossed
this
bridge
that
I
tried
to
sort
of
summarize
and
the
reason
why
I
did
that
is.
I
wanted
us
to
have
several
options
of
things
that
people
have
been
doing
to
solve
this
and
I
think
we're
starting
to
approach
a
place
where
there
isn't
one
solution.
D
That's
going
to
help
this
right,
we're
starting
to
dive
into
something
where
the
sea
of
data
that
we're
managing
is
so
big
that
we're
going
to
have
to
pick
in
two,
so
I
think
you're
totally
right
and
that
we
should
have
very
concrete
things
that
we're
going
to
be
working
on.
But
I
did
want
to
refer
to
the
working
group
because
you're
way
closer
than
I
am
to
the
actual
plans
that
we're
seeing
if
there
is
another
pattern
that
we
should
add
or
there's
a
pattern
that
we
should
remove.
D
And
we
have
examples
to
do
that
more
than
happy
to
create
another,
mr
to
readjust
things
but
again,
you're
the
expert
you're
closer
to
you're
much
closer
to
the
data
than
I
am.
I'm
just
sort
of
nudging
things
along.
So
yes
open
to
to
having
concrete
examples.
D
A
Yeah
sorry
taking
notes,
so
the
next
item
will
be
just
some
logistics
for
this
working
group.
The
first
question
is
a
dri,
of
course,
for
working
groups.
Usually
we
have
one
single
dri,
but
given
the
scale
of
this
working
group,
I'm
also
proposing
pausing
the
idea
here.
Do
we
actually
want
to
one
dri
per
work
stream.
E
I
think
it
does
so.
The
way
I
was
thinking
this
would
move
forward
is,
is
jerry
is
kind
of
the
overall
vri
to
make
sure
we're
making
progress
on
this
and
feel
free
to
push
back.
It
feels
like
I'm
volunteering
here
jerry,
but
then
the
the
broken
down
work
streams.
We
do
have
a
single
dri
like
the
data
application
layer.
E
We
talked
about
the
memory
group
owning
that
and
logically,
it
kind
of
makes
sense
that
camille
would
be
the
dro
on
that
one,
because
we
do
have
the
composable
codebase
blueprint
already,
which
aligns
closely
with
that
and
logically,
it
makes
sense
for
the
database
team
to
own
some
of
the
database
work,
that's
going
to
be
outlined
there
and
we
have
andreas.
Who
would
be
the
good
dri
for
that.
So
so
I
agree
with
that
pattern.
But
if
there's
a
different
proposal
that
makes
more
sense
I'd
be
on
board
with
that
as
well.
D
Way
of
doing
it,
we
can
readjust
later,
if
we,
if
we
find
like
initially,
I
think
some
boundaries
are
going
to
be
super
clear
and
then
some
other
boundaries
are
not
like.
The
data
access
layer
is
going
to
be
kind
of
a
loose
boundary.
I
think
it's
totally.
It
makes
total
sense
that
the
memory
team
would
be
sort
of
working
on
that,
but
yeah,
I'm
all
for
that.
A
Thank
you.
So
we
will
pursue
the
one
work,
what
dri
per
work
stream,
so
that
will
be
three
patterns.
That's
the
3d
rise,
then
the
data
access
layer
for
that
looks
like
the
memory
team
already
volunteered,
either
craig
or
camille
being
a
dri
for
the
data
access
layer.
Then
we
can
once
we
identify
the
work
streams,
we
will
find
volunteers
or
the
dris
for
those
work
streams
sounds
good,
okay,
cool.
So
next
question
is
probably
too
early
to
ask
for
volunteers
at
this
time.
A
Let's
just
identify
try
to
identify
the
work
streams
for
the
patterns
as
a
next
step
meeting
time.
This
weekly
meeting,
I'm
looking
at
the
age
30
8
30
a.m,
will
be
7
30
a.m.
Pacific
time
after
we
switch
to
daylight
savings
time
that.
C
A
A
They
are
king
of
this
topic,
so
I
hope
others
will
be
more
flexible.
How
about
this
time
or
jerry
or
eric?
Do
you
have
a
suggestion
of
another
alternative
slot.
G
Morning
my
time
makes
sense,
there's
a
there's
a
lot
of
folks
in
europe
and
a
lot
of
folks
on
the
west
coast
of
the
us.
So
mooring
generally
works.
I
think
once
once
we
get
going,
I
don't
necessarily
have
to
be
here
every
single
meeting.
That
would
be
the
ideal,
but
I'm
I'm
obviously
happy
to
be
here
every
time.
So
if
I'm
the
only
blocker,
then
we
can
schedule
around
that
I
have
at
eba,
so
we
can
ask
christy
to
find
the
best
time
if
that's
helpful,.
A
Thank
you,
okay,
so
I
will
propose
the
ngs.
You
have
a
database
office
hour.
Is
it
possible
to
shift
it
around.
B
Yes,
we
can
look
into
that.
This
is
something
that
the
database
group
facilitates.
So
it
would
be
nice
to
sort
of
separate
that
so
that
we
can
also
join
the
working
group.
A
So,
let's
I'll
do
this,
I
will
propose
this
time
to
christy
so
so
that
she
can
probably
coordinate
that
with
eric's
schedule.
Hopefully,
this
time
slot
works,
if
not
we'll,
let
christine
pick
a
time
slot
that
works
for
gary
and
eric.
Then
we
can
adjust
our
schedule
so
for
now
don't
make
any
change
to
the
office
hour.
D
Okay,
yeah
and
I
definitely
don't
mind
new
things.
So
if
that's
the
only
thing
we
find
now,
I
realize
other
folks.
Andreas
is
here
in
europe
as
well
as
camille.
I
think
some
others,
so
I'm
fairly
malleable,
but
that
doesn't
apply
to
everyone.
D
E
So
I
have
the
next
topic:
there
are
there
any
blockers?
We
need
to
call
it
beforehand.
The
obvious
one
that
comes
to
mind
is
the
primary
key
migration
right,
because
I
know
ci
builds
was
a
topic,
that's
brought
up
down
below
and
we
can't
really
do
any
effect.
E
Any
change
on
the
ci
builds
table
until
we
migrate
primary
key,
but
I
guess
the
question
would
be
and
we
can
do
it
asynchronously,
let's
call
out
any
blockers
beforehand,
because
that's
something
that
kind
of
did
us
on
previous
working
groups
that
I've
been
on
that
lockers
were
called
out
way
too
late.
D
So
what
are
I
know?
We've
been
talking
about
this
on
an
office,
it
relates
to
post
wars,
12
upgrade
and
all
that.
What
is
the
current
state
of
the
union
in
terms
of
the
primary
keys
issue,
because
I
know
the
clock
was
closer
than
we
thought
a
few
months
ago,
and
the
last
estimate
that
I
think
I
saw
from
gregor's
was
november
october.
F
Yes,
so
basically,
I
think
that
in
this
particular
case,
primary
keys
are
simply
more
urgent.
We
want
to
resolve
the
problem
before
the
end
of
december
or
the
sooner
the
better.
We
can
work
on.
Partitioning
sierra
builds
in
parallel,
but
it's
a
matter
of
capacity
and
urgency.
B
So
basically,
the
the
blocker
or
you
know
the
problem
that
we
have
to
solve
is
being
able
to
run
data
migrations
more
reliably,
because
this
is
gonna
be
a
very
large
data
migration,
and
this
is
what
we're
currently
actively
working
on
once
we
have
that
we
should
be
able
to
get
this
going,
and
this
is
you
know
this
is
high
priority
for
us
right
now,
so
this
is
already
happening
in
that
sense.
B
D
B
It
can
be
sort
of
folded
into
the
same
like
when
you
do
partitioning.
At
the
same
time,
you
can
also
use
that
opportunity
to
change
the
data
type.
It
is
primarily
a
data
type
problem
that
we
can
solve
one
or
the
other
way.
D
Okay,
well,
I
know
I
know
you're
all
working
on
it,
I'll
I'll,
follow
I'll.
D
Yeah,
the
only
reason
why
I'm
asking
is:
I'm
I'm
usually
wary
of
doing
too
many
things
at
once,
and
I
I
think
I
would
like
to
understand
some
of
the
trade-offs
between
oh
we're,
gonna
flip,
the
type
which
involves
all
these
things
or
we're.
D
Gonna
do
partitioning,
which
and
both
of
these
things
and
then
understanding
because
partitioning
in
in
some
respects
and
based
on
specifically
to
ci,
builds
like
the
thing
that
I
and
the
way
I
understand
ci
builds
is
it's
an
overcrowded
table
because
we
use
it
as
a
junk
drawer
for
a
ton
of
stuff.
It
has
the
pka
issue
for
sure,
and
so
trying
to
solve
those
with
a
single
sort
of
thing
sometimes
make
make
sense.
But
I'm
when
it
comes
to
data
on
the
database,
I'm
always
far
more
paranoid
than
usual.
D
Then
this
is
why
I'm
asking
that,
because
one
of
the
things
that
I
talk
about
in
the
in
the
in
the
working
group
description
is
there's
gonna
be
a
point
and
it's
not
too
far
away
in
the
future,
where
we
won't
be
talking
about
migrations
anymore,
it
just
won't
when
we
have
100
terabytes,
you
just
won't
get
time
for
it
to
do
any
sort
of
migration,
and
so
some
of
this
work
just
sort
of
ends
up
migrating
into
the
application
itself,
where
the
application
has
enough
awareness
to
be
shuffling
things
around.
D
That's
a
very
long-term
thing,
but
once
you
end
up
in
100,
terabyte
land
migrations
are
ridiculously
expensive
and
just
not
not
feasible
like.
If,
if
you
have
a
10
20
terabyte
table,
it
just
goes
out
the
door.
So
we're
not
going
to
solve
that
right
now,
obviously,
but
it
is
something
to
keep
in
the
rearview
mirror
or
in
the
radar
as
we're
looking
at
say,
ci
bills.
What
can
we
learn
to
you
know?
How
do
we
avoid
this
problem,
or
how
do
we
avoid
finding
ourselves
in
migration
land?
D
I
know
it's
a
different
problem
and
it's
a
very
simple
thing
compared
to
migrating
a
table
that
is
live
and
it's
doing
these
things,
but
I
love
the
approach
of
here's,
this
other
solution
and
we're
going
to
be
juggling
both
of
them
for
a
while,
and
we
know
it's
going
to
you
know
we
just
have
to
keep
track
of
them
for
a
while
until
things
are
where
we
want
them
to
land,
and
I
think
it's
a
it's
a
pattern
that
we
can
extend
to
a
number
of
of
problems.
Marion
was
mentioning
another.
E
D
C
C
Kind
of
thinking
about
like
very
drastic
approach,
but
this
working
group
seems
very
suited
for
drastic
approach.
Instead
of
fixing
civil,
stable
fixing
primary
kids
of
the
civ
stable,
can
we
just
create
a
new
builds
table
that
has
much
more
efficient
structure?
Doesn't
have
these
legacy
problems
and
kind
of
switch
over
to
this
table
and
keep
this
table
like
as
an
archive
or
legacy
thing.
E
Can
I
recommend
that
we
take
this
specific
topic
offline
and
we
start
talking
about
proposals
going
forward.
We
database
team
can
continue
in
parallel
with
primary
key
migration,
but
we
can
start
talking
about
the
drastic
proposal,
so
we
can
get
back
to
the
agenda
here
and
get
through
this
yeah
good
call.
Craic.
A
Let's
continue
that
in
the
slack
channel
basic
okay
move
on
nick
dr
yeah,
please
verbalize
your
question.
Sure.
E
Yeah
I
just
wanted
to
follow
up
on
the
dri
discussion.
It
seems
like
something
that
we
could
assign
a
dri
for
for
now
would
be
to
collect
the
example,
issues
that
andrea
suggested
and
add
those
to
the
handbook.
Page
and
that'll
probably
help
inform
the
potential
patterns
and
and
work
streams
that
we've
been
talking
about.
A
Thank
you,
jerry.
Moving
on
to
the
next
item.
We
have
last
five
minutes
remaining,
so
our
qr
deliverables
are
at
least
called
out
the
krs
there
from
development
and
infrastructure,
but
also,
I
think
we
are
going
to
deliver
the
blueprints
so
three
patterns,
that's
three
blueprints
and
one
blueprint
for
the
data
access
layer
and
also,
I
call
out
that
we
need
to
define
the
exit
criteria
for
the
first
iteration.
A
The
that's
just
that
we
that's
a
goal
for
qy.
Moving
on
to
the
next
item,
jerry
actually
already
shared
the
idea
here
so.
A
Yeah
is
this
going
to
be
a
work
pattern
that
we
can
just
perform
now
or
where
is
just
you
know,
one-off
see?
In
your
opinion,
jerry.
A
D
A
So
it
looks
like
we
have
a
one
pair
now
any
volunteers
for
dri.
D
F
Yeah
I'll
be
happy
to
work
on
that.
Just
one
thing
to
mention
is
that
the
verify
rapid
action
kind
of
you
know
is
consuming
my
focus
a
little
bit
so,
but
after.
C
A
A
B
We
don't
have
to
talk
about
this
now.
This
is
more
of
a
detailed
question.
I
think
it
comes
up
with
the
data
access
layer.
Let's
skip
that.
A
Cool
ask
my
question
and
eric
you
have
actually
criteria.
G
Yeah,
I
just
I
keep
thinking
we've
sort
of
tried
this
before
and
we
keep.
I
think
we
end
up
misapplying
our
iteration
value,
like
we're
really
good
at
doing
small
things,
and
so
we
end
up
in
this
local
minimum
of
we
relieve
the
immediate
pressure
we
respond
to
incidents
or
something
like
that.
G
We
haven't
been
successful,
cracking
this
problem,
so
I
I
I
don't-
have
any
prescription
but
there's
some
ideas
in
here
from
conversations
I
had
yesterday
my
skip
level
with
christopher
reports
and
then
with
sid
about
how
we
might
frame
this,
where
there's
no
way
to
satisfy
the
exit
criteria,
just
by
doing
the
short-term
stuff
or
even
the
midterm
stuff,
and
you
know
at
the
end
of
the
day,
this
needs
to
feel
more
like
the
gcp
migration
project,
then,
like
past
times,
we've
relieved
database
pressure.
This
should
be
a
big
deal.
G
I
don't
want
to
be
so
prescriptive,
I'm
saying
like
it's
starting,
and
this
is
the
shard
key
or
something
like
that.
I'm
trying
to
avoid
that,
but
I'm
trying
to
set
the
boundaries
so
that
we
don't
just
you
know
two
months
from
now
we're
wrapping
this
up.
Like
oh,
we
raised
capacity,
we
can
go
back
to
our
day,
job
sort
of
thing.
That's
happened
two
or
three
times
in
the
past
and
then
also
an
e.
We
have
a
really
unique
constraint
where
we
like
most
people
that
run
an
enterprise.
G
I
don't
want
to
be
too
prescriptive
to
say
this
thing
has
to
be
a
shim
that
goes
in
between
a
vanilla
database
and
our
application
code
as
it
stands
today,
but
something
around
like
just
minimizing
or
eliminating
the
complexity
for
what
we
ship
to
self-managed
customers,
because
I
think
even
the
largest
self-managed
customers,
like
the
50k
reference
architecture,
is
still
like
at
least
an
order
of
magnitude
away
from
needing
sharding
right.
G
So
I
think
it's
genuine
to
say,
like
gitlab.com
is
the
only
one
that
needs
charting,
but
that
means
in
the
worst
sense
we
might
accidentally
create
sort
of
a
fork
like
a
totally
different
database
interface,
and
then
gitlab.com
becomes
a
really
poor
use
case
for
testing
our
code
before
we
ship
it
to
self-managed
users.
G
So
we
talked
about
things
like
cytis
data
in
the
past,
which
kind
of
has
this
shim
sort
of
functionality
they've
since
been
acquired
by
microsoft.
So
I
think
we're
all
feeling
like
well,
if
that
was
ever
an
option
now,
they're,
probably
just
going
to
become
azure's
version
of
aws
aurora,
or
something
like
that.
So
it's
probably
not
good
to
rely
on
a
vendor
for
it,
but
maybe
something
that
works
in
a
similar
sort
of
fashion
as
a
way
to
think
about
how
to
reduce
that
complexity.
G
D
Yeah,
I
can
definitely
be
more
specific
and
concrete
about
those
goals.
I
mean
those
aren't
mine
right,
as
in
I'm
keeping
in
mind
the
fact
that
the
code
base
is
the
same
and
we're
shipping
self-managed,
but
I
can
definitely
be
more
explicit
about
that.
I
think
you
know
that
this
is
normally
a
challenge
and
for
us
it's
a
it's
a
an
even
bigger
challenge,
because
we
do
ship
self-manage,
which
I
think
is
actually
pretty
unique.
There
are
ways
to
make
things
logically
in
the
application.
D
Look
like
you're
sharding,
but
it's
still
one
box
and
all
that
logic
lives
in
the
in
the
application
itself,
where
the
application
is
talking
to
multiple
databases.
They
just
you
don't
have
a
spring
of
you
know
a
mushroom
cloud
of
little
databases
and
self-managed.
So
I'll
I'll
submit
an
mr
to
be
more
explicit
about
that.
G
Okay
thanks
my.
G
D
Yeah
on
the
10x,
I
think
one
thing
we
can
do
is
to
to
have
something
more
concrete
is
to
see
if
we
could
make
it
run
on
smaller
hardware
you
know,
can
get
lab.com
be
shrunk
down
from
next
to
the
biggest
thing
we
have
to
something
smaller,
because
now
we've
distributed
the
load,
and
that
might
be
a
more
tangible
thing
to
to
measure,
because
otherwise
scalability
is
like
this
very.
As
you
say,
it's
very
abstract
and
10x
doesn't
really
reflect
that
so
food
for
thought.
A
No
problem
at
all
who
wants
to
drive
this
exit
criteria,
discussion.
A
E
You
and
before
we
go,
I
had
the
one
last
question:
what
what?
What
are
the
goals
and
deliverables
for
next
meeting?
I
think
update
on
primary
key
migration
is
probably
just
something
we
can
do
a
quick
blurb
in
the
meeting
agenda
every
week
as
to
where
we
are,
what
the
or
in
the
roadblocks.
A
A
Okay,
we
are
we're
over
time,
so
that's
it
for
today
next
meeting
we'll
change
our
agenda
format
to
the
to
the
top
or
what
is
a
specified
item
of
the.