RE: Postgres and Java Microservices Multithreading
От | |
---|---|
Тема | RE: Postgres and Java Microservices Multithreading |
Дата | |
Msg-id | 2A91BEF8171A5349931391E0C721CC537570555B@CPEMS-KPN501.KPNCNL.LOCAL обсуждение исходный текст |
Ответ на | Re: Postgres and Java Microservices Multithreading (Tim Cross <theophilusx@gmail.com>) |
Список | pgsql-admin |
Thanks Tim, your response covered all :-) -----Original Message----- From: Tim Cross <theophilusx@gmail.com> Sent: donderdag 5 december 2019 15:17 To: pgsql-admin@lists.postgresql.org Cc: peter@osdev.nl; pgsql-admin@postgresql.org Subject: Re: Postgres and Java Microservices Multithreading soumik.bhattacharjee@kpn.com writes: > Thanks Peter for your response, appreciate much. > > > > But I think the applications wont behave the same way as with > Oracle.(We have 15+ Microservices running in Oracle with parallel > processing) > > > > Below I just checked and testing in Test Env. > > > > https://www.postgresql.org/docs/12/parallel-query.html > > https://dzone.com/articles/postgresql-connection-pooling-part-1-pros-a > mp-cons > > > > > > If anyone have some use cases/real time project executions will be really helpful. > > > Oracle and Postgres are very different DBMS. While the functionality is basically equivalent with respect to CRUD operations,the underlying architecture is very different. This means how query plans are derived, how indexes, locks etcwork are very different and will need different strategies to optimise performance. You won't just be able to create theDB schemas in postgres, point your Java microservices to PG and expect everything to perform in the same way. A lot moreeffort will be required in order to get a reliable level of performance. With regard to your questions concerning parallelism of the java micro services and the links you posted, I wonder if yourconfused regarding how/where you believe this parallel processing is performed. Assuming (as Peter stated) your Java microservices are separate Java software (i.e. not Java functions embeded in your 11gdb), then what your dealing with is concurrent connections to your database to perform CRUD operations. This is distinctto parallel execution of the actual SQL statements within the database. Connection pooling will likely be a criticalcomponent, especially if the SQL statements are small/simple, but with a high volume. The overhead of establishinga connection can easily be as much or more than the actual query in many micro service type applications. Likewise, the extent to which your SQL statements are able to take advantage of parallel processing within the database arelikely to be less relevant compared to correctly structuring transactions (commits/rollbacks), contention and lockingin the database tables. This in turn depends a lot on the type of application and relationship between frequency and complexity of queries, updatesand inserts. Even if someone can provide the use cases or other examples, they are unlikely to be very relevant. Too much depends on thespecifics of your application, your schema design (tables, data types, indexes, number of columns, table sizes etc), theprocessing profile and required performance metrics and how the DB is tuned. The good news is I suspect PG will be able to satisfy your requirements. However, the bad news is it sounds like the migrationeffort has been woefully under estimated. Based on your questions, I would also suggest you need to get someoneon your team experienced with PG. I spent 15+ years working with Oracle before moving to working with Postgres and after 2 years, I'm still learning everyday. The databases I work with are large (appro 8Tb) and on a slow day we process 1.5 billion updates and inserts andhave a number of REST and GrapQL API's which process large numbers of queries for a number of applications requiring real-timedata. Very little of my Oracle knowledge has been relevant to working with PG. Tim -- Tim Cross
В списке pgsql-admin по дате отправления: