A method and device for realizing database and table separation of a network car-hailing order

Abstract

The application discloses a method and device for realizing driver and passenger order database and table splitting of online car-hailing, wherein the method comprises the following steps: creating a driver order database table, realizing database and table splitting based on a driver ID, and forming a driver order database table; obtaining historical orders, synchronizing effective passenger orders with transport capacity in the historical orders, and respectively writing the effective passenger orders into the driver order database table based on corresponding driver IDs; switching the transport capacity side to the driver order database table after reading the database and table splitting; obtaining data of an old single-table passenger order database, creating a new passenger order database table, realizing database and table splitting based on a passenger ID, and forming a hot passenger order database and a cold passenger order database; adopting a database double-writing strategy, inserting data into an order table of the old single-table passenger order database when a passenger places an order, and simultaneously writing data into the new passenger order database; and switching the passenger side to the hot passenger order database or the cold passenger order database based on cold and hot passenger order business demands.

Description

Technical Field

[0001] This invention relates to the technical field of ride-hailing driver and passenger order databases, specifically to a method and apparatus for implementing database sharding and table partitioning of ride-hailing driver and passenger orders. Background Technology

[0002] Ride-hailing, or online-booked taxi services, has gradually become an important mode of transportation for people due to the increasing coverage of the internet, the development of network technology, and the widespread use of mobile devices. It has joined public transportation and taxis, and its market share continues to rise. Compared to traditional modes of transportation, ride-hailing presents a new interaction between people, vehicles, and roads, offering advantages such as real-time performance, accuracy, efficiency, safety, and energy conservation.

[0003] However, existing ride-hailing platforms generally use a single database to store driver and passenger orders. When carpooling or order reassignment occurs, driver and passenger orders need to be modified in real time. Existing technologies generally require creating new orders, making the database bloated and difficult to trace. Otherwise, the coupling of business needs cannot be met.

[0004] In existing technologies, once a ride-hailing order is established, it is impossible to fulfill business needs such as carpooling and order reassignment, which affects the scalability of business needs and makes it difficult to meet the ever-increasing order demand. Summary of the Invention

[0005] To overcome the technical shortcomings of existing ride-hailing databases that cannot meet the needs of order business, this invention provides a method and apparatus for implementing separate databases and tables for ride-hailing driver and passenger orders.

[0006] To solve the above problems, the present invention is implemented according to the following technical solution:

[0007] In a first aspect, the present invention discloses a method for implementing database and table partitioning of ride-hailing driver and passenger orders, specifically including the following steps:

[0008] Step S1: Create a driver order database table, and implement database sharding and table partitioning based on driver ID to form the driver order database table;

[0009] Step S2: Obtain historical orders, synchronize valid passenger orders with available capacity in the historical orders, and write the valid passenger orders into the driver order database table based on the corresponding driver ID;

[0010] Step S3: Switch the data in the passenger order database read by the capacity side to the driver order database table after reading the sharded database;

[0011] Step S4: Obtain the data from the old single-table passenger order database, create a new passenger order database table, and implement database sharding and table partitioning based on passenger ID to form a hot passenger order database and a cold passenger order database;

[0012] Step S5: Adopt a dual-write strategy for the database. When a passenger places an order, insert data into the order table of the old single-table passenger order database, and at the same time write data into the new passenger order database.

[0013] Step S6: Switch the data in the passenger order database read by the passenger side, obtain the business requirements of hot and cold passenger orders, and switch to the hot passenger order database or the cold passenger order database accordingly based on the business requirements of hot and cold passenger orders.

[0014] As a preferred embodiment of the first aspect, the driver order database table adopts a dual-write strategy. After a passenger order is assigned to a driver, a driver order is generated based on the driver ID, and a driver order record is written to the driver order database in the driver sharding table in real time.

[0015] The driver order database table uses MongoDB for dynamic data expansion and data synchronization to ensure traceability of abnormally lost data, and Redis for relationship mapping and caching of hot passenger orders.

[0016] As a preferred embodiment of the first aspect, the creation of the new passenger order database table specifically includes the following sub-steps:

[0017] Create a new passenger order database table;

