EDWARD BELL: Hey, everyone.
I'm Edward and I'm
Partner Technology here at Striim.
Today I will be talking a bit about Striim,
a strategic Microsoft Parker.
Striim is a Striim ETL Platform which
enables you to continuously
ingest data from a variety of sources,
typically transactional databases,
and push it to one or many targets.
In the middle, there's
a streaming processing engine which allows you to do
transformations and rhetoric and other
pre-processing all in memory in flight.
This enables a continuous 24/7 feed of data into Azure,
drastically increasing Azure consumption
and decreasing the user's time to insight.
Just stepping back a little bit,
Striim was founded by
the same founders as GoldenGate software,
or now Oracle GoldenGate.
Prior to being sold to Oracle,
they had eight Customer Advisory Board,
which really enabled them to see into
the future of what customers were looking
for their upcoming use cases
and tuning deems came out of that.
One was the ability to ingest from
non transactional sources and
write to non transactional targets.
Then the second was the ability to do
something with that data while it was in flight.
Then the team came back together,
really let those two main ideas in play.
We still have all of that context and
knowledge from building out previous CDC platform,
but now have put it together in
this next generation platform to add
in a wide variety of
functionality and support these latest use cases.
Talking about use cases,
given Striim as a platform,
typically we focus on three primary ones.
The first one is Cloud adoption.
This is zero downtime database migrations
from on-premises or other Clouds to Azure.
With that log base CDC technology,
we support zero downtime and
also enable the ability to keep
the source and target databases in sync for
a period of time prior to the application cutover,
really reducing risk and
enabling use cases that customers
might otherwise be wary to execute.
We actually have a joint program in place with Microsoft.
For specific use cases which are
internal DMS tools don't support,
we use Striim to help augment those use cases.
Outside of migrations,
typically we focus on hybrid Cloud integration,
more often analytical use cases of say,
replicating data from Oracle to Synapse,
where the customer doesn't want to
necessarily get rid of Oracle,
but they'd like to offload
any analytical queries to the Cloud.
Again, with log-based CDC can keep the source and
target in sync for years at a time.
When you think about Striim,
think about all of the enterprise use cases,
most critical data integrations.
When there's Oracle or SQL Server as a source,
we have a lot of history of working
with these database technologies.
If it says zero downtime migration or large size
and heavy volume of moving terabytes of data at a time.
Then lastly, heterogeneous data movement.
With that streaming processing engine in the middle,
you can execute these transformations and
really enable these heterogeneous data movements.
Terms of the migration sign, again,
think of Striim for the most critical migrations.
For Cosmos heterogeneous, for DB, for Postgres,
anytime going from Oracle to Postgres
or the largest homogeneous migrations,
as well as for DB for MySQL.
From here, I'll go ahead and dive into a demo.
Today I have an Oracle to DB for Postgres demo,
which will really just show the Striim platform
and what a typical use case looks like.
Here we are in the Striim UI.
You can deploy Striim either as
a fully managed SaaS Striim Cloud or self-hosted in
either on-premises or in your own Azure subscription.
Really what we care here about is
applications or what we call data
pipelines from a source to a target.
What you'll notice is we have
all these different application groups because
a zero downtime migration or
continuous replication consists of two processes.
The book historical log,
as well as the log base CDC process to
continuously capture any new inserts,
updates, and deletes.
If we go to the initial node application,
there are a variety of ways to create applications,
but one of the main ways is this drag-and-drop interface.
Simplest application is the one we have
here, drag-and-drop the source,
drag-and-drop a target,
configure your connection properties,
enter, get to go.
In the middle, you can also do
a variety of transformations, enrichments,
and other processing with
these out of the box transformations,
with SQL queries,
or even Java code.
Who go to our source?
In this demo, we're using a ticketing application,
so for baseball and football tickets,
running on top of an Oracle database.
Here all of our tables are
located within that DMS sample schema,
which we are going to migrate to DB for Postgres.
Just specifying our connection properties here.
Before running the initial node,
we'll just run a simple count star
on one of our largest tables.
This is our target database.
You can see that our target is currently empty.
I'll go back to Striim and start the application.
What Striim is going to do is first check
the schema to make sure the source and target match.
We're okay with that, so I'll click
continue and now we'll actually start the data movement.
You'll see down there in the bottom of
the page a preview Window.
You can get a sample for some of this data.
Here you can see some baseball player data.
That's just contained in one of
those tables within that DMS sample schema.
Up top we have total input and output
kelps as well as the associated rates.
Then we can also dive into
additional metrics in this application progress window.
Here we actually get a progress bar both for
the entire migration as well as each individual table.
This can just ensure that
the initial or bulk historical load
is migrating smoothly.
With that started, I'll go ahead
and just fast forward real quick,
then we can get to
see what it looks like when the initial load is complete.
So with
the initial load complete,
we can now see that our input and output metrics match.
Then at the top, our application is
now in the completed stage.
If we go back to that progress monitor window,
let's scroll down to that supporting event ticket.
So that table that we queried on
the target database prior to running this app.
We can see that there are about
37.2 million rows in there.
If we just go to the target database,
we'll run that count star again.
Just give it a minute for this query to complete.
Now we can see that our initial load is completed.
With the initial load complete,
we can go back to "Striim" and let's
go to the CDC application.
If you go back to
our main page and then click on that "CDC out".
What you'll notice is it looks
remarkably similar to our initial load out.
The only difference is we're using
this other source component.
We are using an Oracle reader to
read from the underlying Oracle redo logs,
and capture any of those new changes.
Specifically, on this single table,
which will be changed when people purchase tickets.
Our target is the exact same as the initial load.
You can literally copy and
paste it from the initial load application.
Prior to running the CDC app,
we would just run a select star on our CDC table.
You can see that our target is empty,
and what we'll do is we'll start the CDC application.
What we'll notice is by default.
We're only looking for new changes,
and since this isn't an active database,
we don't actually have the application running.
We don't have any data moving through.
But what we'll go ahead and do,
is run this simple script to
simulate that people are purchasing tickets.
We can see that Striim is
instantaneously picking up all of those new changes,
and then replicating them to dB for Postgres.
Down there in the bottom,
again, within that preview screen,
you can see some of that sample data
as well as the associated metadata.
We can validate that were replicating data
to dB for Postgres by
running that same select star query.
Now we have a 24-seven live feed of data into Azure.
Which you can further utilize
with Azure as broader ecosystem.
In our demo, what we're doing is we're running
Power BI on top of this dB for Postgres instance.
Just simulating what you can do when you
combine Striim plus Azure.
This is just running some simple analytics
on our target database.
We can see our total ticket sales.
We have zeros sold out games.
Perhaps you want to sell out some games,
as well as the average ticket price.
Maybe you only want to increase that or
increase it based off of specific rows,
and some additional information.
So really just showing what you can do when you
combine Striim and Azure products.
Again, I'll just go ahead and fast-forward real quick.
Then if we get back into "Striim",
just a few other things I wanted to show quickly.
There's actually a monitoring suite,
so we just click that monitor button
in that top menu bar.
This actually shows the infrastructure
that Striim is running on.
You can ensure that everything is running smoothly.
And then we can actually dive into
application specific monitoring as well.
If we just click that monitoring button.
Here, you can take a look at your sources,
you can take a look at your targets,
make sure the amount of events
in equal that amount of events out.
Then Striim even computes the into M lag.
The mono time that it takes from reading a record on
the source to writing it on the target,
as well as provides additional details here.
You can really just ensure that
your continuous replication is running smoothly.
Besides the monitoring, if we
continue up there in that top menu bar,
you can also create specific users.
This is helpful if you have larger teams using Striim.
You can have users with application creation privileges,
or users with just monitoring privileges.
You can also configure alerts,
whether for the infrastructure that streams running on,
application specific, or even at a component level.
If that Oracle readers at that rate reached zero,
you can receive an alert.
This helps in terms of usability,
so you don't actually have to be
constantly monitoring UI.
Lastly, Striim actually has
a fully command line interface.
If you don't want to interact with
the UI, you don't have to.
But that console is also exposed within the UI,
where there's some additional information
not shown in other pages.
Lastly, all the applications within
the UI are backed by what we call [inaudible] file.
It essentially looks like PLC sql.
If we go ahead and export this application,
we'll open that up in a text editor,
and you can get a feeling for what that T-SQL looks like.
You can see it's very simple syntax,
things like create application, create source,
and your various connection
properties.We've seen people create
either migration or replication factories by creating
a simple script to
automatically create these applications.
Then there's a rest API around Striim.
Everything that you saw me doing in the UI,
can be done via an API.
You can only create
a programmatic approach to
these migrations and replication.
That's about it, that I had in terms of the demo,
that was pretty representative of
a typical Oracle db for Postgres replication.
If you have any questions,
please reach out to us @MicrosoftUpstream.Com,
and we'll be happy to
discuss your use case. Thanks, everyone.