Okay. Hi. Good afternoon. My name is Yoshinori Matsunogu. I'm a production engineer at
Meta. So today I'm going to talk about the myrox, myrox study storage engine for my
scale. So I'm using my scale since 2004, so it's over 20 years. So I started using my scale
for 0.0. Then I first worked at Sony, then joined my scale company. After I acquired
my son and all the crew, then I'd have to do some local Japanese gaming company. And since
then I joined Facebook in 2003. And after that I was still working on my scale. And
a couple of years ago, we created rock-stabby, the embedded rock-stabby library, and we integrated
into my scale as a storage engine. So myrox is a rock-stabby storage engine for myrox,
but essentially it's a new storage engine for best and rock-stabby. So rock-stabby itself is also
open source, so that is more active. The activity also created by Meta, that is GitHub.
So the popular open source area, same, log selection, masterly database libraries, and
going to briefly talk about from next slide. The myrox is a log set with engines and the
built-in of my scale. So my regular my scale grants talk to my scale server, and my scale
server areas like the pass-up of the myrox, the replication, these are all the same, not
affected. And the only storage engine like a table is different. And binary distribution is
available from Percon server. And also at Facebook's Meta, so we have it used, this is
so we initially created myrox for the best things, social database, background, we call
at UDD, so it's a Facebook Instagram, social interactions like likes, comments, like live
comments or whatever. So all social activities are still at the end of the background database
called UDDB. And UDDB is very space-based, bound service, and the innovative using quite a
lot of space because of the P3 architecture. So log set is the same, so it is technically
saved more space, so that's why we wanted to migrate. And the first myrox, so there was
several migration attempts like HBs, and they didn't work where, so because my scale is pretty
good database, so the HBs was not so great. So after myrox and that migration finally succeeded,
so now we land the whole UDDB as a myrox, with a rock study data format. And now they
we are trying to migrate as I use cases, like other databases, in set Meta, so we have
many kinds of land database services like similar to Amazon RDS customers. So we are trying
to migrate them, we are hitting several interesting issues, some of them I can share today.
So this is a brief architecture of the rock stable, I'm talking about light pass and build pass,
so this is a light pass, so when light thickness comes to rock stable,
there is a transaction rock called light hydrox, which is equivalent to inner-devilied rock,
transactions committed to log by fast, then the change is kept in memory, which is called
a light memptable. Then all the changes are accumulated in the memptable, and it's not
touching to the back end file called SSD files. So until the memptable gets full, then all the
changes are kept in memory, which means light is very fast, and after memptable gets full,
then the back end ground process called flash happening, and the stretching is memptable
into SSD files, the data file. Then after there are many SSD files, there is another background
process called complexions happening to magic them, these SSD files into more compact ones,
more specific or more efficient for these. So the key architecture difference is light,
all light because it thinks memory, which means no random light, the random needs to regard,
which is very fast, and also the complexion is the SSD file levels, which is more efficient compared
to a bit in a little bit. On the other hand, lead pass is a bit more complex, because there are
many places that data is managed, the vines are SSD files, so if the data is not in memptable,
or broadcast, then the files in SSD files needs to be literally led, and the castings of broadcast.
But also, the user may change in the memptable, since when the memptable needs to
return, then the data is not in the broadcast, so it is still valid. So the process called
much, the magic from a memptable and leading from broadcast, then the magic results and the
returning is the most latest record is a grant, so this step is needed, so this is more expensive
compared to B3. So there is a clear thread of the generic characteristics of the
RSM database, so I am talking about lock study, but it is applied for any other RSM database
architecture like HPS. But the space is much smaller, because that is light optimised and
the space of the device database, so the space is much smaller, light performance is good,
and light using the less CPU and higher light throughput, and that also means the replication
lags, less software, so which is much easier to manage the fighting with the replication lags.
But instead there is a more expensive, especially if you are doing a lot of range of scans,
or deleting lots of records and doing range scans, that is quite expensive. I am going to briefly
talk about data. So from this as overview of the lock study architecture, so from next slide,
I am going to talk about the recent developments we have done in the Myrox and the lock study.
So why part of the first part is a Chrome plugin, so Chrome plugin is, it is a bit
plugin, so it is available in the database of absolutely many areas where, and this is the
great, so we implemented for the Myrox that is where, that is a Myrox plugin, so the main objective
is deprecating the external backup, so the company 300 is a database copy, using the MySQL server,
so the main benefit of the Chrome plugin is, there are several benefits managed by server,
so you don't need external process, but to meet it for metadata, the one of the biggest benefits
you can control the target copy speed with a Chrome plugin, and the speed can be much faster.
So if you use the external backup, the streaming copy, so we used to use that,
then when streaming copies and everything is English read, so if the Myrox speed or if you copy
to a different regions, like from the US, the rest goes to Europe, then that is a very long distance,
so if you copy with single thread, then copy speed 10 to go down, like from one year by
second to two like 10 to 20 megabytes per second, so if you want to copy the database quickly,
then the single thread is often causing problems, but with Chrome plugins, you can set the target
copy speed, then the Chrome plugin spans more stress as needed, then the copying the
massively large data, when needed, using more CPUs, but copy speed is more guarantees, so that means
the copy speed is predictable, that is much easier to operate for us, because you know that
by when the copy is finishing or not, so we are actively using that, so if you're using
it, you know, they really are not compiling it, then that's a pretty useful feature, so I
didn't really recommend for that. The second part is read free replication, so
back is via inspired by this feature from Tokudavit, so that's what's got some attention about
10 years ago, so Tokudavit is already stage the resume database, so that the support is read free
replication, so concept is, it is same database, you can put the data, you have all the previous
record image, you can install the database without reading record, so with robust final log,
the whole primary key of the change in low image is available in the window, so by reading the
window, you can compose all the change APIs that are needed to send to Tokudavit, so you don't
have to read anything from Microsoft database, so default behaviors, when change comes, then
the replication is replicas, read from Tokudavit by primary key to change which record is changed,
then composing a log save API called delete or put to send the action, log save API calls,
then changing that, so that involves the primary key record, that is not a zero cost, so if there
are massive updates from the primary instance, then the random reads overhead is getting problems,
and sometimes they're replicas, but it is read free replication, so you can see the all changes
in the window, so you can just compose a log save API, that doesn't have any random reads,
so we have this feature, we created this feature for a long time ago, but the recent AI use case,
so some applications like a huge data through my scale, my logs, and then we started hitting
a replica rack, so we enabled the replication for that, then the replica catch up speed went up to
6x, so the replica rack issue got resolved, so some of the new use case like a huge light rate,
which is a relatively uncommon in my scale work, but the new trends change some of the
characteristics, and this feature paid off there, so we are using that, so one challenge is
if you using a traditional my scale replication, which is taking really different
replicas, then it has a better consistency, like if the record doesn't exist,
or if the record is a duplicate, then that returns errors, like a duplicate key error, so key
not found errors, so this is a return, that there is a pretty good consistency guarantees,
but there is really a critical, that guarantee is lost, so only it is a brandry changing,
there is a replica, so there are some trade-offs, but especially for light intensity use case,
so this is pretty useful, so check some, so it's a pretty basic requirement, but after
using, we are adopting more use cases, so a massive scale, so sometimes a bit free,
half on the inside my rocks, or in some of the rocks, say beside, I'm failing to decode a record,
or some rocks really broke corruption happenings, and that behavior, more strict behavior is
maybe helpful, like if the data is corrupted, and if the corrupted, but instance keeps running,
and if the copy is at the instance to elsewhere, then the data can get spread to many
replicas, so that is problematic, so we have more controllable features, like the
range of corruption, corrupted record found, then reclining errors to the client, or just
identity-opelating, or just avoiding the machines, or when, look, say, we check some failure,
when chronic instance, there's a bit, verify the checks, so that's a corrupted data,
she will not be replicated elsewhere, so these types of control features of the settings too,
so this is a bit high-up level layer, but this is inspired from a hand-drosser kit,
you know, they will be managed to plug in from a marker, but we also implemented
some noise-care interface, so at Facebook, with Meta, and RPC, the fact standard RPC is
called a Swift, so we implemented a Swift sub-up, the ins and ins case sub-up, and that receives
RPC request, then talking to my ROXCV by just directory-composing ROXCV vehicles, bypassing the skills
passers, optimize us, just some Swift API calls, then get our range scans to Swift sub-up, then
composing ROXCV, API calls, and some basic my skill checks, like a table exists or not,
what schema change is ongoing, so then directly talking to the ROXCV, that's saved quite a good
substitute, and our main use database code UDB is actually we don't allow the customers to send
that under my skill, because that's a main database, so a lot of people shouldn't take down
the hold of Facebook services, so that's a reasonable architecture, but we have a big cash
service call tower, and the tower cash sub-up is talking to UDB by very common simple size skills,
like primary key rookups, a market point primary key rookups, or range scans, with just
my index, so like getting some list of the people who liked this post or not, on this type of
operation, so these are simple range scans, so about 99% of the main database lead workloads,
very simple primary key rookups for range scans, so that's why we support it, it's implemented
with some simple query paths, so bypassing the paths and optimizers, but as very similar to
100% as a main cash progress, so it doesn't support right or compress queries, so it's a
reasonable thread of, so if majority of the workloads have a heavy lead, then that's a good use case,
this is not implemented yet, but we are realizing that this is one of the biggest
architectural challenge in the recent database and looks maybe, and also the challenge for supporting
government main general purpose services for a minor level to my rooks, so optimizers in
Q-based workloads, so we have quite a few customers who are using my skill as a basic
EQ, so inserting a lot of records, then deleting them, and then checking if the rows are deleted
or not by doing the range scans, so like insert, so in the looks there is the insert is equal to
put, then people doing a lot of insights by put, then it's a Q, so people delete a bunch of
all records by delete, so this is a very challenging for ASMR, so the challenge is,
unlike the inner database, update in place database, so ASMR database doesn't immediately
trim the delete chance, it's called tombstones in Luxeville, but this delete markers and don't
immediately disappear, so they are accumulated until the flash of compactions, so at least the first
10 minutes or 20 minutes, so these are all inside the main table, and these directions are remaining,
and if someone checks if the Q is deleted or not, then people are doing range scans,
or deleted the regions, so these are pretty expensive because that ends up scanning the lots of
tombstones, so this is a common issue and we often have to rewrite, but fundamentally it's
we are realizing that we should optimize more, and so we have several architectural work runs,
like a traditional three-guard complexions, like if there are users, lots of traditions,
inside FST-5, then we're triggering additional complexions, so aggressively wiping these two
mistons, but nowadays, recently there's a big issue inside the main table, so inside the main
table, so we cannot figure out the complexions because there's no SST-5, so there are lots of
traditions inside main tables and these are still causing problems, and we have several ideas to
work around, but this is from the area so we are prioritizing, again so this is the Luxeville challenge,
so it was fixing Luxeville, as a service is using Luxeville, like the IDV, we'll see the benefits
elsewhere. We have two other topics, the ones are user-defined timestamp, so there's several
people, the building database on top of Luxeville, and there are these type of people at some time
stamp on top of Luxeville, and the building consists of these for that. We also want some basic
times more consistent leads features based on the timestamp, and we recently supported inside
Luxeville, so that providing the appendings at timestamp, so user-defined timestamp on top of
Luxeville, so that people can lead based on timestamp by using Luxeville PIs, so this is
optional features, so we can continue to use the traditional Luxeville or user-defined timestamp,
and with user-defined timestamp, this is more like a new SQL world, like a tiny V,
cockroach, you go by type, but this is a pretty big building block for supporting the
cross-shadowed consistent leads, like with user-defined timestamp, every record will have the time
stamp, so if you start transactions based on this time, then you can lead the consistent data based
on the time, and since the time with HLC, the time is consistently stored in the different
charts, so by starting the transactions, it's the same time, so you can see the consistent
leads across different charts, multiple charts, so like a global consistent lead, so the user-defined
timestamp is a building block for that, and the reason to be supporting this feature in
Luxeville, and our intention is using the same table only, so that doesn't change the Luxeville
data format, so timestamp is at some space, and as I said, the UDP is a very space band,
so we don't want to increase space, so the intention is just using the same table timestamp,
so that at least this and data can be consistent. The last big is a vector database, so
we are building some vector database capabilities by using a library called phase,
so phase is a simulated search library, the leads from a phase to quiz search, which is also
open source, so there are some several asks like a similar, like many other people talk today,
so at Meta, there are some requirements for building a vector database, and myerox is a
risky database, and people want to use vector vz-scale, so the direction is basically integrating
with phase, and using that feature, using myerox, and offering that as a risky syntax,
so country with a JSON probe format, so we don't have a specific type yet, but JSON probe
so far we're using that, but JSON kind of uses a lot of space, even of the compression,
especially when having a lot of floating pointers, so we use a probe, that's especially
kind of about two weeks, so we are using probe, but anyway, so we support both, and the vector
functions are provided by from phase, so it too, you create a little distance, and IP, the
networks, so these are some vector functions, I'm not very familiar with that, but it's a part
from phase, so that, and some JSON probe is a combustion function that provided, and yeah, the
simulated search is by using these functions, and combining this SQL, so you can do a similar
discharge, so it's a from phase, combining with a SQL, that's quite powerful, because you can
order by these scores, distance scores, or the filtering by using having, so these are pretty
the useful, the vector database people do lots of experiments, and the vz-scale, and the
experiment is very easy, so you don't have to write code, so you just using the skills you can
get some results, so it's pretty useful, and so on the index, indexes, yeah, I also got confused
like my hair, so the vector database terminology, index is more like returning results faster,
so even though the results are bit inaccurate, so that's very different from the relational database,
so index, but anyways, so we are using the phase provided, the indexes, there are much
preindexing supports, the flat h, h, h, the handler can navigate h and s w, and the ib, ib,
the ib, f means the embedded file, so today it's we provide the flat ib, flat ib, pq, the
product quantization, so these different indexes, we are planning to support more, but basically
it's these are all far from phase, just integrate with the monoxide, so one particular thing
I made was calling out it's, so trace the vector talk or all over the h, h and s w, but we
met as we are using the ib, the major reasons h and s w is very sensitive, everything is
speaking memory, and met as we have a bunch of hardware, but the many hardware has a very small memory,
and the last set is very large, so we last wanted to work with a small memory or the
large database, not data set, so then the embedded file types, the ib, f, the fit, the vector for us,
but anyway, so generally it's a vector format, and I pretty sure the pj vector supports also
both h and s w and the ib, f, so with ib, it's a kind of embedded, embedded file, but you need
some training data, so in fact if it's a partitioning, the data across the modules, then for
better partitioning, so we need training, so it needs some training data sets, and so based on the
training data sets, and when you're studying data, and when building indexes, the data is
partitioned property, so there are several features, but most of it's far from phase, but yeah,
it's a complex query supported with sqr, so with sqr, so you can filter them, or with having
quotes of workloads, and also condition pushdowns, and then we can offer good support, and yeah,
so the layout on this is like a flat, it's more like flat format, but ib, it means a partitioned,
and with this partitioned based on the detailed by training, and yeah, the execution of the
single query is optimized, and then we need filters, or index scans, these are traditional
flows, and it's very little that talking to phase for the similarity such, and talking to
the vectors, and yeah, it's basically mixing the sqr, behavior, and the vector behavior from phase,
and yeah, we have several use cases for that. This is the last slide, so the future developments,
so the most of the work from a rock cv is from rock cv, and rock cv is a very
actively developed open source product, and all that development is based on GitHub, so yeah,
if you are not familiar with rock cv, and if you're using that, or already using the data
based type, and it's recommended to check in the rock cv features development. Also,
with my rocks, we are also pushing more features to rock cv, so that more people can get benefits,
and my skin is self-cold based, it's now managed, and internal depository, and meta,
so all development is done inside including my rocks, but we also regularly push the changes
to GitHub, the Facebook GitHub, the meta, the Facebook five six, it's five six, but name that
five six, but it's based on the eight, so we're really going to change the update, it's absolutely,
that's it, thank you very much.
The question for three minutes for questions, yes?
If you do have to do the leads and do selects after, which is expensive,
is there anything you can do from your application to just kind of help from Cv,
like actually, and all that already? So the, yeah, so the expensive part is a select,
so the range of scans, so there are some customers that think repeatedly doing range of scans,
like 100 times per second or so, then we are the vice-cent of the not doing that, so just
catching the results, the sending results, less often, or the range of directions,
the range of directions, without that page, like ID, larger than 0, limit 5,000, 50,000, then
the lifting that, and just these, or every time, so instead just using properties,
the filtering, for example, remember that last nearest record and the passing factors are new
records, so this type of, the beta filtering, or catching, so these are generally helpful.
Yes, yes, yes, potentially, yeah, yes, I imagine you like work work and
urbanization, but also, we have a problem with write-up negation and compassion,
because you have the least material, like 0, and actual record files, 0, or 0, or 0, or 1, or 2,
then it's compact, use the role of write-play, or the least compact, the next level, so you get
a lot of write-up negation in this case. Yes, the question was a write-up application, which is,
so generally, on the set-in-state workloads, the rook-stabies write-up applications much more
up than typical beta, it's typical, let's not have, or even this, but yes, you're like,
when doing aggressive, deletion-triggered compactions, then it compacts much more often,
so then write-rate becomes a problem, or CPU for compressions. Yes, we had that issues on some of
that, very likely, in terms of subsidies, so yeah, the challenges we need to find balance,
like, write-rate was mostly fine, but CPU was concerning, so doing some active compressions,
so for that, use-case, we changed compression algorithm from Zstandard to LZ4, which is
faster compressions, like, check-ins write-rate under CPU, and then taking some balance,
relaxing some of the deletion-triggered compactions threshold, so this is quite a, some
tuning was needed, so we hope that we can be more automated, so that's a future study set-up.
Yes, yes, yes, the question's face, the face is open source, yes, and I believe it's supposed to be
on GPU, so you can choose, yes, yes, thank you very much.