CN104794249A - 一种数据库的实现方法和设备 - Google Patents

一种数据库的实现方法和设备 Download PDF

Info

Publication number
CN104794249A
CN104794249A CN201510250110.8A CN201510250110A CN104794249A CN 104794249 A CN104794249 A CN 104794249A CN 201510250110 A CN201510250110 A CN 201510250110A CN 104794249 A CN104794249 A CN 104794249A
Authority
CN
China
Prior art keywords
database
data
user
targeted customer
target database
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.)
Granted
Application number
CN201510250110.8A
Other languages
English (en)
Other versions
CN104794249B (zh
Inventor
杜杰朋
曹鲁
吴波
马坤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Netease Bamboo Information Technology Co ltd
Original Assignee
Lede Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Lede Technology Co Ltd filed Critical Lede Technology Co Ltd
Priority to CN201510250110.8A priority Critical patent/CN104794249B/zh
Publication of CN104794249A publication Critical patent/CN104794249A/zh
Application granted granted Critical
Publication of CN104794249B publication Critical patent/CN104794249B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/21—Design, administration or maintenance of databases
    • G06F16/217—Database tuning
    • 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/21—Design, administration or maintenance of databases
    • G06F16/211—Schema design and management

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明的实施方式提供了一种数据库的实现方法。该方法包括：根据目标用户的注册时间，从可用于记录用户数据的可用数据库中，确定用于记录所述目标用户的数据的目标数据库；其中，各个可用数据库各对应于一个时间段，所述目标数据库对应的时间段包含所述目标用户的注册时间；建立所述目标用户与所述目标数据库之间的第一对应关系，以便根据所述第一对应关系而在所述目标数据库中查询和/或记录所述目标用户的数据。通过按照注册时间对用户数据进行数据库分库分表，本发明的方法避免了应用系统运行时大量数据频繁的数据迁移，从而显著地提升了应用系统的数据库性能，为用户带来了更好的体验。此外，本发明的实施方式提供了一种数据库的实现设备。

Description

一种数据库的实现方法和设备
技术领域
本发明的实施方式涉及数据库技术领域，更具体地，本发明的实施方式涉及一种数据库的实现方法和设备。
背景技术
本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
许多应用系统在为用户提供服务时，其功能需要通过对数据库进行查询、更新等数据操作来实现。对于一些应用系统来说，随着用户数量的急剧增长以及各用户对应用系统提供的各种服务越来越频繁地使用，数据库中增加数据、删除数据、更改数据及查询数据等数据操作的开销越来越大，这使得单一数据库的性能难以满足这样巨大的数据操作开销。因此，为了提高应用系统的性能而满足大量用户对大量服务的使用需求，需要将应用系统的单一数据库进行分库分表(sharding)，使得应用系统涉及的数据分配到多个数据库中记录，从而使得应用系统承担的大量数据操作能够分摊到多个数据库执行，减小每个数据库的数据操作开销。
目前，已经出现了一些对数据库进行分库分表的实现方式。例如，一种现有的数据库分库分表方式是散列方式(即hash算法)，具体地，对于应用系统来说，对当前可用于记录数据的多个可用数据库进行编号，根据各用户的用户标识利用散列算法计算各用户的散列值，再分别将各用户的散列值对可用数据库的数量取余数，并以各用户的散列值相对于可用数据库数量的余数作为各用户对应的编号，将各用户的数据映射到各用户对应编号的可用数据库中。这样，各用户的数据可以根据其用户标识映射到不同的数据库中，从而降低数据库的访问压力。
发明内容
需要说明的是，在应用系统的运行过程中，随着新用户不断地注册到应用系统以及已注册用户对应用系统的使用，应用系统需要记录的数据会不断增加，在当前可用于记录数据的数据库数量不能满足当前记录的数据数量对应的数据操作开销时，就需要增加数据库去分担数据的记录，从而保证各个数据库能够承担其记录的数据数量对应的数据操作开销。可见，在应用系统的运行过程中，通常需要动态地增加数据库去分担数据的记录。此外，在应用系统的运行过程中，有时一些数据库所在设备也会宕机，宕机设备的数据库则不能再用于记录数据和响应数据操作，从而使得用于记录数据的数据库减少。由此可见，在应用系统的运行过程中，用于记录数据的数据库的数量是动态变化的。
而在现有技术中，由于数据库分库分表时各用户的数据是映射到以各用户的散列值相对于数据库数量的余数作为编号的数据库，当数据库的数量增加或者减少时，大部分用户的散列值相对于数据库数量的余数都会发生变化，这导致了大部分用户的数据在数据库数量发生变化时需要从一个数据库迁移到另一个数据库中记录。因此，在应用系统的运行过程中，由于用于记录数据的数据库数量是动态变化的，每次数据库数量发生变化都会导致大部分用户的数据需要在数据库之间进行数据迁移，而大量数据的数据迁移则导致数据库需要为大量数据重新构建索引和缓存，从而大大降低了应用系统的数据库性能。
由此可见，在现有技术中，应用系统运行过程中，随着用于记录数据的数据库数量的动态变化，经常发生大量数据在数据库之间进行数据迁移，从而大幅度降低了数据库的性能，这是非常令人烦恼的过程。
为此，非常需要一种改进的数据库的实现方法和设备，以在数据库数量发生改变时避免大量数据在数据库之间进行数据迁移，从而提升数据库的性能。
在本上下文中，本发明的实施方式期望提供一种数据库的实现方法和设备。
在本发明实施方式的第一方面中，提供了一种数据库的实现方法，包括：
根据目标用户的注册时间，从可用于记录用户数据的可用数据库中，确定用于记录所述目标用户的数据的目标数据库；其中，各个可用数据库各对应于一个时间段，所述目标数据库对应的时间段包含所述目标用户的注册时间；
建立所述目标用户与所述目标数据库之间的第一对应关系，以便根据所述第一对应关系而在所述目标数据库中查询和/或记录所述目标用户的数据。
在本发明实施方式的第二方面中，提供了一种数据库的实现设备，包括：
第一确定模块，用于根据目标用户的注册时间，从可用于记录用户数据的可用数据库中，确定用于记录所述目标用户的数据的目标数据库；其中，各个可用数据库各对应于一个时间段，所述目标数据库对应的时间段包含所述目标用户的注册时间；
第一建立模块，用于建立所述目标用户与所述目标数据库之间的第一对应关系，以便根据所述第一对应关系而在所述目标数据库中查询和/或记录所述目标用户的数据。
根据本发明实施方式的用于数据库实现的方法和设备，应用系统可以按照用户注册时间来为各用户分配用于记录用户数据的数据库，以实现对应用系统记录的用户数据进行分库分表，具体地，以应用系统中的任意一个用户作为目标用户，根据该目标用户的注册时间，可以从可用数据库中确定用于记录目标用户的数据的目标数据库，并建立目标用户与目标数据库之间的第一对应关系，以便根据该第一对应关系在目标数据库中查询和/或记录目标用户的数据，其中，各个可用数据库各对应于一个时间段，该目标数据库对应的时间段包含该目标用户的注册时间。由此可见，对于应用系统的各个用户及各个可用数据库来说，由于各个可用数据库中记录的数据均是用户注册时间位于其对应时间段内的用户的数据，也即，各个可用数据库记录的是在各自对应时间段内注册用户的数据，因此，对于应用系统的运行过程中可用数据库数量增加或减少的动态变化，大部分或全部可用数据库依然可以是用于记录其自身时间段内注册用户的数据，这使得大部分用户的数据依然可以记录在其原本所在的可用数据库中而无需从一个可用数据库迁移到另一个数据库中，从而避免了大量数据频繁的数据迁移所导致的重新为大量数据构建索引和缓存，大大提升了应用系统的数据库性能，为用户带来了更好的体验。
附图说明
通过参考附图阅读下文的详细描述，本发明示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本发明的若干实施方式，其中：
图1示意性地示出了本发明实施方式的一个示例性应用场景的框架示意图；
图2示意性地示出了本发明中数据库的实现方法一实施例的流程图；
图3示意性地示出了本发明中数据库的实现方法另一实施例的流程图；
图4示意性地示出了本发明实施例中一种应用系统数据库分库分表示例的示意图；
图5示意性地示出了本发明实施例中一种应用系统可用数据库扩容示例的示意图；
图6示意性地示出了本发明实施例中另一种应用系统可用数据库扩容示例的示意图；
图7示意性地示出了本发明中数据库的实现设备一实施例的结构图；
在附图中，相同或对应的标号表示相同或对应的部分。
具体实施方式
下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。
本领域技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
根据本发明的实施方式，提出了一种数据库的实现方法和设备。
在本文中，需要理解的是，所涉及的术语“应用系统”表示的是能够为用户提供服务或功能的系统，所涉及的术语“数据”表示的是用户在应用系统中使用各种服务或功能时在应用系统中产生的操作数据。例如，在一种可能的应用场景示例中，“应用系统”可以是一种网络社交应用，相应地，“数据”可以是网络社交用户在网络社交应用平台中发布的日志消息、聊天信息、添加好友的操作记录、查询消息的操作记录等任何网络社交用户操作产生的数据。又如，在另一种可能的应用场景示例中，“应用系统”可以是一种电商应用，相应地，“数据”可以是电商用户在电商平台中购买商品的订单记录、查询商品的操作记录、收藏商品的信息等任何电商用户操作产生的数据。可以理解的是，本发明实施方式的“应用系统”及“数据”不限于上述两个应用场景示例，本发明实施方式的“应用系统”可以是任何一种能够为用户提供服务的应用系统，本发明实施方式的“数据”可以是用户使用应用系统提供的服务时在应用系统中产生的任何一种操作数据。
此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。
下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。
发明概述
本发明人发现，在应用系统的运行过程中，一方面，随着新用户不断地注册到应用系统以及已注册用户对应用系统的使用，应用系统需要记录的数据在不断增加，这就使得应用系统需要不断地增加数据库去分担不断增加的数据记录，另一方面，有时一些数据库所在的设备会出现宕机的情况，宕机设备的数据库无法继续用于记录数据和响应数据操作，这就使得应用系统需要将由宕机设备的数据库所处理的数据记录及数据操作响应分配到其他数据库处理，从而使得应用系统中用户记录数据的数据库减少，因此，在应用程序的运行过程中，用于记录数据的数据库数量是动态变化的。但是，现有的数据库实现方式中，数据库性能无法适应应用系统运行过程中的数据库数量动态变化，原因在于，现有的数据库实现方式中是以散列方式来对数据库进行分库分表的，这导致了数据库数量变化时为大部分用户记录数据的数据库都会发生变化，从而在数据库数量动态变化的应用系统中造成了大量数据频繁的数据迁移，数据库就需要为大量数据频繁地构建索引和缓存，从而大大降低了应用系统的数据库性能。进一步而言，现有数据库实现方式对数据库的分库分表之所以会在数据库数量动态变化的应用系统运行过程中造成大量数据频繁的数据迁移，原因在于，现有数据库实现方式对数据库进行分库分表时，各用户的数据映射到的数据库是以该用户的散列值相对于数据库数量的余数作为编号的数据库，因此，在应用系统运行过程中，每次出现数据库数量变化的情况，大部分用户的散列值相对于数据库数量的余数都会发生变化，这就导致了每次数据库数量变化时大部分用户的数据都需要从一个数据库迁移到另一个数据库中记录。
基于上述研究，本发明实施方式的基本思想在于：为了尽量避免在数据库数量变化的应用系统运行过程中大量数据频繁的数据迁移，以提升应用系统的数据库性能，在对数据库进行分库分表时，可以按照用户注册时间来为各用户分配用于记录用户数据的数据库，具体地，应用系统的各个可用数据库可以对应着一个时间段，各个可用数据库中记录的数据可以均是用户注册时间位于其对应时间段内的用户的数据，也即，各个可用数据库对应记录的是在各自对应时间段内注册用户的数据，因此，对于应用系统运行过程中动态出现的可用数据库数量变化，大部分或全部可用数据库依然可以是用于记录其对应时间段内注册用户的数据，这使得大部分用户的数据依然可以记录在其原本所在的可用数据库中而无需从一个可用数据库迁移到另一个数据库中。
在介绍了本发明的基本原理之后，下面具体介绍本发明的各种非限制性实施方式。
应用场景总览
首先参考图1，图1是本发明的实施方式的一个示例性应用场景的框架示意图。其中，用户通过用户设备上的客户端102与应用系统的服务器101进行交互。本领域技术人员可以理解，图1所示的框架示意图仅是本发明的实施方式可以在其中得以实现的一个示例。本发明实施方式的适用范围不受到该框架任何方面的限制。
需要注意的是，此处的用户设备可以是现有的、正在研发的或将来研发的、能够通过任何形式的有线和/或无线连接(例如，Wi-Fi、LAN、蜂窝、同轴电缆等)实现其上客户端102与服务器101交互的任何用户设备，包括但不限于：现有的、正在研发的或将来研发的智能手机、非智能手机、平板电脑、膝上型个人计算机、桌面型个人计算机、小型计算机、中型计算机、大型计算机等。
还需要注意的是，此处的服务器101仅是现有的、正在研发的或将来研发的、能够配置应用系统的设备的一个示例。本发明的实施方式在此方面不受任何限制。
基于图1所示的框架，服务器101根据所述目标用户的注册时间，从可用于记录用户数据的可用数据库中，确定用于记录所述目标用户的数据的目标数据库；其中，各个可用数据库各对应于一个时间段，所述目标数据库对应的时间段包含所述目标用户的注册时间。然后，服务器101可以建立所述目标用户与所述目标数据库之间的第一对应关系，以便服务器101根据所述第一对应关系而在所述目标数据库中查询和/或记录所述目标用户的数据。
可以理解的是，本发明的应用场景中，虽然此处和下面将本发明实施方式的动作描述为由服务器101执行，但是这些动作也可以部分由客户端102执行、部分由服务器101执行。本发明在执行主体方面不受限制，只要执行了本发明实施方式所公开的动作即可。
示例性方法
下面结合图1的应用场景，参考图2～6来描述根据本发明示例性实施方式的用于实现数据库的方法。需要注意的是，上述应用场景仅是为了便于理解本发明的精神和原理而示出，本发明的实施方式在此方面不受任何限制。相反，本发明的实施方式可以应用于适用的任何场景。
参见图2，示出了本发明中数据库的实现方法一实施例的流程图。在本实施例中，例如具体可以包括如下步骤：
步骤201、根据目标用户的注册时间，从可用于记录用户数据的可用数据库中，确定用于记录所述目标用户的数据的目标数据库；其中，各个可用数据库各对应于一个时间段，所述目标数据库对应的时间段包含所述目标用户的注册时间。
在本实施例中，各个可用数据库均对应着一个时间段。对于应用系统的任意一个可用数据库来说，在该可用数据库中记录数据的用户是在该数据库对应时间段内注册的用户，也即，在该可用数据库中记录数据的用户的注册时间均位于该数据库对应时间段内。对于应用系统的任意一个用户来说，用于记录该用户数据的可用数据库是对应时间段包含该用户注册时间的可用数据库。可以理解的是，对于应用系统的某一用户来说，在一种可能的情况下，该用户的注册时间仅位于一个可用数据库对应的时间段内，此时，该用户的数据可以记录到这一可用数据库；在另一种可能的情况下，该用户的注册时间同时位于多个可用数据库对应的时间段内，此时，该用户的数据可以记录到这些可用数据库中的任意一个数据库，或者，该用户的数据可以记录到从这些可用数据库中特定选出的一个数据库。
可以理解的是，从整个应用系统的角度来看，应用系统当前为记录用户数据而提供了多个具有对应时间段的可用数据库，而各个可用数据库对应时间段综合起来需要覆盖应用系统开放用户注册的所有时间。在本实施例中，考虑到应用系统开放用户注册的所有时间的覆盖，各个可用数据库对应时间段的设置方式有多种可能的实施方式。
在一些实施方式中，各个可用数据库可以是对应各不相同的时间段。举例来说，假设应用系统当期提供了4个可用数据库用于为用户记录数据，并且应用系统开放用户注册的时间是2010年1月1日至当前时间，则这4个可用数据库对应的时间段例如分别可以是2010年1月1日至2011年12月31日、2012年1月1日至2013年12月31日、2014年1月1日至2014年12月31日以及2015年1月1日至当前时间。
在另一些实施方式中，各个可用数据库中，可以有部分的可用数据库对应各不相同的时间段，同时，也可以有部分的可用数据对应着相同的时间段。举例来说，假设应用系统当期提供了4个可用数据库用于为用户记录数据，并且应用系统开放用户注册的时间是2010年1月1日至当前时间，则这4个可用数据库对应的时间段例如分别可以是2010年1月1日至2012年12月31日、2013年1月1日至2014年12月31日、2013年1月1日至2014年12月31日以及2015年1月1日至当前时间。其中，对应时间段为2013年1月1日至2014年12月31日的可用数据库有两个，对于在2013年1月1日至2014年12月31日这段时间内注册的用户，该用户的数据可以记录到这两个可用数据库的其中一个。
需要说明的是，在本实施例中，基于在不同的情况下为目标用户分配用于记录数据的目标数据库，目标用户可以分成两种类型。
在本实施例的一些实施方式中，在应用系统已采用注册时间对各用户的数据进行数据库分库分表的情况下，需要分配数据库的用户为新注册的用户，也即，一种类型的目标用户可以为当前正在进行注册的用户。对于当前正在进行注册的这类目标用户来说，用于记录其数据的目标数据库，是对应时间段包含当前时刻的可用数据库。而由于在已采用注册时间对用户数据进行数据库分库分表的应用系统中，通常起始时间最晚的可用数据库是分配给新注册用户记录数据的，因此，对于当前正在进行注册的这类目标用户来说，用于记录其数据的目标数据库也可以理解成，在所有可用数据库对应时间段的起始时刻中，该目标数据库对应时间段的起始时刻是最接近于当前时刻的。具体地，对于当前正在进行注册的这类目标用户，步骤201例如可以包括：响应于所述目标用户的注册请求，从所述可用数据库中，查找对应时间段的起始时刻最接近于当前时刻的数据库，作为所述目标数据库，并确定所述目标数据库用于记录所述目标用户的数据。
在本实施例的另一些实施方式中，如果在应用系统采用单一数据库已运行一段时间之后才需要按照注册时间对应用系统整体进行数据库分库分表，或者，如果在应用系统采用现有散列方式的数据库分库分表的情况下需要按照注册时间重新对应用系统整体进行数据库分库分表，则在应用系统整体进行数据库分库分表的时候，需要分配数据库的用户为对过去已注册的用户，也即，另一种类型的目标用户可以为过去已注册的用户。对于过去已注册的这类目标用户来说，在应用系统整体进行数据库分库分表的时候，可以先为各个可用数据库设置各自对应的时间段，然后再为应用系统中已注册的各个用户分配对应时间段包含各自注册时间的可用数据库，以记录各自数据。具体地，对于过去已注册的这类目标用户，步骤201例如可以包括：响应于对已注册用户的数据的分库分表指令，针对所述目标用户的数据，获取所述目标用户的注册时间作为目标注册时间，查找对应时间段包含所述目标注册时间的数据库作为所述目标数据库，并确定所述目标数据库用于记录所述目标用户的数据。
可以理解的是，对于一个应用系统来说，在开始开放用户注册之后的一段时间内，需要为用户记录的数据增长是较为缓慢的，在这一时间段内应用系统通常可以采用单一可用数据库来为用户记录数据，而无需进行数据库分库分表，此时，在单一可用数据库能够负担所有数据时所有数据驻留同一shard，不仅能为应用系统节省数据库数量的开销，而且所有表间关联关系也可以得到最大限度的保留，同时还可以保证书写SQL的自由度，不易受join、group by、order by等子句限制。而当应用系统需要为用户记录的数据增长加快之后，单一可用数据库无法负担所有数据的情况下，应用系统可以采用数据库分库分表的方式，采用多个可用数据库来分担不同用户的数据记录。具体地，一方面，对于过去已注册的用户，其数据原先是记录于单一可用数据库中的，为此，应用系统可以按照注册时间为已注册用户在多个可用数据库中重新确定用于记录其数据的可用数据库，从而将原先记录于单一可用数据库的用户数据按照用户注册时间分摊到多个可用数据库上。另一方面，对于后续新注册的用户，应用系统的多个可用数据库中具有可用于记录当前注册用户的数据的可用数据库，应用系统可以将该可用数据库分配给新注册用户记录数据。其中，关于为已注册用户和新注册用户分配可用数据库，可参见前述为两类目标用户确定目标数据库的实施方式，在此不再赘述。
步骤202、建立所述目标用户与所述目标数据库之间的第一对应关系，以便根据所述第一对应关系而在所述目标数据库中查询和/或记录所述目标用户的数据。
其中，目标用户与目标数据库之间第一对应关系的建立，是为了使目标用户在应用系统执行数据操作时，应用系统能够通过目标数据库来实现目标用户的数据操作，即能够在目标数据库中查询和/或记录目标用户的数据。例如，该第一对应关系的建立方式，可以是根据目标用户的用户标识与目标数据库的数据库标识之间对应关系为目标用户建立路由信息，该路由信息即相当于前述第一对应关系，这样，目标用户在应用系统执行数据操作时，应用系统可以根据该路由信息查找到目标数据库，从而能够通过目标数据库来实现目标用户的数据操作。又如，该第一对应关系的建立方式，也可以是目标数据库为目标用户建立数据存储目录，位于目标数据库上的该数据存储目录即相当于前述第一对应关系，这样，目标用户在应用系统执行数据操作时，应用系统可以通过为目标用户的数据操作生成全局唯一主键来查找到目标数据库，从而在目标数据库的该数据存储目录中实现目标用户的数据操作。
可以理解的是，为了避免应用系统运行过程中大量数据频繁的数据迁移，尽量减少数据库数量变化时需要数据迁移的数据量，本实施例的应用系统中，为各个用户分配用于记录各自数据的可用数据库，均可以是采用前述步骤201和202为目标用户分配目标数据库的方式实现，也即，本实施例中，前述目标用户表示的是应用系统中的任意一个用户，此时，应用系统中所有用户的数据均是按照用户注册时间划分到各个可用数据库，各个可用数据中记录的数据都是属于在各自对应时间段内注册的用户。在这样的数据库分库分表方式下，在应用系统的运行过程中，例如，当为了分担不断增加的数据记录而需要增加新的可用数据库时，可以仅需增加一个可用数据库用于记录后续注册的新用户的数据，而原有可用数据库中全部用户的数据就均可以无需迁移，或者，对于个别对应时间段内注册用户较为活跃、数据负载较重的原有可用数据库，可以仅需将这些个别原有可用数据库中一部分用户的数据迁移到新增加的可用数据库中进行记录，而这些个别原有数据库中其余用户的数据以及其余大部分原有数据库中全部用户的数据均可以无需迁移。又如，当个别可用数据库所在设备出现宕机情况而无法用于实现数据操作时，可以仅需将位于宕机设备的可用数据库中用户的数据迁移到应用系统现有的其他可用数据库，使得接收迁移数据的可用数据库对应的时间段在原来其时间段的基础上又合并了宕机设备上可用数据库对应的时间段，而除宕机设备上的可用数据库之外，其余可用数据库中用户的数据均可以无需迁移。由此可见，在应用系统的运行过程中，无论可用数据库数量增加还是减少，都无需大量数据进行数据迁移，因此，在可用数据库数量处于动态变化的应用系统运行过程中，按照用户的注册时间为用户分配用于记录数据的可用数据库，可以避免大量数据频繁的数据迁移，从而提升应用系统的数据库性能。
需要说明的是，考虑到应用系统运行过程中用户数据不断的增长会经常导致当前的可用数据库数量不足以满足用户数据记录的需求，应用系统可以根据当前各个可用数据库的数据负载情况来确定是否要增加新的可用数据库。可以理解的是，以目标数据库来表示应用系统当前提供的任意一个可用数据库，基于目标数据库对应时间段的不同，目标可用数据库可以分成两种类型，对于这两种不同类型的目标数据库出现数据负载过大的情况，新增加的可用数据库可以采用不同的方式去分担用户数据的记录。
在本实施例的一些实施方式中，第一种类型的目标数据库，其对应时间段包含当前时间并且用于记录新注册用户的数据，也即，其对应时间段的起始时刻通常是所有可用数据库对应时间段的起始时刻中最接近于当前时刻的。对于这类目标数据库出现数据负载过大的情况，可以使该目标数据库对应时间段截止到当前时刻而不再继续延续至后续时刻，后续新注册用户的数据可以记录到新增加的可用数据库，也即，新增加的可用数据库的对应时间段是以当前时刻为起始时刻并不断延伸至后续时刻，从而新增加的可用数据库的对应时间段可以包含后续新注册用户的注册时间。具体地，对于这类目标数据库，本实施例例如还可以包括：监测所述目标数据库的数据负载；响应于所述目标数据库的数据负载超过所述目标数据库的负载上限，将当前时刻确定为所述目标数据库对应时间段的结束时刻，并增加一个可用数据库作为第一数据库，将所述第一数据库对应时间段的起始时刻确定为当前时刻。
可以理解的是，对于第一种类型的目标数据库数据负载过大的情况，增加一个可用数据库替代该目标数据库去记录后续新注册用户的数据，这样虽然可用数据库的数量增加了，但并不需要对任何数据库的任何用户的数据进行数据迁移。
在本实施例的另一些实施方式中，第二种类型的目标数据库，其对应时间段不包含当前时刻并且仅用于记录已注册用户的数据而不用于记录新注册用户的数据，也即，其对应时间段的起始时刻通常在所有可用数据库对应时间段的起始时刻中不是最接近于当前时刻的，也即，相对于所述目标数据库对应时间段的起始时刻，应用系统中通常存在其他可用数据库对应时间段的起始时刻更接近于当前时刻。对于这类目标数据库出现数据负载过大的情况，可以预先在该目标数据库中设置多个数据库分区并将该目标数据库中各用户的数据映射到各个数据库分区中去，这样，当该目标数据库出现数据负载过大的情况时，该目标数据库可以仅保留其一部分数据库分区，而其另一部分数据库分区可以整体迁移到新增加的可用数据库。具体地，对于这类目标数据库，本实施例例如还可以包括：监测所述目标数据库的数据负载；响应于所述目标数据库的数据负载超过所述目标数据库的负载上限，增加一个或多个可用数据库作为第二数据库，将所述目标数据库的一部分数据库分区迁移到相应第二数据库，并为所述目标数据库建立各数据库分区与用于承载各数据库分区的数据库之间的第二对应关系，以便根据所述第二对应关系查找和/或记录所述目标数据库的各数据库分区中各用户的数据。
其中，在目标数据库的数据负载超过负载上限时，对于任意一个保留在目标数据库的数据库分区来说，数据映射到该数据库分区的所有用户，其当前已记录的数据将均仍然记录在目标数据库中，并且，其后续需要记录的数据也将记录在目标数据库中，也即，这些用户的数据操作仍然由目标数据库来实现；对于任意一个被迁移到第二数据库的数据库分区来说，数据映射到该数据库分区的所有用户，其当前已记录的数据将全部迁移到同一个第二数据库进行记录，并且，其后续需要记录的数据也将记录在被迁移到的该第二数据库中，也即，这些用户的数据操作由迁移到的第二数据库来实现。此外，该数据库分区中所有用户的数据可以从目标数据库中删除。可以理解的是，对于任意一个被迁移的数据库分区来说，该数据库分区中所有用户的数据可以是迁移到同一个第二数据库中。
对于第二种类型的目标数据库来说，按照散列方式将其各用户的数据映射到其各数据库分区，具体可以包括：针对目标数据库，对其各数据库分区进行编号，根据其各用户的用户标识利用散列方式计算其各用户的散列值，再分别将其各用户的散列值对其数据库分区的数量取余数，并以其各用户的散列值相对于其数据库分区数量的余数作为其各用户对应的编号，再将其各用户的数据映射到其各用户对应编号的数据库分区中。可以理解的是，第二种类型的目标数据库，其表示的是应用系统中任意一个对应时间段已固定不变的可用数据库，而在其固定的对应时间段内的注册用户的数据通常是平缓的增长并且也不会是无限的增长，也即，第二种类型的目标数据库的数据负载不会无限增大，因此，其为了分摊数据负载而需要设置的数据库分区数量是有限的，比如，有些应用系统中，第二种类型的目标数据库仅需要16个数据库分区，如果该目标数据库的数据负载过大，则至多可以在该目标数据库保留1个数据库的同时将其余15个数据库分区分别迁移到15个不同的新增加数据库，使得目标数据库的16个数据库分区迁移后最终分别被16个不同的数据库承载，这16个数据库就足以分担该目标数据库对应的固定时间段内注册用户的所有数据操作需求。因此，应用系统可以参考其第二种类型的目标数据库的数据负载情况，为第二种类型的目标数据库预先设置固定数量的数据库分区，这样可以便于各个第二种类型的目标数据库执行cache和将各用户数据映射到各数据库分区。
对于第二种类型的目标数据库，由于目标数据库对应时间段内注册的部分用户的数据会随着部分数据库分区被迁移到第二数据库上，使得目标数据库对应时间段内注册用户被分配到多个不同的数据库上执行数据操作，为了使这些用户在执行数据操作时应用系统能够查找到用于执行其数据操作的数据库，需要为目标数据库建立各个数据库分区与用于承载各数据库分区的第二数据库之间的第二对应关系。具体地，从在任意一个数据库分区记录数据的任意一个用户的角度来说，当该用户执行数据操作时，可以在为目标数据库建立的第二对应关系中，根据该用户所在的数据库分区，确定为该用户记录数据的数据库，以便在该数据库中查找和/或记录该用户的数据，从而通过该数据库来实现该用户的该数据操作。其中，第二对应关系中各数据库分区可以是通过分区标识来表示。为了满足本地索引的要求并便于数据迁移，数据库分区的分区标识可以是数据库分区的编号与目标数据库的数据库标识组合而成，或者，也可以是数据库分区的编号与流水号组合而成。其中，数据库分区的编号，可以是在目标数据库中各用户的数据按照散列方式向各数据库分区映射的过程中数据库分区取得的编号。
对于第二种类型的目标数据库来说，其各数据库分区与用于承载各数据库分区的数据库之间第二对应关系，例如可以通过映射表或配置文件来实现。例如，以映射表实现的第二对应关系为例，对于第二种类型的目标数据库，可以在预先为该目标数据库设置多个数据库分区时也为该目标数据库建立一个映射表，该映射表用于记录该目标数据库的各个数据库分区到将来可能用于承载各自的数据库的映射关系，即前述的第二对应关系，当该目标数据库的部分数据库分区迁移到新增加的第二数据库时，可以修改映射表中被迁移的数据库分区的映射关系，从而始终保持映射表的记录中各数据库分区对应的数据库为承载各数据库分区的数据库。其中，该映射表可以在数据库与应用系统的服务器各保存一份，并在映射表中对各数据库分区设置迁移状态和非迁移状态，这样可以使得应用系统的服务器知晓各个数据库分区是否正在数据迁移，以避免对正在数据迁移的数据库分区执行数据操作。
对于第二种类型的目标数据库来说，在上述通过映射表来实现第二对应关系的实施方式的基础上，当该目标数据库的数据负载超过负载上限时，可以先对数据库的映射表进行修改，以使得映射表中的一部分数据库分区分配给新增加的第二数据库并将相应数据库分区的状态设置为迁移状态，再通知应用系统的服务器(如resin)按照数据库映射表的修改刷新该服务器的映射表，然后将这部分数据库分区的所有用户的数据从该目标数据库迁移到相应第二数据库，再在检查出迁移到第二数据库的数据与该目标数据库中的原数据两者相一致时，将数据库的映射表中相应数据库分区的状态设置为非迁移状态，并通知应用系统的服务器按照数据库映射表的修改刷新该服务器的映射表，最后再从该目标数据库中删除被迁移到第二数据库的数据。
对于第二种类型的目标数据库来说，在上述按照散列方式进行数据库分区的实施方式基础上，考虑到有些应用系统有时会对历史数据进行处理，历史数据处理过程中可能会涉及到历史数据的迁移，为了便于历史数据的迁移，对于任意一个数据库分区来说，可以在该数据库分区中设置多个对应时间段的数据库子分区，该数据库分区的各数据可以分别映射到对应时间段包含各自记录时间的数据库子分区，这样在执行历史数据迁移时，仅需将相应数据库子分区完整的迁移即可，而无需遍历整个数据库去查找需要迁移的历史数据。具体地，在上述按照散列方式进行数据库分区的实施方式基础上，本实施例例如还可以包括：响应于基于数据生命周期的历史数据迁移指令，对于所述目标数据库的每一个数据库分区，以所述目标数据库的各数据库分区中所述生命周期对应的数据库子分区作为目标数据库子分区，将所述目标数据库子分区中各用户的数据迁移到用于记录历史数据的数据库中；其中，所述目标数据库的每一个数据库分区都具有多个数据库子分区；对于所述目标数据库的任意一个数据库分区来说，该数据库分区中各用户的数据是按照数据的记录时间映射到各数据库子分区中的，其中，该数据库分区的各个数据库子分区各对应一时间段，各数据库子分区中所有数据的记录时间均分别包含于各数据库子分区对应的时间段。其中，通常应用系统按照一定的周期来进行历史数据处理的，该历史数据处理的周期即为前述生命周期，因此，应用系统在执行历史数据迁移时，实际上是要迁移记录时间在一定生命周期内的历史数据，即需要迁移的历史数据的记录时间属于该生命周期，也即，需要迁移的数据库子分区对应的时间段是该生命周期。
可以理解的是，对于第二种类型的目标数据库数据负载过大的情况，增加至少一个可用数据库去分担该目标数据库的部分数据库分区的用户的数据记录，这样虽然可用数据库的数量增加了，但仅需要将该目标数据库的部分数据库分区的用户数据迁移到新增加的数据库，而无需对该目标数据库其他数据库分区的用户数据进行数据迁移，也无需对其他数据库的用户数据进行数据迁移。
需要说明的是，对于上述第一种类型的目标数据库，在其数据负载过大时为其增加第一数据库之后，该第一数据库的起始时刻相对于该目标数据库是更接近于当前时刻的，因此，该目标数据库则由第一种类型变为第二种类型，而该第一数据库则成为第一种类型的目标数据库。举例说明，假设数据库A为第一种类型的目标数据库，当数据库A数据负载过大时增加数据库B作为第一数据库，此时，数据库A则变为第二种类型的目标数据库，数据库B则为第一种类型的目标数据库。
可以理解的是，在应用系统中，以任意一个用户作为目标用户，为目标用户确定用于记录其数据的目标数据库之后，在目标用户执行用户操作时，需要找到用于记录其数据的目标数据库，这样才能利用该目标数据库执行该目标用户的数据操作，即应用系统需要为目标用户的数据操作路由到目标数据库。
在本实施的一些实施方式中，为了实现为目标用户的数据操作路由到目标数据库，应用系统可以建立路由数据库，为各个用户设置数据路由信息并将这些数据路由信息保存到路由数据库，其中，以任意一个用户作为目标用户，目标用户的数据路由信息表示的可以是目标用户的用户标识与用于记录该用户数据的数据库之间的对应关系，这样，当目标用户执行数据操作时，如果其数据操作请求包含目标用户的用户标识，则可以响应于包含有目标用户的用户标识的数据操作请求，在路由数据库中可以查找到所述目标用户的数据路由信息，根据该数据路由信息可以确定用于为目标用户记录数据的目标数据库，从而就可以根据目标数据库实现目标用户的数据操作。
在本实施例的另一些实施方式中，在通过路由数据库为各个用户记录数据路由信息的实施方式基础上，考虑到在路由数据库中读取信息的速度较慢，为了缩短应用系统对数据操作的响应时间，可以为路由数据库增加可持久化保存数据的独立缓存并将路由数据库中记录的数据路由信息也记录到该独立缓存中，这样，当目标用户执行数据操作时，如果其数据操作请求包含有目标用户的用户标识，则可以根据目标用户的用户标识，先在独立缓存中查找目标用户的数据路由信息，而在独立缓存中查找不到的情况下再去路由数据库中查找。具体地，本实施例例如还可以包括：建立路由数据库，并将各用户的数据路由信息记录到所述路由数据库；为所述路由数据库增加可持久化保存数据的独立缓存，并将所述路由数据库中记录的数据路由信息记录到所述独立缓存中，以便响应于包含有所述目标用户的用户标识的第一数据操作请求，在所述独立缓存中查找所述目标用户的数据路由信息，如果所述独立缓存中查找不到所述目标用户的数据路由信息则在所述路由数据库中查找所述目标用户的数据路由信息，以便根据所述目标用户的数据路由信息确定出所述目标数据库，从而通过所述目标数据库来实现所述第一数据操作。其中，独立缓存可以是在独立于运行应用系统的设备及应用系统各数据库所在设备之外的设备上实现的，例如，应用系统运行在第一服务器上，应用系统各数据库位于第二服务器上，独立缓存可以是在第三服务器上实现，这样可以保证独立缓存具有较大的存储空间，从而能够将路由数据库中所有的数据路由信息均保存到独立缓存。可以理解的是，通过独立缓存和路由数据库共同查找数据路由信息的实施方式，由于独立缓存读取信息的速度要远远快于路由数据库读取信息的速度，大部分数据操作由独立缓存来查找数据路由信息，使得从路由数据库中读取数据路由信息的需求大大减少，这就提高了数据路由信息的查找速度，从而缩短了应用系统响应数据操作的时间。
在本实施例的又一些实施方式中，在通过独立缓存和路由数据库共同为各个用户记录数据路由信息的实施方式基础上，考虑到应用系统中通常有少量活跃用户对应用系统的使用最为频繁，这些少量的活跃用户通常为应用系统中带来了大量的数据操作，因此，为了减少网络开销并进一步缩短应用系统对这些活跃用户带来的大量数据操作的响应时间，可以将这些少量活跃用户的数据路由信息记录到本地内存，这样，以任意一个用户作为目标用户，当目标用户执行数据操作时，如果该数据操作包含有目标用户的用户标识，则可以根据目标用户的用户标识，先在本地内存中查找目标用户的数据路由信息，在本地内存中查找不到的情况下再去独立缓存、路由数据库中查找。具体地，本实施例例如还可以包括：建立路由数据库，并将各用户的数据路由信息记录到所述路由数据库；为所述路由数据库增加可持久化保存数据的独立缓存，并将所述路由数据库中记录的数据路由信息记录到独立缓存中；在所述独立缓存中，按照各用户的活跃时间对各用户的数据路由信息进行排序，并按照排序结果，以活跃时间最接近于当前时刻的N个用户作为当前活跃用户，将各个所述当前活跃用户的数据路由信息保存到本地内存中，以便响应于包含有所述目标用户的用户标识的第二数据操作请求，在所述本地内存中查找所述目标用户的数据路由信息，如果所述本地内存中查找不到所述目标用户的数据路由信息则在所述独立缓存中查找所述目标用户的数据路由信息，如果所述本地内存和所述独立缓存中均查找不到所述目标用户的数据路由信息则在所述路由数据库中查找所述目标用户的数据路由信息，以便根据所述目标用户的数据路由信息确定出所述目标数据库，从而通过所述目标数据库来实现所述第二数据操作；其中，所述N为当前活跃用户数量的预设值。其中，用户的活跃时间可以表示用户最近活跃过的时间，即lastActiveTime。此外，本地内存是相对于应用系统来说的，本地内存具体是位于运行应用系统的设备上，例如，应用系统运行在第一服务器上，应用系统各数据库位于第二服务器上，独立缓存在第三服务器上实现，则本地内存即是第一服务器的内存。可以理解的是，通过本地内存、独立缓存和路由数据库共同查找数据路由信息的实施方式，由于活跃用户所带来的大量数据操作是由本地内存来查找数据路由信息的，而相对于独立缓存和路由数据库，本地内存读取信息不仅没有网络开销而且响应速度也更快，这就减少了从独立缓存和路由数据库中读取数据路由信息的需求，从而缩短了减少了网络开销并进一步缩短了应用系统响应数据操作的时间，同时，由于活跃用户的数量较少，将少量活跃用户的数据路由信息记录到本地内存也不会占用本地内存过多的存储空间，从而避免了对应用系统的运行造成影响。
对于上述通过本地内存、独立缓存和路由数据库共同查找数据路由信息的实施方式，为了便于各用户的数据路由信息之间按照活跃时间进行排序，对于任意一个用户来说，该用户的数据路由信息例如具体可以表示该用户的用户标识(如account ID)与该用户的注册时间(即createTime)、该用户的活跃时间(如long型的lastActiveTime)、用于记录该用户数据的数据库(即DB)之间的对应关系，这样就可以使得各用户的数据路由信息之间的排序可以依据各用户的数据路由信息来实现。在本实施例的一个应用示例中，独立缓存例如可以采用SortedSet结构的Redis缓存来实现，其中，Redis缓存可以增加在路由数据库的上层，对于每一个数据路由信息，其redis的key可以为用户的account ID，其redis的value为用户的createTime、用户的long型lastActiveTime以及用于为用户记录数据的DB，SortedSet结构可以按照指定的排序方式返回一个有序集合存放在独立缓存中，其中，指定的排序方式可以是以long型lastActiveTime为权重的排序，具体地，用户的long型lastActiveTime越接近于当前时刻，用户的数据路由信息在独立缓存中的存放位置越靠前，而本地内存中加载的是独立缓存中存放位置最靠前的N个数据路由信息，其中，本地内存中加载的数据路由信息的数量N，可以根据业务需要进行合理设定。可以理解的是，为了避免redis缓存的使用与其他业务混乱，redis缓存可以独立进行部署，由于用户的注册时间在生成后基本不会发生变化，其按照注册时间分配的、用于为其记录数据的数据库也就基本不会变化，因此，数据路由信息一旦记录到redis缓存则可以持久化有效，而无需修改再修改redis缓存中的数据路由信息。
此外，对于上述通过本地内存、独立缓存和路由数据库共同查找数据路由信息的实施方式，以任意一个用户作为目标用户，响应于目标用户的数据操作，当本地内存、独立缓存和路由数据库中均不存在目标用户的数据路由信息时，可以在路由数据库中写入该目标用户的数据路由信息，同时将该数据路由信息加载到独立缓存中，并按照该目标用户的活跃时间将该数据路由信息加载到本地内存。
对于前述通过数据路由信息为目标用户的数据操作路由到目标数据库的实施方式中，需要根据目标用户的用户标识来为目标用户确定目标数据库，而在一些情况下，应用系统响应到的数据操作请求可能没有包含用户标识，在这些情况通过数据路由信息可能难以查找到用于实现该数据操作的数据库。在本实施例的一些实施方式中，针对数据操作请求没有包含用户标识的情况，例如可以通过全局唯一主键来为数据操作请求查找相应的数据库。具体地，本实施例例如还可以包括：响应于未包含用户标识的第三数据操作请求，获取所述第三数据操作对应的全局唯一主键，并通过所述全局唯一主键对应的数据库来实现所述第三数据操作；其中，所述全局唯一主键，用于在各个数据库中唯一地标识出所述第三数据操作对应数据所在的数据库。更具体地，对于应用系统记录的任意一个数据，在根据该数据所属的用户将该数据记录到该用户对应的可用数据库时，可以为该数据生成一个全局唯一主键，该全局唯一主键带有该数据所在可用数据库的标识，此后，在针对该数据的数据操作请求可以无需携带用户标识，仅需根据数据操作请求获取到该数据的全局唯一主键，即可根据全局唯一主键确定该数据所在的可用数据库，也即确定用于实现该数据操作的数据库。其中，为第三数据操作生成全局唯一主键，可以是按照第三数据操作所属业务的ID生成规则来生成。在本实施例的一个应用示例中，全局唯一主键例如可以采用“时间戳+相关业务ID生成规则生成的ID+数据库标识+后缀”的方式来实现。可以理解的是，考虑到数据库分库分表之后应用系统的整个数据库被切分为多个可用数据库的物理节点，各个可用数据库自身的主键生成机制，一方面无法保证其主键能够区别于所有其他的可用数据库的主键，另一方面也无法在写入数据前获得ID来进行SQL路由，而采用全局唯一主键来标识各个可用数据库则可以避免上述两方面的问题。
需要说明的是，应用系统可能会存在一些多个数据操作组成的跨库事务。在跨库事务下的多个数据操作是要在多个不同的可用数据库上实现的数据操作，并且，这些数据操作的实现具有一致性要求，也即，跨库事务下的所有数据操作，只允许全部在数据库实现成功或全部在数据库实现失败，而不允许一部分数据操作在数据库实现成功而另一数据操作在数据库实现不成功。例如，在电商平台的应用场景示例下，买家用户的购买操作与卖家用户的出售操作需要分别在买家用户的数据库和卖家用户的数据库中实现，两者属于交易这一跨库事务，其中，买家用户的购买操作与卖家用户的出售操作全部实现成功则表明该笔交易完成，买家用户的购买操作与卖家用户的出售操作全部实现失败则表明该笔交易失败，这两种操作的实现具有一致性要求。针对跨库事务的数据操作，考虑到跨库事务的多个数据操作通常仅需在一定处理时间内达到一致性的实现效果即可，在本实施例的一些实施方式中，跨库事务的各个数据操作在数据库实现时可以标记为待确认状态，直到跨库事务的所有数据操作都在各自数据库实现之后再标记为完成状态。具体地，本实施例例如还可以包括：响应于属于跨库事务的第四数据操作请求，通过用于实现所述第四数据操作的数据库，实现所述第四数据操作并将所述第四数据操作标记为待确认状态；其中，所述跨库事务包含有实现于多个数据库的多个数据操作；响应于在所述跨库事务的处理期限内查询到所述跨库事务包含的所有数据操作均已实现完成，将所述第四数据操作标记为完成状态；响应于在所述跨库事务的处理期限内查询不到所述跨库事务包含的所有数据操作均已实现完成，在用于实现所述第四数据操作的数据库中取消所述第四数据操作。
可以理解的是，应用系统可能会存在一些涉及多个可用数据库中数据的数据操作，即跨节点Join的数据操作。针对跨节点Join的数据操作，在本实施例的一些实施方式中，考虑到跨节点Join的数据操作通常是基于其所涉及的数据的标识而发起请求的，可以以其请求所基于的数据作为初始数据，先查找初始数据，然后基于初始数据的查找结果确定后续数据并查找。具体地，本实施例例如还可以包括：响应于基于初始数据的标识而发起的第五数据操作请求，根据所述初始数据的标识，通过用于记录所述初始数据的数据库对所述初始数据实现所述第五数据操作，并查找出后续数据的标识；所述第五数据操作涉及的数据包括所述初始数据和至少一个所述后续数据；根据各所述后续数据的标识，通过各个用于记录各所述后续数据的数据库对各所述后续数据分别实现所述第五数据操作。例如，在电商平台的应用场景示例下，对于合买订单来说，一起合买的多个用户可能在多个不同的数据库中记录数据的，对于合买订单查询这一跨库Join的数据操作，响应于合买订单的查询操作，可以先查找为该查询操作的发起用户记录数据的可用数据库，并在该可用数据库中查找到该发起用户在该合买订单下的数据，即初始数据，并基于该初始数据查找出该合买订单下其他用户的数据作为后续数据，再在其他可用数据库中查找后续数据。
通过本实施例的技术方案，应用系统的各个可用数据库可以都对应着一个时间段，各个可用数据库中记录的数据可以均是用户注册时间位于其对应时间段内的用户的数据，也即，各个可用数据库对应记录的是在各自对应时间段内注册用户的数据，因此，在应用系统的运行过程中，无论可用数据库数量增加还是减少，都无需大量数据进行数据迁移，因此，在可用数据库数量处于动态变化的应用系统运行过程中，按照用户的注册时间为用户分配用于记录数据的可用数据库，可以避免大量数据频繁的数据迁移，从而提升应用系统的数据库性能。
为了便于本领域技术人员更清楚地理解本发明在具体场景下的实施方式，下面以一个应用场景作为具体示例，对本发明实施方式进行介绍。在该应用场景中，应用系统一开始采用的是单一数据库来为用户记录数据，然后再采用多个可用数据库对应用系统中已注册用户的数据进行数据库分库分表；在数据库分库分表之后，针对数据负载过大的可用数据库，增加新的可用数据库去分担需要记录的数据；在数据库分库分表之后，为新注册用户分配记录数据的可用数据库；在数据库分库分表之后，为已分配到可用数据库的用户记录数据路由信息；在数据库分库分表之后，应用系统接收到用户的数据操作请求时查找相应的可用数据库去实现该数据操作请求。需要说明的是，该应用场景仅为使得本领域技术人员更清楚地了解本发明，但本发明的实施方式不限于该应用场景。
参见图3，示出了本发明中数据库的实现方法另一实施例的流程图。在本实施例中，例如具体可以包括：
步骤301、对应用系统的单一数据库进行数据库分库分表。
具体地，响应于单一数据库的数据负载超过上限，为应用系统设置多个对应不同时间段的可用数据库，然后，针对应用系统各个已注册用户，根据各个已注册用户的注册时间，分配用于记录各自数据的可用数据库，并将各个已注册用户的数据记录到各自分配到的可用数据库。
可以理解的是，与前述实施例中两种类型的目标数据库相对应，本实施例中，在数据库分库分表之后，应用系统中的可用数据库包括一个开放数据库和多个封闭数据库。其中，开放数据库的起始时刻是所有可用数据库的起始时刻中最接近于当前时刻的，并且，开放数据库对应的时间段是从其固定的起始时刻开始一直实时地延续到当前时刻，即其对应的时间段处于不断延长的状态；封闭数据库的起始时刻则均相对于开放数据库的起始时刻更远离当前时刻，并且，封闭数据库对应的时间段是从其固定的起始时刻到其固定的结束时刻，即其对应的时间段处于固定不变的状态。例如，在图4所示的一种应用系统数据库分库分表示例中，可用数据库DB1～DBn-1为封闭数据库，可用数据库DBn为开放数据库；其中，DB1～DBn-1的前后两端是封闭的，表示封闭数据库的起始时刻和结束时刻都是固定不变的；DBn的前端是封闭的而后端是开放的，表示开放数据库的起始时刻固定不变但结束时刻不断延伸至后续时刻。
需要说明的是，在应用系统已经执行了数据库分库分表之后，一方面，可以进入步骤302，从而为数据负载过大的可用数据库增加新的可用数据库分担需要记录的数据，以避免单个可用数据库出现数据负载过大的热点问题；另一方面，可以进入步骤305，从而实现历史数据的迁移；再一方面，可以进入步骤306，从而为新注册用户分配记录数据的可用数据库；又再一方面，可以进入步骤307，从而为数据库分库分表过程中分配到可用数据库的已注册用户建立数据路由信息，以便于已注册用户的数据操作通过各自分配到的可用数据库来实现。
步骤302、监测各个可用数据库的数据负载。
可以理解的是，根据监测的结果，可以选择进入步骤303或者步骤304，再或者，在未监测到数据负载超过负载上限的可用数据库时，可以继续执行步骤302。
步骤303、响应于监测到数据负载超过负载上限的可用数据库为开放数据库，将负载超限的可用数据库由开放数据库变为封闭数据库，并为应用系统增加一个可用数据库作为开放数据库。
具体地，对于数据负载超过负载上限的可用数据库，可以将当前时刻作为其对应时间段的结束时刻，这样其对应的就是一个固定不变的时间段，成为封闭数据库，并且，还可以将当前时刻作为新增加的可用数据库对应时间段的起始时刻，并将新增加的可用数据库对应时间段实时地延伸到后续时刻，从而使得新增加的可用数据库成为开放数据库。例如，在图5所示的一种应用系统可用数据库扩容示例中，作为开放数据库的DBn出现数据负载超限的情况时，应用系统增加了一个可用数据库DBn+1，并且此时，DBn的后端被封闭，这表示DBn的结束时刻被固定，使得DBn成为一个封闭数据库，而新增加的DBn+1的前端封闭而后端开放，这表示新增加的DBn+1的起始时刻固定不变而结束时刻不断延伸至后续时刻，也即，新增加的DBn+1是一个开放数据库。
可以理解的是，在步骤303执行完成之后，可以返回步骤302继续对各个可用数据库的数据负载进行监测。
步骤304、响应于监测到数据负载超过负载上限的可用数据库为封闭数据库，为应用系统增加至少一个可用数据库，并将负载超限的可用数据库的一部数据库分区迁移到新增加的可用数据库中。
具体地，各可用数据库均可以预先按照hash算法分成多个数据库分区，则可用数据库中各用户被分配到不同的数据库分区中记录数据，当某个作为封闭数据库的可用数据库出现负载超限时，可以在负载超限的可用数据库上保留一部分数据库分区，另一部分数据库分区则迁移到新增加的可用数据库，其中，每个数据库分区中所有用户的数据是迁移到同一个可用数据库中。例如，在图6所示的另一种应用系统可用数据库扩容示例中，作为封闭数据库的DBn-1具有数据库分区DB1n-1与DB2n-1，当DBn-1出现数据负载超限的情况时，应用系统新增加了一个可用数据库DB’n-1，此时，可以将DB1n-1保留在DBn-1上而将DB2n-1迁移到DB’n-1上，其中，DBn-1与DB’n-1两者前后两端都是封闭的，也即，两者都属于封闭数据库。
可以理解的是，在步骤304执行完成之后，可以返回步骤302继续对各个可用数据库的数据负载进行监测。
步骤305、响应于历史数据迁移指令，将各可用数据库中相应生命周期对应的数据库子分区迁移到用于记录历史数据的数据库中。
具体地，在各个可用数据库按照hash算法分成多个数据库分区的情况下，各个数据库分区还可以按照数据的记录时间分成多个数据库子分区，每个数据库子分区均对应一个时间段，记录在各数据库子分区的数据的记录时间位于各数据库子分区对应的时间段内。
步骤306、响应于新注册用户的注册请求，将作为开放数据库的可用数据库分配给新注册用户记录数据。
可以理解的是，步骤306与步骤302～304是在步骤301执行之后同步进行的。具体地，在数据库分库分表之后，每次当前作为开放数据库的可用数据库负载超限时，应用系统都会新增加一个可用数据库作为当前开放数据库并将原开放数据库变为封闭数据库，因此，为新注册用户记录数据而分配的可用数据库实际上是在其注册时作为开放数据库的可用数据库。
步骤307、在路由数据库中记录已分配可用数据库的用户的数据路由信息。
其中，用户的数据路由信息表示该用户的用户标识与该用户的注册时间、活跃时间、分配到用于记录其数据的数据库之间的对应关系。
可以理解的是，已分配可用数据库的用户，一方面可以是步骤301对单一数据库进行数据库分库分表时被分配可用数据库的已注册用户，另一方面也可以是步骤306在数据库分库分表之后注册时分配到可用数据库的新注册用户。
步骤308、将路由数据库中的数据路由信息加载到独立缓存中。
步骤309、按照用户的活跃时间对独立缓存中各用户的数据路由信息进行排序，确定当前活跃用户，将当前活跃用户的数据路由信息更新到本地内存中。
可以理解的是，由于用户的活跃时间处于实时地变化，应用系统中的当前活跃用户会实时地变化，为此，可以实时地或定期地执行步骤309，以尽量保证本地内存中记录的是当前较为活跃的用户的数据路由信息。
步骤310、接收数据操作请求。
需要说明的是，当用户执行了数据操作时，则需要到为该用户分配记录数据的可用数据库上实现该数据操作，即数据的查询和/或记录。而根据数据操作请求的形式不同，在接收到数据操作请求时，可以选择进入步骤311、步骤315或步骤317。
步骤311、响应于该数据操作请求包含用户标识，在本地内存中查找包含有该用户标识的数据路由信息。
其中，如果能够查找到，进入步骤314，如果查找不到，进入步骤312。
步骤312、在独立缓存中查找包含有该用户标识的数据路由信息。
其中，如果能够查找到，进入步骤314，如果查找不到，进入步骤313。
步骤313、在路由数据库中查找包含有该用户标识的数据路由信息。
其中，如果能够查找到，进入步骤314。可以理解的是，如果路由数据库中查找不到包含有该用户标识的数据路由信息，一种可能是该数据操作请求是新注册用户的注册请求，此时可以返回步骤306为新注册用户分配可用数据库并记录数据路由信息，另一种可能是路由数据库丢失了该用户的数据路由信息，此时可以在确定该用户分配到的可用数据库之后重新在路由数据库、缓存和内存中为该用户记录数据路由信息。
步骤314、在该数据路由信息所记录的可用数据库中实现该数据操作。
步骤315、响应于该数据操作请求未包含用户标识，获取该数据操作请求对应的全局唯一主键。
步骤316、在该全局唯一主键对应的可用数据库中实现该数据操作。
步骤317、响应于该数据操作属于跨节点Join的数据操作，基于该数据操作中的初始数据的标识，在用于记录所述初始数据的可用数据库中，对所述初始数据实现该数据操作并查找该数据操作的后续数据的标识。
步骤318、根据后续数据的标识，在用于记录所述后续数据的可用数据库中，对所述后续数据实现该数据操作，从而完整实现该数据操作。
在步骤314、步骤316或步骤318实现了数据操作之后，根据该数据操作的类型，还可以进一步选择进入步骤319。
步骤319、响应于该数据操作属于跨库事务，将已在数据库实现的该数据操作标记为待确认状态。
步骤320、响应于在该跨库事务的处理期限内查询到该跨库事务中其他数据操作均已实现完成，将该数据操作标记为完成状态；
步骤321、响应于在该跨库事务的处理期限内查询不到该跨库事务中其他数据操作均已实现完成，取消数据库中已实现的该数据操作。
通过本实施例的技术方案，一方面，在可用数据库数量处于动态变化的应用系统运行过程中，按照用户的注册时间为用户分配用于记录数据的可用数据库，可以避免大量数据频繁的数据迁移，从而提升应用系统的数据库性能；另一方面，对于对应时间段内注册的用户较为活跃的可用数据库，通过按照散列方式将该可用数据库分成多个数据库分区以及将部分数据库分区从该可用数据库迁移到新增加数据库，可以实现将该时间段内注册的用户分散到多个可用数据库上记录数据，从而避免某些可用数据库的数据负载过大而造成的“热点”问题；再一方面，通过本地内存、独立缓存和路由数据库对数据路由信息的三级缓存策略，可以尽量避免网络开销，减少路由机制的响应时间，从而提升应用系统的响应效率。
示例性设备
在介绍了本发明示例性实施方式的方法之后，接下来，参考图7对本发明示例性实施方式的、用于实现数据库的设备进行介绍。
参见图7，示出了本发明中数据库的实现设备一实施例的结构图。在本实施例中，所述设备例如具体可以包括：
第一确定模块701，用于根据目标用户的注册时间，从可用于记录用户数据的可用数据库中，确定用于记录所述目标用户的数据的目标数据库；其中，各个可用数据库各对应于一个时间段，所述目标数据库对应的时间段包含所述目标用户的注册时间；
第一建立模块702，用于建立所述目标用户与所述目标数据库之间的第一对应关系，以便根据所述第一对应关系而在所述目标数据库中查询和/或记录所述目标用户的数据。
可选的，在本实施例的一些实施方式中，所述目标用户可以为当前正在进行注册的用户，并且，在所有可用数据库对应时间段的起始时刻中，所述目标数据库对应时间段的起始时刻可以是最接近于当前时刻的；
所述第一确定模块701例如具体可以包括：
第一查找子模块，用于响应于所述目标用户的注册请求，从所述可用数据库中，查找对应时间段的起始时刻最接近于当前时刻的数据库，作为所述目标数据库；
第一确定子模块，用于确定所述目标数据库用于记录所述目标用户的数据。
可选的，在本实施例的另一些实施方式中，所述目标用户可以为过去已注册的用户；
所述第一确定模块701例如具体可以包括：
获取子模块，用于响应于对已注册用户的数据的分库分表指令，针对所述目标用户的数据，获取所述目标用户的注册时间作为目标注册时间；
第二查找子模块，用于查找对应时间段包含所述目标注册时间的数据库作为所述目标数据库；
第二确定子模块，用于确定所述目标数据库用于记录所述目标用户的数据。
可选的，在本实施例的又一些实施方式中，所述设备例如还可以包括：
第一监测模块，用于监测所述目标数据库的数据负载；其中，在所有可用数据库对应时间段的起始时刻中，所述目标数据库对应时间段的起始时刻最接近于当前时刻；
第二确定模块，用于响应于所述目标数据库的数据负载超过所述目标数据库的负载上限，将当前时刻确定为所述目标数据库对应时间段的结束时刻；
第一增加模块，用于增加一个可用数据库作为第一数据库；
第三确定模块，用于将所述第一数据库对应时间段的起始时刻确定为当前时刻。
可选的，在本实施例的再一些实施方式中，所述设备例如还可以包括：
第二监测模块，用于监测所述目标数据库的数据负载；其中，相对于所述目标数据库对应时间段的起始时刻，存在其他可用数据库对应时间段的起始时刻更接近于当前时刻；所述目标数据库具有多个数据库分区，所述目标数据库中各用户的数据是按照散列方式映射到所述目标数据库的各个数据库分区中的；
第二增加模块，用于响应于所述目标数据库的数据负载超过所述目标数据库的负载上限，增加一个或多个可用数据库作为第二数据库；
第一迁移模块，用于将所述目标数据库的一部分数据库分区中各用户的数据迁移到相应第二数据库；
第二建立模块，用于为所述目标数据库建立各数据库分区与用于承载各数据库分区的第二数据库之间的第二对应关系，以便根据所述第二对应关系查找和/或记录所述目标数据库的各数据库分区中各用户的数据。
进一步可选的，在本实施例的又再一些实施方式中，在前述包括第二监测模块、第二增加模块、第一迁移模块和第二建立模块的实施方式基础上，所述设备例如还可以包括：
第二迁移模块，用于响应于基于数据生命周期的历史数据迁移指令，对于所述目标数据库的每一个数据库分区，以所述目标数据库的各数据库分区中所述生命周期对应的数据库子分区作为目标数据库子分区，将所述目标数据库子分区中各用户的数据迁移到用于记录历史数据的数据库中；
其中，所述目标数据库的每一个数据库分区都具有多个数据库子分区；对于所述目标数据库的任意一个数据库分区来说，该数据库分区中各用户的数据是按照数据的记录时间映射到各数据库子分区中的，其中，该数据库分区的各个数据库子分区各对应一时间段，各数据库子分区中所有数据的记录时间均分别包含于各数据库子分区对应的时间段。
可选的，在本实施例的又再一些实施方式中，所述设备例如还可以包括：
第三建立模块，用于建立路由数据库，并将各用户的数据路由信息记录到所述路由数据库；其中，对于任意一个用户来说，该用户的数据路由信息表示该用户的用户标识与该用户的注册时间、用于记录该用户数据的数据库之间的对应关系；
第三增加模块，用于为所述路由数据库增加可持久化保存数据的独立缓存；
记录模块，用于将所述路由数据库中记录的数据路由信息记录到所述独立缓存中，以便响应于包含有所述目标用户的用户标识的第一数据操作请求，在所述独立缓存中查找所述目标用户的数据路由信息，如果所述独立缓存中查找不到所述目标用户的数据路由信息则在所述路由数据库中查找所述目标用户的数据路由信息，以便根据所述目标用户的数据路由信息确定出所述目标数据库，从而通过所述目标数据库来实现所述第一数据操作。
进一步可选的，在本实施例的又再一些实施方式中，在包括第三建立模块、第三增加模块和记录模块的实施方式基础上，所述设备例如还可以包括：
排序模块，用于在所述独立缓存中，按照各用户的活跃时间对各用户的数据路由信息进行排序；其中，对于任意一个用户来说，该用户的数据路由信息具体表示该用户的用户标识与该用户的注册时间、该用户的活跃时间、用于记录该用户数据的数据库之间的对应关系；
保存模块，用于按照排序结果，以活跃时间最接近于当前时刻的N个用户作为当前活跃用户，将各个所述当前活跃用户的数据路由信息保存到本地内存中，以便响应于包含有所述目标用户的用户标识的第二数据操作请求，在所述本地内存中查找所述目标用户的数据路由信息，如果所述本地内存中查找不到所述目标用户的数据路由信息则在所述独立缓存中查找所述目标用户的数据路由信息，如果所述本地内存和所述独立缓存中均查找不到所述目标用户的数据路由信息则在所述路由数据库中查找所述目标用户的数据路由信息，以便根据所述目标用户的数据路由信息确定出所述目标数据库，从而通过所述目标数据库来实现所述第二数据操作；其中，所述N为当前活跃用户数量的预设值。
可选的，在本实施例的又再一些实施方式中，所述设备例如还可以包括：
获取模块，用于响应于未包含用户标识的第三数据操作请求，获取所述第三数据操作对应的全局唯一主键；
第一实现模块，用于通过所述全局唯一主键对应的数据库来实现所述第三数据操作；
其中，所述全局唯一主键，用于在各个数据库中唯一地标识出所述第三数据操作对应数据所在的数据库。
可选的，在本实施例的又再一些实施方式中，所述设备例如还可以包括：
第二实现模块，用于响应于属于跨库事务的第四数据操作请求，通过用于实现所述第四数据操作的数据库，实现所述第四数据操作并将所述第四数据操作标记为待确认状态；其中，所述跨库事务包含有实现于多个数据库的多个数据操作；
标记模块，用于响应于在所述跨库事务的处理期限内查询到所述跨库事务包含的所有数据操作均已实现完成，将所述第四数据操作标记为完成状态；
取消模块，用于响应于在所述跨库事务的处理期限内查询不到所述跨库事务包含的所有数据操作均已实现完成，在用于实现所述第四数据操作的数据库中取消所述第四数据操作。
可选的，在本实施例的又再一些实施方式中，所述设备例如还可以包括：
第三实现模块，用于响应于基于初始数据的标识而发起的第五数据操作请求，根据所述初始数据的标识，通过用于记录所述初始数据的数据库对所述初始数据实现所述第五数据操作；
查找模块，用于查找出后续数据的标识；所述第五数据操作涉及的数据包括所述初始数据和至少一个所述后续数据；
第四实现模块，用于根据各所述后续数据的标识，通过各个用于记录各所述后续数据的数据库对各所述后续数据分别实现所述第五数据操作。
通过本实施例的技术方案，应用系统的各个可用数据库可以都对应着一个时间段，各个可用数据库中记录的数据可以均是用户注册时间位于其对应时间段内的用户的数据，也即，各个可用数据库对应记录的是在各自对应时间段内注册用户的数据，因此，在应用系统的运行过程中，无论可用数据库数量增加还是减少，都无需大量数据进行数据迁移，因此，在可用数据库数量处于动态变化的应用系统运行过程中，按照用户的注册时间为用户分配用于记录数据的可用数据库，可以避免大量数据频繁的数据迁移，从而提升应用系统的数据库性能。
应当注意，尽管在上文详细描述中提及了数据库的实现设备的若干模块或子模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。
此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (20)

1.一种方法，包括：
根据目标用户的注册时间，从可用于记录用户数据的可用数据库中，确定用于记录所述目标用户的数据的目标数据库；其中，各个可用数据库各对应于一个时间段，所述目标数据库对应的时间段包含所述目标用户的注册时间；
建立所述目标用户与所述目标数据库之间的第一对应关系，以便根据所述第一对应关系而在所述目标数据库中查询和/或记录所述目标用户的数据。
2.根据权利要求1所述的方法，其中，所述目标用户为当前正在进行注册的用户；
所述根据所述目标用户的注册时间，从可用于记录用户数据的可用数据库中，确定用于记录所述目标用户的数据的目标数据库，包括：响应于所述目标用户的注册请求，从所述可用数据库中，查找对应时间段的起始时刻最接近于当前时刻的数据库，作为所述目标数据库，并确定所述目标数据库用于记录所述目标用户的数据。
3.根据权利要求1所述的方法，其中，所述目标用户为过去已注册的用户；
所述根据所述目标用户的注册时间，从可用于记录用户数据的可用数据库中，确定用于记录所述目标用户的数据的目标数据库，包括：响应于对已注册用户的数据的分库分表指令，针对所述目标用户的数据，获取所述目标用户的注册时间作为目标注册时间，查找对应时间段包含所述目标注册时间的数据库作为所述目标数据库，并确定所述目标数据库用于记录所述目标用户的数据。
4.根据权利要求1所述的方法，还包括：
监测所述目标数据库的数据负载；其中，在所有可用数据库对应时间段的起始时刻中，所述目标数据库对应时间段的起始时刻最接近于当前时刻；
响应于所述目标数据库的数据负载超过所述目标数据库的负载上限，将当前时刻确定为所述目标数据库对应时间段的结束时刻，并增加一个可用数据库作为第一数据库，将所述第一数据库对应时间段的起始时刻确定为当前时刻。
5.根据权利要求1所述的方法，还包括：
监测所述目标数据库的数据负载；其中，相对于所述目标数据库对应时间段的起始时刻，存在其他可用数据库对应时间段的起始时刻更接近于当前时刻；所述目标数据库具有多个数据库分区，所述目标数据库中各用户的数据是按照散列方式映射到所述目标数据库的各个数据库分区中的；
响应于所述目标数据库的数据负载超过所述目标数据库的负载上限，增加一个或多个可用数据库作为第二数据库，将所述目标数据库的一部分数据库分区迁移到相应第二数据库，并为所述目标数据库建立各数据库分区与用于承载各数据库分区的数据库之间的第二对应关系，以便根据所述第二对应关系查找和/或记录所述目标数据库的各数据库分区中各用户的数据。
6.根据权利要求1所述的方法，还包括：
建立路由数据库，并将各用户的数据路由信息记录到所述路由数据库；其中，对于任意一个用户来说，该用户的数据路由信息表示该用户的用户标识与用于记录该用户数据的数据库之间的对应关系；
为所述路由数据库增加可持久化保存数据的独立缓存，并将所述路由数据库中记录的数据路由信息记录到所述独立缓存中，以便响应于包含有所述目标用户的用户标识的第一数据操作请求，在所述独立缓存中查找所述目标用户的数据路由信息，如果所述独立缓存中查找不到所述目标用户的数据路由信息则在所述路由数据库中查找所述目标用户的数据路由信息，以便根据所述目标用户的数据路由信息确定出所述目标数据库，从而通过所述目标数据库来实现所述第一数据操作。
7.根据权利要求6所述的方法，还包括：
在所述独立缓存中，按照各用户的活跃时间对各用户的数据路由信息进行排序；
按照排序结果，以活跃时间最接近于当前时刻的N个用户作为当前活跃用户，将各个所述当前活跃用户的数据路由信息保存到本地内存中，以便响应于包含有所述目标用户的用户标识的第二数据操作请求，在所述本地内存中查找所述目标用户的数据路由信息，如果所述本地内存中查找不到所述目标用户的数据路由信息则在所述独立缓存中查找所述目标用户的数据路由信息，如果所述本地内存和所述独立缓存中均查找不到所述目标用户的数据路由信息则在所述路由数据库中查找所述目标用户的数据路由信息，以便根据所述目标用户的数据路由信息确定出所述目标数据库，从而通过所述目标数据库来实现所述第二数据操作；其中，所述N为当前活跃用户数量的预设值。
8.根据权利要求1所述的方法，还包括：
响应于未包含用户标识的第三数据操作请求，获取所述第三数据操作对应的全局唯一主键，并通过所述全局唯一主键对应的数据库来实现所述第三数据操作；
其中，所述全局唯一主键，用于在各个数据库中唯一地标识出所述第三数据操作对应数据所在的数据库。
9.根据权利要求1所述的方法，还包括：
响应于属于跨库事务的第四数据操作请求，通过用于实现所述第四数据操作的数据库，实现所述第四数据操作并将所述第四数据操作标记为待确认状态；其中，所述跨库事务包含有实现于多个数据库的多个数据操作；
响应于在所述跨库事务的处理期限内查询到所述跨库事务包含的所有数据操作均已实现完成，将所述第四数据操作标记为完成状态；
响应于在所述跨库事务的处理期限内查询不到所述跨库事务包含的所有数据操作均已实现完成，在用于实现所述第四数据操作的数据库中取消所述第四数据操作。
10.根据权利要求1所述的方法，还包括：
响应于基于初始数据的标识而发起的第五数据操作请求，根据所述初始数据的标识，通过用于记录所述初始数据的数据库对所述初始数据实现所述第五数据操作，并查找出后续数据的标识；所述第五数据操作涉及的数据包括所述初始数据和至少一个所述后续数据；
根据各所述后续数据的标识，通过各个用于记录各所述后续数据的数据库对各所述后续数据分别实现所述第五数据操作。
11.一种设备，包括：
第一确定模块，用于根据目标用户的注册时间，从可用于记录用户数据的可用数据库中，确定用于记录所述目标用户的数据的目标数据库；其中，各个可用数据库各对应于一个时间段，所述目标数据库对应的时间段包含所述目标用户的注册时间；
第一建立模块，用于建立所述目标用户与所述目标数据库之间的第一对应关系，以便根据所述第一对应关系而在所述目标数据库中查询和/或记录所述目标用户的数据。
12.根据权利要求11所述的设备，其中，所述目标用户为当前正在进行注册的用户；
所述第一确定模块包括：
第一查找子模块，用于响应于所述目标用户的注册请求，从所述可用数据库中，查找对应时间段的起始时刻最接近于当前时刻的数据库，作为所述目标数据库；
第一确定子模块，用于确定所述目标数据库用于记录所述目标用户的数据。
13.根据权利要求11所述的设备，其中，所述目标用户为过去已注册的用户；
所述第一确定模块包括：
获取子模块，用于响应于对已注册用户的数据的分库分表指令，针对所述目标用户的数据，获取所述目标用户的注册时间作为目标注册时间；
第二查找子模块，用于查找对应时间段包含所述目标注册时间的数据库作为所述目标数据库；
第二确定子模块，用于确定所述目标数据库用于记录所述目标用户的数据。
14.根据权利要求11所述的设备，还包括：
第一监测模块，用于监测所述目标数据库的数据负载；其中，在所有可用数据库对应时间段的起始时刻中，所述目标数据库对应时间段的起始时刻最接近于当前时刻；
第二确定模块，用于响应于所述目标数据库的数据负载超过所述目标数据库的负载上限，将当前时刻确定为所述目标数据库对应时间段的结束时刻；
第一增加模块，用于增加一个可用数据库作为第一数据库；
第三确定模块，用于将所述第一数据库对应时间段的起始时刻确定为当前时刻。
15.根据权利要求11所述的设备，还包括：
第二监测模块，用于监测所述目标数据库的数据负载；其中，相对于所述目标数据库对应时间段的起始时刻，存在其他可用数据库对应时间段的起始时刻更接近于当前时刻；所述目标数据库具有多个数据库分区，所述目标数据库中各用户的数据是按照散列方式映射到所述目标数据库的各个数据库分区中的；
第二增加模块，用于响应于所述目标数据库的数据负载超过所述目标数据库的负载上限，增加一个或多个可用数据库作为第二数据库；
第一迁移模块，用于将所述目标数据库的一部分数据库分区中各用户的数据迁移到相应第二数据库；
第二建立模块，用于为所述目标数据库建立各数据库分区与用于承载各数据库分区的第二数据库之间的第二对应关系，以便根据所述第二对应关系查找和/或记录所述目标数据库的各数据库分区中各用户的数据。
16.根据权利要求11所述的设备，还包括：
第三建立模块，用于建立路由数据库，并将各用户的数据路由信息记录到所述路由数据库；其中，对于任意一个用户来说，该用户的数据路由信息表示该用户的用户标识与用于记录该用户数据的数据库之间的对应关系；
第三增加模块，用于为所述路由数据库增加可持久化保存数据的独立缓存；
记录模块，用于将所述路由数据库中记录的数据路由信息记录到所述独立缓存中，以便响应于包含有所述目标用户的用户标识的第一数据操作请求，在所述独立缓存中查找所述目标用户的数据路由信息，如果所述独立缓存中查找不到所述目标用户的数据路由信息则在所述路由数据库中查找所述目标用户的数据路由信息，以便根据所述目标用户的数据路由信息确定出所述目标数据库，从而通过所述目标数据库来实现所述第一数据操作。
17.根据权利要求16所述的设备，还包括：
排序模块，用于在所述独立缓存中，按照各用户的活跃时间对各用户的数据路由信息进行排序；
保存模块，用于按照排序结果，以活跃时间最接近于当前时刻的N个用户作为当前活跃用户，将各个所述当前活跃用户的数据路由信息保存到本地内存中，以便响应于包含有所述目标用户的用户标识的第二数据操作请求，在所述本地内存中查找所述目标用户的数据路由信息，如果所述本地内存中查找不到所述目标用户的数据路由信息则在所述独立缓存中查找所述目标用户的数据路由信息，如果所述本地内存和所述独立缓存中均查找不到所述目标用户的数据路由信息则在所述路由数据库中查找所述目标用户的数据路由信息，以便根据所述目标用户的数据路由信息确定出所述目标数据库，从而通过所述目标数据库来实现所述第二数据操作；其中，所述N为当前活跃用户数量的预设值。
18.根据权利要求11所述的设备，还包括：
获取模块，用于响应于未包含用户标识的第三数据操作请求，获取所述第三数据操作对应的全局唯一主键；
第一实现模块，用于通过所述全局唯一主键对应的数据库来实现所述第三数据操作；
其中，所述全局唯一主键，用于在各个数据库中唯一地标识出所述第三数据操作对应数据所在的数据库。
19.根据权利要求11所述的设备，还包括：
第二实现模块，用于响应于属于跨库事务的第四数据操作请求，通过用于实现所述第四数据操作的数据库，实现所述第四数据操作并将所述第四数据操作标记为待确认状态；其中，所述跨库事务包含有实现于多个数据库的多个数据操作；
标记模块，用于响应于在所述跨库事务的处理期限内查询到所述跨库事务包含的所有数据操作均已实现完成，将所述第四数据操作标记为完成状态；
取消模块，用于响应于在所述跨库事务的处理期限内查询不到所述跨库事务包含的所有数据操作均已实现完成，在用于实现所述第四数据操作的数据库中取消所述第四数据操作。
20.根据权利要求11所述的设备，还包括：
第三实现模块，用于响应于基于初始数据的标识而发起的第五数据操作请求，根据所述初始数据的标识，通过用于记录所述初始数据的数据库对所述初始数据实现所述第五数据操作；
查找模块，用于查找出后续数据的标识；所述第五数据操作涉及的数据包括所述初始数据和至少一个所述后续数据；
第四实现模块，用于根据各所述后续数据的标识，通过各个用于记录各所述后续数据的数据库对各所述后续数据分别实现所述第五数据操作。
CN201510250110.8A 2015-05-15 2015-05-15 一种数据库的实现方法和设备 Active CN104794249B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510250110.8A CN104794249B (zh) 2015-05-15 2015-05-15 一种数据库的实现方法和设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510250110.8A CN104794249B (zh) 2015-05-15 2015-05-15 一种数据库的实现方法和设备

Publications (2)

Publication Number Publication Date
CN104794249A true CN104794249A (zh) 2015-07-22
CN104794249B CN104794249B (zh) 2018-08-28

Family

ID=53559041

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510250110.8A Active CN104794249B (zh) 2015-05-15 2015-05-15 一种数据库的实现方法和设备

Country Status (1)

Country Link
CN (1) CN104794249B (zh)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105138676A (zh) * 2015-09-08 2015-12-09 浙江维融电子科技股份有限公司 基于高级语言并发聚合计算的分库分表merge查询方法
CN105589937A (zh) * 2015-12-14 2016-05-18 江苏鼎峰信息技术有限公司 一种分布式数据库存储架构系统
CN105930387A (zh) * 2016-04-14 2016-09-07 北京思特奇信息技术股份有限公司 一种基于数据路由、分库分表的数据操作系统及方法
CN106204125A (zh) * 2016-07-06 2016-12-07 合信息技术（北京）有限公司 一种定价方法及装置
CN106302640A (zh) * 2016-07-27 2017-01-04 乐视控股（北京）有限公司 数据请求处理方法及装置
CN106598823A (zh) * 2016-10-19 2017-04-26 同盾科技有限公司 一种网络行为特征的差量计算方法和系统
CN106776785A (zh) * 2016-11-24 2017-05-31 腾讯科技（深圳）有限公司 一种数据写入方法及装置和数据处理系统
CN106897332A (zh) * 2016-06-14 2017-06-27 阿里巴巴集团控股有限公司 数据库扩容方法及装置
CN107229674A (zh) * 2017-04-26 2017-10-03 努比亚技术有限公司 一种数据迁移装置、服务器及方法
CN107783974A (zh) * 2016-08-24 2018-03-09 阿里巴巴集团控股有限公司 数据处理系统及方法
CN107895049A (zh) * 2017-12-05 2018-04-10 泰康保险集团股份有限公司 数据处理方法及装置、计算机可读存储介质、电子设备
CN108055312A (zh) * 2017-12-07 2018-05-18 畅捷通信息技术股份有限公司 路由方法及其装置与计算机装置及其可读存储介质
CN108572991A (zh) * 2017-03-14 2018-09-25 北京京东尚科信息技术有限公司 数据库处理方法、装置和存储介质
CN109213761A (zh) * 2018-08-06 2019-01-15 北京马上慧科技术有限公司 一种自由扩展免迁移的分库分表方法
CN110069484A (zh) * 2017-08-29 2019-07-30 苏宁云商集团股份有限公司 一种数据库的分库方法及装置
CN110213075A (zh) * 2019-04-04 2019-09-06 特斯联（北京）科技有限公司 一种多重网络节点配置方法、装置、终端设备及介质
CN111143414A (zh) * 2019-12-26 2020-05-12 五八有限公司 一种缓存数据的反馈方法、装置、电子设备及存储介质
CN111221840A (zh) * 2018-11-23 2020-06-02 阿里巴巴集团控股有限公司 数据处理方法及装置、数据缓存方法、存储介质、系统
CN111506644A (zh) * 2019-01-31 2020-08-07 北京神州泰岳软件股份有限公司 一种应用数据处理方法、装置和电子设备
CN113032402A (zh) * 2021-04-09 2021-06-25 北京百度网讯科技有限公司 存储数据和获取数据的方法、装置、设备和存储介质
CN115102901A (zh) * 2022-06-17 2022-09-23 深圳前海百递网络有限公司 路由选择方法、装置、计算机设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101217392A (zh) * 2007-12-27 2008-07-09 华为技术有限公司 行为采集分析方法及系统
CN101916261A (zh) * 2010-07-28 2010-12-15 北京播思软件技术有限公司 一种分布式并行数据库系统的数据分区方法
CN102331993A (zh) * 2011-06-23 2012-01-25 北京新媒传信科技有限公司 分布式数据库的数据迁移方法和分布式数据库迁移系统
US8447730B1 (en) * 2012-01-31 2013-05-21 Yahoo! Inc. Probe system for replication monitoring
CN103425684A (zh) * 2012-05-18 2013-12-04 中兴通讯股份有限公司 数据库的操作方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101217392A (zh) * 2007-12-27 2008-07-09 华为技术有限公司 行为采集分析方法及系统
CN101916261A (zh) * 2010-07-28 2010-12-15 北京播思软件技术有限公司 一种分布式并行数据库系统的数据分区方法
CN102331993A (zh) * 2011-06-23 2012-01-25 北京新媒传信科技有限公司 分布式数据库的数据迁移方法和分布式数据库迁移系统
US8447730B1 (en) * 2012-01-31 2013-05-21 Yahoo! Inc. Probe system for replication monitoring
CN103425684A (zh) * 2012-05-18 2013-12-04 中兴通讯股份有限公司 数据库的操作方法及装置

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105138676A (zh) * 2015-09-08 2015-12-09 浙江维融电子科技股份有限公司 基于高级语言并发聚合计算的分库分表merge查询方法
CN105138676B (zh) * 2015-09-08 2017-11-24 浙江维融电子科技股份有限公司 基于高级语言并发聚合计算的分库分表merge查询方法
CN105589937A (zh) * 2015-12-14 2016-05-18 江苏鼎峰信息技术有限公司 一种分布式数据库存储架构系统
CN105930387A (zh) * 2016-04-14 2016-09-07 北京思特奇信息技术股份有限公司 一种基于数据路由、分库分表的数据操作系统及方法
CN106897332A (zh) * 2016-06-14 2017-06-27 阿里巴巴集团控股有限公司 数据库扩容方法及装置
CN106204125A (zh) * 2016-07-06 2016-12-07 合信息技术（北京）有限公司 一种定价方法及装置
CN106302640A (zh) * 2016-07-27 2017-01-04 乐视控股（北京）有限公司 数据请求处理方法及装置
CN107783974B (zh) * 2016-08-24 2022-04-08 阿里巴巴集团控股有限公司 数据处理系统及方法
CN107783974A (zh) * 2016-08-24 2018-03-09 阿里巴巴集团控股有限公司 数据处理系统及方法
CN106598823A (zh) * 2016-10-19 2017-04-26 同盾科技有限公司 一种网络行为特征的差量计算方法和系统
CN106598823B (zh) * 2016-10-19 2019-01-25 同盾控股有限公司 一种网络行为特征的差量计算方法和系统
CN106776785A (zh) * 2016-11-24 2017-05-31 腾讯科技（深圳）有限公司 一种数据写入方法及装置和数据处理系统
CN108572991A (zh) * 2017-03-14 2018-09-25 北京京东尚科信息技术有限公司 数据库处理方法、装置和存储介质
CN107229674A (zh) * 2017-04-26 2017-10-03 努比亚技术有限公司 一种数据迁移装置、服务器及方法
CN110069484A (zh) * 2017-08-29 2019-07-30 苏宁云商集团股份有限公司 一种数据库的分库方法及装置
CN107895049A (zh) * 2017-12-05 2018-04-10 泰康保险集团股份有限公司 数据处理方法及装置、计算机可读存储介质、电子设备
CN108055312A (zh) * 2017-12-07 2018-05-18 畅捷通信息技术股份有限公司 路由方法及其装置与计算机装置及其可读存储介质
CN109213761A (zh) * 2018-08-06 2019-01-15 北京马上慧科技术有限公司 一种自由扩展免迁移的分库分表方法
CN111221840A (zh) * 2018-11-23 2020-06-02 阿里巴巴集团控股有限公司 数据处理方法及装置、数据缓存方法、存储介质、系统
CN111221840B (zh) * 2018-11-23 2023-05-30 阿里云计算有限公司 数据处理方法及装置、数据缓存方法、存储介质、系统
CN111506644A (zh) * 2019-01-31 2020-08-07 北京神州泰岳软件股份有限公司 一种应用数据处理方法、装置和电子设备
CN111506644B (zh) * 2019-01-31 2024-01-23 北京神州泰岳软件股份有限公司 一种应用数据处理方法、装置和电子设备
CN110213075B (zh) * 2019-04-04 2020-01-31 特斯联（北京）科技有限公司 一种多重网络节点配置方法、装置、终端设备及介质
CN110213075A (zh) * 2019-04-04 2019-09-06 特斯联（北京）科技有限公司 一种多重网络节点配置方法、装置、终端设备及介质
CN111143414A (zh) * 2019-12-26 2020-05-12 五八有限公司 一种缓存数据的反馈方法、装置、电子设备及存储介质
CN113032402A (zh) * 2021-04-09 2021-06-25 北京百度网讯科技有限公司 存储数据和获取数据的方法、装置、设备和存储介质
CN113032402B (zh) * 2021-04-09 2024-01-12 北京百度网讯科技有限公司 存储数据和获取数据的方法、装置、设备和存储介质
CN115102901A (zh) * 2022-06-17 2022-09-23 深圳前海百递网络有限公司 路由选择方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
CN104794249B (zh) 2018-08-28

Similar Documents

Publication Publication Date Title
CN104794249A (zh) 一种数据库的实现方法和设备
US10353742B2 (en) Tracking large numbers of moving objects in an event processing system
CN105512200A (zh) 一种分布式数据库处理的方法和设备
US5333318A (en) Creating and searching a quad linked list in a trunked communication system
CN102243660B (zh) 一种数据访问方法及设备
CN108920552B (zh) 一种面向多源大数据流的分布式索引方法
CN105138571B (zh) 分布式文件系统及其存储海量小文件的方法
CN101741907A (zh) 一种均衡服务器负载的方法、系统和主服务器
US12032550B2 (en) Multi-tenant partitioning in a time-series database
US10650013B2 (en) Access operation request management
CN106415534B (zh) 一种分布式数据库中关联表分区的方法和设备
CN105224532A (zh) 数据处理方法及装置
CN104301233A (zh) 路由访问方法、路由访问系统及用户终端
JP2017509043A (ja) グラフデータクエリ方法および装置
CN106933891A (zh) 访问分布式数据库的方法和分布式数据服务的装置
US9607043B2 (en) Peak data federation multizone splitting
EP2778921B1 (en) A method and a system for distributed processing of a dataset
CN103049574A (zh) 实现文件动态副本的键值文件系统及方法
US11496562B1 (en) Method and system for accessing digital object in human-cyber-physical environment
CN107704475A (zh) 多层分布式非结构化数据存储方法、查询方法及装置
Kumar et al. M-Grid: a distributed framework for multidimensional indexing and querying of location based data
CN108829745A (zh) 业务数据的管理方法、装置及电子设备
CN111274004A (zh) 进程实例管理方法、装置及计算机存储介质
CN110134698A (zh) 数据管理方法及相关产品
CN105978744A (zh) 一种资源分配方法、装置及系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
EXSB Decision made by sipo to initiate substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information

Address after: 100190, Zhongguancun 1 East Road, Beijing, Haidian District Tsinghua Science and Technology Park, building 8, building 21, enlightenment technology building, A

Applicant after: NETEASE LEDE TECHNOLOGY CO.,LTD.

Address before: 401, room 4, building 599, 310052 business road, Changhe Road, Binjiang District, Zhejiang, Hangzhou

Applicant before: LEDE TECHNOLOGY Co.,Ltd.

COR Change of bibliographic data
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20240604

Address after: Room 303, building 3, No. 399, Wangshang Road, Changhe street, Binjiang District, Hangzhou City, Zhejiang Province, 310052

Patentee after: Hangzhou Netease bamboo Information Technology Co.,Ltd.

Country or region after: China

Address before: Building 8, Tsinghua Science and Technology Park, No. 1 Zhongguancun East Road, Haidian District, Beijing, 100190, 21st Floor, Building A, Qidi Technology Building

Patentee before: NETEASE LEDE TECHNOLOGY CO.,LTD.

Country or region before: China

TR01 Transfer of patent right