Database Architecture

In general, the architecture of the database is governed by the trade-off between consistency/integrity and availability and speed.

Typical architecture The main products Availability Speed Consistency/Integrity
Relational Database(RDB) SQL Server
Oracle
MySQL
NoSQL MongoDB
Redis
Google BigTable
Amazon DynamoDB
HBase
Cassandra

Some said the Era of Relational Database (RDB) is now at the end and now is the age of NoSQL, but we believe it is better to combine the respective characteristics.
Please let me decide what to choose what kind of architecture depending on the use case.
As in the above table, for availability and speed is fast enough, respectively, consider the architecture to meet the Consistency/Integrity requirements.

So, our policy is as follows

  • User experience takes precedence over the availability and speed.
  • Important data is saved in favor of consistency/integrity.

The above policy does not have a difference at the time of normal operation. There is no difference when you are a small operation on a single server.
There is a difference when runing multiple server and there is a failure on server.
In case of R
elational Database (RDB) (Depending on the configuration) the entire site is more likely to stop. This is because the server is stopped with an emphasis on consistency/integrity.
NoSQL will continue the server basically. This is because NoSQL prioritize the availability rather than consistency/integrity.

Which is good or is based on the use case.

NoSQL doesn't have a refined technique to normalize the data as Relational Database (RDB). If data is simple application can be immediately implemented in the NoSQL. So, it seems simple at first glance. However, operation of NoSQL will be difficult gradually as the data becomes complicated and increases the risk of bankruptcy.

Therefore, we use Relational Database (RDB) as a first choice, consider the use of NoSQL in the case where access is increased.
To avoid the complex management by using different database architecture,
we use only Relational Database (RDB) as long as possible, then use NoSQL in addition to Relational Database (RDB) when it is required.

Recent server has a high perfomance. So, Relational Database (RDB) can be used for the basic use.

As the scale is expanding, it will follow the following configuration.

Step Scale Configuration Database to be used
1 Small Web and Database on a single low-speed Server Relational Database (RDB) only
2 Middle Web and database on a single high-speed Server (scale-up) Relational Database (RDB) only
3 Big Some Web server and Some Database Server (scale-out) Relational Database (RDB) only (*1)
4 Very Big Many Web server and Many Database Server (scale-out) Relational Database (RDB) only (*1)
OR
The combination of Relational Database (RDB) and NoSQL

(*1) Supplemental: In accordance with the requirements of the data, some data which consistency/integrity is important will make all server to stop entirely when some server is failed regarding the data. On the other hand, if some data's consistency/integrity can be postponed until server recover when some server fails, we define server to continue regarding that data. By doing this, the requirement which is typical for NoSQL can be fulfilled by Relational Database (RDB). It's more simple to manage by using only Relational Database (RDB) rather than using both Relational Database (RDB) and NoSQL.

■Useful use cases for NoSQL

It is useful when offered data is relativety fixed, rarely updated, the number of access is huge and multiple server is necessary such as online shopping mall.

  • The number of access is huge. Scale Out is necessary by multiple servers.
  • The case if it is enough to run server independently basically.
  • The case if the priority of consistency between severs is low.

So, it is not wise to use NoSQL if the number of access is small. It is because the consistency and data structure has sometimes a problem in NoSQL.

■NoSQL is weak for data structure

Relational Database prioritize the consistency of data by defining data structure. On the other side, NoSQL prioritize the speed and availability rather than consistency. It is enough to fulfil consistency later for NoSQL. In our company, Relational Database is a first choice. We prioritize the consistency by defining Database Structure confidently. In addition to that, we will use NoSQL in case of special case when Speed and Availability is important.

■There is a misunderstanding. NoSQL is not easy to develop, not quick

Some NoSQL save data without defining a structured data in the database, which is so called Document-Oriented, Document Store Database. Such a NoSQL sometimes appeals the easiness or quick development because you do not define the data but it could become a time bomb to break down firmly because data structure is not defined in NoSQL database system. The management of data structure will be difficult at the later phase. It is beneficial to use NoSQL with an understanding of the advantages and disadvantages, but it is not necessarily a simple comparison theory of "easy development" or "quickly make" which is the blurb that close-up of the only one side. In fact it is truely necessary define data structure as a design regardless of defining data structure in database regardless of Database type such as Relational Database which requires the definition of data structure or NoSQL which does not necessarily require it otherwise management is not possible. So, Relational Database is better to design and use data structure definitely. The use case for NoSQL is truely limited.

■Solve problem of Relational Database development by Matsuesoft Database Cloud

When using Relational Database, the implementation is a problem because of it's development effort if code manually. The hard work of coding will be reduced by Matuesoft Database Cloud. Then development will be fast by that. This is our strength. See article about Database Technology.

LoginLogin with this Site's User Name (ID)
Quick Login:Quick Login by Facebook ID (Keep Login Option:ON) / Newly Register


Inquiry

© 2016-2017 Matsuesoft Corporation

Follow Matsuesoft