Thanks Andy and Jeremiah for your inputs. I will update once we reach a
stage where we will run some performance tests on both flavors. Maybe the
results could provide a conclusive answers.
I agree on the part that performance of databases depends on the way schema
is being used.
On Thu, Apr 5, 2018 at 2:16 PM, Andy Sayer <andysayer@xxxxxxxxx> wrote:
One of the main differences will be to do with feautures available to you,
if you take advantage of Oracle functionality then you will either need to
find the alternative in your target system or accept you can’t have it.
Things like compression are likely to be implemented differently, maybe
better, maybe worse. Obviously you no longer have PL/SQL, But there may be
an equivalent.
A fundemental difference will be how transactions work in either system,
you will need to relearn everything. A quick google suggests that InnoDB
has MVCC Non-Blocking Reads which suggests it might not be as much of a
nightmare as others but that’s no excuse to not read up.
The rest of the performance is not going to be down to the cache
management or the details of how it allows you to recover after a crash. It
will be pure and simply the amount of work that your code requires the
database to do. If your code is sensible and effecient then there’s no
reason it shouldn’t also be good enough on a different RDBMS. If your code
demands the DB to do lots of work (chatty slow by slow applications, or
ones that don’t understand filtering etc) then no matter what RDBMS you run
it in, you’re gonna have a bad time.
Ultimately, you are going to rewrite and retest all of your code. It will
take a long time depending on how much time you’ve already invested in your
code in Oracle.
Hope that helps,
Andrew