[0018] Get the database sharding and table partitioning rules;

[0019] Classify historical passenger orders based on passenger ID;

[0020] The categorized passenger orders are written into a new passenger order database table after sharding and partitioning.

[0021] As a preferred implementation of the first aspect, the new passenger order database table uses Binlog+MQ to handle data synchronization, and the entire data is stored off-site.

[0022] As a preferred embodiment of the first aspect, the step of discarding the old database is also included, specifically comprising:

[0023] Obtain business feedback data on passenger orders;

[0024] The system will switch the current passenger order to either the hot passenger order database or the cold passenger order database.

[0025] Abandoned the old, single-table passenger order database;

[0026] Write the new passenger order to the new passenger order database table.

[0027] Secondly, this aspect also discloses a device for implementing separate databases and tables for ride-hailing driver and passenger orders, comprising:

[0028] The driver sharding module M1 is used to create a driver order database table, which is based on the driver ID to shard the database and form a driver order database table.

[0029] The driver data writing module M2 is used to obtain historical orders, synchronize valid passenger orders with available capacity in the historical orders, and write the valid passenger orders into the driver order database table based on the corresponding driver ID;

[0030] The driver data switching module M3 is used to switch the data in the passenger order database read by the capacity side to the driver order database table after reading the sharded database.

[0031] The passenger sharding module M4 is used to retrieve data from the old single-table passenger order database, create new passenger order database tables, and shard the database based on passenger IDs to form a hot passenger order database and a cold passenger order database.

[0032] The passenger data writing module M5 is used to employ a dual-write strategy in the database. When a passenger places an order, it inserts data into the order table of the old single-table passenger order database, and simultaneously writes data into the new passenger order database.

[0033] The passenger data switching module M6 is used to switch the data read from the passenger order database on the passenger side, obtain the business requirements of hot and cold passenger orders, and switch to the hot passenger order database or the cold passenger order database accordingly based on the business requirements of hot and cold passenger orders.

[0034] As a preferred implementation of the second aspect, the driver order database table adopts a dual-write strategy. After a passenger order is assigned to a driver, a driver order is generated based on the driver ID, and a driver order record is written to the driver order database in the driver sharding table in real time.

[0035] The driver order database table uses MongoDB for dynamic data expansion and data synchronization to ensure traceability of abnormally lost data, and Redis for relationship mapping and caching of hot passenger orders.

[0036] As a preferred embodiment of the second aspect, the passenger database sharding module performs the following specific actions during operation:

[0037] Create a new passenger order database table;

[0038] Get the database sharding and table partitioning rules;

[0039] Classify historical passenger orders based on passenger ID;

[0040] The categorized passenger orders are written into a new passenger order database table after sharding and partitioning.

[0041] As a preferred implementation of the second aspect, the new passenger order database table uses Binlog+MQ to handle data synchronization, and the entire data is stored off-site.

[0042] As a preferred embodiment of the second aspect, it also includes a database abandonment module, which specifically executes the following during runtime:

[0043] Obtain business feedback data on passenger orders;

[0044] The system will switch the current passenger order to either the hot passenger order database or the cold passenger order database.

[0045] Abandoned the old, single-table passenger order database;

[0046] Write the new passenger order to the new passenger order database table.

[0047] Compared with the prior art, the beneficial effects of the present invention are:

[0048] The key point is that driver and passenger orders are separated and databases are divided into separate tables through a double-write and then read approach.

[0049] This invention creatively separates driver and passenger orders, ultimately achieving database sharding and table partitioning for these orders. This separation resolves the coupling of business requirements; before separation, it was impossible to implement business needs such as carpooling and order reassignment. Separation also addresses the scalability of these business requirements. Database sharding and table partitioning improves the efficiency of inserting, updating, and querying driver and passenger order data, breaking through the bottleneck of a single database to meet the ever-increasing order demand. Furthermore, this invention creatively uses MongoDB for dynamic data expansion and data synchronization with traceability safeguards for driver orders, and Redis for hot order relationship mapping and caching. For passenger orders, Binlog+MQ is used for data synchronization, achieving off-site storage of all data; and secure order data is encrypted and stored separately. Attached Figure Description

