Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I am new to microservices architecture, but I have learned that a key advantage of using such architecture is scaling.
Say we have one microservice instance and it is connected to one Mysql database.
Now we need to scale it up to be 3 instances instead of one, does that mean that each instance will have its own database? or it will be 3 instances and one database?
Any information is appreciated.
Usually you would like to have a single database backing a microservice. Otherwise you are just creating multiple instances of the same service. Challenges there are to avoid locking tables and/or rows so the services scaling is worth.
Classic SQL database are hard to scale horizontally (typically the do not support multiple write replicas and depends on a single node for writing). This also represents a challenge in case your services are geographically distributed. There are multiple ways to reduce those effects (using no SQL databases, messages queues) but which matches best depends on each context.
Just in case, sharing database amongst several microservices is definitely an anti-pattern. That is using the database as integration point.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am currently working on a project built using the spring framework. We are using stored procedures instead of Hibernate queries
What are the advantages of using Stored procedures instead of using either Hibernate methods or queries in DAO classes?
Depending on what you are doing in the stored procedures, it might be better latency-wise to use stored procedures to avoid network round trips for successive database calls. I don't know if MariaDB supports this, but I think some databases support pre-compiling stored procedures to reduce the latency even further.
Having said that, if you use the advanced SQL features of your database (recursive CTEs, window functions, anonymous blocks), you should be able to get a very similar performance. IMO it only makes sense to use stored procedures if they are called by multiple applications that can't share code.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I already have a blog application which is built on Spring-Boot as a monolith.
There are 2 entities.
user
post
And the mapping is one to many.
A single user can create multiple blog posts.
How can i recreate the same functionality as separate microservice applications.
So far on researching through internet, what i see people saying is create database per service etc.
Suppose if i create 2 services say
UserService(which has separate DB and CRUD operations associated with it)
PostService(which has separate DB and CRUD operations associated with it)
How can i make communications in between them.
In the monolith app the POST entity has createdBy mapped to User.
But how this works in Microservices architecture?
Can any one please help me how can i design such architecture?
First list out the reasons why you want to break it in micro-services. To make it more scalable (in following scenarios for example).
Post comments becomes slow, and during this period registration of
new Users to remain unaffected.
Very few users upload/download files, and you want general users who simply view comments and post comments to be unaffected, while upload/download files may remain
slow.
Answers of the above question and analyzing,priotizing other NFR's shall help to determine how and what to break.
Additionally,
Post service only needs to validate whether the user is a valid logged in user.(Correct?)
User Service does not really need to communicate with post service at all.
Further you might want to decouple other minor features as well. Which in turn talk to each other which can be authenticated via other means like(Certificates, etc.) as they will be internal and updating some stats(user ranking), aggregates data etc.
The system might also have a lot of smaller hidden features, which might or might not have to do anything with Post Service at all, which can be separated in terms of different micro-services(like video/file/picture/any binary content upload/download) also and prioritized based on computation power needed, hit frequency and business priority.
After breaking it in to micro-services, you need to run some stress tests (based on current load) to know which services needs replication and which not and needs a automatic load balancing. Writing stress load first before breaking can also help to understand which features need to be move out of the monolith first.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have been doing research on micro services. I have used spring boot seeing how simple it is to start with. During my research i have read that is a good approach that every micro service, that is the ones that do data access from a database, have its own database.
I am curious how this works when starting multiple instances of that same micro service. Can those instances of the same micro service work with just one database or they also need a separate database? The dilemma for me is the data would be different across multiple databases. How does load balancing micro services work for such situations?
edited after the first 3 comments
I appreciate the comments. I feel i was lacking in explaining my thoughts behind this question. I am used to building monolithic applications. I made use of spring and hibernate (hibernatedaosupport) and lately also hibernate envers. I use transaction management of spring to manage the commits and rollback situation of the database. This has worked for me so far. I have started looking into micro services and so far am unable to find a proper explanation of how spring transaction management used with hibernate and envers as a micro service would work with a single database. I can understand just one instance of this micro service working, but i am curious if multiple instances of this micro service would work properly with just one database. Especially considering the fact that hibernate would cache objects of the database for performance reasons, not to mention envers and its actions.
There is no requirement about that micro-service must have a different database, you could share one database across all your micro-services or have one per micro-service. It depends on you and architectural decisions taking into account the different tradeoffs.
If you decide one database per micro-service and you have many instances of the same micro-service. You must use just one database (like with monolith). About your concerns of Hibernate and Cache you must handle the cache in different way, by example using Hazelcast (https://hazelcast.com/use-cases/caching/hibernate-second-level-cache/) or EhCache.
Anyway the design patterns are just best practices with different tradeoffs, you must understand the advantages and disadvantages of every pattern for later take a decision.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We have a big MS-SQL database with millions of records. There are java services which interacts with DB for data retrieval. The application deals with lot of LIKE, IN & JOIN clauses. This leads to higher CPU usage & longer response time during service call for java services.
Based on our analysis, we identified 4 big tables in DB which occupies lot of space. The decision is to add one more DB in a different server and allocate enough memory. Then move those 4 huge tables to a separate one from existing DB.
Can anyone please suggest will this idea help for DB optimization , making full use of two databases or any other helpful techniques?
Has the existing server maxed out its CPUs? Often times CPU is not so much the issue but I/O capacity is (network, disks). You might be able to provide more I/O resources on your existing server and then distribute your temp db, tx logs, and potentially the four tables, across separate disks.
Splitting your schema across two servers will not be transparent to your Java clients. Also, if there are referential integrity constraints between those tables and the rest of the schema then you cannot do it unless you drop the constraints.
One alternative could be to use transcactional replication to replicate your complete schema across to another server. You could put both instances behind a load-balancer. Or you move all read-only processes to the replication.
Replications have their own downsides though. E.g. schema changes become harder because not all types of changes can be replicated. A stuck tx replication is a pain to resolve.
Before you start with any of this, make sure you have the appropriate indexes. The view sys.dm_db_missing_index_details can help you with that. Check out the MSDN article to see how to query the view.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am getting started working on a Java project I inherited from my predecessor. I am new to SQL, but SQLite is used to store various different types of data in this system. Previously, I always would store this type of information in internal Java data structures (i.e. Hashmap of usernames, etc.)
My question is why is SQL considered a better alternative?
SQL solves a number of problems that are not addressed by native programming languages. These may not be important for a particular application. But, here are some examples.
SQL can process data both from disk and in memory, transparently. It has the notion of a table, which is persistent and stored on disk, but the processing can all be in memory (if the table is already loaded into the page cache).
SQL seemlessly handles data as it gets larger, managing both memory and disk.
SQL handles security and authorization. New methods do not have to be invented.
SQL ensures atomicity of transactions, so you don't have to worry about partial updates to the system in the event of a failure.
SQL seemlessly enables multiple clients to access the same data, with the database taking care of concurrency issues.
SQL can readily handle multiple different types of entities and the processing needed to combine them.
Although not applicable to SQLite, SQL often takes advantage of multiple processors and multiple disks -- transparently to the application.
However, I must emphasize, this doesn't mean that all data in all applications should be stored in a database (although I do lean in that direction). You may have an application where an external data store simply isn't necessary.
An external database such as SQLite provides persistence and allows you to share data among multiple instances of your application.