“实时”这个术语是数据库系统供应商随便说说的，但是实时在嵌入式系统中一直有特定的含义。“实时系统意味着系统是实时的，换句话说，响应应该在指定的时间限制内得到保证，或者系统应该满足指定的期限。例如，飞行控制系统、实时监视器等。”换言之，在嵌入式开发中，实时并不意味着真正的快速。在实时系统中，速度不是衡量成功的标准;决定论是衡量成功的主要标准。

　　实时系统正以令人难以置信的速度发展。实时系统曾经相对简单，比如飞机上的防抱死制动系统，以及后来的汽车。今天，实时系统更加复杂。高级驾驶辅助系统(ADAS)是典型代表。它们是现代实时系统复杂性的一个很好的例子。ADAS必须接收来自多个不同来源的数据，例如激光雷达、声纳、雷达、光学相机、GPS和地图等，这就产生了一个重大的传感器数据融合问题。有必要将所有数据放在一个中心位置(一个数据库!)以便可以关联、分析和采取行动(启动、停止、转向等)，所有这些都在严格的实时期限内完成。

　　但问题是：直到最近，还没有商用现货(COTS)嵌入式数据库可以用于实时系统，因为所有产品都不知道最后期限。为了说明这一点，嵌入式开发人员考虑一个必须在50毫秒内做出反应的实时系统。如所示图1，实时任务分别在5毫秒和10毫秒标记处完成前两步。然后，该任务调用数据库运行时。然而，数据库运行时不知道截止日期，直到截止日期到期时才把控制权交还给任务。这个系统失败了。

　　三个目标

　　为了适用于实时系统，嵌入式数据库运行时系统必须达到三个目标。第一，必须让它知道最后期限，并根据给它的最后期限记录已经过去的时间。第二，它不能有任何不具有时间认知的外部依赖。例如，数据库运行时不应调用malloc()(用于动态分配内存的C运行时函数)。第三个目标是它必须能够以适合实时系统的方式调度数据库事务。

　　1.最后期限—如果嵌入式数据库系统必须管理截止日期，那么嵌入式数据库运行时必须能够知道截止日期。只要数据库中的工作单元是一个事务，开始一个事务的数据库API就是将截止日期传递到数据库运行时的逻辑位置。随着事务的进行，数据库运行时需要根据截止日期频繁地检查进度，并且如果必要的话，中止事务以满足截止日期。在实时数据库系统中，事务可以满足(成功提交)或错过(成功中止)它们的截止日期，但绝不会迟到(超过它们的截止日期)。实现这一点并不像你想象的那么简单，除非你只针对一个实时操作系统(RTOS)，因为不同的RTOS有不同的管理时钟和定时器的方式。图2说明了事务的时间线。嵌入式开发人员感兴趣的是截止时间验证控制点和截止时间控制点。

　　2.外部依赖性—大多数嵌入式和实时系统都是用C/C++编写的。程序员倾向于自由地使用C运行时(CRT)库中的函数。在许多情况下，这是无害的，但是应该避免调用像malloc这样的CRT函数，或者执行输入/输出。它们具有与图1所示相同的风险:调用任务和(在本例中是数据库运行时)可能会在没有时间认知的CRT函数中消失，并且直到超过截止日期才返回，从而导致系统失败的风险。

　　3.行程安排—数据库通常由多个任务/线程/进程使用。数据库运行时必须协调任务对数据库的访问，以避免冲突。在行业术语中，这被称为并发控制，分为两大类：乐观和悲观并发控制。嵌入式开发人员使用悲观并发控制，一个任务请求访问一个资源，该资源可以是整个数据库、一个数据库表或一组表、一个数据库页或表中的一行。不管这些请求的粒度如何，数据库运行时的一个组件(通常称为锁仲裁器或锁管理器)需要协调这些请求。

　　通常，这是按照先进先出的顺序进行的。但是这对于实时数据库系统来说是不够的。实时数据库系统必须首先根据开发人员指定的优先级来调度事务，然后在相同的优先级内，首先根据最早的截止日期来调度事务。或者，实时数据库运行时必须利用优先级继承，以便已经运行的低优先级任务的事务可以提升到与新调度的具有更高优先级的事务相同的优先级。

　　重新想象的数据库

　　今天的实时系统正在经历增长，就像90年代末和21世纪初的嵌入式系统一样，当时嵌入式数据库成为一种必需品，因为嵌入式系统被赋予了更多的任务。业务线/部门计算嵌入式数据库需要重新设计，以便在嵌入式系统的资源限制内运行。这就是McObject的eXtremeDB开发的驱动力。现在，随着硬实时系统中数据管理需求的不断增长，嵌入式开发人员重新设想和设计了eXtremeDB，以创建eXtremeDB/rt，这是第一个在任务和安全关键实时系统的约束下运行的COTS确定性数据库管理系统。