The Anatomy of a Migration

Let’s begin
by analyzing the anatomy of a migration or
in other words, how it really works
under the hood.
Now, the good news is that most of the time
the migration from one database to another or
even if you happen to be migrating to the same database,
but for example, to a different topology,
the good news is
that, the migration is…, doing a migration is really simple.
As soon as you understand the basics, you will be able
to work on your own for almost 80% or 90%
of most data migration strategies over there.
To put it simply, the overall goal of a migration
is, you know, to simply transfer data
from a source system to a target system.
That’s it.
However,. I have seen many people creating
some sort of mysticism around it,
which is often tied to a lack of fundamental
understanding over the entire process.
So a migration, although simple, in a migration
you still need to take some important decisions
before you actually kick off your migration process.
And a migration
can typically be classified in two ways.
Typically, you will be doing an online migration,
which effectively means that
you expect no down time for your application
and you will need to deal with increased complexity,
plus the fact that you will need to properly test it
in order to, you know, avoid introducing an extreme impact
to your existing applications that are already reading
and writing from your source database.
And then we have
an offline migration, which is much simpler.
You stop the source system, the source database,
which is currently receiving traffic,
you transfer the data over and you switch your clients
after that’s completed.
But no matter which route you decide to take,
there will always be some common steps
that you will need to follow, such as, you will need to do
your schema migration and changes, particularly if you are
going from one
database to another.
So unless you’re migrating to the same database, it’s
very unlikely that you won’t need to do any schema training.
And, John talked very extensively
about the basics of
data modeling for Cassandra/ScyllaDB types
of databases.
After you are done with your schema adjustments,
you will need to actually migrate your data,
which is what we are discussing here today.
And lastly, but no less important,
you will also need to validate your data to ensure that,
of course, everything is working as you originally intended.
All right.
So this brings us to the actual migration flow
presented in this slide, where, as you can see,
the process is split by those dotted vertical lines
as seen in the diagram.
So when we start, the application is actually,
of course, writing and reading from the source database.
And while it is doing so,
we will first
migrate the schema over here.
All right.
It is worth to underline here the importance of getting
your schema correctly set up on your destination
database as if you failed during this
step, every subsequent work will likely become redundant
because if you get your data modeling incorrect,
you will eventually need to redo the migration all over again.
So consider extending some really precious time
over this step when you are working on adjusting
your schema.
All right.
So if you are not sure about whether you got
your data modeling correctly,
then you may want to check the previous data
modeling masterclass talks that we had earlier this year
to avoid running into the typical errors and mistakes
that most people do. All right.
So if you are doing an online type of migration,
then in addition to the schema migration part,
you will also want to start capturing changes
as they happen in your source database.
The approach that you will use here will depend on
from which to which database you will be migrating.
For example, in DynamoDB, you would enable Dynamo Streams.
If you are migrating
from Cassandra to ScyllaDB then most of the time,
not always, but most of the time you can simply do
dual-write for your application and that should work just fine.
Other approach could involve using Kafka,
some CDC that your database already has, and so on.
All right.
The next step is for us
to actually move the existing data.
So if you enable CDC in the previous step,
then you will also want to wait
for our change to get replayed
before you proceed to the next step.
All right.
After that is done, both your source
and your target database should be in sync in the natural
follow up is for us to actually test the migration results
prior to actually switching our application clients.
This can be accomplished in a variety of ways, such as,
we can compare random individual records or
it can also be done in a very
extensive way
and also very lengthy, where every individual record
gets compared before you actually
make a decision
whether you are going to switch your clients or not.
And finally, after you validate it,
then that’s the moment when you would
switch your clients, either altogether, you could to simply
switch off your source clients and move everything
to the target,
or you could also do it in a canary way as a safety measure.
So you would only move
a set of users until you gain more and more confidence.
So those approaches are typically vary
from company to company from use case to use case.
Okay. Now,
the migration process that we’ve just walked
through, was very simple, but unfortunately
it happens that not everything is flowers.
For example,
there are several important stuff that we need to
account for, such as, for example, the technology
switch, and John spoke about this during his talk.
So if you are migrating from one database
to a different one, then you will quickly realize
that some features you are using may not be available.
Or perhaps those features are available, but the way it’s done
is actually accomplished in different way.
You will also need to understand the characteristics
of your target database
to ensure your data modeling scales as your workload grows.
And given all the data modeling and application changes
you need to carry on, there also comes a need for
dedicating some time for testing all these changes
as well as testing your migration plan.
As for tooling it is a bit unfortunate,
but unless you are a Spark/Scala expert,
it is almost impossible for you
to find a single tool which will rule them all.
So a tool that migrates from any database to
any database is unfortunately something that is yet to exist.
Even when tooling exists, depending on your workload
and requirements,
it may need further adjustments to work for you specifically.
And when there is no tooling, you pretty much need
to cook your own tools and set off processes
for you to actually accomplish the data migration.
And then we also have to account for edge cases.
Some use cases may depend on specific database data types
such as “Counters”
which we are going to talk here today; or concurrency
control techniques such as “serializability”,
which may introduce an additional challenge
requiring us to identify and deal with these situations
in an extraordinary way.
All right.
Another
important aspect to remember with regards to migration
is that in general, they are very flexible.
So consider spending some time to walk
through all the considerations
and try to make reasonable decisions according to your
business requirements.
One of the things that
we have learned over the years is that most people blindly
try to migrate all of their data set
when this is not really always necessary.
Doing this exercise will not only save you time
by greatly simplifying all the migration efforts,
but will also allow you to better understand
the inner details of your workloads, such
as your consistence requirements and your user behaviours.
Let me give you guys an example.
Most of the time when we ask people,
can you tolerate some level of data loss?
The immediate response that most people is going to answer
without thinking is “no,. I cannot lose any data”. Why?
Because that’s natural.
That’s our natural, that’s our natural reaction
when we hear the words “data loss”.
However, consider that you have an IOT type of use case
where you generate reports hourly, daily, weekly.
The chances are that if you miss migrating
some few measurements, everything is going to be fine
and your dashboards are going to load
in the same way as they did with those measurements.
Because typically
when you aggregate a bunch of data, you’re
spending a huge time
period, there’s pretty much very little variation
when you miss some of these measurements.
It might also happen that very few of your users
actually care about data past one month, for example,
making it redundant to migrate
your entire dataset as a whole rather than
one of the things you could do, would be “okay,
so if I have only 10% of my users who care about
data is spending over a month, then I’ll just move the data
for those specific set of users or don’t even migrate at all.
After one month they will have their dashboards back.
Alright.
Logs and traces also behave quite similarly.
Perhaps you could simply snapshot
out of your existing historical data
and just start ingesting fresh ones
through the new database readily
without actually having to migrate anything.
Done, migration is done.
Of course, there are some use cases
which definitely require no, zero data loss.
Social networks or messaging apps, financial transactions
are just some examples where this cannot by any means
have missing information as it would otherwise
introduce a direct impact on the business, right? And
your user would quickly realize that their data is missing.
Still, even for these use cases, you may have
some level of flexibility over how to migrate.
Maybe you need to migrate,. I don’t know, ten tables,
but you are able to map,
I few tables to specific microservices
which would allow you to actually split
the actual migration work in smaller iterations.
And maybe some of these tables make use of time to leave,
TTL data, so you could migrate only the parts
most relevant to your business.
In summary, take this and other aspects into account
when you are planning for your migration.
This will help you identify potential pain points
in improvement opportunities early in the process.
Which is a great thing and
that’s
the overall goal of carrying out a migration
and it will save a lot of time and burden as you progress.
Lastly, but no less important,
always test your migration plan
before you actually roll it out on production.
Otherwise you may find yourself just wasting precious time
and potentially money if you later on find out
that you overlooked some very important aspect.