►
From YouTube: 2021-04-12 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).
A
B
Thanks,
so
this
is
just
a
short
one
about
how
we
do
imagination
within
bit
lab.
We
know
that
the
current
way
we
are
doing
pagination
can
be
problematic
when,
let's
say
an
api
user
visits
a
really
high
page
number.
So
we
had
some
problems
that
an
api
user
requested,
I
don't
know
really
large
page
size
and
it
spent
like
10
15
seconds
in
in
the
database,
and
the
other
part
was
when
basically
the
first
page
load.
When
you
visit
a
group
level
feature
project
level,
feature
and
loading
list
of
items.
B
So
for
the
offset,
let's
replace
the
offset
page
patching
nation,
we
could
do
key
set
patching
nation
and
we
are
doing
this
already
in
graphql,
and
the
idea
is
that
we
could
maybe
adapt
it
more
on
our
existing
features
and
maybe
for
new
features
to
to
use
keyset
pagination.
To
avoid
these
problems
in
the.
B
C
Yeah,
that
makes
a
lot
of
sense.
I
think
we
had.
We
had
an
attempt
to
implement
keysight,
pagination
and
the
rest
api
earlier
that
got
stalled,
so
we
we
only
have
it
on
a
couple
of
endpoints,
but
it's
really
the
way
to
mitigate
the
let's
say
the
attack
surface,
also
on
on
the
on
the
api,
because
it's
so
easy
to
just
send
requests
asking
for
very
high
offsets
and,
like
adam
mentioned,
having
like
very
large
long
database
queries.
So
this
is
great
thanks
for
the
for
the
write-up
on
this.
D
I
was
worried
kind
of
that
there
was
no
affinity
as
far
as
I
could
see
like
we're
we're
starting
projects
in
italy
without
affinity.
I
think
I
wanted
to
do
that
by
sharding
or
kind
of
by
by
saying
which
gita
server
you
use
based
on
the
top
level
name,
space.
B
D
Had
a
great
remark
that
hey
what
happens
if
you
move
a
project
between
namespaces,
it
won't
happen
that
often,
but
it
would
be
very,
very
sad.
If,
then,
you
have
to
move
the
whole
level
namespace
or
something
like
that.
So
I
think
I
think
I'm
convinced
I'd
love.
If
someone
would
do
a
write-up
or
something
like
that,
but
I
think
I.
A
A
Did
it
this
weekend
and
I
posted
it
today,
it's
on
0.2,
but
there's
a
write-up
that
talks
about
sharding
and
tenancy
and
how
these
two
things
relate
and
how
project
sharding
would
essentially
allow
us
to
do
tenancy
in
many
many
different
ways
like
namespace
or
customer
or
whatever
so
camille.
Actually,
he
and
I
were
chatting-
and
he
put
it
in
a
way
that
I
need
to
add
to
that
write-up,
which
is
a
project.
A
We
can
take
into
account
wanting
to
balance
the
charts
for
performance,
but
we
can
also
say
well:
this
project
belongs
to
this
namespace
or
this
user.
So
these
are
the
shards
that
service
that
namespace
in
that
user,
so
think
of
it
as
tenancy
in
a
kind
of
a
virtual
lens,
where
we're
not
building
walls
right
off
the
the
at
the
beginning.
A
We're
just
saying
if
these
shards
are
for
this,
this
customer
we're
going
to
make
that
decision
way
up
in
the
stack,
but
as
it
traverses
down
then
they're
going
to
land
on
the
right
places,
and
then
we
can
have
disalignment
from
you
know
from
getaly
to
the
database
to
the
top
of
the
stack
that
allows
us
to
say
yeah
we
can
do
you
know
we
can
put
your
name
space
in
a
specific
place
or
we
can
have
you
as
a
customer
that
has
this
dedicated
infrastructure.
A
So
you
know
if
you
have
comments
on
the
on
the
write
up,
which
I
hope
sort
of
explains
this
thing
that
I
just
mumbled
out.
Let
me
know
if
that
actually
makes
sense
on
how
we
can
actually
achieve
your
goals,
doing
this
and
still
remain
very
scalable
and
highly
balanced
on
the
back
end.
D
If
you
do
the
database
per
project,
how
do
I
get
analytics
over
multiple
projects?
Do
I
now
have
to
query
multiple
databases?
How
does
that
work?
If
I
do
search
across
multiple,
if
I
have
multiple
tendencies
like
aggregating,
that
search
is
super
hard
because,
like
elasticsearch
cannot
make
the
weight,
so
you
get
the
output
of
elasticsearch
and
you
have
to
right
get
that
together
at
the
application
layer,
which
is
not
going
to
be
as
good
as
so.
Those
are.
Those
are
those
are
the
problems
I'd
like
to
see
addressed
in
these
proposals.
Yeah.
A
A
But
this
is
in
the
in
the
write-ups
in
the
blueprints
we
talk
about
the
caps
url
and
we're
starting
to
we're
going
to
bump
our
heads
into
it,
so
you
may
not
be
able
to
get
the
analytics
right
away,
but
you
can
get
them
eventually,
and
so
this
is
where
we
start
choosing
what
is
important
to
us
that
this
query
returns
immediately,
which
is
true
for
some
queries
or
that
this
query
is
slightly
delayed
but
more
accurate.
A
D
Yeah,
I
don't
like
how
much
we're
on
the
theory
and
how
little
we
are
on
the
practice
here.
I
agree
kept
theorem
like
who
cares
like
we
have
just
a
database
on
gitlab.com
that
we
need
to
shard
across
10
database
servers,
plus
we
have
some
customers
who
want
to
make
sure
that
their
data
never
leaves
the
eu
that's
what
we
have
to
solve
and
the
capital
theorem
tells
you
like.
D
Everything,
has
a
disadvantage,
and
I
know
of
one
of
our
main
competitors.
That
is
having
like
a
lot
of
trouble
right
now,
because
they've
done
the
ultimate
thing
and
the
theoretical
thing,
and
you
know
what
the
applications
are:
dock
slow
right
now
they
are
unusable
and
all
their
customers
are
complaining.
D
So,
oh,
it
will
work,
but
it's
just
a
little
bit
slower
that
that
can
be
like
a
company
ending
thing.
Company
ending
is
a
bit
stark,
but
that
can
be
like
a
huge
problem
for
multiple
years.
So,
let's
not
do.
Let's
not
overdo
it.
Let's
do
what
we
need
to
do
to
to
make
it
lab.com
scale
to
10
million
people,
which
is
the
the
goal
of
this
working
group.
D
But
if
we
do
more
than
that,
we
have
to
be
sure
that
it
doesn't
come
with
disadvantages
and
if
that
disadvantage
is
speed
and
latency,
that's
a
big
thing
and
github
is
still
faster
than
us,
and
we've
seen
that
some
competitors,
what
happens
if
you
overdo
it.
So
let's
not
make
that
same
mistake
and
I'm
I'm
very
worried
if
we're
starting
to
go
through
so
practical.
A
I
like
to
believe
that
I'm
a
very
practical
engineer
that
doesn't
mean
that
I
discard
theorems
or
whatever
they're
called
the
whole
idea
of
a
cap
theorem
here,
is
that
we're
smart
about
things
not
that
we
just
wave
the
flag
of
hey.
I
read
about
the
caption
and
it's
great
my
point
here
is
when
we're
making
decisions.
We
should
understand
what
the
trade-offs
are.
That's
simply
what
it
is
and
that
there
is
some
engineering
and
science
behind
them.
A
It
doesn't
mean
that
I
want
to
build
some
random,
perfect
thing,
but
I
do
want
people
to
understand
that
as
we're
making
these
decisions,
some
queries
are
going
to
be
faster.
Some
are
going
to
be
slower
and
on
those
that
are
slower.
There
are
ways
to
get
around
that,
but
we
should
walk
into
the
query,
understanding
that
it's
going
to
be
slower,
because
what
I'm
trying
to
avoid
is
for
us
to
walk
into
building
this
thing
and
not
understanding
what
we're
building
and
just
saying,
gosh.
It's
slower.
A
Let's
all
rally
together
to
make
this
query
faster.
That's
not
that's
being
reactive!
So
I'm
trying
to
just
say
when
we're
thinking
about
hey,
we
need
to
solve
this
analytics
problem
that
you
just
brought
up.
Well,
what
do
we
understand
about
the
problem
and
how
are
we
going
to
get
around
it?
So
maybe
we
need
to
add
some
cash
in
or
maybe
we
need
to
do
these
things.
So
it's
not
like
everything
I'm
going
to
write
is
going
to
be
the
caption
says,
but
it
is.
A
It
is
something
that
sort
of
I
want
to
have
some
guidance
on
how
we
solve
the
problems,
and
I
I
want
people
to
understand
that
today,
all
queries
are
nearly
instantaneous
for
some
value
of
instantaneous,
because
it's
a
single
instance,
but
as
soon
as
we
have
multiple
instances
per
project
per
name
space
per
whatever
you
want
that
changes,
and
we
just
need
to
have
some
awareness
about
this.
So
I
am
fully
with
you.
A
I
don't
intend
to
build
a
time
machine,
but
I
do
need
some
guidance
to
understand
that
how
we're
going
to
work
around
it
so
I'll
do
my
best
to
to
be
very
practical
and
very
pragmatic
and
ensure
that
we're
building
the
right
thing
and
that
we're
doing
it.
You
know
we're
doing
iterations
and
we're
trying
to
produce.
But
it's
not
going
to
be
just
writing
code.
D
No,
no
look.
I
want
this
solved
more
than
anyone
and
look.
This
is
the
second
working
group.
This
is
one
and
a
half
years
that
we
could
have
had
to
to
get
this
right
and
we've
we've
now
we're
now
with
our
back
against
the
wall,
because
we
have
to
get
this
done
fast.
On
the
other
hand,
it's
a
very
important
decision
and
if
you
say
look,
some
things
are
now
instantaneous
and
they're
going
to
be
slower.
I'm
very
worried
about
that
because
I
don't
think
we
need
to
start
a
database
for
a
project.
D
E
It
I
think,
like
there
is
like
a
lot
of
sides
to
that.
E
I
probably
like
the
most
important
aspect
from
my
site
is
like,
like
the
blueprint
that
gary
is
right
now
working
on
it
kind
of
like
makes
it
possible
to
put
us
on
the
same
understanding
of
the
problem,
but,
to
be
honest,
I
kind
of
expected,
like
we're
gonna
hit,
so
many
that
ends
with
the
solutions
that
we're
gonna
be
testing,
that
there
is
no
really
like
work
where,
like
a
way
around
of
like
testing
these
different
things
and,
to
be
honest,
like
we
actually
gonna,
be
starting.
E
The
engineering
work
like
next
week,
because
they're
gonna
be
additional
people
joining,
and
I
asked
them
that
really
like
the
first
thing
that
we're
gonna
start
doing
like
we're.
Gonna
start
running
github.com
database
in
like
in
different
ways
in
a
sort
of
way
and
see
like
how
many
of
these
things
are
broken
and
how
many
things
would
we
would
have
to
fix
like
in
these
different
scenarios,
because,
like
now,
it's
like
a
lot
of
theory
and
like
in
the
practice.
E
Some
of
these
things,
I'm
not
sure
like
if
they're
gonna
be
working
properly,
so
I
think,
like
the
way
to
quickly
iterate
on
that
is
really
like
get
like
this
kind
of
fundamental
thinking
about
the
problem
to
be
like
shared
between
us.
But
then
we
like
start
testing.
These
different
approaches,
which
is
like
we're
gonna,
be
probably
testing
like
per
name
space.
We're
gonna,
be
testing
per
project.
E
We're
gonna
be
testing
how
we
can
move
this
data
freely,
what
impacts
it's
gonna
have
to
pick
actually
the
one
that
is
the
rest
of
the
resistance
and
the
fastest
really
like
to
to
implement,
because
gitlab
is
built
about
like
this
kind
of
single
database
in
mind,
and
it's
gonna
take
a
lot
of
tinkering
to
like
really
disconnect
this
kind
of
thinking.
E
So
I'm
like
personally,
I'm
not
sure
like
which
one
of
this
way
it's
gonna
be
like
the
most
efficient
to
do
even
now,
I'm
just
kind
of
know
that
we
need
to
test
them
and
we
need
to
test
them
like
very
quickly
and
now.
I
know
that
like
if
I
start
working
with
the
people
that
are
going
to
be
joining
the
team
like
next
week,
the
gary
work
actually
gonna
be
helpful
to
keep
them
on
the
same
page
for
like
what
we
want
to
achieve.
E
As
for
the
guarantees
that
we
want
to
offer,
that's
that's
kind
of.
I
think
my
perception
about
how
we
should
approach
is
like
way
of
doing
that.
D
Yeah,
I
think
it's
really
important
to
me
that
we
keep
the
two
two
options
open.
So
I'm,
okay
with
the
proposal
that
is
as
jerry
wants
to
make
it,
but
I
also
want
to
see
the
proposal
or
the
alternative
to
shard
the
database
per
top
level
name
space
and
then
probably
red
is
an
elastic
search
as
well.
I
think
those
are
two
that's
a
major
decision
and
I
want
to
see
the
the
pros
and
cons
of
both
and
I
think
we
want
to
keep
our
mind
open.
F
F
So
I
think
what
we,
what
I
would
be
looking
forward
to
is
saying.
Okay,
jerry
has
proposed
this.
We
are
in
agreement
that
we're
going
to
do
this
first
and
then
we
are
actually
going
to
start
like
camilla,
suggested
testing
these
things
out
and
seeing
how
it
works,
but
keeping
our
minds
also
open
if
we
hit
a
role
right
and
we
find
out
that
it
doesn't
work
that
we're
able
to
you
know
to
iterate
on
that
and
move
forward,
because
I
think,
there's
still
also
a
lot
of
things
that
are
not
quite
known.
F
D
We've
been
working
on
this
for
one
and
a
half
years,
and
and
both
proposals
that
we're
discussing
in
this
meeting
have
been
made
over
the
weekend
like
it.
It
feels
it
feels
like
we're
starting
from
scratch,
even
though
there's
been
all
this
time
spent.
So
I'm
a
bit
puzzled
by
that,
thanks
for
the
propose
of
fabian,
I
think
that
is
great.
D
I'm
sold
after
camille
on
the
gita
issue,
beeper
project,
I
think
someone
was.
D
B
B
Is
yeah?
I
I
linked
the
issue
about
the
upper
discussion
here
and
highly
too
happy
to
collaborate
and
communicate,
maybe
asynchronously.
I
know
this
is
the
the
database
starting
working
group.
F
Sid,
this
is
fabian
again
I
linked
an
issue.
I
just
wanted
to
say
that
I
think
there's
actually
a
lot
of
work
that
was
done.
It
is
a
little
bit
scattered
across
quite
a
bit
of
items
and
handbook
entries.
I
think
so
these
proposals,
as
far
as
I
can
tell
I've,
also
I'm
relatively
new
to
this
there's
been
a
lot
of
prior
art
on
it.
F
But
I
think
the
challenge
that
we
have
here
is
to
synthesize
this
information,
and
I
think
jerry
did
a
great
job
on
that
and
saying:
okay,
let's,
let's
take
it
and
move
forward,
but
I
I've
spent
a
few
days
reading
through
a
lot
of
like
deep
thought
on
many
of
those
things.
So
I
think
people
have
experimented,
but
I
I
think
it's
important
to
also
find
sort
of
an
exit
point
and
say:
okay,
this
is
sort
of
proposal,
a
let's,
let's
try
and
iterate
on
it
and
see
what
walls
we
hit.
D
Thanks
for
that,
I'm
looking
at
shard
and
gitlab
by
root
namespace,
I
I'm
puzzled
even
by
the
name
like
the
root
namespace,
there's
one
root
name,
space
right,
that
is,
that
was
going
to
be
kind
of
our
our
workspace
people
use
root,
name,
space
and
workspace
interchangeably.
The
other
thing
that
I
think
people
mean
when
they
say
roots
space
here
means
top
level
namespace.
C
You're
right
that
that
relates
back
to
what
we
wrote
a
year
ago,
I
think-
and
at
that
time
we
were
talking
about
namespace,
but
that
has
changed.
I
guess
over
time.
D
I
okay,
I'm
there's
like
many
different
proposals,
many
different
things
and-
and
I
think
even
the
even
the
most
recent
proposals-
don't
have
a
clear
articulation
of
like
this
is.
D
E
A
F
A
Yeah-
and
you
know
to
add
to
that,
the
the
team
that
is
going
to
be
focusing
on
this
is
starting
to
be
constituted
this
week.
So
camille
is
already
starting
to
think
about
this,
essentially
full-time.
D
I'm
sold
on
italy
being
project,
I'm
not
sold
on
redis
elasticsearch
and
the
database
or
project.
I
think
it
should
be
for
top
level
name
space,
but
I
think
we
should.
We
should
just
it's
a
big
decision,
so
we
should
have
we
should.
We
should
have
that
trade-off
clear
and
that
should
include
like
what
is
the
percentage
of
queries.
How
much
slower
will
they
be,
but
also
the
the
advantages
of
sharding
per
project
like
how?
How
much
easier
is
it
to
move
et
cetera.
A
A
D
C
A
G
I've
yeah
I've.
Actually
we
have
a
few
architectural
issues
from
the
rapid
actions
recently.
So
I'm
just
I
just
created
a
search
here,
so
we
can
probably
investigate
whether
they
fit
into
one
of
our
work
work
tracks
like
the
data
patterns.
G
One
of
those
may
be
a
good
place
to
hold
this
items
there
so
just
to
bring
up
two
attention,
then
the
the
dris
from
the
work
tracks
from
the
data
patterns
research
can
take
a
look
and
consider
if
any
of
those
issues
will
fit
into
one
of
our
data
patterns
to
to
work
on
here.
Otherwise,
we
may
find
a
another
solution
here
to
host
this.
At
these
issues.
F
You
vocalize
key
very
quickly
if
you
want
to
read
something
really
interesting.
The
paper
linked
here
is
about
the
bias
of
people
to
solve
problems
by
adding
new
things
rather
than
by
removing
them,
and
I
was
just
wondering
in
a
general
sort
of
scalability
discussion
if
there
are
opportunities
in
gitlab
to
just
remove
certain
things
from
the
database
or
at
other
points,
to
make
scaling
easier,
it's
more
of
a
thought,
provoking
provocation.
F
Whatever
the
english
word
is,
go
read
it
it's
cool.