►
From YouTube: 2021-04-07 Database Scalability Working Group
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).
B
Yeah,
so
this
is
more
of
an
fyi.
I
shared
sort
of
general
information
about
this
working
group
in
the
product
meeting
yesterday
to
make
the
product
organization
aware
that
this
is
an
ongoing
effort,
and
I
also
try
to
highlight
that
it
is
very
likely
that
some
of
the
things
that
this
working
group
is
going
to
do
will
raise
product
questions
and
that
those
product
questions
will
need
to
be
discussed
in
the
dialogue
with
engineering,
and
there
was
already
some
good
discussion
in
the
in
the
call
overall
jerry
provided
some
some
context.
B
But
my
goal
here
was
to
sort
of
raise
the
visibility
in
product
as
well
and
sort
of
start
preparing
for
a
potential
impact
in
you
know
a
couple
of
months
when
we
are
actually
iterating
towards
solutions.
A
Yeah
I
thanks
for
playing
pointing
us
out
to
to
that
item
in
in
the
product
agenda.
I
did
add
some
feedback
and
this
is
actually
all
starting
to
tie
together
in
in
some
ways,
because
there
are
separate
conversations
about
there's
an
item
that
christopher
added
below
that
also
ties
into
this.
So
I
think
the
most
important
thing
is
that
cap
is
gonna,
start
driving
some
of
our
decisions,
and
you
know
we.
We
can't
have
all
three
things
in
the
cap.
Theorem
be
true
anymore
and
that's
gonna
have
to
to.
B
Yes-
and
we
can
maybe
discuss
a
little
bit
down
in
the
agenda,
because
I
have
some
thoughts.
C
Yeah
one
thing
we
want
to
be
careful:
our
fabian
is
it's
just
that
we
don't
confuse
policy
and
implementation
and
make
them
magically
come
together,
because
I
have
a
feeling
that
our
policy
is
going
to
change
three
times
in
the
next
five
years.
C
That's
just
what
my
gut
says,
depending
on
different
scenarios
and
different
situations.
So
you
know
it
might
be
good
to
kick
off
those
policy
discussions.
Just
let's
make
sure
we
don't
conflate
that
with
like
basic
mechanisms,
we
need
to
get
in
place
and
like
things,
we
need
to
do
just
to
make
the
system
scale.
From
that
perspective,.
B
No,
I
think
actually
my
intent
is
to
specifically
point
out
that
those
are
different
things
that
need
to
be
driven
at
at
different
levels.
It's
like,
I
think,
as
a
product
organization.
We
actually
I
I've
yeah,
I'm
still
reading
right.
I'm
not
really
sure
we
exactly
know
where
we
want
to
go
right
with
like
tenancy
and
all
of
those
things,
and
they
may
change
right
and
whatnot
and.
C
Agree
completely,
that's
what
I'm
saying
deep
thought
can
be
invested
in
the.
Where
do
we
want
to
go?
Let's
just
make
sure
that
we're
still
working
on
the
engineering
side
like
let's
not
like
oh
okay.
Well,
we
got
to
stop
everybody
to
talk
about
where
we
want
to
go.
Let's,
let's
do
those
in
parallel,
because
I
think
I
think
there's
so
much
complexity
of
this
problem
that
you
know
there's
like.
A
All
right,
so
next
item
is:
please
read
andreas
mr
on
read
mostly
and
provide
feedback.
I
already
added
some
comments
there
and
it
turns
out.
I
I
had
not
read
the
entire
thing.
I
guess,
but
yes,
please
provide
feedback.
There,
records.
E
Yeah,
I
think
so
we
had
a
call
with
camille
and
decided
to
take
a
little
different
strategy
regarding
improvements
to
the
ci
builds
data
model.
E
We
want
to
create
a
new
table
that
is
going
to
accelerate,
builds
queueing,
and
this
is
a
prerequisite
for
like
sharding,
perhaps
moving
forward
with
the
primary
key
migrations,
or
at
least
making
it
easier.
Then
we
are
thinking
about
introducing
a
separate
table
and
supporting
both
tables.
At
the
same
time,
of
course,
this
strategy
is
still
working
progress.
It
might
change
depending
on
what
we
learn
as
we
move
forward,
but
that's
the
current
plan.
D
I
wanted
to
add
emphasis
on
that
coming
from
today's
incident,
so
we
had
a
database
incident
today
that
we
just
wrapped
up,
and
the
problem
that
you
described
with
ci
builds
is
very
much
at
the
core
of
that
incident
and
yeah.
I
just
wanted
to.
F
Yes,
so
we
also
had
a
call
like
on
friday,
which
I
was
in
fabio
about
composite
blueprint,
code-based
blueprint,
it
doesn't
directly
like
answer
that
access
layer
concern,
but
this
is
one
of
the
approaches
to
make
our
performance
of
the
application
better
over
time.
So
I
hope
that
we
are
pretty
close
on
kind
of
getting
this
into
final
shape
and
I
think
gary
it
will
probably
be
on
your
agenda
either
friday
or
monday,
okay,
to
put
some
additional
tweaks
to
it.
F
I
also
discussed
with
craig
about
the
data
access
layer
extensively
and
we
may
kind
of
consider
maybe
opening
a
additional
grouping
or
something
that
would
discuss
that
in
a
more
detail
from
the
application
level
approach,
because
I
think
there
are
a
few
aspects
that
are
not
covered
in
the
compostable
codebase.
That
could
be
maybe
important
to
consider,
but
about
that
later,
gary,
your
item.
A
Yeah,
I
just
made
a
few
updates
to
the
sharding
blueprint
for
things
that
either
have
come
up
in
discussions
like
the
shark.
Cycling
is
something
camille
mentioned
and
then
based
on
conversations
that
I've
had
over
the
last
few
hours.
A
You
know
the
grouping
versus
charting
is
not
the
same
thing,
which
I
think
is
essentially
what
christopher
is
saying
with.
You
know,
policy
and
implementation
on
different
things
and
also
highlighting
infrastructure
concerns,
because
today
we
treat
the
database
as
a
snowflake
of
sorts.
Yes,
we've
built
a
lot
of
automation
around
it
and
in
self-managed
everything
is
automated,
but
certainly
on
github.com,
which
is
where
we're
you
know
where
this
really
comes
into
play.
B
B
This
is
mainly
for
my
own
benefit,
because
I'd
like
to
understand
what
other
folks
have
done
before
us,
sometimes
the
same
people,
but
it
may,
if
you
know
of
anything,
that's
relevant,
feel
free
to
contribute
to
that
issue.
I'll
probably
raise
an
mr
to
the
working
group
page
to
aggregate
that
information,
because
I
think
it's
important
that
it
is
more.
A
Okay,
I
am
not
aware
of
any
blockers
at
this
time.
So,
let's
go
on
to
the
discussion
and
fabian.
You've
got
the
first
point.
B
Yeah,
I
think
this
is
quick.
We
covered
this,
maybe
a
little
bit
already,
so
I
I'm,
I
think,
I'm
hopeful
that
we
will
be
able
to
engage
sort
of
product
management
and
drive
some
necessary
change
as
well.
If,
if
needed,
to
allow
us
to
you,
know
scale,
for
example,
be
a
sharding.
B
B
So
I
think
that's
quite
I
think
it's
a
good
opportunity,
but
I
think
we
need
to
be
also
aware
that
it's
a
very
big
topic
right
and
I'm
not
really
clear
at
this
moment
what
our
sort
of
policy
at
the
moment
actually
is,
or
if
we
have
one
or
where,
where
we
will
go.
But
if
you
have
any
sort
of
product
concerns,
please
voice
them
and
I'll
make
sure
to
connect
with
the
right
the
right
people
so
that
we
can
have
a
dialogue
and
that's
it.
A
All
right
yeah,
I
just
started
there,
so
I
have
a
coffee
chat
with
a
product
manager
and
she
we
talked
about
this
topic
and
cap,
and
all
that-
and
I
explained
how
cap
affects
the
things
that
we
can
do
and
cannot
do
and
how
today
is
kind
of
negligible
and
she's.
Like
I
didn't
know
about
this,
so
maybe
you
should
come
and
talk
to
product
managers
about
this
because
it
is
like.
A
There
is
some
level
of
awareness
that,
as
we
scale
and
do
things,
things
cannot
be
the
same,
but
deciding
how
those
things
are
going
to
be
affected
is
not
something
they're
they're
aware
of
I
mean
cup
is
a
computer
science
thing,
so
I
don't
expect
managers
to
know
about
it,
but
she
suggested
that
I
do
a
video
on
this
because
we
were
actually
in
in
order
to
explain
to
her.
I
was
using
gitlab
as
an
example,
and
that
made
a
lot
of
sense
to
her.
A
So
I'll
work
with
you
fabian
to
maybe
do
a
short
video
on
it,
and
so
we
can
populate
it
through
or
spread
it
through
product.
A
Then
the
next
point
is
mine,
which
is
you
know
we
already.
We
we
already
have
some
patterns,
as
it
turns
out
with
reap
mostly
we
already.
We
already
implemented
something
in
in
the
summer
and
so
the
question.
This
is
more
organizational
of
okay.
We
we
started
developing
these
patterns.
We
solved
some
immediate
problems
which
is
sort
of
the
exit
criteria
for
the
working
group,
but
then
how
do
we
make
sure
that
development
developed
at
large
are
embracing
these
patterns
and
using
them?
A
And
so
I
looked
at
the
single
database
right
up
and
that
obviously
or
singles
data
store-
and
that
makes
it
very
clear.
You
know
you
can't
just
go
off
and
create
separate
databases.
So
how
do
we
make
sure
that
these
patterns
are
known
to
developers
that
they're
being
sort
of
checked
or
used?
Or
so
that's
where
my
question
was,
and
camilla
and
andreas
have
points
on
that.
F
I'm
kind
of
like
thinking
because,
like
we
can
have
like
very
good
idea
what
this
pattern
do,
but
actually
like
enforcing
something
that
we
don't
know
how
it's
gonna
be
implemented,
can
be
pretty
challenging
because,
like
there
is
like
different
ways
how
how
they
could
be
actually
be
done.
So
I'm
more
like
the
person
of
like
trying
to
work
by
example.
If
we
have
a
pattern
that
we
want
to
use,
we
should
provide
a
exemplary
usage
of
that
pattern
in
a
state
that
everyone
can
pick
an
mr
copy
it
over
and
start
using
that.
F
I'm
not
really
like
a
big
fan
of
enforcing
something
that
we
didn't
actually
like
validated
ourselves
and
we
didn't
kind
of
provide
a
strong
implementation
guidance,
because
I'm
then
kind
of
assuming
that,
unless
we
kind
of
work
with
these
people
closely,
initially
it
will
kind
of
very
likely
go
in
completely
opposite
direction
that
they
intended,
and
it
may
not
solve
the
goal
that
we
wanted
to
achieve.
F
So
I
I'm
I'm
more
like
the
person
of
like
doing
and
promoting
rather
than
I
mean
documented
still
varies
at
any
point
like
having
a
good
idea.
What
you
want
to
do
it's
very
valid,
but
I
am
not
really
like
a
big
fan
of
promoting
something
that
we
didn't
validated
and
provided
like
exemplary
usage
of
that.
A
G
Yeah,
so
we
make
the
blueprint
identify
the
cases
then
pass
the
case
to
the
relative
teams
to
work
on
that
is
that
the
work
process
this?
I
think
this
is
the
way
we
enforce
the
working
model
right.
This
working
group
putting
out
the
blueprints
identify
the
cases
that
fit
into
this
blueprint
then
pass
the
work
to
the
stage
group
to
work
on
that.
A
A
G
We
established
a
first
example
to
just
to
show
people
how
to
do
that
right:
cool,
okay,
thank
you.
C
I
just
wanted
to
note
that
once
we
have
that
documented
path,
we've
had
really
good
success
in
the
past,
with
getting
every
engineer
to
go
through
those
kinds
of
things
through
a
training
format.
Really
it's
just
create
an
issue,
and
then
they
follow
that
issue
to
basically
go
through
either
things
to
read-
or
you
know,
go
implement
some
kind
of
test
scenario
that
we
feel
like
would
be
valuable
to
them.
So
I'm
happy
to
support
that
on
this.
This
initiative
we're
doing
this
based
on
retro
information
around
upgrades.
C
I
do
this
kind
of
that
same
category
but
to
camille's
point.
We
had
to
have
that
working
implementation
before
we
want
to
basically
push
that
broad
brush
wide
wide
distribution.
A
And
I'll
jump
back
to
andreas's
point
that
sharding
is
not
the
only
thing
we're
solving
here,
which
goes
to
nomenclature
so
yeah.
D
For
the
blueprint
that
I
was,
I
was
working
on
with
read
mostly
data,
what
I
felt
a
bit
like
a
like
a
textbook
exercise
at
the
beginning.
Like
you
know,
this
is
how
do
you
deal
with
most
of
the
other?
You
do,
caching,
what
I,
what
I
found
hard
is
to
push
it
in
a
state
where
it
basically
suggests
how
to
or
document
how
to
find
read
mostly
data
like
when
you
look
at
the
database
today
at
the
application
today.
A
Yeah
and
I
just
started
a
comment
that
a
lot
of
that
has
to
do
with
taxonomy
right,
and
so
you
know
when
I
wrote
the
original
thing
I
just
went
to
the
four
or
five
things
that
I've
seen
on
recent
database
reports
and
just
use
those
okay.
This
looks
like
tom
decay.
This
looks
like
read
mostly
and
that's
why
I
always
said
I
put
these
four
in
there.
I'm
sure
there
are
more.
So
if
there
are
more,
we
should
add
them,
and
if
any
of
these
make
no
sense,
then
we
should
get
rid
of
them.
A
So
I
think
for
the
working
group
this
is
you
know
the
patterns
that
we
agreed
are
sort
of
the
initial
batch,
but
we
should
definitely
this
sort
of
this
dovetails
into
this
whole
idea
of
data
management.
Discipline
of
we
need
to
stop
looking
at
the
database.
As
you
know
this
table,
or
that
thing
or
that
schema
and
look
at
the
overall
picture
of,
is
there
a
way
you
know
the
thing
that
I'm
trying
to
do?
Is
there
a
way
that
already
solves
this
without
me
reinventing
the
wheel
and
having
two
stage
groups
building?
D
And
in
terms
of
fanning
out
the
information,
I
think
we
can
also
always
start
with
with
maintainers
background
containers
or
database
maintainers,
because
they
are
ultimately
the
ones
that
are
looking
at
code
and
may
be
able
to
suggest
and
recognize.
Those.
A
Patterns.
The
next
point
is
this
whole
shrouding
versus
tenancy
or
policy
versus
implementation,
and
and
it
it's
something
that
is
popping
up
in
different
contexts.
There
was
an
old
you
know
when
we
talked
about
starting
the
last
time.
There
was
also
a
a
tenant
based
proposal,
but
to
me,
tenancy
is
a
very
different
thing
from
sharding.
Sharding
is
where
I'm
trying
to
scale
the
back
end
without
really
thinking
about.
A
What's
going
on
at
the
front,
and
so
tenancy
to
me
is
something
that
it's
implemented
at
the
top
of
the
stack
where
sharding
happens
at
the
bottom
of
the
stack,
and
these
two
things,
don't
don't
really
know
about
each
other.
There
is
a
rowling
layer
in
the
middle,
so
to
me,
sharding
is
something
that
it's
very
much
a
technical
solution
for
scalability,
which
sometimes
helps
you
do
tenancy
and
on
the
back
end.
A
So
this
is
why
I'm
saying
that
tendency
and
sharding
are
not
the
same
thing
and
one
of
them
is
actually
sharding
gives
you.
The
flexibility
to
implement
tenancy
tenancy
puts
a
straight
jacket
on
you
and
it's
a
forcing
function
to
shard,
but
it's
not
going
to
share
on
a
scalability
basis.
It's
going
to
show
on
some
policy
basis
which
we
want
to
avoid
getting
into
that
conundrum.
So
I
can
definitely
put
an
mr
either
on
the
working
group,
page
or
somewhere
else.
C
C
We
need
to
implement
some
basic
mechanisms
and
then,
if
it
turns
out
that
we
have
to
do
migrations
or
other
things
associated
with
that,
I
think
that's
a
trade-off
that
we're
willing
to
make
right
now
on
the
guidance
of
you
know,
policy
can
potentially
come
later.
We
don't
want
necessarily
the
implementation
just
to
be
personal
policy,
because
I
would
expect
our
policies
to
change
over
time.
B
By
the
way
I
I
enjoy
it,
and
I
think
right
now
at
least
to
me
to
me,
the
policy
is
unclear
or
it
may
change.
So
I
think
it's
it's
probably
wise
to
leave
it
right
and
maybe
just
be
clear
that
we
are
not
doing
this.
A
F
We
are
more
thinking
about
more,
like
a
complete,
separate
way
of
deploying
gitlab
somewhere
else
before
completely
separate
data
stores,
but
like
coming
into
this
meeting,
like
my
whole
perception
why
we
are
doing
that
was
like
to
provide
a
headroom
and
provide
resiliency.
There
are
probably
like
two
key
aspects
starting
around.
I
think
we
provide
a
headroom
but
will
not
provide
that
much
of
the
residency.
So
I
think,
like
at
least
from
my
perspective
is
like
we
need
to
start
data.
F
F
We
know
that
some
aspects
of
the
application
are
more
important
because
they
have
really
like
a
very
wide
effect
on
the
system
and
one
of
my
perceptions
about
the.
What
I
want
to
achieve
with
this
working
group
is
like
not
short
data
but
actually
short
data,
in
a
way
that
we
can
say
that
this
that
we
actually
increase
the
residency
of
the
gitlab.
F
F
But
the
nancy
thought
about
like
key
customers
using
github.com,
but
having
some
kind
of
dedicated
set
of
the
resources
that
we
can
use
the
current
architecture,
and
if
we
would
consider
the
concept
of
like
we
have,
the
authentication
using
code
base
running
assets
can
something
completely
separate,
maybe
still
showing
a
majority
of
the
code
base,
but
having
much
more
resilient
data
store.
F
And
we
have
these
customer
projects
running
on
some
charts.
It
could
be
just
general
database
sharding.
This
could
maybe
ensure
that
we
can
provide
much
kind
of
like
search,
tenancy
approach
without
doing
like
this
kind
of
what
we
are
discussing
in
the
gitlab
private.
I
think
that
this
is
my
perception.
A
A
All
right,
I
think,
we've
talked
about
tenancy
on
this
and
we're
almost
that
time.
Andreas
and
database
scalability
patterns.
D
Yeah,
I
was
basically
wondering
like
the
the
patterns
that
we
were
discussing.
I
think
there
is
in
terms
of
in
terms
of
database
scalability.
There
is
more
patterns
than
split
patterns
and
in
fact
we
already
run
into
problems
with
with
some
of
them
or
we
were
not.
We
would
benefit
from
from
recognizing
those
as
patterns
as
well,
and
I
was
wondering
if
we
should
bring
those
up
here.
If
that
is
right,
right
context
for
it
and
jerry,
you
sound
like
yes,.
A
Yeah-
and
I
mean
I
again-
I
put
those
four
early
on
just
to
seat
the
working
group,
but
anything
that
allows
us
to
scale
the
database
we
should
use,
which
is
why
we
said
these
are
just
examples
we
can
choose
to
throw
away,
replace,
add
another.
I
would
say
that
we
should
add
them
now
that
we
like,
if
we
just
thought
of
something,
put
an
mr
together
and
submit
it
to
the
to
the
working
group
page,
and
then
we
can
decide.
A
You
know
what
it
makes
sense
to
solve
this
one
as
part
of
the
exit
criteria
than
this
other
one
or
because
at
least
they're
recorded
somewhere
right
and
then
once
they
work.
We
either
extend
the
working
group,
or
I
mean
we
can
decide
on
a
specific.
So,
yes,
I
would
vote
that
we
at
them
now
and
then
make
decisions
about
them
versus
remembering
later.
Oh,
there
are
other
things
we
could
do.
D
Yeah
sounds
good
and
I
think
for
many
of
those
we
suffer
from
those
now,
and
we
probably
also
going
to
continue
having
problems
with
that,
even
if
we
do
sharding
later,
for
example,
long
transactions
is
always
going
to
be
a
problem
in
this
kind
of
application,
yeah,
so
yeah.
B
Okay,
my
next
point
I'll
be
quick,
is
I
I
found
out
today
by
talking
to
john,
that
global
surge,
already
shards
elasticsearch
by
project,
and
so
potentially
this
is.
You
know
something
where
we
can
utilize
or
re-utilize
some
knowledge
that
people
already
gathered.
You
know
in
like
limitations
or
issues,
I'm
not
quite
sure
how
transferable
it
is,
but
I
just
wanted
to
highlight
that.
B
Yeah,
so
I
want
to
add.
I
think
this
depends
on
the
on
the
use
case
and
usage
pattern,
so
it
works
well
for
us
to
distribute
the
data
to
different
charts.
So
that's
there
are
no
single
elastics
or
chart
would
be
too
big
and
it
worked
well
for
project
level
search,
but
it
sometimes
introduced
problem
on
group
level
search
because
when
you
do
the
good
level
search,
the
data
may
come
from
different
charts
that
take
some
time
right.