-1

i am a junior programmer who have no background or so ever in dbs, i only encounter mongodb during my yearly programmer work and these it. Lastly I'm trying to understand the advantages of micro service design, and one of the reasons was "if you want to scale part of the app but you only want to leave one writing service for the dbs. Because you never want to have more than one db (or duplicate it?)”.

My question is, it is really wrong to have more than one db for the same table/schema? Because it sounds problematic in scale.

Thanks, Or

2 Answers 2

1

It is a technical choice that must be made at design time and it is not good or bad. It is good or bad to choose SQL vs NOSQL? It depends...

A service that will be used by many customer while hosted on your servers may simplify maintenance for you if everything is in a single database. That choice requires data separation made by the business layer (sql code with more filters and/or application level filtering) hence more complexity at that layer (more $$$ in development). This solution also require more attention to security because the possibility for a customer to read on the data of other customers (more $$$ here too).

The above does not holds true (or at least is much less appealing) if the data size grows: having billions of entries for each customer it is usually wise to find a way to partition in order to speed up operation on data (read, write, backup, restore...). Some database engines offer partitioning features, some does not and this is another factor driving the choice.

If the application is deployed on customer's premises then it is somewhat easier if there is a single instance per customer.

Scaling may be done with more resources or more instances: the right choice depends on the context and again there is no one-size-fit-all answer here...

1
  • Thank you, i thought that keep all the dbs sync is the mail problem that they addressing by this sentence
    – Or Halimi
    Aug 23, 2019 at 13:07
0

One issue for larger databases that have a lot of reads and writes is that everything can be slowed down. To combat this, you can have the applications write to one database, then at regular intervals copy to a second one for all the resource-heavy reads. This usually wouldn't be noticed until the datasets reach the multi-million rowcounts, or there are a lot of inserts and updates per hour. I used one database that did this only for one part of their dataset, because there were 4 million records in one table, and it was being updated by the minute. This led to issues with reports that the upper management were running, so we ended up creating a second database on a second server that would update twice a day just for reporting.

If the intent is to separate for business reasons, like if you work for a management company that handles the databases for several other companies with near-identical data, then the two approaches I would suggest is either each company gets a database(s) on your server, or each one gets their own server for their data. Separate servers per company is best for security, but hosting them all on one server is a lot easier for management.

Not the answer you're looking for? Browse other questions tagged or ask your own question.