Бази данни, сървъри и вградени бази данни

Database Server

Database server refers to a database that runs as an independent server process and processes application requests over the network. Most RDBMS, familiar to us, such as MySQL, PostgreSQL, and Oracle DB, fall into this model. A database server has the following advantages:

• Centralized Management: Data is centrally managed in one place, facilitating consistency, security, backup, and recovery.
• Resource Independence: It is allocated its own CPU, memory, and storage, ensuring stable performance regardless of the application's state.
• High Concurrency and Scalability: Optimized for concurrent access by many users, and horizontal scaling through clustering or replication is relatively straightforward.

Thanks to these characteristics, database servers have become the standard for software infrastructure over the past few decades. However, due to technological advancements and environmental changes, the disadvantages of database servers began to emerge in some environments, and embedded databases are once again gaining attention as an alternative.

New Trend: Embedded Databases

An embedded database is a database engine that is included as a library within an application and runs within the same process, without a separate server process. SQLite, LevelDB, and RocksDB are typical examples of embedded databases. The reasons why these embedded databases have emerged as a powerful alternative in the latest technology environment are as follows:

• Emergence of SSDs

  In the past, in an HDD-centric system environment, random access performance was significantly lower compared to sequential data reading/writing performance. Therefore, minimizing disk I/O and maximizing memory caching was key to performance optimization. Database servers have overcome the physical limitations of HDDs by operating large caches and processing write operations in batches.

  However, the advent of SSDs has completely changed this premise. SSDs are thousands of times faster than HDDs in random I/O performance, and their latency is dramatically shorter. As a result, the existing perception that "disk I/O is the biggest bottleneck" has disappeared, and instead, delays caused by remote DB server access over the network have begun to emerge as a new bottleneck.

• MSA and Data Independence

  In the past, it was common for a single monolithic application to rely on a single centralized database. While simple, this approach presented challenges as the service grew, making data schema changes difficult and leading to excessively tight coupling as all services shared the same DB.

  In modern Microservices Architecture, the "Database per Service" principle is emphasized to solve these problems. Each service owns and encapsulates its dedicated data store, ensuring independence between services, and facilitating fault isolation and scaling. In this process, an embedded DB becomes an ideal choice for a service-unit data store. It is lightweight, fast, and can be deployed with the service code, making it very well-suited for MSA environments.

  For example, in Kubernetes environments, it is common practice to optimize local data processing by placing an embedded DB next to the application container using the sidecar pattern. This reduces network bottlenecks and minimizes data access latency.

• Simplified Operating Environment

  Database servers require complex operational procedures such as installation, patching, backup, disaster recovery, replication, and performance monitoring, which necessitate dedicated DBAs and specialized operational personnel. Especially in large-scale environments, this management burden is very significant.

  Embedded DBs significantly alleviate these issues. When a database is integrated within an application, unit testing, building, version control, and deployment are performed together, eliminating the need for separate server operations. Furthermore, when an application scales out, the embedded DB also scales with it, enabling automated management through DevOps culture and CI/CD pipelines. Especially in startups, small-scale services, and prototype development environments, embedded databases dramatically reduce operational complexity and significantly accelerate development and deployment speed.

• Evolution of High-Performance System Languages and Ecosystems

  In the past, it was common for databases and applications to be written in different languages. For example, high-performance database engines were primarily written in C, C++, while applications were developed in languages such as Java, Python, and PHP. While effective for performance optimization, this approach had limitations such as memory stability issues, complex concurrency handling, latency, and difficulties in library integration and deployment.

  However, with the recent emergence of modern system programming languages like Go and Rust, these limitations have been significantly mitigated. Go, in particular, is suitable for writing both high-performance applications and low-level programs like database engines, allowing databases and applications to be handled together within a single language ecosystem.

  Indeed, in Golang, high-performance embedded databases like BadgerDB and PebbleDB are actively used. This indicates that embedded databases are no longer just lightweight alternatives to database servers but have established themselves as important options with their own competitive advantages.

Conclusion

For conditions requiring centralized management of large-scale data, complex transactions, and high concurrency, database servers remain the most powerful solution. However, for individual services in an MSA environment, IoT edge devices, rapid prototyping, and projects where operational efficiency is crucial, embedded databases can be a more efficient and rational choice. Ultimately, the important thing is to choose the optimal tool that best suits the given situation and requirements, and the development of embedded databases provides us with a wider and more diverse range of options.