►
From YouTube: 2022-02-14 Database Scalability WG 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
A
B
Okay,
I'll
get
started
so
welcome.
Everyone
today
is
february
14th.
This
is
the
database
scalability
working
group
weekly
sync
up,
so
let's
get
started
from
the
agenda.
The
first
item
is
a
significant
update
since
last
meeting,
and
I
have
the
first
item
from
a
sharding
group
so
update
from
dylan
earlier
last
week
that
phase
3
was
rolled
out
to
staging.
B
We
are
keeping
the
traffic
at
50
percent
like
last
time,
since
this
is
the
best
chance
to
catch
any
issues
in
staging,
so
our
ci
rates
are
50
from
the
ci
cluster
in
staging
and
also
enabled
the
loose
foreign
key,
fair
queuing
feature
flag
last
week
as
well,
and
also
the
readiness
probe
for
the
phase
four
and
six
that
the
task
is
wrong
or
truly
decompo
decompose
the
pipeline
across
two
databases.
B
As
last
report,
as
the
last
reported,
we
have
only
three
issues
left
from
it,
and
the
remaining
work
is
mostly
feature
flag
to
disable
and
camille.
You
want
to
verbalize
your
command
here.
C
Nothing
in
particular
the
phase
six
main-
I
guess
one
of
the
last
outstanding
bigger
issues
is
like
work
on
the
support
of
selective
running
of
the
migration,
but
this
is
also
progressing
well
and
I
I
don't
anticipate
any
slowdowns
on
that
one
for
the
phase
six.
So
I
think,
in
summary,
what
you
are
saying
like
we
are
progressing.
We
are
at
pretty
good
state
with
the
phase
four
and
effectively
phases
finishing
from
the
development
side.
B
Yeah,
thank
you
for
the
update,
camille
and
moving
to
next
one
as
we
are
preparing
face
for
fisher
flag.
I
roll
out
in
that
merge
request
is
going
also
going
well
and
a
summary
of
what
has
been
done
last
week.
So
we
close
the
seven
issues
and
also
our
development.
Progress
is
very
steady
and
we
continue
to
see
the
open
issues
trending
down.
So
that's
the
update
from
the
sharding
group.
B
Okay,
moving
on
to
the
next
one
sami
since
you
are
here,
do
you
have
any
update
for
the
ops
side.
D
No,
I
don't,
I
think
it's
still
on
track,
although
I
was
reading
down
below
in
the
agenda.
I
was
curious
about
your
note.
I
guess
in
four
a
but
no,
I
think
I
think
it's
on
track.
Okay,.
B
Thank
you
and
steve
is
not
here,
so
I'll
have
to
stick
up
later
with
steve
and
then
moving
on
to
the
next
one
review,
the
raw
the
process,
so
dealer
actually
brought
this
up
that
the
the
ci
cluster
in
production
right
now
is
projecting
to
be
available
february.
25Th,
that's
the
best
effort.
B
So
what
that
means
is.
This
is
a
two
weeks
behind
our
schedule,
the
time
timeline.
So
this
could
result
in
a
time
overall
timeline
push
out
to
the
may
22nd.
B
So
I
had
a
question
for
steve
or
ken,
so
just
to
confirm:
what's
the
what's
the
latest
update,
because
we
had
a
meeting
last
week
we
signed
up
on
that
infrastructure
team
is
working
on
it
still
just
to
confirm
the
date
and
then
also
get
a
confidence
level
from
that.
Since
steve
is
not
here,
I
will
follow
up
offline
with
steve
any
questions
about
this
update.
B
D
Is
this
the
two
week
delay
that
you
mentioned
in
four.
B
Yes,
yes,
that's
the
two.
I
think
the
number.
B
So,
okay
I'll
sync
up
later
offline
with
steve,
any
other
updates
about
this
raw
other
progress
or
questions
about
this.
B
Okay,
then,
the
number
of
bullet
number
three.
I
captured
the
the
charts
from
the
sciences
dashboard
and
you
can
see
the
first
chart
our
outstanding
issues.
The
green
line
keeps
dropping.
So
that's
our
demand
overall
work
is
progressing
very
well.
B
And
the
risks
of
course
mention
that
the
two-week
delay
in
the
2.8
will
follow
up
and
then
timeline
review,
that's
pretty
much
done
and
then
moving
on
to
other
topics.
So
the
new
topic
here
is
engineer.
Allocation
is
evolving
to
engineering
allocation
2,
which
actually
will
capture
the
long-term
architectural
work,
and
the
conversation
was
selected
as
a
first
for
the
first
iteration,
along
with
really
limiting.
So
some
knows
about
that
and
for
a
couple
changes
here.
B
New
labels
will
be
introduced
so
for
decomposition
there
will
be
a
new
label
called
allocation,
functional
dcom
and
the
new
sizes.
Dashboard
was
also
added
for
visibility,
so
dylan's
question
here
just
to
verbalize
quickly.
Does
this
mean
that
issues
created
or
prioritized
by
pm
don't
need
this
label
and
yeah?
And
basically
there
were
a
lot
already
a
lot
of
labels
for
decomposition.
B
This
will
add
another
one
to
the
to
the
to
the
play.
So
that's
how
yeah,
basically
that's
a
question:
how
this
will
impact
our
efficiency
or
or
our
progress
so
mac?
I
see
you
have
a
comment
here.
Would
you
like
to
work.
E
Yes,
so,
first
off
these
two
groups
are
the
first
early
adopters
of
engineering
allocations.
So
thank
you
for
all
your
patience
as
we
as
we
are
still
navigating.
How
are
the
best
fit
these
two
work
streams
into
the
process.
I
understand
that
because
we
are
picking
on
something
that's
been
in
process
for
a
while.
The
the
labels,
the
work
screen
is
not
mapped
one
to
one
and
that's.
Okay,
because
engineer
allocation
dashboards
are
long-term
architectural.
E
Rework
that
you
want
to
capture
and
think
from
now
to
like
one
year
plus
two
year,
plus
time
horizon
as
eric
use
the
term
right
now,
it's
reliability
and
a
bit
of
a
wartime.
This
is
the
dashboard
for
for
peace
time.
When
things
have
settled,
we
want
to
capture
only
the
long-term
re-architecture
work
and
we
want
to
focus
on
just
these
two
items
right
now,
which
is
functional,
decomposition
and
then,
and
then
rate
limiting.
E
So
I'm
going
to
skip
to
point
four
then
I'll
provide
space
for
sam
as
well
as
I
mentioned
before.
This
is
meant
to
be
scalable
to
the
future.
When
an
initiative
like
this
comes
up,
it's
not
just
development.
It
may
also
involve
infrastructure,
quality
and
development,
or
sometimes
support
so
we're
testing
out
this
framework
that
that
was
that's
linked
in
the
in
the
issue
above
the
team
can
use
existing
labels.
So
my
my
top
goal
is
to
not
change
anything.
E
That's
working
people,
no
workflow
changes,
no
process
change,
no
level
label
changes
at
all.
I'm
working
with
chun
on
identifying
how
many
labels
are
capturing,
functional
decomposition
as
a
work
stream,
and
then
we
can
apply
the
the
automation
the
tries
to
capture
that
to
start
and
then,
when
we
have
the
dashboards
up,
you
can
filter
by
you.
Could
you
should
have
a
top-down
visibility?
E
Okay,
this
initiative,
how
many
teams
in
development,
how
many
teams
and
quality
how
many
teams
in
infrastructure
actually
working
on
this
functional
decomposition
and
then
providing
a
simple
pull
down
chart?
It
can
exist
in
parallel
with
whatever
charge
that
is
already
working
at
this
point.
We
do
want
to
start
capturing
this
into
into
this
dashboard
to
test
it
out,
and
I
I
anticipate
there
will
be
changes
and
fine
tuning.
So
it's
not.
E
This
is
not
the
end
state,
but
more
of
a
heads
up
that
we're
going
to
include
this
into
the
the
future
state
of
engineer
allocations
and
then
any
questions
before
I
pass
it
to
sam
for
roman
numeral,
three.
D
Yeah
and
just
said
also
thanks,
mack
for
setting
up
all
these
dashboards
and
team
for
setting
up
all
these
dashboards
because
it
is
going
to
really
help
track.
Some
of
these,
you
know
things
going
forward
and
yeah.
My
plan
was,
to
kind
of
this
week,
start
looking
at
automation
around
some
of
these
labels,
because
I
think
at
least
in
raid
limiting
the
way
I'm
thinking
of
it
now
is
like
we
have
an
existing
label.
We
could
kind
of
automatically
apply
this
for
certain
types
of
tracking
and
there's
kind
of
other
things.
D
B
Yeah
cool,
let's
sync
up
offline
and
also
I
took
a
look
at
our
our
backlog,
so
it
won't
be
hard
to
pull
out
the
decomposition
issues,
development
issues,
but
there
could
be
some
tricks
there
to
pull
out
the
infrastructure
issues.
They're,
not
specif.
Many
of
those
tasks
are
not
specifically
labeled
to
decomposition,
but
they
are
actually
so
I'll
synch
up
with
jose
offline
to
see
how
we
can
pull
out
those
issues
for
automation,
okay,.
E
So
shin
and
sam
can
I
can
I
facilitate
with
an
issue
in
the
engineer,
analytics
team,
and
then
we
can
capture
whatever
labels
you
want
to
map
there
and
then
either.
Someone
in
our
team
can
go
and
implement
some
sort
of
automation,
but
we
want
to
document
it
and
the
things
that
are
common.
That's
going
to
be
that's
going
to
set
up
for
like
what
is
the
third
initiative?
That's
going
to
be
included,
we're
setting
up
the
standards
going
forward
and
then
on
what
to
decide
to
be
included.
Yeah.
D
B
Awesome
cool.
Thank
you,
matt.
Thank
you,
yeah.
Any
more
questions
about
this
engineer,
allocation
tool.
E
Is
there
anything
more,
I
could
help
provide
clarity
on
for
the
team
members.
I
know
not.
Everyone
is
joining
this
working
group.
Anything
I
need
to
copy
over
to
the
other
agenda.
Please
let
me
know
I'm
happy
to
to
multi-modal
communicate
to
everyone,
and
everyone
understands
the
reason
why
the
path
forward.
B
C
A
So
meg,
if
I'm
writing
your
comment
correctly
yeah,
are
we
saying
that
the
I
can
can?
I
can
now
go
back
to
the
architecture,
evolution
workflow
and
say
you
know
the
the
outcome
of
that.
Is
you
hook
it
into
engineering
allocation
to
get
people
and
re
assigned
to
these
things?
Yeah.
A
The
the
architectural
revolution
is
very
adult
about
that
right,
you
get
a
manager,
you
get
a
senior
technical
lead
and
then
we
talk
to
some
vp
and
then
you
kind
of
put
it
together,
but
I
mean
I,
I
love
this
idea
and
I'm
fully
on.
I
just
want
to
make
sure
that
I
can
go
and
write
up
an
mr
and
say
connect
these
two
things
together
and
you
know
you
get.
E
A
short
answer:
yes,
when
I
was
talking
with
eric,
steve
and
and
christopher,
this
should
be
something
that
has
a
conversation
at
the
top
level.
Okay,
this
one
should
be
an
ng
allocation
that
we
added
in,
but
if
it's
long-term
architectural
rework-
yes
that's!
This
is
the
the
goal.
Why
don't
I
set
up
a
coffee
chat
with
you
jerry?
E
I
we
have
dashboards
that
can
show
what
the
next
state
is
and
the
goal
is
when
you,
when
you're
tracking
something
like
this,
you
should
be
able
to
filter
down
okay,
how
many
teams
in
engineering
that's
in
development
quality
infrastructure
are
working
on
this
long-term
architecture
initiative
and
that
that's
probably
that's
probably
what
you
want
to
be
be
tracking
at
and
then
I'll
reach
out
to
set
up
a
demo.
I
mean.
A
B
Okay,
looks
like
I'll
be
our
last
question
for
this
one:
okay,
moving
on
to
the
next
one.
Actually
from
do
you
want
to
verbalize.
D
Yeah,
I
was
curious.
It
came
up
this
week,
but
I
was
curious
with
the
work
that
we're
doing
to
set
up
a
separate
database
cluster
for
4ci
kind
of
how
close
that
gets
us
to
being
able
to
do
that
for
other
purposes.
If
we
wanted
to,
for
example,
like
if
a
new
feature
was
developed,
that
there
was
a
reason
that
you
would
want
to
keep
it
outside
of
the
primary
database
kind
of.
Does
the
tooling
like
how.
A
Actually,
there's
ci,
there's
registry:
there
is
the
main
database
we're
already
doing
that,
so
the
the
biggest
quote-unquote
blocker
you
need
to
conquer.
There
is
to
convince
it
and
one
of
either
stan
or
myself
that
you
do
really
need
a
separate
data
store
early
on.
There
are
other
ways
we
can
do
it.
We
can
set
up
a
logical
database
inside
the
main
cluster
if
the
usage
is
going
to
be
low
enough,
that
it's
not
going
to
hit
us
hard
in
production
once
ci
is
actually
working
on
outside
of
the
main
database.
A
That
will
give
us
more
room
so
that
that
that's
the
biggest
thing
but
we're
already
supporting
multiple
clusters.
So
operationally
speaking,
I
think
we're
fine,
but
sid
has
always
had
a
reticence
to
have
you
know
a
mushroom
cloud
of
data
stores,
so
he
set
up
some
riches
or
some
gates
for
that
to
happen.
D
A
I
forget
her
name,
let
me
just
make
sure
I'm
getting
it
right
monre.
I
think
it
is.
A
Yeah
monre
is
now
asking
for
that,
and
so
I'm
meeting
with
her
to
understand
why
they
feel
they
need
a
separate
data
store.
Their
case
actually
seems
to
make
a
lot
of
sense
because
they're
consuming
data
but
they're
writing
all
these
very
different
data
and
then
we're
trying
to
understand
how
busy
is
this
going
to
be?
Do
we
just
start
you
on
the
main
database
in
a
separate,
logical
database,
and
then
we
move
you
to
a
separate
cluster
and
all
that.
A
So
at
some
point
I
need
to
write
an
mr
that,
actually,
you
know
right
now:
we've
documented
that
there
is
this
gate,
but
we
now
have
several
use
cases
where
we
can
start
documenting
what
the
process
looks
like
in
terms
of
first
thing,
we'll
likely
do
if
you
do
not
fit
in
the
main
databases
will
create
geological
database
and
from
there
we
use
smaller
size
hardware,
and
then
just
you
know
scale
you
up
as
we
go.
F
So
I
have
a
I
added
a
link
sam
in
the
agenda
for
the
process
for
proposing
a
separate
database.
It's
in
the
handbook
and
the
way
I
took
your
question
under
bullet
point
b
is
you're
questioning.
Does
the
work
that
we're
doing
for
decomposition
provide
tooling
to
allow
us
to
separate
some
other
area
of
functionality
into
a
separate
database?
Is
that
what
you
were
asking.
D
D
A
dz
was
the
last
project
he
worked
on
before
you
know
moved
on
from
the
company
and
right
now
it
writes
all
of
the
error
data
just
into
the
primary
database,
which
has
caused
some
production
incidents
and
right
higher
knowledge
of
like
error,
reporting
software
you
can
get
the
data
volume
can
get
very
large
very
quickly
when
you're
storing,
like
you
know,
javascript
errors.
Things
like
that.
D
So
there's
a
concern
that
that's
kind
of
a
ticking
time
bomb
we're
putting
various
limits
in
place
to
kind
of
make
sure
that
it
kind
of
you
can't
use
it.
You
know
as
a
full.
You
can't
store
that
much
in
it,
but
you
know
the
probably.
D
Would
be
to
build
it
on
top
of,
like
click
out
like
one
of
the
observability
stores,
that
you
know,
teams
working
on
the
shorter
term,
it
was
really
easy.
Maybe
it
makes
sense
to
pull
it
into
a
separate
database
but
yeah
it's
kind
of
a
lot
of
work
to
I.
You
know
it
doesn't
seem
like
long
term.
That's
right
the
idea
of
the
store,
even
if
it's
isolated,.
F
Agreed
yeah.
That
sounds
like
an
ideal
scenario
for
separate
database
storage
and
for
new
features.
You
would
have
to
go
through
that
proposal
for
separate
database.
I
I
thought
you
were
asking
something
different
like
can
we
carve
out
yet
another
feature
to
a
separate
database
and
yeah?
That
is
an.
F
B
C
So
like
from
the
development
side,
it's
doable,
but
there
is
like
the
challenge
and
understanding
if
we
will
not
end
up
with
too
much
granularity
on
having
too
many
small
databases,
especially
some
in
your
case.
I
think
you
also
have
packages
features
that
are
mostly
a
kind
of
sort
of
cdn.
So
mostly
reads
that
also
probably
generates
an
amount
of
pressure.
C
So
I
think
like
what
you
may
look
at
look
at
that
set
of
the
features
holistically.
If
there
is
like
enough,
I
mean
content
that
would
really
justify
another
database,
because
there
is
also
discussion
of
on
pots
and
pots.
Ideas
technically
make
the
each
instance
small
enough
that
you
don't
really
need
that
many
databases
and
you
can
deal
with
the
bloat.
C
C
What
we
do
as
part
of
the
decomposition,
we
definitely
make
it
simpler,
but
it's
still
like
quite
amount
of
the
work,
because
you
kind
of
have
to
reinvent
what
we've
been
doing
now,
but
it
should
be
half
easier
right
now,
but
the
third
part
is
really
like
the
pots
just
make
each
pot
small
enough
that
this
is
not
really
your
concern
and
you
kind
of
you
don't
really
need
that.
We
don't
really
need
that
many
small
databases,
so
I
I
think
there
is
like
some
balancing
act
between
these
three
initiatives.
Now.
D
Yeah
that
totally
makes
sense,
and
I
think
that
in
some
with
observability
data
one
thing
I'd
point
out
is
it
can
get
very
large.
So
that's
probably
another
axis
that
we
could
look
at
it's
like
if
the
you
know
volume
like
one
customer
can
generate
is
like
on
the
order
of
like
all
the
data
that
we
have
today.
D
Of
what
I'd
be
most
worried
about
with
errors
is
just
that
you
can
get
into
your
very
trillions
of
records.
You
know
very
quickly
without
even
a
lot
of
users.
C
Yes,
but
but
this
is
also,
then
I
connected
with
the
retention
policy,
and
I
know
that
we
are
also
talking
about
the
time
scale-
databases
in
the
past,
so
yeah
our
decomposition
effort,
maybe
could
be
focused
on
introducing
a
third
database.
That
is
truly
like
timescale
db
that
we
may
use
to
these
various
usage
patterns
instead
of
introducing
generic
postgres
as
we
would
be
doing
so,
there
may
be
a
benefit
not
in
particularly
moving
errors
as
a
feature,
but
rather
introducing
timescale
db
as
additional
database
to
which
we
slowly
migrate.
C
D
Yeah
no
and
that's
I
agree,
that's
exactly,
I
think
what
we're
doing
and
I
actually
want
to
get
you
and
some
other
folks
kind
of
more
involved
in
reviewing
this
stuff
soon,
because
it's
starting
to
you
know
kind
of
get
some
momentum,
but
basically
click
house
is
the
database
data
store
that
we're
looking
at
kind
of,
or
you
know,
kind
of
actively
developing
on
top
of
the
obstrace
stuff
it
kind
of
came
out.
There's
a
lot
of.
I
could
go
into
why
but
basically
click
house.
D
It's
a
columnar
database
out
of
the
index.
It's
very
performant
in
certain
ways.
It's
like
clustered
and
yeah.
The
plan
is
for
that
to
be
the
backend
for
logs
traces,
which
actually
kind
of
works.
Today,
there's
a
demo
of
that
and
then
maybe
metrics
and
errors,
because
apparently
that's
what
century
uses
as
well.
I've
learned
so
it's
kind
of
a
more
you
know,
yeah.
If
you
had
like
large
observability
data.
D
I
think
that's
that's
the
direction.
I
guess
we're
going
in
so
yeah
be
good
to
get
more
kind
of
eyes
and
put
on
that.
A
You
should
engage
these
people
as
soon
as
possible
because,
like
I'm
all
in
favor
of
filming
that
problem
that
way,
but
now
you're
we're
now
talking
about
supporting
this
new
thing
and
having
to
learn
about
it,
and
you
know
we
learn
with
elastic
mounting
elastic,
is
not
easy
right.
So
if
we're
introducing
some
new
beats
into
the
environment
and
thinking
about
it,
the
earlier
you
get
in
for
people
to
start
thinking
about
this
and
be
informed
and
maybe
send
some
people
to
training
the
better
like.
D
No,
I
totally
agree.
I
mean
we're
like
a
few
weeks
into
this,
so
I'd
say
yeah
at
this
point.
D
There
is
a
write-up
that,
like
that
team,
has
reviewed
like
that
they
wrote
last
week
in
terms
of
like
this
is
the
kind
of
proposed
sas
infrastructure,
and
I
think
you
know
steve's
been
kind
of
aware
of
this,
but
but
yeah
we
need
to
okay,
yeah,
more
security,
so
we're
kind
of
at
that
point
now
yeah
exactly
I
mean
the
plan
is
not
to
like
dump
this
on
infrastructure
immediately
like
the
the
idea.
Is
that
there's.
A
D
A
D
D
Links
to
the
end
of
the
agenda
after
the
meeting
here-
and
we
can
talk
about
it
next
week
or
I'll
kind.
B
Exactly
this
meeting
is
for
synchronization
between
the
groups,
so
great
everyone.
Thank
you
very
much
and
enjoy
the
rest
of
your
day.
Bye.
Everyone.