[0050] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, wherein:

[0051] Figure 1 This is a flowchart illustrating the method for implementing the database and table partitioning of ride-hailing driver and passenger orders according to the present invention;

[0052] Figure 2This is a schematic diagram of the device for implementing the separate database and separate tables for ride-hailing driver and passenger orders according to the present invention. Detailed Implementation

[0053] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0054] The following detailed description of the features and advantages of the present invention in the embodiments is sufficient to enable anyone skilled in the art to understand the technical content of the present invention and implement it accordingly. Based on the disclosure, claims, and drawings in this specification, anyone skilled in the art can easily understand the related objectives and advantages of the present invention. The following embodiments are further detailed in illustrating the viewpoints of the present invention, but are not intended to limit the scope of the present invention in any way.

[0055] Furthermore, embodiments of the present invention will be disclosed below with reference to the accompanying drawings. For the purpose of clarity, some conventional structures and components may be shown in a simplified schematic manner in the drawings, and some features in the drawings may be slightly enlarged or have their scale or size changed to facilitate understanding and viewing of the technical features of the present invention. However, this is not intended to limit the present invention. In addition, coordinate axes are provided in the drawings to facilitate understanding the relative positional relationships and directions of operation of the components.

[0056] Preferred embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art.

[0057] The term "comprising" and its variations as used herein signify open inclusion, i.e., "including but not limited to". Unless otherwise stated, the term "or" means "and / or". The term "based on" means "at least partially based on". The terms "one example embodiment" and "one embodiment" mean "at least one example embodiment". The term "another embodiment" means "at least one additional embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0058] Access devices and servers can be connected directly or indirectly via wired or wireless communication. Access devices can be terminals or servers. The target application runs on the access device. The target application is an application capable of making data requests to the server, such as social applications, payment applications, and game applications. The server can be an application server providing services to the target application, or a proxy server distinct from the application server corresponding to the target application. The server identifies whether each access device is malicious and intercepts data packets from malicious devices. When the server acts as a proxy server, it forwards data packets not originating from malicious devices to the application server. Terminals can be desktop terminals or mobile terminals. Mobile terminals can include smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, etc., but are not limited to these. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0059] Furthermore, unless otherwise defined, all words or terms used herein, including technical and scientific terms, have their ordinary meanings that can be understood by those skilled in the art. In other words, the definitions of the above-mentioned words or terms should be interpreted in this specification as having the same meaning as those in the relevant technical field of this invention. Unless specifically defined, these words or terms will not be interpreted as having overly idealized or formal meanings.

[0060] Example 1

[0061] like Figure 1 As shown, in a first aspect, the present invention discloses a method for implementing database and table partitioning of ride-hailing driver and passenger orders, specifically including the following steps:

[0062] Step S1: Create a driver order database table, and implement database sharding and table partitioning based on driver ID to form the driver order database table;

[0063] Step S2: Obtain historical orders, synchronize valid passenger orders with available capacity in the historical orders, and write the valid passenger orders into the driver order database table based on the corresponding driver ID;

[0064] Step S3: Switch the data in the passenger order database read by the capacity side to the driver order database table after reading the sharded database;

[0065] Step S4: Obtain the data from the old single-table passenger order database, create a new passenger order database table, and implement database sharding and table partitioning based on passenger ID to form a hot passenger order database and a cold passenger order database;

[0066] Step S5: Adopt a dual-write strategy for the database. When a passenger places an order, insert data into the order table of the old single-table passenger order database, and at the same time write data into the new passenger order database.

[0067] Step S6: Switch the data in the passenger order database read by the passenger side, obtain the business requirements of hot and cold passenger orders, and switch to the hot passenger order database or the cold passenger order database accordingly based on the business requirements of hot and cold passenger orders.

[0068] Among them, hot passenger orders and cold passenger orders are distinguished based on passenger access frequency, order frequency, etc., to differentiate between hot passenger data and cold passenger data, and are further segmented into the corresponding hot passenger order database or cold passenger order database based on the type of passenger data.

