The times, when developers built the applications on a single database are certainly long over. Many services nowadays use a variety of databases in combination, to power the different aspects of their applications. We are not an exception in that manner for sure 🙂
Recently we have started a new project, where we have to implement our own data reservoir. For sake of good order, we have chosen MongoDB for saving unstructured meta information and PostgreSQL for saving the actual data. For orchestration of data flow between the databases we have finally chosen an open-source container-native serverless platform called Fn Project, which at the time of writing this article had 2 years history, or so.
I’ll not go much in details on how to setup Fn Project, to create your own Fn functions for storing in the databases. There is already much information about it. You can try out these tutorials, if you are new in Fn Project. I’ll just focus on orchestration of Fn functions, which problems we have faced with while implementing our data reservoir and how did we solve them.
The Orchestration
As mentioned we are storing our data across two databases, we use MongoDB in order to store unstructured meta data, and the structured data is stored in PostgreSQL. Due to the nature of our data, the first entry point is MongoDB, we then use MongoDB’s _id as a cross DB foreign key. Our data is supposed to flow like this: Read the complete article here.
For regular information become a member in the WebLogic Partner Community please visit: http://www.oracle.com/partners/goto/wls-emea ( OPN account required). If you need support with your account please contact the Oracle Partner Business Center.
Blog
Twitter
LinkedIn
Facebook
Meetups
Technorati Tags: PaaS,Cloud,Middleware Update,WebLogic, WebLogic Community,Oracle,OPN,Jürgen Kress