数据存储方法和装置与流程

1.本发明涉及计算机应用技术，特别是涉及一种数据存储方法和装置。


背景技术：

2.随着业务的增长，单表数据量很大的时候，会出现读写性能的瓶颈，以mysql为例，b+树索引的深度会随着数据的增多而逐渐加深，根据索引查询的开销也会越来越大。这种情况下，就需要对数据库做优化以适应业务的发展。
3.目前，为了解决由于数据量过大而导致数据库性能降低的问题，分表分库是一种常用的解决方法。该方法通过将原来独立的数据库拆分成若干数据库组成，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。现有的分表分库中间件有很多，如shardingsphere、mycat等,这些中间件都可以让开发人员按照标准mysql协议使用数据库，在不改变业务代码的情况下透明地实现分库分表的能力。
4.申请人在实现本发明的过程中发现现有分表分库方法存在扩展性差、扩展成本高、无法适应数据存储动态变化以及技术要求高等问题。经过研究分析，导致这些问题的具体原因如下：
5.现有的分表分库的方法基于既定的数据规模确定分表的数量，相应的数据访问维护代码(包括数据的增、删、改等操作)将与已确定的表、库绑定的。而随着业务的发展，数据规模也会动态增长的，当既有的分表分库方案不适用于新的数据规模时，就需要重新进行分库分表，相应的，数据访问维护代码也需要重新编写，从而导致现有的分表分库方法的扩展性差、扩展成本高。
6.另外，现有分表分库方案不具有动态切换分表分库规则的功能，需要人工确定分表分库时机，并且在进行分表分库时也需要技术人员针对不同的业务场景做深入分析，来确定所采用的分表分库策略，因此，存在无法自适应数据存储动态变化以及对开发人员技术要求高等问题。


技术实现要素：