[0069] As a preferred embodiment of the first aspect, the driver order database table adopts a dual-write strategy. After a passenger order is assigned to a driver, a driver order is generated based on the driver ID, and a driver order record is written to the driver order database in the driver sharding table in real time.

[0070] The driver order database table uses MongoDB for dynamic data expansion and data synchronization to ensure traceability of abnormally lost data, and Redis for relationship mapping and caching of hot passenger orders.

[0071] As a preferred embodiment of the first aspect, the creation of the new passenger order database table specifically includes the following sub-steps:

[0072] Create a new passenger order database table;

[0073] Get the database sharding and table partitioning rules;

[0074] Classify historical passenger orders based on passenger ID;

[0075] The categorized passenger orders are written into a new passenger order database table after sharding and partitioning.

[0076] As a preferred implementation of the first aspect, the new passenger order database table uses Binlog+MQ to handle data synchronization, and the entire data is stored off-site.

[0077] As a preferred embodiment of the first aspect, the step of discarding the old database is also included, specifically comprising:

[0078] Obtain business feedback data on passenger orders;

[0079] The system will switch the current passenger order to either the hot passenger order database or the cold passenger order database.

[0080] Abandoned the old, single-table passenger order database;

[0081] Write the new passenger order to the new passenger order database table.

[0082] In summary, this invention creatively separates driver and passenger orders, ultimately achieving database and table partitioning for these orders. This separation resolves the coupling of business requirements; without it, services such as carpooling and order reassignment could not be implemented. Furthermore, driver and passenger order partitioning addresses the scalability issues. Database and table partitioning for driver and passenger orders improves the efficiency of inserting, updating, and querying data, overcoming the bottleneck of a single database to meet the ever-increasing order demand.

[0083] Furthermore, this approach innovatively utilizes MongoDB for dynamic data expansion and data synchronization with traceability safeguards in the driver order dimension, while Redis is used for mapping and caching hot order relationships. For passenger orders, Binlog+MQ is employed for data synchronization, enabling off-site storage of all data; and secure order data is encrypted and stored separately.

[0084] Other steps of the method for improving the success rate of anonymous calls by changing the binding method described in this embodiment are found in the prior art.

[0085] Example 2

[0086] like Figure 2 As shown, in a second aspect, this aspect also discloses an apparatus for implementing separate databases and tables for ride-hailing driver and passenger orders, comprising:

[0087] The driver sharding module M1 is used to create a driver order database table, which is based on the driver ID to shard the database and form a driver order database table.

[0088] The driver data writing module M2 is used to obtain historical orders, synchronize valid passenger orders with available capacity in the historical orders, and write the valid passenger orders into the driver order database table based on the corresponding driver ID;

[0089] The driver data switching module M3 is used to switch the data in the passenger order database read by the capacity side to the driver order database table after reading the sharded database.

[0090] The passenger sharding module M4 is used to retrieve data from the old single-table passenger order database, create new passenger order database tables, and shard the database based on passenger IDs to form a hot passenger order database and a cold passenger order database.

[0091] The passenger data writing module M5 is used to employ a dual-write strategy in the database. When a passenger places an order, it inserts data into the order table of the old single-table passenger order database, and simultaneously writes data into the new passenger order database.

[0092] The passenger data switching module M6 is used to switch the data read from the passenger order database on the passenger side, obtain the business requirements of hot and cold passenger orders, and switch to the hot passenger order database or the cold passenger order database accordingly based on the business requirements of hot and cold passenger orders.

[0093] As a preferred implementation of the second aspect, the driver order database table adopts a dual-write strategy. After a passenger order is assigned to a driver, a driver order is generated based on the driver ID, and a driver order record is written to the driver order database in the driver sharding table in real time.

[0094] The driver order database table uses MongoDB for dynamic data expansion and data synchronization to ensure traceability of abnormally lost data, and Redis for relationship mapping and caching of hot passenger orders.

[0095] As a preferred embodiment of the second aspect, the passenger database sharding module M4, during operation, specifically executes:

[0096] Create a new passenger order database table;

[0097] Get the database sharding and table partitioning rules;

