►
From YouTube: How we test NebulaGraph
Description
Jingchun Xia, Head of QA & DE talked about how we test NebulaGraph this time.
A
That
section
today,
we'll
have
a
topic
brought
from
attention
and
he
will
introduce
a
whole
view
of
how
we
will
do
the
tests
in
multiple
layers
and
perspectives
in
the
team
of
Neville
graph.
And
finally,
we
will
have
the
open
floors
so,
and
this
is
way
you
you
are
you
always
see
me
in
this
meeting
and
maybe
I
see
John
is
is
on
the
line
so
John.
Could
you
help
introduce
yourself
and
later
jinxing
will
introduce
himself
with
the
slides.
A
A
So
with
this
change,
we
bring
the
the
semantic
to
the
the
native
and
ngql,
so
you
can
unwind
a
list
so
transpose
it
to
a
transport
States
this
this
vector,
like
with
the
pipeline.
You
can
put
all
the
items
of
this
a
real
vector
and
do
query
in
in
next
and
in
next
step
after
the
pipeline,
so
I
recommend
to
check
check
the
the
pr.
There
are
some
examples
and
there
are
some
tests
in
this
code
either
the
quotient
description
of
the
of
the
pr.
A
A
A
A
So
apart
from
the
core
part,
we
one
of
the
news
is
last
week
in
last
few
days,
we
announced
another
front-end
infrastructure
projects
to
be
open
source.
It's
called
The
Never
graph,
we
editor,
so
it's
actually
a
library
that
we
underneath
use
the
to
construct
our
a
preparatory
offering
called
Neighbor
graph
Explorer.
So
it's
the
things
this
Project's
doing
is
to
render
like
diagramming
and
some
other
things
I'm,
not
a
expert
in
front
end.
A
So
if
you're
interested
to
check
out
just
check
out
this
report,
Repository
we
our
studio,
comes
to
3.4.1
with
some
major.
The
major
change
are
the
connection
session
handling
in
the
back
end
of
the
studio
and
the
the
two
brown
shades
of
dashboard
are
upgraded.
I
have
a
new
release,
so
they
for
the
V3
Branch.
It
comes
with
more
newly
introduced
metrics
to
be
to
be
managed
and
shown
in
in
the
dashboard.
A
There
are
some
of
the,
so
these
are
the
fixed
pictures.
So
we
invite
many
of
our
friends
and
families
members
here.
So
we
have
a
quite
good
party
and
I
want
to
quickly
go
through
some
of
our
projects,
so
maybe
in
the
future
we
can
put
them
on
on
the
main
branch.
One
thing
is
the
first
one
is
our
about
network
of
academies.
A
Not
all
the
teams
are
r
d
teams,
so
they
will
introduce
a
LinkedIn
patch
systems
for
our
internal
of
for
all
the
naval
graph
related
certification.
So
please
stay
tuned.
We
will
have
a
couple
of
certifications
to
be
released.
There
will
be
some
courses
and
afterwards
you
will
have
a
LinkedIn
badges,
so
you
can
share
it
on
a
profile.
Another
one
is
created
by
one
of
contributors
in
our
test
team,
so
he
shared
she
made.
A
Another
thing
is,
though,
I
was
involved
in
the
team
that
we
made
some
talks
and
Integrations
between
Network
graph
and
the
djl,
which
is
a
deep
graph
learning
deep
graph
Library.
So
it's
pretty
cool
another
one
is
called
Naval
graph
merak.
So
basically
they
implement
the
the
vector
search
in
ambergraph.
A
C
It's
about
60
billion
nodes
and
350
billion
edges
for
to
our
use
cases
covering
and
currently
we
are
started
with
the
testing
of
nebula
3.2
and
yeah
preparing
a
new
production
cluster
for
that
testing
cluster
is
operational
and
working
synchronizing
data
and
everything
works.
Fine.
It's
I
had
some
issues
with
the
importing
history
data,
but
I
will
try
to
resolve
that
and
build
report
on
community
Pages
somewhere
yeah.
C
A
C
A
B
B
Course,
because
I'm
still
working
on
this,
let's
start
with
that
I
was
like
okay
yeah.
So
here's
the
topic,
my
name
is
Jin
Chun.
This
is
my
my
email,
and
this
is
what
I
want
to
share
today,
starting
from
introducing
myself
and
a
little
bit
about
the
you
know
the
overview
of
the
testing
landscape
in
the
paragraph
and
dive
into
some
of
the
areas
and
finally,
we'll
talk
about
some
future
work.
B
You
can
find
the
path
from
me
to
this
community
because
I'm
currently
leading
the
group
of
qand,
which
means
quality,
engineering
and
delivery,
is
really
soft.
Of
course,
we
we
are
the
company
behind
the
network
graph
and
runs
this
community
and
I'm
actually
I've
been
in
the
software
industry.
For
already
more
than
20
years,
okay
and
prior
to
vsoft
I
spent
more
than
10
years
working
as
a
group
leader
of
a
product
for
the
air
mqc
or
quality
Center.
B
It
may
ring
a
bell
if
you
are
familiar
with
the
testing
business,
because
these
names
are
once
very
famous
in
the
industry,
and
so
microfocus
is
now
on
these
three
products:
a
clothes
runner
for
the
load,
testing
and
UFT.
For
the
automated
functional
testing-
and
you
know
they
came
from
HP
software
by
a
big
m.
A
so
I
did
have
some
experience
in
the
testing
business.
Okay.
So
that's
why
I
came
to
this
role
as
well.
B
So
in
my
team
we
are
not
a
very
big
one,
but
really
we
have
a
lot
of
talented
I
put
a
label
here,
excellent.
He
members
I
think
we
already
mentioned
one
about
the
gql
fuzzer
right
in
in
hacked
on
this.
You
know
came
from
it,
so
all
the
stuffs
I'm
going
to
share
the
Great
Stuff,
it's
them
who
made
it
happen.
B
I
have
to
say
so,
take
a
look
at
this
graph
from
bottom
up
and
there
are
all
these
kind
of
test
types
like
unit
test,
functional
stability,
performance
and,
of
course,
security.
So
the
unit
test,
we
mainly
run
it
in
the
GitHub
actions,
because
we,
you
know,
we
use
GitHub
a
lot
and
we
developed
our
own
platform
called
ngtp,
enable
graph
testing
platform
to
support
the
functional
the
automated
functional
testing,
including
some
long-running
ldbc
SMB.
B
You
know
good
for
us
to
do
the
penetration
testing
mainly
for
the
vulnerability
scan
so
from
left
to
right,
is
the
frequencies
how
we
run
all
the
tests,
so
in
here
from
the
you
know,
the
left
leftmost
is
that
upon
each
PR,
the
pull
request
in
GitHub
will
run
the
unit
test,
including
the
Google
test,
payroll
test
and
also
some
PCP
test
case.
I
will
dive
into
the
details
in
a
minute:
okay,
so
every
night,
every
night
we
we
run
also
this
unit
test
and
all
this
stuff's
like
functional
testing.
B
Okay,
so
well,
of
course,
for
this,
this
testing
these
test
cases
we
use
a
rather
relatively
smaller
data,
sets
to
make
it
great
and
for
the
weekly,
this
is
something
already
still
in
progress,
I
have
to
say,
but
we
plan
to
run
this.
These
cases,
as
I
put
I,
showed
here,
the
stability
and
the
the
functional
part
against
a
larger
or
much
larger
data
set
like
one
terabyte
and
more
to
test
the
the
you
know
the
database
so
for
every
single
release.
B
Candidates
will
run
all
these
tests
so
and
of
course,
the
regression
cycle
is
important,
like
the
new
features
are
tested
along
the
release
development
and
at
the
end,
we
will
run
the
regression
test,
which
is
also,
you
know
automated
or
will
be
automated
in
the
nttp
OR
platform,
and
apart
from
The
Benchmark,
we
will
also
run
a
scripts
testing.
You
know
we
try
to
boost
the
concurrency
to
like
10,
000
or
20.
000
is
much
to
really
test
the
extreme
of
the
limit
of
on
a
cluster.
B
B
The
most
popular
test
framework
for
C,
plus
plus
Developers
py
test
in
Python,
is
something
in
the
middle
I
would
say:
some
developers
write
this
test,
so
it's
around
50,
and
so
it's
not
so
popular
even
inside
the
company,
even
inside
we
served
and
the
last
one
is
what
we
call
TCP.
This
is
something
we
borrowed
from
neo4j.
Okay,
we
took
to
the
the
good
ones
and
it
stands
for
technology
capability,
kit,
okay,
so
the
beauty
of
it
is
that
you
only
need
to
write
this
gherkin
features.
B
If
you
are
familiar
with
the
ability,
Behavior
driven
development,
turkey
is
the
the
language
actually
the
most
popular
language.
For
bdd,
so
in
in
never
graph,
you
can
write
simple
feature
files.
Like
this
example,
you
give
a
background.
Let's
say
a
space
named
MBA,
okay,
and
then
you
define
the
scenarios
with
all
the
test
steps.
You
give
a
an
action
like
this.
One
executes
one
step
right,
one
step
from
Tim
Duncan
over
serve,
and
then
you
you
just
write
the
expectations
in
the
then
across.
B
So
it's
quite
simple,
not
only
developers
can
do
it,
of
course,
testers
or
our
document
team
and
our
UI
testers.
For
example,
we
have
a
product
called
the
nebler
Explorer,
which
is
for
Enterprise
only,
and
it
of
course
runs
a
lot
of
queries
right
so
the
way
to
make
it
always
compatible.
We
also
add
it
to
the
tck
Tesla,
Suite,
okay,
so
and
I
know
we
have
a
documentation
and
to
introduce
this
and
it's
open
for
the
community
to
contribute.
Okay,
and
next
is
the
the
main
part.
B
Ngdp
stands
for
Network
graph
testing
platform,
let's
start
from
how
the
tests
are
organized
in
level
and
in
nttp,
so
every
test
cases
or
every
test
case
is
a
Double
Image.
Okay,
so
it's
implemented
in
a
darker
image
and
a
suite
a
test
Suite.
Actually
it's
a
group
of
test
cases
for
sure
and
it
defines
the
target
version
of
a
neighbor
graph,
whether
it's
a
branch
or
a
commitment
ID
or
some
release
package.
Okay.
So
this
is
the
target
to
test
and
it
can
also
configure
the
cluster
of
network
graph.
B
You
want
you
want
to
test,
including
a
common
method.
You
want
to
have
from
any
storage
or
gravity,
and
you
can
also
change
the
configurations.
I
mean,
like
you
know,
the
like
for
the
tuning
tuning
part
and
a
test
plan
is
a
a
group
of
test
Suites,
okay,
so
we
we
can
configure
a
test
plan
and
run
it
manually
or
you
know,
trigger
it
by
by
timer,
so
how
the
tests
or
test
Suite
can
be
run
in
GTP,
it's
actually
in
a
pipeline
of
tasks.
This
is
this.
B
B
Then
deploy
it
according
to
the
cluster
compilation,
right
like
how
many
meta
or
how
many
other
services,
and
then
we
will
run
a
data
genetogen
as
the
formation
is
also
included
in
in
a
darker
image.
Okay,
so
for
the
big
data
and
just
mentioned
for
the
weekly
weekly
tests.
Of
course,
we
don't
want
to
generate
the
data
or
even
you
know,
import
the
data
into
the
cluster
each
time.
So
we
do
have
a
very
good
solution
to
you
know.
We
have
some
already
generated
very
big
data.
Let's
say:
ldbc
sf1000,
okay.
B
This
is
like
one
terabyte
with
the
three
replicas
and
when
the
mttp
pick
this
step,
we
can
simply
make
a
hard
link,
okay
to
to
link
the
network
graph
cluster
to
the
already
existing
data.
So
it's
like
in
seconds.
Okay.
So
then,
next
we'll
run
the
docker
image.
Okay
defined
in
the
in
the
test,
switch
to
run
the
real
test
against
the
nebula
cluster.
You
define
and
also
the
data
set.
B
You
choose
all
right
and
then
lastly,
it
will
give
a
report
and
if
everything
works,
okay,
I
mean
the
test
passed
and
the
the
resources
will
be
released.
Okay,
but
you
know
when
a
test
is
failed,
we
would
like
to
keep
keep
the
resource
so
that
our
test
has
testers
can
do
some
checks.
Okay,
so
put
it
all
together.
This
is
the
the
architecture
of
ngtp,
so
everything
everything
is
inside
a
large
kubernetes
cluster.
B
Behind
the
scenes
we
have
a
dozen
of
powerful
physical
servers
and
starting
from
the
website,
the
web
UI
or
from
GTP,
is
developed
in
Python,
using
the
Django
framework
and
also
the
pipelines.
We
use
the
tactone
something
called
tecton,
it's
actually
a
popular
cicd
framework
for
kubernetes,
okay.
So
of
course
we
can
also
integrate
the
dashboard
of
attack,
tone
and
the
kubernetes
dashboard
itself.
B
So
all
the
tests
with
runs
okay,
so
we
see
already
a
test
case
is
run
inside
a
path
or
a
container,
and
also
the
network
clusters
are
running
also
in
in
containers.
Okay,
so
on
the
right
side,
we
use
gray
lock
to
be
our
log
Center.
This
is
something
and
still
in
progress
to
collect
all
the
logs.
It
can
be
logs
from
the
nebular
cluster
and
also
locks
from
the
tecton
pipeline
execution,
and
we
also
have
these
parameters
and
the
grafana
steps
to
monitor
the
nebular
cluster.
Okay.
So
that's
basically
how
it
works.
B
One
thing
to
mention
how
we
develop
a
test
cases
in
nttp.
There
are
three
layers:
okay,
the
top
two
we
developed
a
framework
called
a
knife.
It's
based
on
the
jingle
test
framework,
which
is
the
most
popular
testing
framework
for
Golan
gold,
language
Okay.
So
the
first
layer
is
the
most
simple
one
you
can
write
again
in
a
gherkin.
We
love
cooking
a
lot.
We,
you
can
also
write
in
13
language
to
test
some
queries.
Let's
say
in
certain
scenarios:
okay,
especially
those
from
the
customers.
B
I
just
already
showed
you
before,
and
so
the
second
level
is
that
you
can
write
tests
in
Gola
language,
okay,
so
this
is
like
purely
from
the
jinko
framework,
but
with
the
with
the
support
like
say
the
graph
kinds,
sessions
or
connections
to
never
graph.
So
this
the
knife
trimmer,
can
only
work
with
the
graph
current
you
know
through
sessions.
B
This
is
how
it
works,
and
the
last
layer
is
what
we
call
native,
so
you
can
write
in
any
language
to
test
the
most
complicated
functionalities,
to
just
give
me
a
darker
image
and
a
command
line,
how
to
trigger
the
test
inside
it.
Okay,
so
like
we
developed
a
lot
of
like
stability
testing,
to
do,
let's
say
the
scaling
or
disaster
to
recovery
and
so
on.
So
this
is
the
knife
and
I
also
introduced,
of
course,
the
stability
testing
written
in
a
native
document,
so
on
the
left
side,
is
our
chaos.
B
Engineering
stack.
Of
course
chaos.
Mesh
is
the
okay
most
famous
one
in
the
kubernetes
world,
but
we
use
it
to
to
stimulate
like
this
guy
all
fours
and
we
plan
to
use
it
for
also
to
simulate
some
Linux
kernel
thoughts,
but
they
found
it
not
so
well
fit
to
neighbor
graph
scenario,
especially
in
this.
In
this
kind
of
cases,
let's
say
the
network,
partitioning
Network,
delay
or
packet
loss
and
also
do
some
between
load
testing
on
the
apis.
So
with
the
developed,
our
own
component
called
a
never
ladder.
Okay,
so
this
comes
from.
B
This
name
comes
from
the
let's
say:
like
chaos
is
a
ladder.
It's
not
that
thing.
It's
a
letter
to
for
help.
I
mean
to
help
us
to
go
up
right
for
the
nebula
is
to
help
us
be
more
strong.
More
stable
on
the
right
side
is
the
first
test
in
that.
So
you
already
mentioned
this
is
a
G4
father
that
it
can
basically
connect
to
a
network
graph
with
the
schema
and
use
the
you
know,
the
the
parts,
the
grammar
and
try
and
generates
like
various
NG
code
queries.
B
So
the
purpose
is,
of
course
it
never
graphs,
don't
ever
crash.
So
this
is
the
purpose
of
the
stability
testing
yeah
and
let's
move
to
a
meter,
so
some
very
basic
concepts,
so
I
mean
it's.
You
you'll
find
you'll,
find
it
familiar
with
the
ngtp,
so
we
also
have
has
the
test
cases,
but
this
time
it's
only
only
on
June
code.
Okay
and
a
suite
contains
the
multiple
tester
case
for
sure
and
in
the
suite
you
can
specify
the
version
to
test
okay
and
also
configure
the
customer.
B
B
Then
you
can
execute
the
test
in
a
meter
given
a
certain
number
of
virtual
use,
which
is
the
actually
the
concurrent
users
right
and
the
test
results
includes
the
QPS
of
this
scenario,
the
latency
and
the
response
time,
and
this
result
can
be
saved
as
a
baseline.
You
know
for
later
use
for,
like
every
diet,
every
night
we
run
the
test,
also
compare
it
to
a
already
released
version
as
a
baseline,
so
we
will
know
whether
or
not
we
got
to
improved
or
you
know,
some
degradation
of
the
performance.
B
So
this
is
how
it
look
like
on
the
architecture
perspective,
so
we
developed
a
unmetal
web
application
to
manage
all
this.
Okay,
the
the
tested
cases
and
switch
and
behind
the
scenes
I
mean
on
the
back
back
end.
There
is
a
master
node
to
keep
all
the
job
in
a
queue
and
you
can
have
multiple
workers
to
build
the,
never
binary
and
deploy
the
cluster
and
import
data
when
necessary.
And
of
course,
you
run
the
test.
B
B
So
the
test
results
is
like
this.
You
have
the
QPS,
as
I
already
mentioned,
the
latency
with
the
you
know,
P90
or
P99
as
well,
and
the
loops
responsible
response
time
and
also
gives
the
the
row
size
of
you
know
the
query,
and
this
this
one
is
the
the
comparison
of
the
Baseline.
So
we
can
easily
tell
whether
this
version
we
3.1,
is
good,
it's
better
than
the
baseline
or
Worse
okay.
So
this
is
how
it
works
and
again
the
goal
is
to
make
a
network
graph
faster
and
faster
okay.
B
So,
lastly,
some
future
work
we
plan
to
do.
Of
course,
we
are
happy
to
get
more
and
more
tester
cases
into
mgtp
and
I
believe
in
Visa.
Everyone
can
contribute,
it
contribute
to
it,
and
we
also
hope
our
community
can
contribute
to
it.
The
more
cases
we
have,
the
better
you
know,
Network
graph
will
be,
and
you
already
noticed
a
meter
has
some
similarities
with
the
ngtp.
So
in
the
future
we
would
like
to
containerize
a
meter
and
integrate
it
into
like
ngtp.
B
That's
the
one
single
platform
and
we
hope
also
have
more
data
set
and
like
various
scenarios
for
a
meter,
and
so
the
result
can
be,
you
know
referenced
not
only
for
the
Social
Network.
Okay
and
you
know
we
have
already
Cloud
offerings
our
dbas
system.
So
in
future
we
can
also
run
the
nttp
or
even
meter
for
the
cloud
you
know
and
TPP
is
basically
a
cloud
native
solution
and
we
just
started
on
the
Securities
diet
and
we
will
spend
more
time
or
more
investment
on
this.
B
Lastly,
don't
forget
manual
testing,
you
know
it
always
exists,
so
we
are
about
to
launch
this
this
tool.
It's
also
a
test
management
tool:
okay,
guys
we'll
just
just
put
all
our
test
cases
into
this
management
system,
okay
and
it
will
be
integrated
to
our
CI
system
and
also
our
ngtp
to
get
the
automated
testing
result.
You
know
like
all
in
one
we
will
have
a
whole
picture
of
the
quality
of
nebulograph,
because
that's
it
and
cannot
cut
in
the
line.
I
hope,
okay,.
A
Yeah,
thank
you.
So
much
I
have
a
high
expectation,
but
still
I'm
surprised,
I'm.
Amazed,
it's
is
is
fantastic.
Thank
you
and
the
ngtp
I'm
surprised
that
we
use
a
lot
of
state
of
art
Solutions.
We
didn't
choose
the
easy
way.
So
it's
it's
awesome.
The
the
most
careers
for
for
me
is
the
the
latter
or
elaborate
I.
Don't
I,
don't
recall.
B
It's
not
it's
not
open
sourced,
yet
I
think
maybe
you
know
it's
got
the
potential
to
be
open
source,
not
necessarily
like
very
specific
to
nebulograph.
That's
my
understanding.
Okay,
so
I
will
check,
but
you
know
the
network
petitioning
and
this
stuff,
it's
kind
of
you
know.
We
like
we
add
something.
You
know
more
suitable
for
neprograph
that
that's
the
idea.
A
B
A
B
Yeah,
you
know
a
similar
question
so
but
I
think
it's
a
good
one.
We
had
some
discussions
before,
but
you
know
we
have
the
community
edition
of
nebrograph,
but
we
also
have
the
Enterprise
Edition
right.
So
at
the
point
at
the
point,
the
the
platforms
and-
and
you
know,
the
tools
are
many
for
the
Enterprise.
Of
course
we
run
the
test
against
the
Community
Edition
as
well,
but
every
every
day,
and
so
it
may
have
some
features
not
not
available
to
the
community.
B
A
B
C
B
C
C
Much
simple
to
scale
yeah
because
we
have
enough
machines
and-
and
you
know,
with
the
docker
or
anything
else
with
a
virtualization-
you
can
produce
as
many
workers
as
you
need
to
to
load
data.
If
you
have
shared
storage
or
something
it's
very
easy.
So
that's
that's
the
way
we
are
using
it
and
usually,
when
I
test
new
version
or
anything
trying
to
to
make
more
stable
or
seed
the
limits.
C
C
Currently,
we
have
four
nodes
testing
cluster
which
use
common
Hardware,
but
it
is
actually
very
good.
Hardware
I,
don't
know
64
cores
machines
with
the
half
terabyte
Ram
and
a
few
ssds,
for
example.
I,
don't
know.
Maybe
6X
is
this
with
a
few
terabytes
of
not
few
few
thousand
terabytes
of
disk
and
our
production
system
have
almost
300
terabytes
of
nvme
disks
and
yeah
I'm,
trying
to
to
see
how
much
power
I
can
squeeze
for
for
that
Hardware,
yeah
and.
C
B
B
B
C
Yeah,
the
performance
is
crucial
part
here,
because
you
know
when
you
have
a
lot
of
data,
it
should
be
performant
in
with
the
limits
of
of
current
technology,
but
nebulize
good
performer
here
and
yeah.
It's
it
works.
Okay.
We
have
a
lot
of,
for
example,
deep,
deep
graphs
for
more
than
50
50
levels,
so
the
scanning
for
one
two
three
levels
is
simple
to
reach
and
it
is
performant.
C
The
parameters
of
the
OS
level
or
something
like
that
or
some
parameters
for
back-end
database
used
so
I
I
think
that
can
be
also
improved.
We
played
with
the
with
some
parameters
for
rocksdb
in
the
back
in
part,
and
that
also
can
be
shown
in
a
transparent
way.
What
are
the
limits?
What
are
what
is
the
best?
Do
you
test
some
parameters,
which
are
large,
for
example,
for
all
system
for
small
system
for
for
huge
grass
with
a
lot
of
nodes,
and
something
like
that?
B
So,
regarding
the
importing
data
importing
performance-
maybe
you
can
you
know
reach
me
in
the
black
Channel.
We
can,
you
know,
have
some
discussion,
so
my
team
has
also
I'm
reading,
also
the
delivery
team
and
we
use
importer
or
exchange
a
lot
in
our
customer
testing,
sometimes
for
the
proof
of
Concepts
and
so
on.
So
we
also
try
to
squeeze
the
performance
to
to
the
best
because
we
need
to
compete
with
other
competitors.
So
maybe
we.
C
Yeah,
it's
very
important
because
you
are
integrating
the
graph
database
platform
to
some
existing
database
systems.
You
have
in
a
company
and
yeah
it's
it's
normal
to
integrate
that
in
some
some
way,
and
you
will
have
also
some
historical
data
to
load
and
a
lot
of
That
So.
Currently,
we
needed
to
load
350
billion
edges
in
a
in
a
nebula
graph
system
and
it
took
40
days
to
load
that
40.
C
Days,
yes,
so
it
is
huge
amount
of
data,
and
you
know
you
you
can
I
can
paralyze
a
lot,
but
at
the
end
we
start
to
to
time
out
and
started
to
introduce
some
problems
with
with
the
timeouts
and
dropping
the
throughput
at
the
end.
So
I
pushed
to
the
Limit
and
stayed
there
for
40
days.
That's
the
approach.
Okay!
Maybe
there
is
some
better
way
to
do
that.
So
I
will
be
glad
to
to
chat
with
you
on
on
a
slack.
A
A
Of
going
through
the
writing
test,
you
generate
the
underlying
file
and
make
a
hard
link
so
that
that
is
awesome.
I
I
celebrated
in
my
mind
and
forgot
about
it
and
then
I
I
come
back
to
my
mind.
So
actually
you
you
did
it
and
you
it's
it's
on
a
local
storage
or
you're
doing
some
centralized
storage
and
you
you
just
make
conquer
construct
how
the
files
lying
under
the
knees
and
the
mounted
it
are
you
using
the
kubernetes
operator
or
your
own
implementation
of
the
kubernetes.
B
But
no,
we
don't
use
operator
yet
all
right,
so
the
story
is
like
we
import
the
data
up
front
Okay,
so
we
have
the
basically
the
The
Meta
or
the
information
for
the
matter,
the
spaces.
Next,
actually,
there
are
more
than
one
spaces
in
this
big
data
data
set.
Okay,
so
you
just
you
know
when
you
create
a
new
of
course,
a
new
cluster
I
think
today
we
need
to
have
the
same
topology
that
way,
the
you
know
the
imported
already
imported
the
data.
B
So
there
are
some
limitations,
okay,
so
it's
simply
like
a
migration
of
a
cluster
from
one
to
another,
but
using
the
hard
link
the
Linux
huddling
way
yeah.
So,
thanks
to
the
you
know,
the
rocksdb
way
I
mean
those
SSP
files.
If
you
are
familiar
with
are
kind
of
read
only
right,
you
don't
need
to
so
so
let's
say
we
run
some
tests.
B
A
B
Different
nodes,
yeah:
it
is
also
possible
yeah
right.
We
we
haven't
done
that
before.
So
you
know
it
requires
a
lot
of
this
space
and
but
yeah
it's
in
theory,
it's
possible
you
just
from
a
central
storage.
You
may
have
links
to
different
clusters
and
different
classes
will
write
to
their
own
like
SCT
files
right
respectively
and
without
touching
the
original
data.
So
we
can
reuse
it
in
a
test
again
and
again.
Okay,.
A
C
Yes,
yeah,
but
it
is
common
practice
to
have
some
links
yeah
to
to
implementation
under
yeah
I
I
had
an
issue
with
the
with
the
enable
exchange
part
it's
using
Hadoop
for
SSD
direct
to
generation.
My
idea
was
to
generate
SSD
files
directly
and
then
import
it
in
a
in
a.
There
is
some
keywords
in
a
in
a
syntax
of
ngql,
so
you
can
you
can
import
SSD
files
directly
in
a
nebula
as
I?
Understand
I
didn't
try
that
because
it
uses
Hadoop
underneath.
B
C
Yeah
we
are,
we
are
using
shared
bgfs
based
storage
system,
which
is
highly
compressed
with
lz4
and
so
to
squeeze
a
little
bit
more
from
from
from
the
storage
part,
and
it
is
a
very
practical
than
to
after
you
generate
those
files.
You
can
copy
that
to
the
local
nvme
disks
and
import
those
SSD
files
in
nebulographs.
C
C
C
I,
don't
know
why
yeah
yeah,
yeah
I
suppose
that
you
are
using
Hadoop
in
a
company.
So
that's
that's
the
reason
why
nebula
exchange
is
set
up
like
that
and
supporting
that.
But
there
is
some
party
in
exchange
which
are
supporting
local
file
system
also
or
some
other
distributed
NFS
or
something
on
the
Linux
so
yeah.
Maybe
it
is
not
hard
to
implement,
also
support
for
for
some
other
distributed
file
system
so
or
or
a
remote
file
system.
Whatever.
A
B
B
A
B
C
Yeah,
maybe
you
know
you
are
familiar
with
New
York
taxi
drivers.
File
with
it
is
also
for
some
analytical
databases,
but
also
can
be
used
in
a
graph
systems.
You
know
driving
around
the
streets
of
New
York
and
this
analyzing
some
shortest
paths
or
some
some
something
like
that.
It
is
a
large
database
and
it
can
be
maybe
better
representing
than
I.
Don't
know,
basketball
players
currently
used,
which
is
a
very,
very
small
data
set.
So
you
you
cannot
cover
with
that.
C
Even
I,
don't
know,
maybe
a
few
partitions
or
whatever
yeah.
It
will
not
populate
enough
data
to
to
cover
I,
don't
know
partition
crash
or
something
like
that.
It
should
be
a
decent
amount
of
data.
It
doesn't
need
to
be
huge,
but
I
don't
know.
A
million
records
is
a
good
starting
point
for
something
I'm,
usually
testing
with
around
10
billion
records
or
any
any
database,
and
most
of
the
modern
databases
are
good
in
dealing
with
10
billion
records.
The
problems
start
with
100
billion.
So
these
days,
okay
and.
C
C
A
C
C
B
C
C
Yeah,
it
is
interactive
and
you
see
the
the
people
behind
the
the
scene
so
and
we
all
have
some
experience
during
the
I
know:
I'm
I'm
involved,
maybe
you're
in
a
half
or
something
with
the
at
least
one
year
with
the
nebula
and
yeah.
A
lot
of
things
happens
during
this
period
of
time,
so
we
should
share
our
experiments,
experience
and
try
to
improve
everything.