Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to choose the right database for the application". The content of the explanation in the article is simple and clear, and it is easy to learn and understand. let's study and learn "how to choose the right database for the application"!

Main memory database Redis

Our database is structured like a JSON object-each key is unique and each key points to a value.

It retains the data in memory, which is very fast, but has a capacity limit, so you can't store a lot of data. And because there are no disks involved, everything burns quickly.

There is no need for queries or joins, so there is no need to worry about too much data modeling. Without a schema, developers always have the flexibility to change the data according to their own needs.

When to use this technology

This technique is mainly used as a caching mechanism to obtain and observe some data very frequently at some times.

Therefore, critical value technology is widely used as a caching mechanism together with other databases.

Wide column database Cassandra

It's like a key value, but on steroids. Modify the value to store a set of columns instead of simple data.

By introducing columns, you can now group related data, but there is still no standard schema. Therefore, each key can point to different packet data.

Because there is no schema, it can handle unstructured data and attach a query language called CQL, which is similar to SQL, but the method is not so powerful.

There is a steady stream of data, such as viewing history from IoT devices, stock markets, financial transactions or Netflix.

When to use this technology

Often write

Update or read less

This is still not universal. Therefore, it can be used to store historical data from all of our different applications.

Document database

This is one of the most popular database techniques we use. This obviously consists of documents, each of which is a set of key-value pairs. They are unstructured and do not require patterns.

Documents are grouped into collections, and these collections can be constructed into logical hierarchies.

This logical set allows you to group related data in a more logical manner, which seems to be similar to a relational database.

Since our database cannot run the join query, how can we get all the relevant data immediately?

We store it all together! We encourage database de-normalization, and data replication / inconsistency is a compromise that we are ready for.

Reading is really fast, but it can be difficult to write and update data while ensuring data consistency.

Document databases are ideal for general-purpose applications and may be suitable for most applications, games, and IoT.

If you are really unsure about the database architecture, then the document database is the best way to start.

Popular document type database

When you have a large amount of data, document-style databases are not enough, and they may be directly or indirectly related to each other.

For these cases, you will have to run multiple complex queries and then merge all received data in the front-end application, or you can use a relational database, where these complex queries are managed by the database.

Relational database

We've all heard of these databases, and the most popular ones are MySQL,Postgres and SQL Server. They are here all the time and are still a popular choice for many applications.

We use structured query language (SQL).

The meaning of "relationship"

Imagine a car factory with different wheels that make car parts.

Suppose the door is made in one place, while the wheels, body and interior are all made in different locations.

> Imaginary car-factory blueprint

Each manufactured part has a unique ID assigned to it.

So, once you have to assemble the car, you can extract all the parts from all these different locations and assemble the car.

For the establishment of such a factory, we will create a blueprint for such a factory, which makes the overall process of manufacturing cars very efficient and optimal. When it is used in a database, this blueprint is called a schema.

Therefore, we need to plan the schema of the database to ensure that our database is very efficient for the data requirements of the application.

shortcomings

Just like how to change the layout of the car factory over time, it will cost the car company a lot of time and money, which is a similar situation when large-scale applications have to do so. Be sure to use a relational database when your requirements are clear.

In addition, once you build a factory that makes 30 cars a month, you cannot easily expand your factory to make 90 cars a month. Similarly, our relational database may work harder, but cockroach DB and PostgreSQL have some exceptions designed to prevail in proportion.

On the bright side

The SQL database complies with the ACID standard, which means that even if there is a possible failure between read and write operations, the validity and integrity of our data will not be compromised-which makes it very suitable for banking / finance-related data

Once a schema is in place, you can rest assured that the stored data will always be stored in a set of fixed structures after validation, which you will define in the schema

What suits you best?

If your requirements are clear and you are sure that you do not need to make any major changes to the requirements, please continue to do so

If you are not sure about the requirements and are in the experimental stage, it is best to use the NoSQL database

But what if we don't need to create a schema and can store relationships directly as data?

Graph database

Here our data is stored in the node, and the relationship is defined as an edge. Very beautiful! Let's see how.

If you have to find all students studying computer science in the SQL database, you need a find / broker table that stores the records of all students separately for all students studying computer science.

In the drawing, this will be more straightforward, because we don't have to store the relational parts of the data separately, and it instinctively is this new style.

> Relationships are easier to record and maintain in graphs

Through this new method of directly showing the relationship between two nodes, our complex join query becomes simpler, and the performance of the database is greatly improved compared with SQL.

Therefore, you use this kind of database when you rely on a large number of join operations, and because it depends on performance degradation.

Search database

If you're building an application like Google, in a small string query search, you must quickly return all matching records-you're talking about a full-text search engine.

These databases are based on the Apache Lucene project that began in 1999.

Algolia and Meilisearch are full-text search engines.

They look similar to document-type databases. We have an index and add data objects to it. The search database engine analyzes all the text in the document and creates content called a reverse index.

When you query something, the database only checks the reverse index, which makes the whole process seem fast, even for large databases.

I saved the most exciting one.

Multi-model database

There are many choices, but the most popular choice seems to be fauna.

As application development, we usually only care about JSON, which we can consume in the front end of our application.

With Fauna, we don't have to worry about data modeling, architecture, scaling, replication, or normalization, and we just need to get our JSON data. We defined how to access our data using GraphQL.

Let's shoot an example of an application like instagram. We will use JSON to define our rules for users, posts, and queries.

We just uploaded our GraphQL schema-it automatically creates a collection of stored data and indexes to query the data.

Behind the scenes, it is how to take advantage of different examples of relationships, graphics, and documents based on the GraphQL schemas you provide.

We just add our data in the same way as in the document database, and we don't encounter the limitations of data modeling.

The best part-it's acidic, very fast.

You don't have to worry about the infrastructure. Just define how you need the data, and the cloud will do the rest for you.

Shortcoming

Obviously, pricing is disadvantageous. Great things are not free, but they do offer generous planning / open source options for developers and small startups who want to learn.

Here are some of the important features listed by Fauna:

Thank you for your reading. the above is the content of "how to choose the right database for the application". After the study of this article, I believe you have a deeper understanding of the problem of how to select the appropriate database for the application. The specific use of the situation also needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.