[0098] Classify historical passenger orders based on passenger ID;

[0099] The categorized passenger orders are written into a new passenger order database table after sharding and partitioning.

[0100] As a preferred implementation of the second aspect, the new passenger order database table uses Binlog+MQ to handle data synchronization, and the entire data is stored off-site.

[0101] As a preferred embodiment of the second aspect, it also includes a database obsolescence module M7, which specifically executes the following during runtime:

[0102] Obtain business feedback data on passenger orders;

[0103] The system will switch the current passenger order to either the hot passenger order database or the cold passenger order database.

[0104] Abandoned the old, single-table passenger order database;

[0105] Write the new passenger order to the new passenger order database table.

[0106] Other structures of the device for implementing the separate database and table of ride-hailing driver and passenger orders described in this embodiment are referred to in the prior art.

[0107] Example 3

[0108] This invention also discloses an electronic device, including at least one processor and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor. When the at least one processor executes the instructions, it specifically implements the following steps: creating a driver order database table, implementing database sharding based on driver IDs to form a driver order database table; acquiring historical orders, synchronizing valid passenger orders with available capacity in the historical orders, and writing the valid passenger orders to the driver order database table based on their corresponding driver IDs; switching the data in the passenger order database read by the capacity side to the driver order database table after database sharding; acquiring data from the old single-table passenger order database, creating a new passenger order database table, and implementing database sharding based on passenger IDs to form a hot passenger order database and a cold passenger order database; adopting a dual-write strategy, inserting data into the order table of the old single-table passenger order database when a passenger places an order, and simultaneously writing data to the new passenger order database; switching the data in the passenger order database read by the passenger side, acquiring hot and cold passenger order business requirements, and switching to the hot or cold passenger order database accordingly based on these requirements.

[0109] Example 4

[0110] This invention also discloses a storage medium storing a computer program. When the computer program is executed by a processor, it specifically implements the following steps: creating a driver order database table, and implementing database sharding and table partitioning based on driver IDs to form a driver order database table; obtaining historical orders, synchronizing valid passenger orders that have been accepted by the transportation capacity in the historical orders, and writing the valid passenger orders into the driver order database table based on their corresponding driver IDs; switching the data in the passenger order database read by the transportation capacity side to the driver order database table after database sharding and table partitioning; obtaining the data in the old single-table passenger order database, creating a new passenger order database table, and implementing database sharding and table partitioning based on passenger IDs to form a hot passenger order database and a cold passenger order database; adopting a dual-write strategy, when a passenger places an order, inserting data into the order table in the old single-table passenger order database, and simultaneously writing data into the new passenger order database; switching the data in the passenger order database read by the passenger side, obtaining the hot and cold passenger order business requirements, and switching to the hot passenger order database or the cold passenger order database accordingly based on the hot and cold passenger order business requirements.

[0111] This disclosure can be a method, apparatus, system, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of this disclosure.

[0112] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0113] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0114] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, Java, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0115] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0116] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0117] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0118] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0119] Various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for implementing database and table partitioning of ride-hailing driver and passenger orders, characterized in that, Specifically, the following steps are included: Create a driver order database table, and implement database sharding and table partitioning based on driver ID to form the driver order database table; Retrieve historical orders, synchronize valid passenger orders with available capacity in the historical orders, and write the valid passenger orders into the driver order database table based on their corresponding driver IDs; The data in the passenger order database read by the capacity side is switched to the driver order database table after the database is split and the tables are split. Retrieve data from the old single-table passenger order database, create a new passenger order database table, and implement database sharding and table partitioning based on passenger ID. Divide the order data into hot passenger orders and cold passenger orders according to the passenger's access frequency or order frequency, and store them in the hot passenger order database and cold passenger order database respectively. A dual-write strategy is adopted for the database. When a passenger places an order, data is inserted into the order table of the old single-table passenger order database, and data is written to the new passenger order database at the same time. The data read from the passenger order database on the passenger side is switched to obtain the business requirements of hot and cold passenger orders, and the hot passenger order database or cold passenger order database is switched accordingly based on the business requirements of hot and cold passenger orders.

