►
From YouTube: GitLab 13.4 Kickoff - Database
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
The
first
thing
we're
working
on
is
helping
the
package
team
to
develop
the
database
schema
and
migration
is
needed
to
partition
the
container
registry
database.
This
is
a
new
database
which
we
need
in
order
to
have
online
garbage
collection
and
understanding
of
where
the
storage
is
going
to
for
various
projects
and
groups
for
the
gitlab
container
registry.
This
is
important
for
gitlab.com,
but
also
provide
critical
insight
to
that
project,
administrators
group,
administrators
and
instance,
administrators
of
self-managed
as
well.
A
So
it's
a
really
important
overall
feature
to
deliver
the
garbage
collection
and
overall
visibility
of
container
images
and
so
we're
helping
to
make
sure
that
the
database
can
scale
and
is
set
up
to
for
success
on
the
first
go
around
here.
A
Next
up.
We
want
to
also
continuing
the
partitioning
work
that
we
went
through
with
audit
events
and
continue
that
with
the
events
table,
the
events
table
is
very
large,
but
it
performs
a
key
action
in
that
it
tabulates
or
contains
every
action
that
a
user
takes.
So
when
you
look,
for
example,
at
your
profile
page,
this
series
of
events
comes
from
your
comes
from
the
events
table,
and
so
it's
getting
quite
large
on
some
of
our
older
larger
instances,
and
we
want
to
make
sure
that
it
can
continue
to
perform.
A
So
we
don't
have
to
trim
it
or
drop
some
of
that
content,
which
would
be
unfortunate.
So
we
are
working
on
that
in
13.4
to
partition
it,
so
we
don't
have
to
and
it
can
continue
to
perform
and
continue
to
scale.
A
We
have
a
few
other
stretch
goals
around
generalized
partitioning
work
and
also
some
ongoing
maintenance
concerns,
but
in
general
we're
focused
on
those
two
primary
things
and
also
with
the
goal
of
enabling
and
looking
at
documentation
so
that
the
rest
of
the
gitlab
development
community
can
also
implement
partitioning
on
their
tables
without
the
database
group
doing
it
themselves.
So,
in
other
words,
enabling
them
to
be
self-sufficient,
and
we
can
then
go
focus
on
other
things
other
than
partitioning,
because
we'll
have
laid
the
groundwork,
foundation
and
documentation
on
how
to
achieve
this.
A
So
that
is
what
we're
working
on
in
13.4,
again,
hoping
to
primarily
provide
better
visibility
into
the
container
registry
by
assisting
that
team
with
their
database
schema
and
overall
partitioning
design
and
then,
of
course,
also
helping
to
scale
the
wrestling
cloud
database.
So,
thank
you
so
much
and
we
will
talk
to
you
again
on
13.5
next
month.