Hi Eric,
The proposal is to use Trafodion and MariaDB/Postgresql? Or how is the
approach?
About doing a setup on the DDL for "small/medium/big" tenant based on
the tenant size, looks strange to me, adding a layer of complexity to
existing functionality of NewSQL.
Big banks have different line of business, medium banks also. (Size...
is very relative... it could be related to retail customers, assets,
market cap, etc) .
Transaction tables are stressed depending on the products that the
financial institution offers to its customers and also the delivery
channels. I have worked for big banks and in the local core banking
(Retail Banking and Wealth Management) running in a zOS, the bottleneck
was not in the DB2 tables related to the customers, it was in a treasury
account used for the interbank payments, because all the channels (ATMs,
Branches, Mobile, Personal Banking, Corporate Banking) access that table
for encrypting/decrypting the transactions and storing them for any
rollback. On another line of business (Global Banking and Markets) the
bottleneck is not in the customer accounts, they in fact do very few
transaction but the tables used for the market data are stressed.
Having a clear use case will help to apply Trafodion.
Regards
Victor
On 6/14/19 9:06 a. m., Eric Owhadi wrote:
Hi Fineracteers,
I have been looking at Trafodion integration requirement, and as
pointed out by Vishwas, the first obstacle is on lack of flyway support.
However, I think this is no big deal, after I have seen that Cassandra
had its own ways of dealing with schema version (CassandraJourney),
and I can easily implement a TrafodionJourney. The advantage of this
approach over flyway is that the flyway method have a drawback (at
least from my quick overview of the features):
Let me explain: when doing a create table, then dropping columns, and
then adding column, and dropping again, and adding again, some (most?)
database, like Trafodion, will end up having an internal storage for
that particular table not as optimized as it would be if the final
table was defined without a succession of adding and dropping columns.
I am not sure flyway allow defining/playing just the final end state
for a given table, or if no matter what, you always have to
successively play all versions one after the other.
I plan to support both successive replay of each version, and a direct
jump to final version on a TrafodionJourney ecosystem. So that for
fresh installs, we don’t get a sub optimal storage format.
Thoughts?
Also I have another question:
The key advantage of going NewSQL is on horizontal scalability. I
assume the reason I read that Fineract cn can support small bank, but
not medium or large, is that the RDBMS for a single tenant will be the
bottleneck?
I am guessing that transactions on the checking account must be the
most stressed table? If so, I am wondering if at tenant configuration
time, we can specify if the tenant we are creating is going to be
“small/medium/big”, so that DDL associated with stressful table can be
adapted and “salted” across multiple servers of the DB cluster. So in
a nutshell, I need the DDL to be parameterized based of tenant size.
Is that already something accounted for?
Thanks in advance for the help,
Eric Owhadi
