Eric, First, thank you very much.
This is a really interesting concept and proposal for a shift in architecture. I have some questions: What would be the impact on current efforts to remove current dependencies on non Apache license compatible data persistent layers/libraries? Once implemented, is this more, less, same to maintain and add functionality? Would it require a dev to map the data logical level (ORM) more intensively? Is there a different skill set needed with this than current concept and are those skills generally available? Is the trajectory of this technology vs noSql clear? What about Apache Ignite? Is there an independent review of Trafodion? You've made a good case, what's the counter? Is the open source version useable or does this require use of the EsgynDB in production? Are other providers using the tech? If the project devs can come to some conclusion on this, what's the level of effort? How should we do think about the size of this effort. & do you think... is there someone available to work on this project, perhaps from one of those banks? Thanks, Jdailey67 On Thu, May 30, 2019, 1:48 AM Eric Owhadi <[email protected]> wrote: > Hello Fineracteers, > > I discovered Fineract and specially Fineract-cn last week, and am very > impressed by the future potential of the project, both to deliver on its > original social mission but also to revolutionize commercial FinTech sector > the same way the big data wave caught up when Hadoop was open sourced. > > The architecture [Cloud Native/micro-services] is at the forefront of what > a modern application should look like, and the decision to start from > scratch and don’t carry the burden of legacy was a bold but very smart move > imho. > > There is however, one area that might be interesting to challenge: the > CQRS and the dual storage engine needed to provide capability for async > command execution (and its draw back on error handling from front end) and > sync query accessing the traditional DBMS with its scalability shortfall. > > > > The current implementation looks optimal when it was picked (I assume when > fineract-cn was still mifos io), because there was no open source “NewSQL” > solution available. Using classic RDBMS with known scalability limitation, > coupled with NoSQL eventual consistency, no ACID, no multicolumn/table > transaction, no join or grouping, given up to gain stellar horizontal > scalability was a smart move. > > > > However, in 2017, Apache released Trafodion as Top Level Project. It could > replace both Postgress/MariaDb/MySQL and Cassandra. It is an MPP RDBMS > built on top of Hadoop Hbase (the Hadoop equivalent of Cassandra). It is > fully ACID, supports multicolumn/multi table transactions, joins, group by, > is fully horizontally scalable and support all the bells and whistle you > would expect from a classic RDBMS. It can be classified as NewSQL, > basically claiming back all the things given up by NoSql in exchange for > scalability. In addition, the company backing it up (Esgyn Corp) have > recently announced that its commercial product (EsgynDB, derived from > Trafodion) is being used for Core Banking in 2 major Banks in China, > struggling with the ever growing mobile payment volume that traditional > scale up databases cannot keep up with. In addition Esgyn provides a DB as > a service offering, cloud hosted fully managed (Esgyn Strato), giving the > option to potential fineract-cn hosting company to “outsource” the > persistence layer management and focus on the rest. > > > > Wouldn’t it be an interesting idea to hook Trafodion to Fineract-cn? I can > think of the following advantages: > > - Simplify persistence layer ecosystem from 2 DB to 1 -> back to > classic RDBMS but with full scale out capability MPP style. > - Still Apache license compatible > - Persistence layer ready to support challenging analytical workload > (reporting use cases? - thanks for reclaiming Join/group-by at scale). > - Remove the reticence of decision maker to use NoSQL in Core Banking > - Performance over Cassandra [on paper, even if Trafodion was used > only as a drop in replacement to Cassandra for async commands, the use of > Trafodion “Align Format” feature should demonstrate higher performance for > journaling, as Trafodion would write 1 BigTable cell per row, while > Cassandra or Native Hbase would write 1 X nb Column cells per row]. > - With a solid company already showing its commitment to core banking > backing the Apache project > > > > Hope this makes sense? > > Eric Owhadi, > > https://www.linkedin.com/in/eric-owhadi-3173058/ > > Principal Engineer at Esgyn Corporation. > message resent from personal email, the first tentative did not make it... >
