CN103678494B - 客户端同步服务端数据的方法及装置 - Google Patents
客户端同步服务端数据的方法及装置 Download PDFInfo
- Publication number
- CN103678494B CN103678494B CN201310574904.0A CN201310574904A CN103678494B CN 103678494 B CN103678494 B CN 103678494B CN 201310574904 A CN201310574904 A CN 201310574904A CN 103678494 B CN103678494 B CN 103678494B
- Authority
- CN
- China
- Prior art keywords
- data
- record
- version number
- moment
- full dose
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2315—Optimistic concurrency control
- G06F16/2329—Optimistic concurrency control using versioning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/275—Synchronous replication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
Abstract
本发明公开了一种客户端同步服务端数据的方法及装置，属于数据库技术领域。所述方法包括：获取服务端的数据对象在第一时刻的全量数据；根据数据记录的版本号获取服务端的数据对象在第二时刻相对于第一时刻发生变化的增量数据，其中，所述第二时刻晚于所述第一时刻；合并所述全量数据和所述增量数据，得到数据对象在第二时刻的全量数据。根据本发明，能够减小客户端与服务端之间的交互次数以及交互传输的数据量，并能够降低客户端的存储消耗。
Description
技术领域
本发明涉及数据库技术领域，具体涉及一种客户端同步服务端数据的方法及装置。
背景技术
在基于客户端／服务器的应用系统中，客户端需要获取存储在服务器上的数据库记录，并且，当服务器上的数据库记录发生更新时，需要保证客户端的数据库记录与服务器上的数据库记录保持一致，即客户端需要同步服务器的数据记录。
现有的一种客户端同步服务端数据的方法是基于事件回放的机制，即当服务端某数据发生变化的时候，需记录下该数据的变化过程，然后基于这个变化过程，客户端拿到这个变化过程的数据，对这个过程进行重做，以保证客户端与服务端的数据记录一致。
假如原始数据如下：
| Nid | pid | status | Nv |
| 1 | 0 | 0 | 1 |
| 2 | 0 | 0 | 1 |
| 3 | 0 | 0 | 1 |
| 4 | 0 | 0 | 1 |
| 5 | 0 | 0 | 1 |
| 6 | 0 | 0 | 1 |
| 7 | 0 | 0 | 1 |
| 8 | 0 | 0 | 1 |
| 9 | 0 | 0 | 1 |
| 10 | 0 | 0 | 1 |
表1
在本发明中，nid为节点的标识，节点为数据库中的一行记录；pid为父节点的标识，父节点是子节点的上一级节点；status为节点的数据状态标识，包括表示数据记录未被删除的正常状态(用0标识)和表示数据记录已被删除的删除状态(用10标识)，其中，服务端对于数据库记录的删除，均为逻辑删除，即做状态标记，并非真正意义上的删除(物理删除)；nv为节点的版本号标识，当数据记录发生变化时，其版本号为所有数据记录中的最大版本号，所述变化包括增加、修改和删除。
服务端对数据库进行了更新(增加、修改或者删除了一些记录)，假如变化后的数据如下：
| nid | pid | status | nv |
| 1 | 0 | 0 | 1 |
| 2 | 0 | 0 | 1 |
| 3 | 0 | 0 | 1 |
| 4 | 0 | 0 | 1 |
| 5 | 0 | 0 | 1 |
| 6 | 0 | 0 | 1 |
| 7 | 0 | 0 | 1 |
| 8 | 0 | 0 | 1 |
| 9 | 7 | 0 | 2 |
| 10 | 0 | 0 | 1 |
| 11 | 5 | 0 | 3 |
| 12 | 5 | 0 | 4 |
| 13 | 5 | 0 | 5 |
表2
在表2中，变化的数据用黑体字标识。则基于事件回放的机制，服务端将会记录4条事件记录，用于描述数据库发生了什么变化，事件记录如下：
| update | 9 |
| insert | 11 |
| insert | 12 |
| insert | 13 |
表3
在表3中，update表示数据记录的修改，insert表示数据记录的增加。
客户端首先会从服务端获取这些事件记录，然后再通过nid把这些事件记录对应的数据记录取到本地进行合并，以实现增量同步。其中，在进行合并时，在节点标识相同的情况下，版本号大的数据记录覆盖版本号小的数据记录。
可以看出，根据现有的实现方式，客户端需要从服务端获取事件记录以及事件记录对应的数据记录，这使得客户端与服务端的交互次数较多，交互传输的数据量也较大；另外，客户端还需要额外的存储事件记录的开销；而且，服务端需要保证数据库的修改与这些事件记录保持一致，如果不一致，还需要兼容如何处理的问题，实现方式复杂。
发明内容
鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的客户端同步服务端数据的方法及装置。
依据本发明的一个方面，提供了一种数据同步方法，包括：
获取服务端的数据对象在第一时刻的全量数据，其中，所述全量数据为所述数据对象的所有数据记录构成的集合；
根据数据记录的版本号获取服务端的数据对象在第二时刻相对于第一时刻发生变化的增量数据，其中，所述第二时刻晚于所述第一时刻；
合并所述全量数据和所述增量数据，得到数据对象在第二时刻的全量数据。
可选地，所述数据对象具有多条数据记录，每条数据记录具有数据状态标识和版本号标识，数据状态包括表示数据记录未被删除的正常状态和表示数据记录已被删除的删除状态，当数据记录发生变化时，其版本号为所有数据记录中的最大版本号，所述变化包括增加、修改和删除，所述获取服务端的数据对象在第一时刻的全量数据，包括：
从服务端获取所述数据对象在第一时刻的所有数据记录的最大版本号bgsp；
从服务端获取所述数据对象中版本号小于等于bgsp的所有处于正常状态的数据记录，得到所述全量数据。
可选地，每条数据记录还具有节点标识，所述从服务器获取所述数据对象中版本号小于等于bgsp的所有处于正常状态的数据记录，得到所述全量数据，包括：
对所述数据对象中的数据记录按照版本号的降序+节点标识的降序进行排序；
分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最小版本号和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号小于等于bgsp的预定数目条处于正常状态的数据记录，得到本页的数据记录，其中，第一页数据记录的获取始于数据对象的第一条记录；
对分页获取到的数据记录进行合并，得到所述全量数据。
可选地，每条数据记录还具有节点标识，所述根据数据记录的版本号获取服务端的数据对象在第二时刻相对于第一时刻发生变化的增量数据，包括：
对所述数据对象中的数据记录按照版本号的升序+节点标识的升序进行排序；
分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最大版本号gsp和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号大于gsp的预定数目条数据记录，得到本页的数据记录，其中，所述第二时刻为最后一页数据记录的获取时刻，第一页数据记录的获取始于数据对象的第一条记录，且gsp采用bgsp；
对分页获取到的数据记录进行合并，得到所述增量数据。
可选地，每条数据记录还具有父节点标识，所述数据对象为数据库或者数据库的一个目录，所述目录为数据库中具有相同父节点标识的数据记录构成的集合。
可选地，当所述数据对象为数据库的一个目录时，服务端按照如下方式修改数据库中某条数据记录的父节点标识：新增一条与原数据记录相同的数据记录，将新增的数据记录的父节点标识进行修改，并将原数据记录的数据状态标识修改为删除状态。
可选地，当所述数据对象为数据库的一个目录时，所述方法还包括：对数据库的所有目录在第二时刻的全量数据进行合并，得到数据库在第二时刻的全量数据。
可选地，在合并所述全量数据和所述增量数据时，在节点标识相同的情况下，版本号大的数据记录覆盖版本号小的数据记录。
根据本发明的另一方面，提供了一种数据同步装置，包括：
全量数据获取单元，适于获取服务端的数据对象在第一时刻的全量数据，其中，所述全量数据为所述数据对象的所有数据记录构成的集合；
增量数据获取单元，适于根根据数据记录的版本号获取服务端的数据对象在第二时刻相对于第一时刻发生变化的增量数据，其中，所述第二时刻晚于所述第一时刻；
数据合并单元，适于合并所述全量数据和所述增量数据，得到数据对象在第二时刻的全量数据。
可选地，所述数据对象具有多条数据记录，每条数据记录具有数据状态标识和版本号标识，数据状态包括表示数据记录未被删除的正常状态和表示数据记录已被删除的删除状态，当数据记录发生变化时，其版本号为所有数据记录中的最大版本号，所述变化包括增加、修改和删除，所述全量数据获取单元进一步适于：
从服务端获取所述数据对象在第一时刻的所有数据记录的最大版本号bgsp；
从服务端获取所述数据对象中版本号小于等于bgsp的所有处于正常状态的数据记录，得到所述全量数据。
可选地，每条数据记录还具有节点标识，所述全量数据获取单元按照如下方式从服务器获取所述数据对象中版本号小于等于bgsp的所有处于正常状态的数据记录，得到所述全量数据：
对所述数据对象中的数据记录按照版本号的降序+节点标识的降序进行排序；
分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最小版本号和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号小于等于bgsp的预定数目条处于正常状态的数据记录，得到本页的数据记录，其中，第一页数据记录的获取始于数据对象的第一条记录；
对分页获取到的数据记录进行合并，得到所述全量数据。
可选地，每条数据记录还具有父节点标识，所述增量数据获取单元进一步适于：
对所述数据对象中的数据记录按照版本号的升序+节点标识的升序进行排序；
分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最大版本号gsp和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号大于gsp的预定数目条数据记录，得到本页的数据记录，其中，所述第二时刻为最后一页数据记录的获取时刻，第一页数据记录的获取始于数据对象的第一条记录，且gsp采用bgsp；
对分页获取到的数据记录进行合并，得到所述增量数据。
可选地，每条数据记录还具有父节点标识，所述数据对象为数据库或者数据库的一个目录，所述目录为数据库中具有相同父节点标识的数据记录构成的集合。
可选地，当所述数据对象为数据库的一个目录时，服务端按照如下方式修改数据库中某条数据记录的父节点标识：新增一条与原数据记录相同的数据记录，将新增的数据记录的父节点标识进行修改，并将原数据记录的数据状态标识修改为删除状态。
可选地，当所述数据对象为数据库的一个目录时，所述装置还包括目录合并单元，适于对数据库的所有目录在第二时刻的全量数据进行合并，得到数据库在第二时刻的全量数据。
可选地，所述数据合并单元在合并所述全量数据和所述增量数据时，在节点标识相同的情况下，版本号大的数据记录覆盖版本号小的数据记录。
与现有技术相比，根据本发明的技术方案，在获取服务端数据对象的全量数据后，根据数据记录的版本号获取服务端数据对象的增量数据，再将全量数据和增量数据进行合并以实现数据同步，减少了客户端与服务端之间的交互次数较以及交互传输的数据量，降低了客户端的存储开销，并降低了数据同步的复杂度。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1示出了根据本发明一个实施例的客户端同步服务端数据的方法流程图；
图2示出了本发明实施例中获取全局全量时客户端与服务端的交互示意图；
图3示出了本发明实施例中获取全局增量时客户端与服务端的交互示意图；
图4示出了本发明实施例中获取目录全量时客户端与服务端的交互示意图；
图5示出了本发明实施例中获取目录增量时客户端与服务端的交互示意图；
图6示出了根据本发明一个实施例的客户端同步服务端数据的装置结构图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
图1示出了根据本发明一个实施例的客户端同步服务端数据的方法流程图。参照图1，所述方法包括：
步骤102，获取服务端的数据对象在第一时刻的全量数据；
所述数据对象可以为存储在服务端的数据库，此种情况下，客户端需要获取服务端的数据库在第一时刻的所有数据记录，即数据库的全量数据。如果数据库的数据量较大，获取整个数据库的全量数据的操作将会消耗很长时间，对服务端和客户端的压力均较大，因此，所述数据对象也可以是数据库的一个目录。在获取到数据库的每个目录的全量数据后，将所有目录的全量数据进行合并，则可以得到整个数据库的全量数据。
其中，所述数据库具有多条数据记录，每条数据记录具有节点标识、父节点标识、数据状态标识和版本号标识，数据状态包括表示数据记录未被删除的正常状态和表示数据记录已被删除的删除状态，当数据记录发生变化时，其版本号为所有数据记录中的最大版本号，所述变化包括增加、修改和删除，所述目录为数据库中具有相同父节点标识的数据记录构成的集合。另外，服务端对于数据记录的删除，均为逻辑删除，即做状态标记，并非真正意义上的删除(物理删除)。
步骤104，根据数据记录的版本号获取服务端的数据对象在第二时刻相对于第一时刻发生变化的增量数据，其中，所述第二时刻晚于所述第一时刻；
由于当数据记录发生变化时，其版本号为所有数据记录中的最大版本号，因此，可以根据数据记录的版本号来获取增量数据。例如，可以记录数据对象在第一时刻的所有数据记录的最大版本号bgsp，这样，在获取增量数据的过程中，如果某条数据记录的版本号大于bgsp，就可以认为该条数据记录为相对于第一时刻的一个增量数据。
步骤106，合并所述全量数据和所述增量数据，得到数据对象在第二时刻的全量数据。
由于版本号大的数据记录比版本号小的数据记录新，因此，在本发明实施例中，全量数据和增量数据的合并方式可以采用：在节点标识相同的情况下，版本号大的数据记录覆盖版本号小的数据记录。
由上述可知，在本发明实施例提供的技术方案中，在获取完增量数据后，客户端将增量数据与全量数据进行一次合并，那么在这个时刻(获取完增量数据的时刻)，客户端与服务端数据就保证了完全一致。相对于基于事件回放的数据同步机制，该技术方案减少了客户端与服务端之间的交互次数较以及交互传输的数据量，降低了客户端的存储开销，并降低了数据同步的复杂度。
由于当数据记录发生变化时，其版本号为所有数据记录中的最大版本号，因此，在步骤102中，可以按照如下方式获取服务端的数据对象在第一时刻的全量数据：
从服务端获取所述数据对象在第一时刻的所有数据记录的最大版本号bgsp；
从服务端获取所述数据对象中版本号小于等于bgsp的所有处于正常状态的数据记录，得到所述全量数据(如果某条数据记录的版本号大于bgsp，说明该数据记录相对于第一时刻已经发生了变化，属于增量数据)。
由于数据对象包括的数据记录的条数通常较多，一次性获取所有的数据记录对客户端及服务端都会造成压力，因此，作为一种可选方案，可以分页获取所述数据对象中的数据记录，然后再将各页的数据记录进行合并。分页获取数据记录的过程中，数据对象中的数据记录也可能时刻在发生着变化，而且，服务端有可能用一条sql语句更新一批数据记录，造成多条数据记录的版本号相同(后文有详细分析)，因此，在获取完一页数据记录后，需要记录一个同步点，以便于根据所述同步点来获取下一页的数据记录。
基于以上分析，本发明实施例给出如下的分页获取数据记录以得到全量数据的方法：
对所述数据对象中的数据记录按照版本号的降序+节点标识的降序进行排序；
分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最小版本号和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号小于等于bgsp的预定数目条处于正常状态的数据记录，得到本页的数据记录，其中，第一页数据记录的获取始于数据对象的第一条记录；
对分页获取到的数据记录进行合并，得到所述全量数据。
也就是说，除了最后一页外，获取到的每页的数据记录的条数为所述预定数目，可以理解的是，最后一页包括的数据记录的条数小于等于所述预定数目。所述预定数目可以根据客户端以及服务端的处理能力来确定，例如，可以将其设置为100。
类似地，本发明实施例还给出如下的分页获取数据记录以得到增量数据的方法：
对所述数据对象中的数据记录按照版本号的升序+节点标识的升序进行排序；
分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最大版本号gsp和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号大于gsp的预定数目条数据记录，得到本页的数据记录，其中，所述第二时刻为最后一页数据记录的获取时刻，第一页数据记录的获取始于数据对象的第一条记录，且gsp采用bgsp；
对分页获取到的数据记录进行合并，得到所述增量数据。
可选地，当所述数据对象为数据库的一个目录时，所述方法还包括：对数据库的所有目录在第二时刻的全量数据进行合并，得到数据库在第二时刻的全量数据。
另外，当所述数据对象为数据库的一个目录时，在获取目录的增量数据时，客户端有可能无法感知对数据记录的父节点的修改所引起的数据记录的变化(后文有详细分析)，为解决该问题，在本发明实施例中，服务端可以按照如下方式修改数据库中某条数据记录的父节点标识：新增一条与原数据记录相同的数据记录，将新增的数据记录的父节点标识进行修改，并将原数据记录的数据状态标识修改为删除状态。
如前所述，本发明实施例在进行客户端与服务端的数据同步时，同步的数据对象可以是存储在服务端的数据库，也可以是数据库的一个目录。以下结合实例分别对这两种情况进行详细描述。在以下的描述中，将数据对象为数据库的同步分为全局全量同步和全局增量同步两个过程，将数据对象为目录的同步分为目录全量同步和目录增量同步两个过程。
参照图2，本发明实施例中获取全局全量时客户端与服务端的交互过程如下：
客户端在首次启动时可以请求全局全量同步，首先向服务端请求当前时刻数据库中所有数据记录的最大版本号bgsp，服务端可以通过执行sql查询语句来获取bgsp，并将获取到的bgsp返回给客户端；
然后，客户端根据bgsp请求获取当前时刻数据库中第一页的所有正常节点(即版本号小于等于bgsp的所有正常节点)，服务端通过执行sql查询语句来获取并返回符合条件的节点列表、gsp(当前页的数据记录的最小版本号)和spnid(当前页的最后一条数据记录的节点标识)；
其次，客户端将gsp和spnid发送到服务端，请求数据库中第二页的所有版本号小于等于bgsp的正常节点，服务端以gsp和spnid作为同步点定位到第二页，并返回符合条件的节点列表、gsp(指更新后的gsp)和spnid；
依次类推，直到客户端获取到服务端的数据库中版本号小于等于bgsp的所有节点后，合并节点信息到本地缓存。
在上述过程中，服务端对数据库中的数据记录是按照版本号的降序+节点标识的降序进行排序。
由于上述获取全量数据的过程是分页获取的，可能在数据获取的过程中或者获取完全量数据之后的某个时刻，在服务端有部分数据被修改或者有节点新增和删除，因此，在做完全局全量同步之后，需要根据bgsp这个点，查询是否有新增或者变化的节点。当数据库中有发生变化的节点时，需要做全局增量同步，其中，全局增量同步的触发条件可以是：服务端主动通知客户端进行全局增量同步，或者，客户端向服务端询问数据记录的版本号是否发生了变化，并根据服务器的反馈来启动全局增量同步。
参照图3，本发明实施例中获取全局增量时客户端与服务端的交互过程如下：
全局增量同步被触发时，客户端首先将bgsp发送到服务端，服务端获取数据库中版本号大于bgsp的第一页数据记录，并向客户端返回第一页的节点列表、gsp(当前页的数据记录的最大版本号)和spnid(当前页的最后一条数据记录的节点标识)；
然后，客户端将gsp和spnid发送到服务端，服务端以gsp和spnid作为同步点定位到第二页，并返回版本号大于gsp的节点列表、gsp(指更新后的gsp)和spnid；
依次类推，直到服务端遍历完数据库中的所有数据记录后，客户端合并节点信息到本地缓存；
最后，客户端清除垃圾数据(同步过程中用到的临时变量，例如gsp和spnid等)。
在上述过程中，服务端对数据库中的数据记录是按照版本号的升序+节点标识的升序进行排序，即按照版本号的升序对所有数据记录进行排序，对于版本号相同的多条数据记录，则进一步按照节点标识的升序进行排序。
例如，未排序时的数据库记录如下：
| nid | pid | status | nv |
| 1 | 0 | 0 | 1 |
| 2 | 0 | 0 | 1 |
| 3 | 0 | 0 | 5 |
| 4 | 0 | 0 | 5 |
| 5 | 0 | 10 | 4 |
| 6 | 0 | 0 | 5 |
| 7 | 0 | 0 | 1 |
| 8 | 0 | 0 | 1 |
| 9 | 0 | 0 | 1 |
| 10 | 0 | 0 | 2 |
| 11 | 0 | 0 | 2 |
| 12 | 0 | 0 | 3 |
表4
则按照上述排序方式排序后的数据库记录如下：
| nid | pid | status | nv |
| 1 | 0 | 0 | 1 |
| 2 | 0 | 0 | 1 |
| 7 | 0 | 0 | 1 |
| 8 | 0 | 0 | 1 |
| 9 | 0 | 0 | 1 |
| 10 | 0 | 0 | 2 |
| 11 | 0 | 0 | 2 |
| 12 | 0 | 0 | 3 |
| 5 | 0 | 10 | 4 |
| 3 | 0 | 0 | 5 |
| 4 | 0 | 0 | 5 |
| 6 | 0 | 0 | 5 |
表5
在获取到全局全量数据和全局增量数据后，把增量获取的数据与全量获取的数据做一次合并，合并的规则为：nid相同的条件下，nv大的节点覆盖nv小的节点。当增量获取完成时，那么客户端获取到的节点数据即为该时刻，服务端最新的数据。
以下对本发明实施例中引入spnid的原因进行分析说明。
通常情况下，对数据节点的操作采用的是批量操作，即：一条sql语句更新一批数据，如果需要保证每个节点的nv不相同的话，则需要对每一个节点进行单独更新，这样的结果则会严重影响数据库系统的性能，因此，在本发明实施例中nv可以重复，并且不限制nv重复的数量(即具有相同nv的节点数量)，以解决批量操作的问题。由于采用的是增量同步，所有的同步点会依赖于nv，因此，无论在获取全量数据或者是增量数据时，都是通过nv排序，然后再基于gsp来获取数据。但是如果nv重复，会引入另外一问题，即：
假如有1000条节点的记录，nv分别为1，2，3，4，....，1000(nv不重复)，每次获取100条记录，通过10次可以把这1000条记录获取完成。当获取到第一页后，会把第一页中最大或最小(根据排序方式的不同)的nv返回给客户端，这个nv值即为前述gsp，当获取到第二页时，则会直接取nv＞100，然后再往后获取100条即为第二页的数据，依次类推。但是，当出现nv重复的情况下，按照上述的的方案就不能准确的定位到第二页的数据了。因此，在gsp的基础上，本发明实施例中引入了spnld的概念，将gsp与spnld进行结合来作为同步点。具体情况如下：
假设记录如下(nv重复)：
| nid | pid | status | nv |
| 1 | 0 | 0 | 1 |
| 2 | 0 | 0 | 1 |
| 3 | 0 | 0 | 1 |
| 4 | 0 | 0 | 1 |
| 5 | 0 | 0 | 1 |
| 6 | 0 | 0 | 1 |
| 7 | 0 | 0 | 1 |
| 8 | 0 | 0 | 1 |
| 9 | 0 | 0 | 1 |
| 10 | 0 | 0 | 1 |
表6
假设客户端每次获取5条记录，第一次获取全量过程(以mysql查询为例)，sql语句如下：
select*from table where 1 order by nv desc limit 1；／／获取bgsp
此时，返回的bgsp为1。
获取全局全量(客户端会把bgsp，gsp，spnid传给服务端进行获取，第一次获取时，gsp等于bgsp，spnid默认为0)时，服务端逻辑的伪代码如下：
此时，第一页返回nid为10、9、8、7、6的这5条数据，返回的gsp为1，spnid为6。
需要注意的是，当全量获取完成后，第一次获取增量时，增量的gsp为bgsp，之后每做完一次全局增量，服务端都会返回一个新的gsp，客户端每次获取增量时，便会通过将这个gsp发送给服务端来获取。
当全量获取完成后，由于某些操作，发生了新增或者修改，表6的数据变化为：
| nid | pid | status | nv |
| 1 | 0 | 0 | 1 |
| 2 | 0 | 0 | 1 |
| 3 | 0 | 0 | 1 |
| 4 | 0 | 0 | 1 |
| 5 | 0 | 10 | 4 |
| 6 | 0 | 0 | 1 |
| 7 | 0 | 0 | 1 |
| 8 | 0 | 0 | 1 |
| 9 | 0 | 0 | 1 |
| 10 | 0 | 0 | 1 |
| 11 | 0 | 0 | 2 |
| 12 | 0 | 0 | 3 |
表7
表7中数据的变化用黑体字表示，相对于表6，增加了nid为11和12的两条记录，nid为5的这条记录被删除，因此，能够通过gsp这个点，获取到这个点之后所有变化节点的数据(包含增加、修改和删除)。
在获取全局增量时，以sql为例(上面例子获得的gsp为4)，假设客户端每次获取10条增量，伪代码则如下：
此时会返回nv为2，3，4的3条记录，同时返回gsp，spnid，此时，gsp为4，spnid为12。
在获取完全局增量后，客户端将全局增量与本地数据进行一次合并，假如此时服务端数据没有再变化，那么这个时刻(获取完全局增量的时刻)，客户端与服务端数据就保证了完全一致。
以上介绍的是全局全量和全局增量的方案。但是，对于移动端设备(网速慢)，由于进行一次全局全量同步，可能数据量会比较大，在手机等2G网络的设备下，如果数据量太大，进行一次全局全量同步，将会消耗很长的时间，严重影响使用速度，因此，还可以采用基于目录(或者叫层级的全量同步与增量同步)的同步方案。
参照图4，本发明实施例中获取目录全量时客户端与服务端的交互过程如下：
当用户进行到某个目录时，首先向服务端请求当前时刻此目录中所有数据记录的最大版本号bdsp(为区别于全局全量时的bgsp，此处采用bdsp)，服务端可以通过执行sql查询语句来获取bdsp，并将获取到的bdsp返回给客户端；
然后，客户端根据bdsp请求获取当前时刻该目录中第一页的所有正常节点(即版本号小于等于bdsp的所有正常节点)，服务端通过执行sql查询语句来获取并返回符合条件的节点列表、dsp(当前页的数据记录的最小版本号)和spnid(当前页的最后一条数据记录的节点标识)；
其次，客户端将dsp和spnid发送到服务端，请求该目录中第二页的所有版本号小于等于bdsp的正常节点，服务端以dsp和spnid作为同步点定位到第二页，并返回符合条件的节点列表、dsp(指更新后的dsp)和spnid；
依次类推，直到客户端获取到该目录中版本号小于等于bdsp的所有节点后，合并节点信息到本地缓存。
在上述过程中，服务端对目录中的数据记录是按照版本号的降序+节点标识的降序进行排序。
对于目录，如果获取了一次完整的全量同步后，以后，便可通过增量的方式来获取数据，减少数据的传输与服务端查询数据带来的压力。
参照图5，本发明实施例中获取目录增量时客户端与服务端的交互过程如下：
目录增量同步被触发时，客户端首先将bdsp发送到服务端，服务端获取该目录中版本号大于bdsp的第一页数据记录，并向客户端返回第一页的节点列表、dsp(当前页的数据记录的最大版本号)和spnid(当前页的最后一条数据记录的节点标识)；
然后，客户端将dsp和spnid发送到服务端，服务端以dsp和spnid作为同步点定位到第二页，并返回版本号大于dsp的节点列表、dsp(指更新后的dsp)和spnid；
依次类推，直到服务端遍历完该目录中的所有数据记录后，客户端合并节点信息到本地缓存；
最后，客户端清除垃圾数据(同步过程中用到的临时变量，例如dsp和spnid等)。
在上述过程中，服务端对该目录中的数据记录是按照版本号的升序+节点标识的升序进行排序。
可见，目录全量与全局全量的同步流程类似，目录增量与全局增量的同步流程也类似，只是在查询相关数据时，会增加一个pid的查询条件(即在sql语句中增加“where pid=...”的查询条件)，但是存在一个问题，假如未发生更新时的数据如下(pid即标识目录，其可以描述节点的层级关系)：
| nid | pid | status | nv |
| 1 | 1 | 0 | 1 |
| 2 | 1 | 0 | 1 |
| 3 | 1 | 0 | 1 |
| 4 | 1 | 0 | 1 |
| 5 | 1 | 0 | 1 |
| 6 | 1 | 0 | 1 |
| 7 | 1 | 0 | 1 |
| 8 | 1 | 0 | 1 |
| 9 | 1 | 0 | 1 |
| 10 | 1 | 0 | 1 |
表8
假如我们更改了nid为5这条记录的pid值，将pid由1更改为5，更改后的数据如下：
| nid | pid | status | nv |
| 1 | 1 | 0 | 1 |
| 2 | 1 | 0 | 1 |
| 3 | 1 | 0 | 1 |
| 4 | 1 | 0 | 1 |
| 5 | 8 | 0 | 4 |
| 6 | 1 | 0 | 1 |
| 7 | 1 | 0 | 1 |
| 8 | 1 | 0 | 1 |
| 9 | 1 | 0 | 1 |
| 10 | 1 | 0 | 1 |
表9
根据前面的描述可知，假如获取目录全量的dsp为1，spnid为5，那么在获取pid=1这层目录的增量时，对于nid=5这一条记录，将无法感知到这一条记录的变化。假设目录增量的伪代码如下(以sql语句为例)：
nodes=select*from table where pid=1 and nv＞dsp limit 10；
由于nid为5这一条记录，pid已经不等于1了，此时，目录增量获取时，无法感知到该节点的变化。因此，对于修改pid这种行为的操作，服务端可以保持pid不变，在逻辑上标识该节点删除，再新增加一条记录来实现，即：先删后加，按这种方案，修改后的数据如下：
| nid | pid | status | nv |
| 1 | 1 | 0 | 1 |
| 2 | 1 | 0 | 1 |
| 3 | 1 | 0 | 1 |
| 4 | 1 | 0 | 1 |
| 5 | 1 | 0 | 4 |
| 6 | 1 | 0 | 1 |
| 7 | 1 | 0 | 1 |
| 8 | 1 | 0 | 1 |
| 9 | 1 | 0 | 1 |
| 10 | 1 | 0 | 1 |
| 11 | 8 | 0 | 5 |
表10
见上表黑体字部分，先对nid为5的这条记录做了逻辑上的删除，而pid并未改变，增加了一条nid为11的新记录。那么再次通过上面的sql语句查询时，将可以正确感知到该节点变化。
与上述客户端同步服务端数据的方法相对应，本发明实施例还提供一种客户端同步服务端数据的装置。
图6示出了根据本发明一个实施例的客户端同步服务端数据的装置结构图，参照图6，所述装置包括全量数据获取单元10、增量数据获取单元20和数据合并单元30。
全量数据获取单元10适于获取服务端的数据对象在第一时刻的全量数据，其中，所述数据对象为数据库或者数据库的一个目录，所述数据库具有多条数据记录，每条数据记录具有节点标识、父节点标识、数据状态标识和版本号标识，数据状态包括表示数据记录未被删除的正常状态和表示数据记录已被删除的删除状态，当数据记录发生变化时，其版本号为所有数据记录中的最大版本号，所述变化包括增加、修改和删除，所述目录为数据库中具有相同父节点标识的数据记录构成的集合，所述全量数据为所述数据对象的所有数据记录构成的集合。
其中，全量数据获取单元10可以按照如下方式来获取全量数据：从服务端获取所述数据对象在第一时刻的所有数据记录的最大版本号bgsp；从服务端获取所述数据对象中版本号小于等于bgsp的所有处于正常状态的数据记录，得到所述全量数据。具体过程可以是：
对所述数据对象中的数据记录按照版本号的降序+节点标识的降序进行排序；
分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最小版本号和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号小于等于bgsp的预定数目条处于正常状态的数据记录，得到本页的数据记录，其中，第一页数据记录的获取始于数据对象的第一条记录；
对分页获取到的数据记录进行合并，得到所述全量数据。
增量数据获取单元20适于根据数据记录的版本号获取服务端的数据对象在第二时刻相对于第一时刻发生变化的增量数据，其中，所述第二时刻晚于所述第一时刻。
其中，增量数据获取单元20可以按照如下方式获取增量数据：
对所述数据对象中的数据记录按照版本号的升序+节点标识的升序进行排序；
分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最大版本号gsp和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号大于gsp的预定数目条数据记录，得到本页的数据记录，其中，所述第二时刻为最后一页数据记录的获取时刻，第一页数据记录的获取始于数据对象的第一条记录，且gsp采用bgsp；
对分页获取到的数据记录进行合并，得到所述增量数据。
数据合并单元30适于合并所述全量数据和所述增量数据，得到数据对象在第二时刻的全量数据。数据合并单元30在合并所述全量数据和所述增量数据时，在节点标识相同的情况下，版本号大的数据记录覆盖版本号小的数据记录。
另外，当所述数据对象为数据库的一个目录时，服务端按照如下方式修改数据库中某条数据记录的父节点标识：新增一条与原数据记录相同的数据记录，将新增的数据记录的父节点标识进行修改，并将原数据记录的数据状态标识修改为删除状态。
可选地，当所述数据对象为数据库的一个目录时，所述装置还包括目录合并单元(图未示)，适于对数据库的所有目录在第二时刻的全量数据进行合并，得到数据库在第二时刻的全量数据。
综上所述，根据本发明实施例的技术方案，在获取完增量数据后，客户端将增量数据与全量数据进行一次合并，那么在这个时刻(获取完增量数据的时刻)，客户端与服务端数据就保证了完全一致。相对于基于事件回放的数据同步机制，该技术方案减少了客户端与服务端之间的交互次数较以及交互传输的数据量，降低了客户端的存储开销，并降低了数据同步的复杂度。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和／或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
Claims (14)
1.一种客户端同步服务端数据的方法，包括：
获取服务端的数据对象在第一时刻的全量数据，其中，所述全量数据为所述数据对象的所有数据记录构成的集合，所述数据对象具有多条数据记录，每条数据记录具有数据状态标识、节点标识和版本号标识，数据状态包括表示数据记录未被删除的正常状态和表示数据记录已被删除的删除状态，当数据记录发生变化时，其版本号为所有数据记录中的最大版本号，所述变化包括增加、修改和删除；
根据数据记录的版本号获取服务端的数据对象在第二时刻相对于第一时刻发生变化的增量数据，包括：对所述数据对象中的数据记录按照版本号的升序+节点标识的升序进行排序；分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最大版本号gsp和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号大于gsp的预定数目条数据记录，得到本页的数据记录，其中，所述第二时刻为最后一页数据记录的获取时刻，第一页数据记录的获取始于数据对象的第一条记录，且gsp采用bgsp；对分页获取到的数据记录进行合并，得到所述增量数据；
其中，所述第二时刻晚于所述第一时刻；
合并所述全量数据和所述增量数据，得到数据对象在第二时刻的全量数据。
2.如权利要求1所述的方法，其中，所述获取服务端的数据对象在第一时刻的全量数据，包括：
从服务端获取所述数据对象在第一时刻的所有数据记录的最大版本号bgsp；
从服务端获取所述数据对象中版本号小于等于bgsp的所有处于正常状态的数据记录，得到所述全量数据。
3.如权利要求2所述的方法，其中，所述从服务器获取所述数据对象中版本号小于等于bgsp的所有处于正常状态的数据记录，得到所述全量数据，包括：
对所述数据对象中的数据记录按照版本号的降序+节点标识的降序进行排序；
分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最小版本号和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号小于等于bgsp的预定数目条处于正常状态的数据记录，得到本页的数据记录，其中，第一页数据记录的获取始于数据对象的第一条记录；
对分页获取到的数据记录进行合并，得到所述全量数据。
4.如权利要求1所述的方法，其中，每条数据记录还具有父节点标识，所述数据对象为数据库或者数据库的一个目录，所述目录为数据库中具有相同父节点标识的数据记录构成的集合。
5.如权利要求4所述的方法，其中，当所述数据对象为数据库的一个目录时，服务端按照如下方式修改数据库中某条数据记录的父节点标识：新增一条与原数据记录相同的数据记录，将新增的数据记录的父节点标识进行修改，并将原数据记录的数据状态标识修改为删除状态。
6.如权利要求5所述的方法，其中，当所述数据对象为数据库的一个目录时，所述方法还包括：对数据库的所有目录在第二时刻的全量数据进行合并，得到数据库在第二时刻的全量数据。
7.如权利要求1至6中任一项所述的方法，其中，在合并所述全量数据和所述增量数据时，在节点标识相同的情况下，版本号大的数据记录覆盖版本号小的数据记录。
8.一种客户端同步服务端数据的装置，包括：
全量数据获取单元，适于获取服务端的数据对象在第一时刻的全量数据，其中，所述全量数据为所述数据对象的所有数据记录构成的集合，所述数据对象具有多条数据记录，每条数据记录具有数据状态标识、节点标识和版本号标识，数据状态包括表示数据记录未被删除的正常状态和表示数据记录已被删除的删除状态，当数据记录发生变化时，其版本号为所有数据记录中的最大版本号，所述变化包括增加、修改和删除；
增量数据获取单元，适于根据数据记录的版本号获取服务端的数据对象在第二时刻相对于第一时刻发生变化的增量数据，包括：对所述数据对象中的数据记录按照版本号的升序+节点标识的升序进行排序；分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最大版本号gsp和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号大于gsp的预定数目条数据记录，得到本页的数据记录，其中，所述第二时刻为最后一页数据记录的获取时刻，第一页数据记录的获取始于数据对象的第一条记录，且gsp采用bgsp；对分页获取到的数据记录进行合并，得到所述增量数据；其中，所述第二时刻晚于所述第一时刻；
数据合并单元，适于合并所述全量数据和所述增量数据，得到数据对象在第二时刻的全量数据。
9.如权利要求8所述的装置，所述全量数据获取单元适于：
从服务端获取所述数据对象在第一时刻的所有数据记录的最大版本号bgsp；
从服务端获取所述数据对象中版本号小于等于bgsp的所有处于正常状态的数据记录，得到所述全量数据。
10.如权利要求9所述的装置，其中，所述全量数据获取单元按照如下方式从服务器获取所述数据对象中版本号小于等于bgsp的所有处于正常状态的数据记录，得到所述全量数据：
对所述数据对象中的数据记录按照版本号的降序+节点标识的降序进行排序；
分页从所述数据对象中获取数据记录，其中，每页数据记录的获取过程为：将上一页数据记录的最小版本号和上一页的最后一条数据记录的节点标识作为同步点，从所述数据对象中获取位于所述同步点之后的版本号小于等于bgsp的预定数目条处于正常状态的数据记录，得到本页的数据记录，其中，第一页数据记录的获取始于数据对象的第一条记录；
对分页获取到的数据记录进行合并，得到所述全量数据。
11.如权利要求8所述的装置，其中，所述每条数据记录还具有父节点标识，所述数据对象为数据库或者数据库的一个目录，所述目录为数据库中具有相同父节点标识的数据记录构成的集合。
12.如权利要求11所述的装置，其中，当所述数据对象为数据库的一个目录时，服务端按照如下方式修改数据库中某条数据记录的父节点标识：新增一条与原数据记录相同的数据记录，将新增的数据记录的父节点标识进行修改，并将原数据记录的数据状态标识修改为删除状态。
13.如权利要求12所述的装置，其中，当所述数据对象为数据库的一个目录时，所述装置还包括目录合并单元，适于对数据库的所有目录在第二时刻的全量数据进行合并，得到数据库在第二时刻的全量数据。
14.如权利要求8至13中任一项所述的装置，其中，所述数据合并单元在合并所述全量数据和所述增量数据时，在节点标识相同的情况下，版本号大的数据记录覆盖版本号小的数据记录。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310574904.0A CN103678494B (zh) | 2013-11-15 | 2013-11-15 | 客户端同步服务端数据的方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310574904.0A CN103678494B (zh) | 2013-11-15 | 2013-11-15 | 客户端同步服务端数据的方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN103678494A CN103678494A (zh) | 2014-03-26 |
| CN103678494B true CN103678494B (zh) | 2018-09-11 |
Family
ID=50316039
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201310574904.0A Expired - Fee Related CN103678494B (zh) | 2013-11-15 | 2013-11-15 | 客户端同步服务端数据的方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN103678494B (zh) |
Families Citing this family (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015200476A2 (en) | 2014-06-24 | 2015-12-30 | Google Inc. | Processing mutations for a remote database |
| CN104346479A (zh) * | 2014-11-26 | 2015-02-11 | 北京奇虎科技有限公司 | 一种数据库同步方法及装置 |
| CN106327196A (zh) * | 2015-06-19 | 2017-01-11 | 阿里巴巴集团控股有限公司 | 一种支付阈值获取方法和装置 |
| CN106339274B (zh) * | 2015-07-14 | 2019-07-02 | 阿里巴巴集团控股有限公司 | 一种数据快照获取的方法及系统 |
| CN105427147B (zh) * | 2015-10-30 | 2019-12-03 | 网易（杭州）网络有限公司 | 基于游戏回档的数据同步方法和装置以及游戏系统 |
| CN105657049B (zh) * | 2016-02-26 | 2019-03-15 | 北京皮尔布莱尼软件有限公司 | 一种增量数据同步方法、装置和移动终端 |
| CN107341163B (zh) * | 2016-05-03 | 2020-08-14 | 阿里巴巴集团控股有限公司 | 数据同步方法及装置 |
| CN106101256B (zh) * | 2016-07-07 | 2019-10-08 | 百度在线网络技术（北京）有限公司 | 用于同步数据的方法和装置 |
| CN108243208A (zh) * | 2016-12-23 | 2018-07-03 | 深圳市优朋普乐传媒发展有限公司 | 一种数据同步方法及装置 |
| CN107844566B (zh) * | 2017-11-02 | 2020-05-05 | 杭州时趣信息技术有限公司 | 一种dump控制方法及其系统 |
| CN108062368B (zh) * | 2017-12-08 | 2021-05-07 | 北京百度网讯科技有限公司 | 全量数据翻译方法、装置、服务器及存储介质 |
| CN108259562B (zh) * | 2017-12-11 | 2022-02-25 | 杭州品茗安控信息技术股份有限公司 | 一种基于多端点的数据同步方法及装置 |
| CN108563694B (zh) * | 2018-03-19 | 2021-04-13 | 广州视源电子科技股份有限公司 | 对逻辑删除的sql执行方法、装置、计算机设备和存储介质 |
| CN108696443A (zh) * | 2018-04-28 | 2018-10-23 | 北京五八信息技术有限公司 | 一种终端数据同步的方法、装置、设备及存储介质 |
| CN110795495A (zh) * | 2018-07-17 | 2020-02-14 | 北京京东尚科信息技术有限公司 | 数据处理方法、装置、电子设备及计算机可读介质 |
| CN109194711B (zh) * | 2018-07-27 | 2020-12-15 | 腾讯科技（深圳）有限公司 | 一种组织架构的同步方法、客户端、服务端及介质 |
| CN109344197B (zh) * | 2018-09-13 | 2021-01-26 | 广州帷策智能科技有限公司 | 基于大数据的分页下载方法和装置 |
| CN109660753B (zh) * | 2018-11-05 | 2021-01-22 | 视联动力信息技术股份有限公司 | 资源同步方法和装置 |
| CN110069567A (zh) * | 2019-04-02 | 2019-07-30 | 北京信安世纪科技股份有限公司 | 一种数据库之间的数据同步方法及系统 |
| CN110365763B (zh) * | 2019-07-11 | 2021-11-23 | 北京蜜莱坞网络科技有限公司 | 一种数据同步方法、装置、设备及存储介质 |
| CN110502584B (zh) * | 2019-08-28 | 2021-09-28 | 北京三快在线科技有限公司 | 数据同步的方法和装置 |
| CN111274253A (zh) * | 2020-01-10 | 2020-06-12 | 北京奇艺世纪科技有限公司 | 全量分区视图的生成方法、装置、存储介质和电子装置 |
| CN111881091A (zh) * | 2020-06-08 | 2020-11-03 | 微梦创科网络科技（中国）有限公司 | 数据存储方法、装置、电子设备及存储介质 |
| CN111901420B (zh) * | 2020-07-28 | 2023-06-16 | 深圳市康冠科技股份有限公司 | 一种数据同步方法、装置及系统 |
| CN114153862A (zh) * | 2021-12-09 | 2022-03-08 | 腾讯科技(成都)有限公司 | 业务数据处理方法、装置、设备及存储介质 |
| CN114579888B (zh) * | 2022-04-26 | 2022-08-30 | 支付宝(杭州)信息技术有限公司 | 知识图谱数据构建的方法、系统和非瞬态计算机可读介质 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1708096A1 (de) * | 2005-03-31 | 2006-10-04 | Ubs Ag | Rechnernetzwerksystem zum Synchronisieren einer zweiten Datenbank mit einer ersten Datenbank sowie Vorgehensweisen hierfür |
| CN102098342B (zh) * | 2011-01-31 | 2013-08-28 | 华为技术有限公司 | 一种基于事务级的数据同步方法、装置及系统 |
| CN103002011B (zh) * | 2012-10-29 | 2016-06-29 | 北京奇虎科技有限公司 | 基于服务器的数据更新方法和服务器 |
| CN103002010B (zh) * | 2012-10-29 | 2016-09-28 | 北京奇虎科技有限公司 | 一种基于增量数据的数据更新方法、装置和系统 |
-
2013
- 2013-11-15 CN CN201310574904.0A patent/CN103678494B/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CN103678494A (zh) | 2014-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103678494B (zh) | 客户端同步服务端数据的方法及装置 | |
| US11663033B2 (en) | Design-time information based on run-time artifacts in a distributed computing cluster | |
| US11003645B1 (en) | Column lineage for resource dependency system and graphical user interface | |
| EP2973041B1 (en) | Apparatus, systems, and methods for batch and realtime data processing | |
| Barmpis et al. | Hawk: Towards a scalable model indexing architecture | |
| CN110609865B (zh) | 一种信息同步方法，装置及系统 | |
| US9116899B2 (en) | Managing changes to one or more files via linked mapping records | |
| CN110300963A (zh) | 大规模数据储存库中的数据管理系统 | |
| CN110168515A (zh) | 用于分析数据关系以支持查询执行的系统 | |
| CN108228817A (zh) | 数据处理方法、装置和系统 | |
| US8521711B2 (en) | Providing persistent refined intermediate results selected from dynamic iterative filtering | |
| CN105630864A (zh) | 存储行标识符值的字典的强制排序 | |
| US20040015486A1 (en) | System and method for storing and retrieving data | |
| CN104572920A (zh) | 一种数据整理方法和装置 | |
| US20160085832A1 (en) | System and method of analyzing data using bitmap techniques | |
| EP2965492B1 (en) | Selection of data storage settings for an application | |
| US11615076B2 (en) | Monolith database to distributed database transformation | |
| CN105808653A (zh) | 一种基于用户标签系统的数据处理方法及装置 | |
| CN110245149A (zh) | 元数据的版本管理方法及装置 | |
| CN106802928B (zh) | 电网历史数据管理方法及其系统 | |
| US9390131B1 (en) | Executing queries subject to different consistency requirements | |
| CN107239568B (zh) | 分布式索引实现方法及装置 | |
| CN103809915B (zh) | 一种磁盘文件的读写方法和装置 | |
| CN105824976A (zh) | 一种优化分词库的方法和装置 | |
| US9542457B1 (en) | Methods for displaying object history information |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20180911 Termination date: 20211115 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |