►
From YouTube: 2020 05 18 Database Sharding 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).
A
We
don't
have
specifics
that
I'm,
aware
of
and
sadly
I
don't
see,
Alberto
or
Jose,
who
are
probably
best
suited
to
answer
those
questions.
So
does
anybody
know
if
we
have
these
specific
measures
in
place
like
I've,
seen
anecdotally,
like
CPU
or
probably
like
double
provision
of
what
we
need
and
I've
seen
measurements
on
other
areas?
But
do
we
have
one
single
source
of
truth
that
says
how
over-provision
we
are
or
how
much
Headroom
we
have
for
our
primary
database.
B
No
I
can
bring
an
update
on
the
effort
that
has
been
done
so
far,
and
actually
it's
been
reinstated
these
days
so
basically
in
part
also
the
migration
the
upgrade
to
11.
There
was
the
idea
of
try
to
run
the
specific
existing
benchmark
for
gitlab
GPG,
if
I
recall
correctly
by
the
acronym
right
to
do
first
up
regression,
benchmarking
for
phosphorus
11
and
then
to
scale
it
up
for
capacity
planning
purposes,
but
the
DBT
tool
was
was
a
discussion
with
the
team
behind
it.
B
They
said
that
it's
not
yet
for
these
years,
it's
ready
so
for
the
upgrade
we
had
to
write
our
custom
benchmarking
tool
that
was
used
for
only
for
unlikely
designers
from
strength
for
performance
regression
on
phosphorus
11
operate.
Now
this
tool
could
be
leveraged
and
and
used
more
thoroughly
for
capacity
planning.
Basically,
it
recorded.
It
has
like
a
simulation
of
the
most
frequent
queries
with
random
parameters,
and
they
can
be
replayed
at
higher
speeds.
This
tool
can
be
elaborate
for
capacity
planning
and
actually
Alberto
asked
on
the
team
to
do
this
start
doing.
B
Ideally,
I'll
get
back
to
the
GPT
development
team
and
and
started
work
to
also
make
this
tool.
Dick
is
already
a
tool
design
for
this
to
be
used
for
this,
but
man
that
will
apparently
take
a
lot
of
effort.
So
I
guess
short
time.
We
can
continue
with
the
tools
we
developed
and
you
know
improve
it.
It
will
also
take
a
bit
that
probably
we're
talking
about
this
or
a
couple
of
weeks,
more
than
anything
else
to
try
to
get
it
to
the
point
where
we
can
do
a
composite
blood
capacity
plan.
A
Thank
you,
but
I
guess.
The
unstated
comment
here
is
we're
not
hitting
a
wall
right
now.
We
feel
like
we're
comfortable
with
Headroom
I
think
a
couple
a
month
or
so
back.
We
said
we
felt
like
we
still
had
probably
a
year
or
more
horizon
on
growth.
Given
the
current
provision.
Hardware
and
known
growth
statistics.
B
B
What
to
say
there
we're
probably
over-provision
terms
of
view
I'm,
not
that
sure
we
are
totally
over
proficient
in
all
the
areas.
There
are
a
lot
of
disk
usage
and
sometimes
you've
hit
the
walls
on
the
maximum
disk
speed.
On
the
other
side,
there
is
potentially
yeah
we're
running
with
very
old
CPUs
right
now
and
if
at
some
point
we
will
decide
to
give
us
the
pleasure
of
having
some
modern
CPU
on
the
US
East
one,
then
we
could
also
have
more
have
more
Headroom
there.
B
Yeah,
so
there's
no
second
generation
instances,
there's
we're
running
on
n1
and
one
hike
man
96
right
now,
and
this
is
first
generation.
There
is
the
second
generation
which,
at
least
on
any
instances,
is
not
present
on
the
USS,
the
last
time
I
checked
in
those
couple
of
weeks
ago
and
other
than
n2.
B
D
E
A
B
E
E
A
C
I
just
wanted
to
say
that
there
is
a
it's
slightly
more
expensive,
but,
like
our
experience
has
been
that
because
of
the
extra
power
that
we've
got,
it's
actually
costing
us
less,
because
we
have
smaller
fleets
so,
but
that's
obviously
different
from
how
you'd
use
it
for
for
Postgres
rides,
but
for
web
fleets
it
means
we
can
do
more
with
with
less
nodes.
So
it's
actually
a
little
bit
cheaper,
yeah.
D
D
E
Anyway,
yeah
so
I
didn't
say
anything
on
the
beginning
at
the
beginning
of
several
was
talking,
but
we
we
working
on
this
horse
a
which
off
today,
by
the
way
so
the
office
today
and
Congress
throughout
Iran
myself
we're
working
on
this
ice
off
made
largely
because
you
know
Craig
a
myself
with
me
that
this
is
what's
operating.
We
wanted
to
clarify
this
as
soon
as
possible.
C
Far
the
biggest
table
there's
been
the
major
Kristoff's
right
and
that's
the
most
problematic
and
there
is
a
quite
slow
going
migration
to
move
those
two
to
object:
storage,
but
I,
don't
know
what
the
second
biggest
is,
but
as
far
as
I
know,
that's
the
biggest
by
some
stretch
but
I,
don't
I,
don't
have
any
of
the
details.
Yeah.
F
A
G
There
sure
so
for
the
for
the
lack
of
a
better
term,
I've
called
that
anti
sharding
features
and
I
think
this
is
something
that
we
should
talk
about
more.
It's
in
I
think
there
is
product
questions
further
than
that
and
also
organizational
questions,
but
maybe
I
can
trust.
You
try
to
explain
what
the
intent
of
sharding
features
are.
So
I
think
something
that
that's
been
sort
of
accepted
that
we
go
with
is
a
namespace
sharding
idea.
G
That's
that's
saying
that
many
features
and
and
their
data
they
live
inside
a
namespace
and
that
that's
what
it
enables
us
to
to
apply
this
idea
to
to
get
a
product,
but
on
the
other
hand,
reality
is
also
that
it's
not
exactly
aligned
with
that.
So
we
have
features
that
don't
believe
inside
a
name
days
at
all
or
they
they
are
being
accessed
from
a
different
perspective.
For
example,
users
are
global.
They
are
not
within
the
namespace,
so
they
can.
G
Now
we
might
want
to
ask
is:
do
we
want
to
go
in
that
direction
where
those
are
confined
to
a
namespace?
So,
as
a
user,
can
you
only
sign
up
within
a
particular
namespace
sort
of
reflecting
the
idea
that
that
people
only
care
what
is
inside
their
namespace?
If
the
customer
is
inside
a
namespace,
their
users
only
care
about
their
namespace?
This
is
something
that
we
want
to
go
into
the
direction
that
we
want
to
go
into.
G
C
Another
mentioned
like
briefly
in
Arcola
Lily
undress,
but
it
was
just
mentioning
to
people
is
anything.
That's
got
a
water
increment
key.
That
is
one
of
those
things
as
well,
like
you
know,
like
a
user
ID
or
even
a
job
ID
on
a
pipeline
job
that
has
a
globally
incrementing
water.
Id
needs
to
be
considered
in
the
same
discussion.
C
F
F
My
suggestion
is
is
and
if
it
doesn't
work
or
we
think
there's
a
better
strategy-
that's
fine,
but
to
raise
it
with
the
specific
feature
teams
to
see
if
we
can
get
them
to
potentially
start
working
issue,
because
you
know
the
divi
theme
can
scale
out
to
solve
everybody's
problem.
We've
got
to
get
these
back
to
the
feature
teams.
Potentially.
From
that
perspective,
you
mange-
and
you
know,
like
one
of
the
I
hate,
to
say
this
way,
because
it
sounds
incorrect,
but
a
you
know,
thinking
about
it
more.
F
It's
probably
the
right
way
to
be
thinking
about
it.
Anyways
is,
is
you
know
if
you
have
a
feature
that
you
want
to
run
calm
and
it
can't
scale
and
that's
you
know
sharding
supposed
to
help
solve
right.
So
so
it
feels
like
that
there
really
is
future
team's
responsibility
to
make
sure
that
they
their
thing
in
the
framework
so
that
they
can
scale
effectively.
F
G
And
currently,
where
we're
going
with
the
audit
log
feature
and
even
they're,
even
even
if
that's
a
that's
a
quite
separate
feature,
quite
a
small
feature
in
your
lab-
it's
not
very
much
entangled
with
everything
else,
but
even
there
we
we
already
recognize
that
there
are
different
ways
of
using
the
audit
log
and
I
think.
This
is
a
really
good
example
where
we
should,
where
we
can
work
with
with
the
second
team,
owning
that
feature
figure
out
how
to
do
that
going
forward.
G
G
F
Doesn't
have
to
be
a
complete
it's
trying
to
get
a
sense
for.
Are
there
a
handful
of
these
or
are
their
tens,
tens
of
these
or
their
hundreds
of
these?
That's
that's.
What
I'm,
trying
to
get
at
more
than
anything
else,
was
called
how
we
attack
it.
May
change
based
on
the
answer
to
that
question.
At
least.
G
G
If
that
is
something
that
we
can
even
do
on
get
like,
where
that
would
be
acceptable.
A
That
timeline
doesn't
really
sync
up
with
what
we're
trying
to
do
with
charting.
If
we're
trying
to
implement
charting
now
that
solves
some
early
scalability
problems,
then
the
timelines
don't
seem
to
sync,
then
we'd
have
to
find
a
way
to
iterate
on
that
maybe
feature
by
feature
and
I'm
not
there'd,
be
a
lot
of
discovery
that
would
need
to
be
done
there
so
and
part
of
this
discussion.
A
Sorry,
if
I'm
stepping
on
what
you
were
gonna
continue
at
thunder
as
part
of
this
discussion
came
with
our
conversation
with
Sid
last
week
when
we
talked
about
our
approach
with
Auto
bogs
and
focusing
on
the
creative
that
date,
and
he
was
concerned
that
that's
a
local
optimization,
as
listed
here
under
the
first
bullet
point
d
and
use
again
using
the
specific
audit
log
functionality.
If
we
partitioned
on
namespace,
then
that
would
we
believe
it
would
break
some
functionality
within
gitlab.
G
Yeah,
so
the
for
the
audit
log,
the
the
date,
is
sort
of
ideal,
with
the
features
that
we
that
we
know
already,
and
in
that
sense
it's
a
good
choice
for
for
the
audit
log.
But
if
we
were,
if
we
wanted
to
sort
of
strategic
strategic
lis
explore,
how
do
we
deal
with
those
those
patterns
like?
How
do
we
deal
with
those
entire
charting
features
and
give
and
perhaps
discover
a
good
example
for
that?
G
You
could
also
explore
the
idea
of
applying
the
namespace
base,
partitioning
approach
and
then
figuring
out
how
to
how
to
deal
with
the
admin
view
how
to
deal
with
it
by
user
view.
I
think
that
would
be
sort
of
valuable
for
us
to
to
figure
out,
because
it's
such
a
such
a
good
example
that
we
are
going
to
see
more
more
of
if
we,
if
we
follow
that
namespace
based
idea.
G
But
it's
certainly
not
the
the
ideal
choice
for
for
the
audit
log,
as
it's
done
at
the
moment,
but
I
wonder
if
we,
if
we
you
know,
should
be
rather
like
try
to
optimize
this
particular
feature
for
the
audit
mark
as
it
is
now
or
do
we
want
to
assume
that
we
want
to
go
forward
with
namespace
base
charting
and
then
explore
that
more
and
discover
those
problems.
More
kind
of
the
point
we're
at
at
the
moment.
H
A
H
Even
for
the
auditioning
I
mean
there
might
be
cases
that
there
are
features
that
I
do
sharding,
but
are
we
blocked
from
making
progress
on
the
charting
based
on
the
namespace
I'm,
guessing
that
we
can
do
some
charting
a
war
proof
of
concept
here
now
when
making
some
progress,
while
thinking
about
those
additional
reading
features
how
we
want
to
deal
with
that?
That's
just
a
my
my
thinking
at
this
point.
H
G
Yeah,
no
we're
not
we're
not
blocked.
In
that
sense,
we
can.
We
can
execute
on
the
by
by
time
partitioning,
and
we
can
also
execute
on
the
name
space
based
partitioning
with
the
ladder.
We
know
that
some
features
are
going
to
break
so
I
think
it's
sort
of
we
already
know
this
is
going
to
happen
right
and-
and
it's
not
not
working
well
with
the
with
the
change
that
we
would
implement.
G
H
G
Yeah,
like
we
could
one
thing
that
we
discussed
is
like
going
at
and
sort
of
prototyping
each
of
those
paths
like
implementing
the
by
time
and
by
namespace,
with
the
existing
feature
set
and
then
doing
some
measurements.
How
things
are
going
I
think
from
from
the
existing
data.
We
can
also
already
anticipate
how
that
looks
like,
and
we
that's
why
we,
where
we
know
that
things
are
going
to
break,
but
is
it
something
that
we
should
do
like
prototype
that
forward,
because
that's
nothing
that
sort
of
directly
feeds
back
into
the
product
right?
A
Guess
our
research
into
what
implementation
of
partitioning
and
charting
will
require
and
what
may
be
gotchas
that
we
encounter
along
the
way
as
we
go
to
the
namespace
strategy
partitioning
and
it
gets
us
the
advantage
of
getting
that
audit
law
and
performance
improvements
as
well.
So
it's
not
if
we
go
down
a
different
partitioning
strategy
in
this
case,
the
time
base.
That's
not
lost
effort
that
that
makes
sense.
It's
just
not
a
perfect
alignment
with
the
bigger
picture
of
charting
and
partitioning
on
namespace
across
the
entire
database.
A
All
right
and
I
think
we've
in
the
conversations
we've
had
we
pretty
well
covered.
What's
been
done,
so
you
can
read
the
epic
on
audit
log
on
what
we've
identified,
what
we
are
and
we
have
a
meeting
database
team
as
a
meeting
for
more
specifics
on
what
we're
going
to
implement
this
week
and
then
and
that's
in
details
there
and
what's
happening
next.