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

This article mainly explains "Why the shared database has become a thing of the past". The content of the explanation in the article is simple and clear, and it is easy to learn and understand. let's go deep into the editor's train of thought. Let's study and learn why shared databases have become a thing of the past.

The shared database paradigm is a common development workflow in which all developers on the team share access to a database and use the database to support application development.

This workflow is simple, and there is no need to configure the infrastructure for each engineer to minimize installation costs, so people are willing to choose it. But because engineers have to take the risk of affecting the work of others while making changes, it can also cause pain and bottlenecks for engineers.

Spawn makes it easy to configure the database and allows each engineer to have his or her own dedicated database environment without having to configure any additional infrastructure.

Shared database

The shared database usually contains a copy of the production database (properly masked to remove sensitive data and may be subset to reduce its size), which is shared by all developers on the team. The advantage of a shared database is that there is less infrastructure to manage, and developers only need to insert a connection string into the shared database to get up and running quickly.

While this setting is useful for a small team or a team that rarely makes database changes, it can quickly encounter some problems:

Step on each other: developers may try to make contradictory and mutually exclusive changes to the shared database, risking erasing each other's work.

Applications cannot be safely migrated: changing the database schema of one feature may break other code.

Unknown state: if the state of the database is not controlled by a single developer, error reproduction and application testing will become more difficult to change from one moment to the next.

The shared database model is increasingly lagging behind because containerization makes database provisioning easier than ever, eliminating the overhead of infrastructure provisioning.

One database per developer

Under this model, each developer on the team has his or her own (hidden) copy of the production database, from which you can work. This allows developers to change their database copies individually, thus resolving problems caused by contention for shared databases.

This has been difficult in the past because we had to provide each developer with a copy of the application database similar to production. However, by using Spawn, we can configure the tempdb instance from the command line without having to set up or host any other infrastructure:

With Spawn, we can create a data image every day from the production environment (as part of the planned build pipeline) and make this image available to developers and CI systems-- all using Spawn CLI. You can create an image from a backup file or script.

Each developer can then configure his or her own database based on this image without having to leave the command line as easily as running spawnctl create data-container.

Spawn creates and hosts a containerized database instance in a behind-the-scenes Kubernetes cluster, freeing the development team from the burden of managing their own database infrastructure and reaping all the benefits of dedicated database development:

Quickly provide databases of any size: Spawn uses block-level file system snapshots to recover and write to the database. This means that even the largest images can be configured in seconds and write at a high speed.

Snapshot and restore: you can use the Spawn CLI spawnctl save command to take a snapshot of the database at any time. Use spawnctlreset to revert to any previous state. There is no need to worry about database changes because it is always easy to restore.

No infrastructure is required: Spawn is responsible for provisioning and hosting databases, allowing developers to focus on code.

Multiple copies of the same image: one image can be used to provide as many databases as needed-all of which have their own connection strings, independent and separate from each other.

Multi-database support: Spawn supports SQL Server, Postgres, MySQL, Redis and Mongo.

Thank you for your reading. the above is the content of "Why sharing the database has become a thing of the past". After the study of this article, I believe you have a deeper understanding of why sharing the database has become a thing of the past. 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.