主页 / dba / 问题 / 168411
Accepted
User1974
Asked: 2017-03-29 09:21:56 +0800 CST

版本控制：该技术是否用于空间以外的 DBMS？

  • 772

ESRI 的空间数据库管理系统，称为地理数据库(更多)，使用一种称为版本控制的技术。

版本表示整个地理数据库的时间快照，并包含地理数据库中的所有数据集。

版本不是地理数据库的单独副本。相反，版本和其中发生的事务在系统表中进行跟踪。这将用户的工作隔离在多个编辑会话中，允许用户在不锁定生产版本中的功能或立即影响其他用户且无需复制数据的情况下进行编辑。

状态树 http://help.arcgis.com/en/geodatabase/10.0/sdk/arcsde/concepts/versioning/basicprinciples/state.htm

将数据集（要素类、要素数据集或表）注册为版本时，会创建两个增量表：A（或添加）表，记录插入和更新，D（或删除）表，存储删除。每次更新或删除数据集中的记录时，行都会添加到其中一个或两个表中。因此，版本化数据集由原始表（称为基表或业务表）加上增量表中的任何更改组成。当您进行填充增量表的编辑时，地理数据库会跟踪您连接到的版本。当您查询或显示版本中的数据集时，ArcGIS 会组合原始表和增量表中的相关行以呈现该版本数据的无缝视图。

在此处输入图像描述

老实说，我发现文档相当模糊；它并没有告诉我很多关于该技术的实际工作原理，或者它基于传统数据库理论的哪一部分。

我不认为许多 DBA SE 社区成员会使用 ESRI 的版本控制技术。所以我不会问“它是如何工作的？”之类的问题。

相反，我想知道，在非空间数据库领域是否有任何类似于 ESRI 版本控制的技术？

spatial data-versioning

3 个回答

  1. 您所描述的内容似乎与 MMVC 非常相似- https://en.wikipedia.org/wiki/Multiversion_concurrency_control不同的客户端可以拥有同一数据库的不同“视图”或“版本”，并且无法通过事务进行编辑被其他会话看到，直到他们通过执行“COMMIT”决定这样做。

    该概念并非空间数据库所独有（维基百科引用了 1981 年的一篇论文作为其最早的描述之一：https ://en.wikipedia.org/wiki/Multiversion_concurrency_control#cite_note-3 ），但该概念必须早于那。虽然我看到了额外维度的一些特殊需求和实现，但要点是相同的。

    当然，实现方式因引擎而异。Git，即使不是数据库，它也必须以特定的方式实现并发控制，而这将与 postgres 的方式完全不同。如果然后我们去分布式数据库，我们就到达了通过网络保持一致性思想异构系统的狂野西部。您想要一个对最有用的情况具有高性能的实现，并且所有优化都意味着对被认为不那么重要的操作进行权衡。对于小交易规模来说速度很快的一种可能对于大型编辑来说太昂贵或难以忍受。此外，不同的数据库引擎以自己的方式解释诸如一致性级别之类的东西。

    好消息是，随着开源数据库系统的兴起，你不再需要阅读大量的手册来了解内部发生的事情——你可以自己直接阅读源代码并理解它们是如何编写的。例如，对于 Innodb：

    • 4

  2. 为了兴趣的缘故，并回应@jynus 的回答：

    有一个组件versioning叫做versioned views. 版本化视图以前称为multiversion views，这与 @jynus 关于multiversion concurrency control.

    版本化视图包含数据库视图、存储过程、触发器和函数，使您可以使用结构化查询语言 (SQL) 读取或编辑地理数据库表或要素类中的版本化数据。当您查询版本化视图时，您可以看到基（业务）表中的数据和存储在增量表中的编辑。当您使用 SQL 编辑版本化视图时，版本化视图使用的触发器会更新增量表。

    下面是版本化视图的定义：

    SELECT 
    b.OBJECTID
    ,b.A_TEST_FIELD
    ,0 SDE_STATE_ID 
FROM 
    USER1.A_TEST_TABLE b
    ,(SELECT 
         SDE_DELETES_ROW_ID
         ,SDE_STATE_ID 
      FROM 
         USER1.D47430 
      WHERE 
         SDE_STATE_ID = 0 
         AND SDE.version_util.in_current_lineage (DELETED_AT) > 0
       ) d 
WHERE 
    b.OBJECTID = d.SDE_DELETES_ROW_ID(+) 
    AND d.SDE_STATE_ID IS NULL  
    AND SDE.version_util.get_lineage_list > 0 

UNION ALL 

SELECT 
    a.OBJECTID
    ,a.A_TEST_FIELD
    ,a.SDE_STATE_ID 
FROM 
    USER1.A47430 a
    ,(SELECT 
         SDE_DELETES_ROW_ID
         ,SDE_STATE_ID 
      FROM 
         USER1.D47430 
      WHERE 
         SDE.version_util.in_current_lineage (DELETED_AT) > 0
      ) d
 WHERE 
    a.OBJECTID = d.SDE_DELETES_ROW_ID(+) 
    AND a.SDE_STATE_ID = d.SDE_STATE_ID(+) 
    AND SDE.version_util.in_current_lineage (a.SDE_STATE_ID) > 0 
    AND d.SDE_STATE_ID IS NULL
    • 2
  3. Best Answer

    Oracle 几乎从一开始就实施了 MMVC。它的主要目的是减少更新期间的争用：使读者和作者之间不会互相阻塞。但这与 ESRI 提供的多版本控制不同。传统的数据库事务是短事务：它们只持续很短的时间：亚秒、秒……对于某些批处理过程可能是几分钟甚至几小时。

    ESRI 提供的那种版本控制适用于长事务。在这里，事务可以持续数天、数周、数月……理论上，数据库可以使用短事务来执行此操作：只是不要提交，并希望您的会话持续数天或数月。显然是不可能的保证。

    所以 Oracle 实现了自己的长事务/多版本控制机制。它称为 Oracle Workspace Manager (OWM)。有关详细信息，请参阅http://docs.oracle.com/database/122/ADWSM/。

    在 OWM 中，用户在工作空间（ESRI 称之为版本）中工作。工作空间是协作的：多个用户可以在同一个工作空间中工作。在工作区中完成的更新仅对该工作区中的用户可见。工作区中的更改通过合并操作应用于父工作区。子工作区可以通过刷新操作开始查看其父工作区中所做的更改。OWM 包括用于冲突检测和解决、长期锁定、变更检测、历史、“假设”场景的所有机制......

    与 ESRI 的版本一样，OWM 的工作空间形成了嵌套工作空间的层次结构，最上面的是 LIVE（或“竣工”工作空间）。

    OWM 对应用程序是完全透明的：它们像往常一样与表和视图交互。引用完整性在每个工作区的上下文中得到维护。

    请注意，OWM 与 GIS 没有特定关系：多版本表可以是任何类型的——而不仅仅是“空间”表。但是，许多需要安全长事务机制的 GIS 工具都使用它：例如 Autodesk Map、Bentley Maps、Geomedia Transaction Manager。许多客户还在任何 GIS 之外使用它。

    从概念上讲，它与 ESRI 的方法非常相似：基本操作相同（但可能使用不同的术语）。然而，实现方式不同：ESRI 将更改保存在单独的表（“A”和“D”表）中，而 Oracle Workspace Manager 将它们全部保存在主表中。视图使使用变得透明。

    所以是的，多版本控制/长事务肯定用于空间数据库的其他上下文中的数据库中。

    • 1

相关问题