7.有鉴于此，本发明的主要目的在于提供一种数据存储方法和装置，可以自适应存储需求的动态变化，且易于扩展。
8.为了达到上述目的，本发明实施例提出的技术方案为：
9.一种数据存储方法，包括：
10.当需要执行数据插入操作时，基于待插入目标数据表的预设最大数据规模阈值和实际数据规模，判断当前是否需要创建新数据表；如果是，则基于所述目标数据表创建新数据表，将所述数据插入操作的目标记录数据插入所述新数据表，否则，将所述目标数据插入所述目标数据表。
11.本发明实施例还提出了一种数据存储装置，包括：
12.存储控制单元，用于当需要执行数据插入操作时，基于待插入目标数据表的预设最大数据规模阈值和实际数据规模，判断当前是否需要创建新数据表；
13.存储执行单元，用于如果需要创建新数据表，则基于所述目标数据表创建新数据表，将所述数据插入操作的目标记录数据插入所述新数据表，否则，将所述目标数据插入所述目标数据表。
14.本发明实施例还提出了一种数据存储设备，包括处理器和存储器；
15.所述存储器中存储有可被所述处理器执行的应用程序，用于使得所述处理器执行如上所述数据存储方法。
16.本发明实施例还提出了一种计算机可读存储介质，其中存储有计算机可读指令，该计算机可读指令用于执行如上所述数据存储方法。
17.本发明实施例还提出了一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现如上所述数据存储方法的步骤。
18.综上所述，本发明提出的数据存储方法和装置，在需要执行数据插入操作时，需要先考虑当前是否需要为该数据插入操作的目标表创建新表，而非仅是执行数据插入操作。这样，通过将数据插入操作与数据表的规模监测绑定，可以在每次需要增加数据表的数据规模时，及时基于数据表的实际数据规模和最大数据规模阈值，及时获知数据表的实际数据规模是否过大，并能及时通过触发新数据表的创建，对数据表的实际规模大小进行控制，从而可以根据实际数据存储情况自动触发创建数据表，实现了数据表的动态创建，进而使得数据表的创建能够自适应存储需求的动态变化。并且，由于数据表的增加并不需要重新编写数据访问维护代码，且不需要人工参与，因此，可以大幅度降低数据表扩展的难度，进而提高了数据存储的可扩展性。
附图说明
19.图1为本发明实施例的方法流程示意图；
20.图2为本发明实施例的基于数据库连接池资源使用状况自适应触发分库的方法流程示意图；
21.图3为本发明实施例的基于对数据库服务器cpu负载的监听自适应触发分库的方法流程示意图；
22.图4为本发明实施例的自适应分表方法流程示意图；
23.图5为步骤403中为数据表确定分表数量的具体方法流程示意图；
24.图6为本发明实施例的装置结构示意图。
具体实施方式
25.为使本发明的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明作进一步地详细描述。
26.图1为本发明实施例的数据存储方法流程示意图，如图1所示，该实施例实现的数据存储方法主要包括：
27.步骤101、当需要执行数据插入操作时，基于待插入目标数据表的预设最大数据规模阈值和实际数据规模，判断当前是否需要创建新数据表，如果是，则执行步骤102，否则，
执行步骤103。
28.本步骤中，考虑到对数据表执行数据插入操作，将会使得数据表的实际数据规模变大，为了避免数据表的规模随着业务数据的增加而过大，这里，在每次需要执行数据插入操作时，都得先基于待插入目标数据表的最大数据规模阈值和实际数据规模，判断当前是否需要创建新数据表。这样，通过将数据插入操作与数据表的规模监测绑定，可以基于数据表的实际数据规模和最大数据规模阈值，及时获知数据表的实际数据规模是否过大，并能通过及时触发新数据表的创建，对数据表的实际规模大小进行控制，从而可以根据实际数据存储情况自动触发创建数据表，实现了数据表的动态创建，进而使得数据表的创建能够自适应存储需求的动态变化。并且，由于数据表的增加并不需要重新编写数据访问维护代码，且不需要人工参与，因此，可以大幅度降低数据表扩展的难度，进而提高了数据存储的可扩展性。
29.在一种实施方式，为了实现对数据表规模的准确控制，所述数据插入操作具体可以为将一条记录数据插入数据表的操作，这样，每插入一条记录数据时，都得先判断当前需要为目标数据表创建新表，以将目标数据表的规范控制在一定范围内，即不能超出最大数据规模阈值。
30.在一种实施方式中，可以采用确保执行当前数据插入操作不会导致目标数据表规模超出相应最大数据规模阈值的原则，来确定当前是否需要创建新数据表，具体实现方法如下：
31.判断将所述目标数据插入所述目标数据表后，所述目标表的数据规模是否大于所述最大数据规模阈值，如果是，则判定需要创建新数据表，否则，判定不需要创建新数据表。
32.上述方法中，将数据插入前目标数据表的实际数据规模大小与待插入数据的大小相加，即得到执行数据插入操作后目标表的数据规模。
33.在一种实施方式中，所述最大数据规模阈值的类型具体可以是数据表的最大记录数，也可以是数据表的最大数据量。前者适用于每条记录大小固定的数据表，后者，适用于每条记录大小不固定的数据表，具体可由本领域技术人员根据实际需要选择合适类型的最大数据规模阈值，并设置合适取值。
34.步骤102、基于所述目标数据表创建新数据表，将所述数据插入操作的目标记录数据插入所述新数据表。
35.本步骤，用于在数据插入操作会导致目标数据表超范围时，基于目标数据表创建新数据表，所得到新数据表的结构和目标数据表相同，然后再将相应的待插入记录数据插入到该新数据表中，而不再存入目标数据表中，从而可以自适应地对目标数据表的数据规模进行有效控制，实现数据表的自适应扩展。
36.步骤103、将所述目标数据插入所述目标数据表。
37.在一种实施方式中，在步骤102和103中完成数据插入操作后，可以进一步为插入数据后的数据表更新数据存储时间范围，即为存储所述目标数据的数据表生成的数据存储时间范围，以便后续进行数据查询时，可以基于各数据表的数据存储时间范围，快速定位查询的目标数据表。
38.具体地的，可以利用数据表中第一条记录的存储时间和最后一条记录的存储时间，分别界定数据存储时间范围的最早时间和最晚时间。
39.在一种实施方式中，还可以进一步对数据表的字段操作(如创建字段、修改字段)进行监听，以在由于数据表中的字段发生变化而导致数据表的规模发生变化时，监测当前是否达到对数据表进行垂直拆分的条件，以及时触发对数据表的垂直拆分，从而进一步实现了对数据表进行垂直拆分的智能扩展，具体可以采用下述方法实现：
40.当对数据表执行完预设的字段操作时，判断所述数据表的单行实际数据量是否大于预设的所述数据表的单行数据量最大阈值，如果是，则触发对所述数据表进行垂直拆分；所述字段操作包括对字段的创建和/或修改操作。
41.这里，在具体进行垂直拆分时，将基于数据表的字段集合，得到若干子字段集合，然后基于每个子字段集合分别构建数据表，再将原数据表中的数据迁移至新构建的数据表中，即实现对原数据表的垂直拆分。这样，通过对所述数据表进行垂直拆分，可以对数据表的字段规模进行自适应控制，避免出现由于字段的增加或修订而导致数据表规模较大的问题。
42.在实际应用中，可以进一步考虑数据表中字段的查询以及修改频繁度、字段间操作的关联性以及字段大小等因素，选择合适的垂直拆分策略，例如，可以将经常同时修改、同时查询的字段放置于同一子字段集合中，对经常使用的字段(如时间版本等)字段，不进行拆分，即在多个数据表中冗余保留。
43.在一种实施方式中，可以进一步基于对数据库连接池中连接资源的使用状况的监听，自适应触发分库，以避免由于数据库服务器中数据库规模过大降低数据库服务器运行性能降低的问题，如图2所示，具体可以采用下述方法实现：
44.步骤201、实时监测当前数据库服务器的数据库连接池中的连接使用比例，当所述连接使用比例达到预设连接比例最大阈值时，触发连接报警，并将每个数据库在所述数据库连接池中的连接占用比例值，记录在连接报警记录中。
45.这里，所述连接使用比例，即数据库服务器当前的并发连接数量与数据库连接池(即数据库连接线程资源池)中总连接资源数量的比值，其反映的是当前数据库服务器中的连接资源使用情况。具体的，一个数据库连接对应一个数据库访问操作。
46.本步骤中，数据库服务器需要对数据库连接池中的连接使用比例进行实时监测，以及时获知数据库连接池中连接资源的使用情况，并在连接开销较大时，触发连接报警，以便后续基于报警记录，筛选出连接开销较大的数据库，对其进行分库，以降低数据库访问维护操作对数据库服务器的压力，保障数据库服务器的运行性能。
47.所述连接比例最大阈值，用于限定连接报警时机，其大小与数据库服务器支持的并发连接数量相关联，具体可以由本领域技术人员根据用户对数据库服务器访问的性能需求，设置合适取值。
48.在一种实施方式中，具体可以基于预设的连接报警监听周期，周期性地进行步骤201中的所述监测，但不限于此。
49.步骤202、在每个预设的第一分库检测周期，基于本周期内产生的连接报警记录，计算每个所述数据库在本周期的报警连接比例累积值。
50.本步骤，为了能够自适应地准确做出分库决策，需要基于一定时间段(即第一分库检测周期)内产生的连接报警记录，来计算每个所述数据库在该第一分库检测周期的报警连接比例累积值，以使得报警连接比例累积值能够准确地体现出数据库的并发连接情况。
51.在一种实施方式中，具体可以采用下述方法，基于每个数据库在本周期内所有连接报警记录，计算相应数据库在本周期的报警连接比例累积值：
52.针对每个所述数据库，将该数据库在本周期内所有连接报警记录中的所述连接占用比例值，进行累加，得到该数据库的报警连接比例累积值。
53.在实际应用中，不限于采用上述实施方式计算每个所述数据库在本周期的报警连接比例累积值。例如，可以从本周期内的连接报警记录中，选择出部分连接使用比例较大的若干连接报警记录，基于所选择的连接报警记录，计算每个所述数据库在本周期的报警连接比例累积值。
54.所述第一分库检测周期，用于限定基于并发连接情况进行分库检测的时机，具体可以由本领域技术人员根据实际分库检测的实时性、准确性需求以及数据库规模的实际增长需求，设置合适的周期长度，例如可以是一天，或若干小时，或若干天等。
55.步骤203、将所述报警连接比例累积值大于预设连接浮动因子的数据库，迁移出所述数据库服务器。
56.这里，如果数据库的报警连接比例累积值大于连接浮动因子，则说明该数据库的并发连接请求数量过大，会降低数据库服务器的运行性能，因此，需要将其从当前数据库服务器迁移至能够支持其正常运行的其他数据库服务器，即执行分库操作。具体分库的目标数据库服务器可采用现有的分库方法确定，在此不再赘述。
57.所述连接浮动因子，用于限定分库的条件，其取值大于0，具体可由本领域技术人员根据实际性能需要设置合适取值。简单起见，可以设置连接浮动因子与上述连接比例最大阈值相同，但不限于此。
58.下面结合一具体示例，进一步详细说明上述步骤201～203的具体实现：
59.假如数据库服务器中有三个数据库：库a、库b和库c，第一分库检测周期为一天，当前第一分库检测周期内数据库服务器的连接报警3次，连接数浮动因子与连接比例最大阈值相同均为69％，具体报警情况如下：
60.第一次连接报警：
61.库a1＝50％，库b1＝20％，库c1＝11％
62.第二次连接报警：
63.库a2＝20％，库b2＝30％，库c2＝31％
64.第三次连接报警：
65.库a2＝40％，库b3＝20％，库c3＝22％
66.每个数据库在本周期的报警连接比例累积值计算如下：
67.库a：库a1+库a2+库a3＝库a＝110％
68.库b：库b1+库b2+库b3＝库b＝70％
69.库c：库c1+库c2+库c3＝库c＝65％
70.由于库a和库b的报警连接比例累积值都大于连接数浮动因子，因此，把库a和库b迁移出去。
71.在一种实施方式中，还可以进一步基于对数据库服务器的cpu负载的监听，自适应触发分库，以避免由于数据库服务器中数据库规模过大降低数据库服务器运行性能降低的问题，如图3所示，具体可以采用下述方法实现：
72.步骤301、实时监测当前数据库服务器的cpu负载以及每条数据库操作语句执行时占用的cpu负载。
73.本步骤中，对数据库服务器的cpu负载以及数据库操作语句执行时占用的cpu负载的具体获取方法可采用现有技术实现，在此不再赘述。
74.在一种实施方式中，具体可以基于预设的cpu负载监听周期，周期性地进行步骤301中的所述监测，但不限于此。
75.所述cpu负载，具体可以采用已占用cpu资源与总cpu资源的比值表征。
76.步骤302、当所述数据库服务器的cpu负载达到预设cpu负载最大阈值时，触发cpu负载报警，并基于当前数据库操作语句的cpu负载，计算本次cpu负载报警中每个数据库占用的cpu负载比例，并记录在cpu负载报警记录中。
77.所述cpu负载最大阈值，用于限定cpu负载报警时机，其大小与数据库服务器支持的cpu负载能力相关联，具体可以由本领域技术人员根据用户对数据库服务器访问的性能需求，设置合适取值。
78.步骤303、在每个预设的第二分库检测周期，基于本周期内产生的cpu负载报警记录，计算每个所述数据库在本周期的报警cpu负载比例累积值。
79.本步骤，为了能够自适应地准确做出分库决策，需要基于一定时间段(即第二分库检测周期)内产生的cpu负载报警记录，来计算每个所述数据库在该第二分库检测周期的报警cpu负载比例累积值，以使得报警连接比例累积值能够准确地体现出数据库占用的cpu负载情况。
80.所述第二分库检测周期，用于限定基于cpu负载进行分库检测的时机，具体可以由本领域技术人员根据实际分库检测的实时性、准确性需求以及数据库规模的实际增长需求，设置合适的周期长度，例如可以是一天，或若干小时，或若干天等。
81.在一种实施方式中，具体可以采用下述方法，基于每个数据库在本周期内所有cpu负载报警记录，计算每个所述数据库在本周期的报警cpu负载比例累积值：
82.针对每个所述数据库，将该数据库在本周期内所有cpu负载报警记录中的所述cpu负载比例进行累加，得到该数据库的所述报警cpu负载比例累积值。
83.在实际应用中，不限于采用上述实施方式计算每个所述数据库在本周期的报警cpu负载比例累积值。例如，可以从当前第二分库检测周期内的cpu负载报警记录中，选择出数据库服务器的cpu负载较大的若干cpu负载报警记录，基于所选择的cpu负载报警记录，计算每个所述数据库在当前第二分库检测周期的报警cpu负载比例累积值。
84.步骤304、将所述报警cpu负载比例累积值大于预设cpu浮动因子的数据库，迁移出所述数据库服务器。
85.这里，如果数据库的报警cpu负载比例累积值大于cpu浮动因子，则说明该数据库占用的cpu资源过大，从而对数据库服务器运行性能的影响较大，因此，需要将其从当前数据库服务器迁移至能够支持其正常运行的其他数据库服务器，即执行分库操作。具体分库的目标数据库服务器可采用现有的分库方法确定，在此不再赘述。
86.所述cpu浮动因子，用于限定分库的条件，其取值大于0，具体可由本领域技术人员根据实际性能需要设置合适取值。简单起见，可以设置cpu浮动因子与上述cpu负载最大阈值相同，但不限于此。
87.下面结合一具体示例，进一步详细说明上述步骤301～303的具体实现：
88.假如数据库服务器中有三个数据库：库a、库b和库c，第一分库检测周期为一天，当前第二分库检测周期内数据库服务器的cpu负载报警3次，cpu浮动因子与cpu负载最大阈值相同均为49％，具体报警情况如下：
89.第一次报警cpu负载：
90.库a1＝10％，库b1＝20％，库c1＝10％
91.第二次报警cpu负载：
92.库a2＝40％，库b2＝10％，库c2＝10％
93.第三次报警cpu负载：
94.库a3＝10％，库b3＝20％，库c3＝10％
95.每个数据库在本周期的报警cpu负载比例累积值计算如下：
96.库a：库a1+库a2+库a3＝60％
97.库b：库b1+库b2+库b3＝50％
98.库c：库c1+库c2+库c3＝30％
99.由于库a和库b的报警cpu负载比例累积值都大于cpu浮动因子，因此，把库a和库b迁移出去。
100.在一种实施方式中，还可以进一步对周期性地对数据表的数据增量进行监测，以便基于监测结果，判断之前创建数据表时预估的数据增量的准确性，从而可以在判断预测增量和实际增量差距较大时，及时根据实际存储增量情况，调整数据表的数量，进而实现数据表的自适应分表，以通过自适应分表满足实际数据存储需要，实现数据存储的自适应性。，如图4所示，具体可以采用下述步骤401～403实现：
101.步骤401、在每个预设的存储监测周期，针对当前数据库服务器中的每个数据表，确定本周期内该数据表的实际存储变化量。
102.所述存储监测周期可以由本领域技术人员根据实际存储变化情况设置合适取值，例如可以是一个月，或若干天或月，但不限于此。
103.步骤402、在每个预设的存储变化评估时刻到达时，针对每个所述数据表，基于所述数据表在最近连续第一数量个所述存储监测周期内的所述实际存储变化量、预设的所述数据表在所述第一数量个所述存储监测周期内的预计存储变化量，以及预设的分表浮动阈值，确定是否需要对所述数据表进行分表。
104.所述存储变化评估时刻可以由本领域技术人员根据实际分表需要设置，例如，可以设置存储变化评估周期，基于该存储变化评估周期，确定所述存储变化评估时刻。例如可以是若干天或月等，但不限于此。
105.所述第一数量，用于限定参与分表决策的实际存储变化量，具体可由本领域技术人员预先根据实际需要设置合适取值。
106.在一种实施方式中，具体可以采用下述方法确定是否需要对所述数据表进行分表：
107.基于所述实际存储变化量和所述预计存储变化量，计算所述数据表在所述第一数量个所述存储监测周期内的实际存储变化量相比于预计存储变化量的超量，如果所述超量大于所述分表浮动阈值，则确定需要对所述数据表进行分表。
108.这里，当所述超量大于所述分表浮动阈值时，说明实际存储变化量远大于预计存储变化量，此时需要重新根据数据表的实际存储变化量，对数据表进行分表，以使得数据表的数量自适应地满足实际数据存储的动态变化，提高数据存储策略的自适应能力。
109.一种实施方式中，具体可以按照公式qk＝(n
a-n
p
)/n
p
，计算所述数据表在所述第一数量个所述存储监测周期内的实际存储变化量相比于预计存储变化量的超量qk：
110.其中，k为所述第一数量；1≤k；
111.na为数据表在最近k个存储监测周期内的实际存储变化量；
112.n
p
为数据表在最近k个存储监测周期内的预计存储变化量。
113.所述分表浮动阈值具体可根据实际应用中可接受的实际存储变化量高于预计存储变化量的程度，设置合适取值，该值大于0，在此不再赘述。
114.步骤403、当需要对所述数据表进行分表时，基于所述数据表在所述最近连续第一数量个所述存储监测周期内的所述实际存储变化量、所述数据表在所述第一数量个所述存储监测周期内的所述预计存储变化量、预设的分表增量浮动因子、预设的所述数据表的预设存储时间范围，以及预设的单个数据表的最大存储规模阈值，为所述数据表确定分表数量，基于所述分表数量，对所述数据表进行分表。
115.在一种实施方式中，如图5所示，步骤403中具体可以采用下述步骤为数据表确定分表数量：
116.步骤501、基于所述数据表在所述最近连续第一数量个所述存储监测周期内的所述实际存储变化量、所述预计存储变化量以及所述分表增量浮动因子，确定单个存储监测周期的平均预计存储变化量。
117.一种实施方式中，具体可以按照公式qh＝((n
a-n
p
)
×
s+n
p
)/k，计算单个存储监测周期的平均预计存储变化量qh。
118.其中，k为所述第一数量；1≤k；
119.na为数据表在最近k个存储监测周期内的实际存储变化量；
120.n
p
为数据表在最近k个存储监测周期内的预计存储变化量；
121.s为分表增量浮动因子。
122.在一种实施方式中，为了使得所确定的平均预计存储变化量能够尽可能地与未来实际的数据存储需求相匹配，所述分表增量浮动因子的取值范围可以为大于等于1，具体地，本领域技术人员可根据实际需求在该取值范围内为所述分表增量浮动因子选择合适的取值。
123.步骤502、基于所述平均预计存储变化量和所述存储时间范围，更新所述数据表的预计总存储量。
124.一种实施方式中，具体可以按照公式qz＝qh×
t，计算更新后的数据表的预计总存储量qz其中，qh为平均预计存储变化量，t为存储时间范围对应的存储监测周期数量。
125.步骤503、基于所述预计总存储量和所述单个数据表的最大存储规模阈值，得到所述数据表的所述分表数量。
126.一种实施方式中，具体可以按照公式m＝qz/c，计算所述所述分表数量。
127.其中，qz为所述预计总存储量，c为单个数据表的最大存储规模阈值。
128.基于上述数据存储方法实施例，本发明实施例还实现了一种数据存储装置，如图6
所示，该装置包括：
129.存储控制单元601，用于当需要执行数据插入操作时，基于待插入目标数据表的预设最大数据规模阈值和实际数据规模，判断当前是否需要创建新数据表；
130.存储执行单元602，用于如果需要创建新数据表，则基于所述目标数据表创建新数据表，将所述数据插入操作的目标记录数据插入所述新数据表，否则，将所述目标数据插入所述目标数据表。
131.需要说明的是，上述数据存储方法和装置实施例是基于同一发明构思的，由于它们解决问题的原理相似，因此，上述方法和装置的实施可以相互参见，重复之处不再赘述。
132.基于上述数据存储方法实施例，本发明实施例还实现了一种数据存储设备，包括处理器和存储器；所述存储器中存储有可被所述处理器执行的应用程序，用于使得所述处理器执行如上所述数据存储方法。
133.具体地，可以提供配有存储介质的系统或者装置，在该存储介质上存储着实现上述实施例中任一实施方式的功能的软件程序代码，且使该系统或者装置的计算机(或cpu或mpu)读出并执行存储在存储介质中的程序代码。此外，还可以通过基于程序代码的指令使计算机上操作的操作系统等来完成部分或者全部的实际操作。还可以将从存储介质读出的程序代码写到插入计算机内的扩展板中所设置的存储器中或者写到与计算机相连接的扩展单元中设置的存储器中，随后基于程序代码的指令使安装在扩展板或者扩展单元上的cpu等来执行部分和全部实际操作，从而实现上述数据存储方法实施方式中任一实施方式的功能。其中，存储器具体可以实施为电可擦可编程只读存储器(eeprom)、快闪存储器(flash memory)、可编程程序只读存储器(prom)等多种存储介质。处理器可以实施为包括一或多个中央处理器或一或多个现场可编程门阵列，其中现场可编程门阵列集成一或多个中央处理器核。具体地，中央处理器或中央处理器核可以实施为cpu或mcu。
134.基于上述数据存储方法实施例，本发明实施例还实现了一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现如上所述数据存储方法的步骤。
135.需要说明的是，上述各流程和各结构图中不是所有的步骤和模块都是必须的，可以根据实际的需要忽略某些步骤或模块。各步骤的执行顺序不是固定的，可以根据需要进行调整。各模块的划分仅仅是为了便于描述采用的功能上的划分，实际实现时，一个模块可以分由多个模块实现，多个模块的功能也可以由同一个模块实现，这些模块可以位于同一个设备中，也可以位于不同的设备中。
136.各实施方式中的硬件模块可以以机械方式或电子方式实现。例如，一个硬件模块可以包括专门设计的永久性电路或逻辑器件(如专用处理器，如fpga或asic)用于完成特定的操作。硬件模块也可以包括由软件临时配置的可编程逻辑器件或电路(如包括通用处理器或其它可编程处理器)用于执行特定操作。至于具体采用机械方式，或是采用专用的永久性电路，或是采用临时配置的电路(如由软件进行配置)来实现硬件模块，可以根据成本和时间上的考虑来决定。
137.在本文中，“示意性”表示“充当实例、例子或说明”，不应将在本文中被描述为“示意性”的任何图示、实施方式解释为一种更优选的或更具优点的技术方案。为使图面简洁，各图中的只示意性地表示出了与本发明相关部分，而并不代表其作为产品的实际结构。另
外，以使图面简洁便于理解，在有些图中具有相同结构或功能的部件，仅示意性地绘示了其中的一个，或仅标出了其中的一个。在本文中，“一个”并不表示将本发明相关部分的数量限制为“仅此一个”，并且“一个”不表示排除本发明相关部分的数量“多于一个”的情形。在本文中，“上”、“下”、“前”、“后”、“左”、“右”、“内”、“外”等仅用于表示相关部分之间的相对位置关系，而非限定这些相关部分的绝对位置。
138.以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