2. The method for implementing database and table partitioning of ride-hailing driver and passenger orders according to claim 1, characterized in that: The driver order database table adopts a dual-write strategy. After a passenger order is assigned to a driver, a driver order is generated based on the driver ID, and a driver order record is written to the driver order database in the driver sharding table in real time. The driver order database table uses MongoDB for dynamic data expansion and data synchronization to ensure traceability of abnormally lost data, and Redis for relationship mapping and caching of hot passenger orders.

3. The method for implementing database and table partitioning of ride-hailing driver and passenger orders according to claim 2, characterized in that, The creation of the new passenger order database table specifically includes the following sub-steps: Create a new passenger order database table; Get the database sharding and table partitioning rules; Classify historical passenger orders based on passenger ID; The categorized passenger orders are written into a new passenger order database table after sharding and partitioning.

4. The method for implementing database and table partitioning of ride-hailing driver and passenger orders according to claim 3, characterized in that: The new passenger order database table uses Binlog+MQ to handle data synchronization, and the entire data is stored off-site.

5. The method for implementing database and table partitioning of ride-hailing driver and passenger orders according to claim 4, characterized in that, It also includes the step of dismantling the old database, specifically including: Obtain business feedback data on passenger orders; The system will switch the current passenger order to either the hot passenger order database or the cold passenger order database. Abandoned the old, single-table passenger order database; Write the new passenger order to the new passenger order database table.

6. A device for implementing separate databases and tables for ride-hailing driver and passenger orders, characterized in that, include: The driver sharding module is used to create a driver order database table, which is based on the driver ID to achieve sharding and table partitioning, forming the driver order database table. The driver data writing module is used to retrieve historical orders, synchronize valid passenger orders with available capacity in the historical orders, and write the valid passenger orders into the driver order database table based on the corresponding driver ID. The driver data switching module is used to switch the data in the passenger order database read by the capacity side to the driver order database table after reading the sharded database. The passenger sharding module is used to retrieve data from the old single-table passenger order database, create a new passenger order database table, and shard the database based on the passenger ID. It divides the order data into hot passenger orders and cold passenger orders according to the passenger's access frequency or order frequency, and stores them in the hot passenger order database and the cold passenger order database respectively. The passenger data writing module is used to employ a dual-write strategy in the database. When a passenger places an order, it inserts data into the order table of the old single-table passenger order database, and simultaneously writes data into the new passenger order database. The passenger data switching module is used to switch the data read from the passenger order database on the passenger side, obtain the business requirements of hot and cold passenger orders, and switch to the hot passenger order database or the cold passenger order database accordingly based on the business requirements of hot and cold passenger orders.

7. The apparatus for implementing separate databases and tables for ride-hailing driver and passenger orders according to claim 6, characterized in that: The driver order database table adopts a dual-write strategy. After a passenger order is assigned to a driver, a driver order is generated based on the driver ID, and a driver order record is written to the driver order database in the driver sharding table in real time. The driver order database table uses MongoDB for dynamic data expansion and data synchronization to ensure traceability of abnormally lost data, and Redis for relationship mapping and caching of hot passenger orders.

8. The apparatus for implementing separate databases and tables for ride-hailing driver and passenger orders according to claim 7, characterized in that, When the passenger database sharding and table partitioning module is running, it specifically performs the following: Create a new passenger order database table; Get the database sharding and table partitioning rules; Classify historical passenger orders based on passenger ID; The categorized passenger orders are written into a new passenger order database table after sharding and partitioning.

9. The apparatus for implementing separate databases and tables for ride-hailing driver and passenger orders according to claim 8, characterized in that: The new passenger order database table uses Binlog+MQ to handle data synchronization, and the entire data is stored off-site.

10. The apparatus for implementing separate databases and tables for ride-hailing driver and passenger orders according to claim 9, characterized in that, It also includes a database obsolescence module, which executes the following during runtime: Obtain business feedback data on passenger orders; The system will switch the current passenger order to either the hot passenger order database or the cold passenger order database. Abandoned the old, single-table passenger order database; Write the new passenger order to the new passenger order database table.

Images