the Serverless design of embedded database system（嵌入式数据库的无服务设计的概念）

本文有选择性的翻译。

VistaDB Embedded Serverless Design

VistaDB.Net > See It! > Technical > Serverless database design

In Process vs Client Server（进程内模式VS 客户端-服务器模式）

Most SQL engines are implemented in a separate process known as the Database Server process.  Client applications usually communicate to the Database Server over named pipes or TCP/IP sockets.  The results of the client request are usually transmitted through this communication channel back to the client app (which may be on the same, or a different machine).

大部分的SQL引擎都会部署于与应用程序相分离的数据库服务进程中。客户应用通常会通过管道或者TCP/IP套接字与数据库服务通信。客户应用请求的结果会通过这样的通信管道返回给客户应用。

Embedded Database

VistaDB works as an embedded database. Our small database engine loads within your process and communicates directly with the database file.  There are no other processes between your application and the database.  This is sometimes referred to as an embedded database (the database engine is hidden from the user by being embedded into your application).

VistaDB是以嵌入式数据库的方式工作。其精小的数据库引擎会加载到你的应用进程中运行并且直接与数据库文件通信。在这种模式下，应用和数据库之间并没有其他的任何进程在工作。这就被称为嵌入式数据库（数据库引擎通过嵌入到你的应用中从而使得用户并不知道其存在）。

Pros / Cons

Of course there are pros and cons to every design.  The main advantage is that each client is just xcopy deployed, there is nothing to setup or configure on the target machine (known as zero config).  Applications built using VistaDB require no admin rights on the target machine in order to run.  The embedded database engine lives only as long as your application is running.  Once your application exists, so does the database engine.

This also means that bugs in your application can cause crashes that affect the database engine. A Database Server is isolated from the client application and does not care if the client application is aborted or terminated by a user.  VistaDB must be very conservative in the writing of data to disk as a result of our engine being embedded with your application.  In the event of an abnormal termination we must ensure data integrity to the VDB3 file on disk.

Database Servers also allow a much finer grain control for concurrency locking.  This is usually being handled by the central process that understands which threads have locks on different database objects.  We do not communicate between application instances and must therefore provider lower level locking through the database on disk, this is slower because the disk is the slowest IO device (usually). Most other in-process (or Serverless) database engines do not allow multiple processes to update the database for these design reasons.  Embedded databases typically lock the entire database per insert operation, we do not.  We provide table and row level locking.

Caching of requests is another large benefit to the Database Server scenario.  If multiple users ask the same question (or their queries use the same indexes), the server process can load the data once and cache the output to the client.

VistaDB Server support?

We are often asked if we will support a VistaDB Server version.  Yes, we have one in the works.  But we are not calling the first version a Server because it will not support caching, query optimization, or user level access controls like SQL Server.  Our initial server-side application will be to get around the file sharing limitations imposed by Windows and allow faster locking for quicker multi process access to the database.