技术特征：
1.一种数据存储方法，其特征在于，包括：当需要执行数据插入操作时，基于待插入目标数据表的预设最大数据规模阈值和实际数据规模，判断当前是否需要创建新数据表；如果是，则基于所述目标数据表创建新数据表，将所述数据插入操作的目标记录数据插入所述新数据表，否则，将所述目标数据插入所述目标数据表。2.根据权利要求1所述的方法，其特征在于，所述判断当前是否需要创建新数据表包括：判断将所述目标数据插入所述目标数据表后，所述目标表的数据规模是否大于所述最大数据规模阈值，如果是，则判定需要创建新数据表，否则，判定不需要创建新数据表。3.根据权利要求1或2所述的方法，其特征在于，所述最大数据规模阈值包括数据表的最大记录数或数据表的最大数据量。4.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：在完成所述插入后，为存储所述目标数据的数据表生成的数据存储时间范围。5.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：实时监测当前数据库服务器的数据库连接池中的连接使用比例，当所述连接使用比例达到预设连接比例最大阈值时，触发连接报警，并将每个数据库在所述数据库连接池中的连接占用比例值，记录在连接报警记录中；在每个预设的第一分库检测周期，基于本周期内产生的连接报警记录，计算每个所述数据库在本周期的报警连接比例累积值；将所述报警连接比例累积值大于预设连接浮动因子的数据库，迁移出所述数据库服务器。6.根据权利要求5所述的方法，其特征在于，所述计算每个所述数据库在本周期的报警连接比例累积值包括：针对每个所述数据库，将该数据库在本周期内所有连接报警记录中的所述连接占用比例值，进行累加，得到该数据库的报警连接比例累积值。7.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：实时监测当前数据库服务器的cpu负载以及每条数据库操作语句执行时占用的cpu负载；当所述数据库服务器的cpu负载达到预设cpu负载最大阈值时，触发cpu负载报警，并基于当前数据库操作语句的cpu负载，计算本次cpu负载报警中每个数据库占用的cpu负载比例，并记录在cpu负载报警记录中；在每个预设的第二分库检测周期，基于本周期内产生的cpu负载报警记录，计算每个所述数据库在本周期的报警cpu负载比例累积值；将所述报警cpu负载比例累积值大于预设cpu浮动因子的数据库，迁移出所述数据库服务器。8.根据权利要求7所述的方法，其特征在于，所述计算每个所述数据库在本周期的报警cpu负载比例累积值包括：针对每个所述数据库，将该数据库在本周期内所有cpu负载报警记录中的所述cpu负载比例进行累加，得到该数据库的所述报警cpu负载比例累积值。
9.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：在每个预设的存储监测周期，针对当前数据库服务器中的每个数据表，确定本周期内该数据表的实际存储变化量；在每个预设的存储变化评估时刻到达时，针对每个所述数据表，基于所述数据表在最近连续第一数量个所述存储监测周期内的所述实际存储变化量、预设的所述数据表在所述第一数量个所述存储监测周期内的预计存储变化量，以及预设的分表浮动阈值，确定是否需要对所述数据表进行分表；当需要对所述数据表进行分表时，基于所述数据表在所述最近连续第一数量个所述存储监测周期内的所述实际存储变化量、所述数据表在所述第一数量个所述存储监测周期内的所述预计存储变化量、预设的分表增量浮动因子、预设的所述数据表的预设存储时间范围，以及预设的单个数据表的最大存储规模阈值，为所述数据表确定分表数量，基于所述分表数量，对所述数据表进行分表。10.根据权利要求1所述的方法，其特征在于，所述确定是否需要对所述数据表进行分表包括：基于所述实际存储变化量和所述预计存储变化量，计算所述数据表在所述第一数量个所述存储监测周期内的实际存储变化量相比于预计存储变化量的超量，如果所述超量大于所述分表浮动阈值，则确定需要对所述数据表进行分表；所述为所述数据表确定分表数量包括：基于所述数据表在所述最近连续第一数量个所述存储监测周期内的所述实际存储变化量、所述预计存储变化量以及所述分表增量浮动因子，确定单个存储监测周期的平均预计存储变化量；基于所述平均预计存储变化量和所述存储时间范围，更新所述数据表的预计总存储量；基于所述预计总存储量和所述单个数据表的最大存储规模阈值，得到所述数据表的所述分表数量。11.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：当对数据表执行完预设的字段操作时，判断所述数据表的单行实际数据量是否大于预设的所述数据表的单行数据量最大阈值，如果是，则触发对所述数据表进行垂直拆分；所述字段操作包括对字段的创建和/或修改操作。12.一种数据存储装置，其特征在于，包括：存储控制单元，用于当需要执行数据插入操作时，基于待插入目标数据表的预设最大数据规模阈值和实际数据规模，判断当前是否需要创建新数据表；存储执行单元，用于如果需要创建新数据表，则基于所述目标数据表创建新数据表，将所述数据插入操作的目标记录数据插入所述新数据表，否则，将所述目标数据插入所述目标数据表。13.一种数据存储设备，其特征在于，包括处理器和存储器；所述存储器中存储有可被所述处理器执行的应用程序，用于使得所述处理器执行如权利要求1至11中任一项所述数据存储方法。14.一种计算机可读存储介质，其特征在于，其中存储有计算机可读指令，该计算机可
读指令用于执行如权利要求1至11中任一项所述数据存储方法。15.一种计算机程序产品，包括计算机程序/指令，其特征在于，该计算机程序/指令被处理器执行时实现权利要求1至11中任一项所述数据存储方法的步骤。

技术总结
本申请公开了一种数据存储方法和装置，其中方法包括：当需要执行数据插入操作时，基于待插入目标数据表的预设最大数据规模阈值和实际数据规模，判断当前是否需要创建新数据表；如果是，则基于所述目标数据表创建新数据表，将所述数据插入操作的目标记录数据插入所述新数据表，否则，将所述目标数据插入所述目标数据表。采用本申请，可以使得数据存储能够自适应存储需求的动态变化，且易于扩展。且易于扩展。且易于扩展。


技术研发人员：李雪楠 刘晓鹏 石小令 刘靖 王彪
受保护的技术使用者：北京嘀嘀无限科技发展有限公司
技术研发日：2022.01.18
技术公布日：2023/8/1