CN114282048A - Playing record warehousing method and device, storage medium and electronic equipment - Google Patents
Playing record warehousing method and device, storage medium and electronic equipment Download PDFInfo
- Publication number
- CN114282048A CN114282048A CN202210214211.XA CN202210214211A CN114282048A CN 114282048 A CN114282048 A CN 114282048A CN 202210214211 A CN202210214211 A CN 202210214211A CN 114282048 A CN114282048 A CN 114282048A
- Authority
- CN
- China
- Prior art keywords
- record
- playing
- play
- stored
- target
- 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
Links
Images
Landscapes
- Television Signal Processing For Recording (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
- Management Or Editing Of Information On Record Carriers (AREA)
Abstract
The method comprises the steps of writing index records of play records to be deleted into a pre-deletion list through a pre-stored queue and the pre-deletion list, writing elements of the play records to be stored into the pre-stored queue, deleting play records corresponding to the main key identifiers in a database based on main key identifiers in the index records of the pre-deletion list after a timing task is triggered, and writing the play records corresponding to the elements meeting a pre-stored rule in a cache into the database based on the elements meeting the pre-stored rule in the pre-stored queue. Instead of writing in the playing record and caching, the playing record is synchronously played and recorded to the database, so that the problems that the database is crashed, the video playing is influenced and the user experience is reduced due to pressure on the handling performance of the database are solved.
Description
Technical Field
The present application relates to the field of video playing technologies, and in particular, to a method and an apparatus for storing a play record, a storage medium, and an electronic device.
Background
The play record is used for recording the play progress of the user. When the user watches the video, the video network station can write the playing record generated by the user into the cache so as to facilitate the user to continue playing at the breakpoint.
Because the capacity and stability of the cache are inferior to those of the conventional database, the playing records are synchronously played and recorded to the database while being recorded in the cache, so that the cache data can be recovered from the database after being lost. However, due to the particularity of the play record, that is, only one record is reserved for the video play record, the database needs to be frequently operated, for example, when the user watches a 1h video, the report is triggered every 10s, the user needs to report the video 360 times after normally watching the video, and the database needs to be operated 720 times (deleting the original play record and inserting a new play record). Therefore, when too many users are active at the same time, pressure is generated on the throughput performance of the database, so that the database is crashed, the video playing is influenced, and the user experience is reduced.
Disclosure of Invention
The application provides a playing record warehousing method and device, a storage medium and electronic equipment, and aims to solve the problems that the existing playing record warehousing scheme generates pressure on the handling performance of a database, so that the database is crashed, the playing of videos is influenced, and the user experience is reduced.
In order to achieve the above object, the present application provides the following technical solutions:
a method for storing a play record comprises the following steps:
after a preset timing task is triggered, acquiring an index record in a preset pre-deletion list, wherein the index record of a play record to be deleted is written in the pre-deletion list in advance;
deleting a playing record corresponding to the primary key identifier and the primary key identifier corresponding to the playing record in a database based on the primary key identifier in the index record;
judging whether elements meeting preset storage rules exist in a preset pre-storage queue or not; writing elements of playing records to be stored into the pre-storing queue in advance;
if the elements meeting the preset storage rule exist in the pre-stored queue, acquiring the elements meeting the preset storage rule in the pre-stored queue;
acquiring a play record corresponding to the first target element in the cache; wherein the first target element is an element that satisfies the preset storage rule;
and writing the playing record corresponding to the first target element into the database, and generating a primary key identifier of the playing record.
Optionally, the method includes a process of writing elements of the play record to be stored in the pre-storage queue in advance, where the process includes:
after a user generates a play record, acquiring a current play record and the generation time of the current play record;
determining the current playing record as a playing record to be stored, and executing a first operation on the playing record to be stored;
the first operation includes:
judging whether a second target element exists in the pre-storage queue or not; the second target element is an element corresponding to both the user identifier of the user and the video identifier of the playing record to be stored;
if the second target element exists in the pre-stored queue, moving the second target element to the tail of the pre-stored queue, and updating the reporting time of the second target element based on the generation time of the play record to be stored;
if the second target element does not exist in the pre-storage queue, generating an element based on the user identifier of the user and the video identifier of the play record to be stored, writing the generated element into the pre-storage queue, and setting the reporting time of the written element based on the generation time of the play record to be stored.
Optionally, the method further includes, after the first operation is performed on the to-be-stored play record, the step of:
writing the playing record to be stored into a cache;
judging whether a first target playing record exists in a preset data dictionary or not; the first target playing record is a playing record belonging to the same video as the playing record to be stored in the playing records related to the user and included in the data dictionary;
if a first target play record exists in the data dictionary, deleting the play record corresponding to the first target play record in the cache, and executing a second operation;
if the first target playing record does not exist in the data dictionary, judging whether a second target playing record exists in a preset data dictionary or not; the second target playing record is a playing record belonging to the same video album as the playing record to be stored in the playing records related to the user and included in the data dictionary;
if a second target play record exists in the data dictionary, deleting elements corresponding to the second target play record in the pre-storage queue, deleting play records corresponding to the second target play record in the cache, and executing the second operation;
the second operation includes:
judging whether a target index record exists in a preset pre-deletion list or not; the target index record is an index record corresponding to the user and belonging to the same video or the same video album as the to-be-stored playing record;
if the pre-deletion list does not have a target index record, searching a primary key identifier of a play record corresponding to the first target play record or the second target play record in a database;
and generating an index record based on the user identifier of the user, the video identifier and the main key identifier of the video corresponding to the to-be-stored playing record and the main key identifier, and writing the generated index record into the pre-deletion list.
Optionally, the writing the to-be-stored play record into a cache includes:
judging whether a play record associated with the user exists in a cache;
if the play record associated with the user does not exist in the cache, synchronizing the play record associated with the user in a database into the cache, and writing the play record to be stored into the cache;
and if the play record associated with the user exists in the cache, writing the play record to be stored into the cache.
Optionally, the determining whether an element meeting a preset storage rule exists in the preset pre-storage queue includes:
the method comprises the steps of calculating the reporting time and the current time of each element in a preset pre-storage queue to obtain a calculated value, judging whether the calculated value is larger than a preset threshold value, if so, determining that the element meets a preset storage rule, and if not, determining that the element does not meet the preset storage rule.
In the foregoing method, optionally, the index record of the play record corresponding to the deletion request may be written in the pre-deletion list in advance; the deletion request is used for requesting deletion of the play record.
Optionally, the method includes, in the pre-deletion list, writing in a compressed index record of the play record corresponding to the deletion request in advance, where the process includes:
receiving a deletion request of a user;
deleting the playing record in the cache and the deletion request;
judging whether an index record corresponding to the deletion request exists in the pre-deletion list or not;
if the index record corresponding to the deletion request does not exist in the pre-deletion list, searching a playing record corresponding to the deletion request and a main key identifier corresponding to the playing record in a database;
and generating an index record of the play record corresponding to the deletion request based on the play record corresponding to the deletion request and the primary key identification of the corresponding play record, and writing the index record of the play record corresponding to the deletion request into the pre-deletion list.
A playback record warehousing apparatus comprising:
the device comprises a first acquisition unit, a second acquisition unit and a third acquisition unit, wherein the first acquisition unit is used for acquiring index records in a preset pre-deletion list after a preset timing task is triggered, and the index records of the play records to be deleted are written in the pre-deletion list in advance;
the deleting unit is used for deleting the playing record corresponding to the main key identifier and the main key identifier corresponding to the playing record in the database based on the main key identifier in the index record;
the judging unit is used for judging whether elements meeting preset storage rules exist in a preset pre-storage queue or not; writing elements of playing records to be stored into the pre-storing queue in advance;
a second obtaining unit, configured to obtain, if an element that meets the preset storage rule exists in the pre-stored queue, an element that meets the preset storage rule in the pre-stored queue;
a third obtaining unit, configured to obtain a play record corresponding to the first target element in the cache; wherein the first target element is an element that satisfies the preset storage rule;
and the writing unit is used for writing the playing record corresponding to the first target element into the database and generating the primary key identifier of the playing record.
A storage medium storing a set of instructions, wherein the set of instructions, when executed by a processor, implement a method of playback record warehousing as described above.
An electronic device, comprising:
a memory for storing at least one set of instructions;
and the processor is used for executing the instruction set stored in the memory and realizing the playing, recording and warehousing method by executing the instruction set.
Compared with the prior art, the method has the following advantages:
the method comprises the steps of writing index records of play records to be deleted into a pre-deletion list through a pre-stored queue and the pre-deletion list, writing elements of the play records to be stored into the pre-stored queue, deleting play records corresponding to the main key identifiers in a database based on main key identifiers in the index records of the pre-deletion list after a timing task is triggered, and writing the play records corresponding to the elements meeting a pre-stored rule in a cache into the database based on the elements meeting the pre-stored rule in the pre-stored queue. Instead of writing in the playing record and caching, the playing record is synchronously played and recorded to the database, so that the problems that the database is crashed, the video playing is influenced and the user experience is reduced due to pressure on the handling performance of the database are solved.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
FIG. 1 is a flow chart of a method for playing a record into a library provided by the present application;
FIG. 2 is a flowchart of another method of a method for playing a record into a library provided by the present application;
FIG. 3 is a flowchart of another method of a method for playing a record into a library provided by the present application;
FIG. 4 is a flowchart of another method of a method for playing a record into a library provided by the present application;
FIG. 5 is a flowchart of another method of a method for playing a record into a library provided by the present application;
FIG. 6 is a flowchart of another method of a method for playing a record into a library provided by the present application;
fig. 7 is an exemplary diagram of a method for storing a play record provided in the present application;
fig. 8 is a schematic structural diagram of a playback record warehousing apparatus provided in the present application;
fig. 9 is a schematic structural diagram of an electronic device provided in the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The application is operational with numerous general purpose or special purpose computing device environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multi-processor apparatus, distributed computing environments that include any of the above devices or equipment, and the like.
The embodiment of the invention provides a method for storing a play record, which can be applied to a video play system, wherein the method has a flow chart as shown in fig. 1, and specifically comprises the following steps:
s101, after a preset timing task is triggered, acquiring an index record in a preset pre-deletion list.
In this embodiment, a pre-storage queue and a pre-deletion list are preset, where the pre-storage queue is used to write an element of a play record to be stored, the element includes related information of the play record to be written into a database, and exemplarily, the element is a user identifier and a video identifier, where the user identifier is used to uniquely identify a user, and the video identifier is used to uniquely identify a video; the pre-deletion list is used to write an index record of the play record to be deleted, optionally, the index record includes related information of the play record to be deleted in the database, and illustratively, the index record is a key value pair, where the key is a user identifier + a video identifier, and the value is a primary key identifier of the play record to be deleted.
In this embodiment, referring to fig. 2, the process of writing the element of the play record to be stored in the pre-storage queue in advance specifically includes the following steps:
s201, after a user generates a play record, acquiring a current play record and the generation time of the current play record.
In this embodiment, after the user generates the play record, the current play record and the generation time of the play record are obtained, where the current play record is the play record currently generated by the user.
S202, determining the current playing record as a playing record to be stored, and executing a first operation on the playing record to be stored.
In this embodiment, the current play record is determined as the play record to be stored, and the first operation is performed on the play record to be stored.
Referring to fig. 3, the process of executing the first operation on the record to be stored and played specifically includes the following steps:
s301, judging whether a second target element exists in the pre-storage queue, if so, executing S302, and if not, executing S303.
In this embodiment, it is determined whether a second target element exists in the pre-storage queue, where the second target element is an element corresponding to both a user identifier of the user and a video identifier of the to-be-stored playing record. That is, it is determined whether the pre-storage queue stores elements corresponding to both the user identifier of the user and the video identifier of the play record to be stored.
S302, moving the second target element to the tail of the pre-stored queue, and updating the reporting time of the second target element based on the generation time of the play record to be stored.
In this embodiment, if a second target element exists in the pre-storage queue, it indicates that the user is watching the same video all the time, and therefore, the second target element is directly moved to the tail of the meta-storage queue without generating a new element, and the reporting time of the second target element is updated based on the generation time of the play record to be stored.
It should be noted that, the elements in the pre-storage queue are arranged according to the reporting time.
And updating the reporting time of the second target element based on the generation time of the play record to be stored, specifically, changing the reporting time of the second target element into the generation time of the play record to be stored.
S303, generating elements based on the user identification of the user and the video identification of the play record to be stored, writing the generated elements into a pre-stored queue, and setting the reporting time of the written elements based on the generation time of the play record to be stored.
In this embodiment, if the second target element exists in the pre-storage queue, it indicates that the user does not watch the video corresponding to the to-be-stored playing record at least at intervals of a preset time, where the preset time is a trigger period of the timing task.
In this embodiment, if the second target element does not exist in the pre-stored queue, the element is generated, the generated element is written into the pre-stored queue, and the reporting time of the written element is set based on the generation time of the play record to be stored.
The process of generating the element specifically includes forming the element by using a user identifier of the user and a video identifier of a video corresponding to the to-be-stored playing record.
The generated element is written into a pre-stored queue, and specifically, the generated element is written into the tail of the pre-stored queue.
The process of setting the reporting time of the written element based on the generation time of the play record to be stored specifically includes: and in the pre-storage queue, setting the generation time of the play records to be stored as the report time of the generated elements.
In this embodiment, referring to fig. 4, after step S202, the following steps may be further included:
s401, writing the playing record to be stored into a cache.
In this embodiment, the play record to be stored is written into the cache.
Specifically, the process of writing the play record to be stored into the cache includes the following steps:
judging whether a play record associated with the user exists in the cache;
if the play record associated with the user does not exist in the cache, synchronizing the play record associated with the user in the database into the cache, and writing the play record to be stored into the cache;
and if the play record associated with the user exists in the cache, writing the play record to be stored into the cache.
In this embodiment, after step S202, it is determined whether a play record associated with the user exists in the cache, and if the play record associated with the user does not exist in the cache, it indicates that the user may not log in the target video application for a long time, and the information in the cache is cleared, or that the user is a new user of the target video application.
In this embodiment, when there is no play record associated with the user in the cache, if there is a play record associated with the user in the database, the play record associated with the user in the database is synchronized to the cache, and the play record to be stored is written into the cache.
In this embodiment, if there is a play record associated with the user in the cache, or if there is no play record associated with the user in the cache, there is no play record associated with the user in the database, and the play record to be stored is directly written into the cache.
S402, judging whether a first target playing record exists in a preset data dictionary, if so, executing S403, and if not, executing S404.
In this embodiment, it is determined whether a first target play record exists in a preset data dictionary, where the first target play record is a play record belonging to the same video as a play record to be stored in a play record associated with a user included in the data dictionary, that is, it is determined whether a play record corresponding to the user and belonging to the same video as a play record to be stored exists in the data dictionary.
S403, deleting the playing record corresponding to the first target playing record in the cache, and executing a second operation.
In this embodiment, if the first target play record exists in the data dictionary, the play record corresponding to the first target play record in the cache is deleted, and the second operation is executed.
Referring to fig. 5, the second operation includes the steps of:
s501, judging whether a target index record exists in a preset pre-deletion list or not, if not, directly ending, and if so, executing S502.
In this embodiment, it is determined whether a target index record exists in a preset pre-deletion list, where the target index record is an index record corresponding to a user and belonging to the same video or the same video album as a to-be-stored play record.
Specifically, matching is performed on the basis of the user identifier of the user and the video identifier of the video corresponding to the play record to be stored with each index record in the pre-deletion list, if the video identifier of the video corresponding to the user identifier and the play record to be stored in the pre-deletion list matches with the index record, it is determined that the target index record exists in the pre-deletion list, and otherwise, it is determined that the target index record does not exist in the pre-deletion list.
In this embodiment, if the target index record exists in the pre-deletion list, it indicates that the primary key identifier of the play record to be deleted in the database is already recorded in the pre-deletion list, and if the target index record does not exist in the pre-deletion list, it indicates that the primary key identifier of the play record to be deleted in the database is not recorded in the pre-deletion list, or the play record to be deleted does not exist in the database.
S502, searching a primary key identifier of a play record corresponding to the first target play record or the second target play record in the database.
In this embodiment, if the target index record exists in the pre-deletion list, the primary key identifier of the play record corresponding to the first target play record or the second target play record in the database is searched based on the first target play record or the second target play record.
S503, generating an index record based on the user identification of the user, the video identification and the main key identification of the video corresponding to the to-be-stored playing record, and writing the generated index record into a pre-deletion list.
In this embodiment, when the primary key identifier of the play record corresponding to the first target play record or the second target play record is found, the index record is generated based on the user identifier of the user, the video identifier of the video corresponding to the play record to be stored, and the primary key identifier, specifically, the user identifier and the video identifier of the video corresponding to the play record to be stored are used as the key of the index record to be generated, the found primary key identifier is used as the value of the index record to be generated, and the index record is generated based on the key and the value of the index record to be generated.
In this embodiment, the generated index record is written into the pre-deletion list.
And S404, judging whether a second target playing record exists in the preset data dictionary, if so, executing S405, and if not, directly ending.
In this embodiment, it is determined whether a second target play record exists in the preset data dictionary, where the second target play record is a play record belonging to the same video album as the to-be-stored play record in the play records associated with the user and included in the data dictionary.
In this embodiment, if the preset data dictionary does not have the second target play record, the process is directly ended.
S405, deleting the element corresponding to the second target playing record in the pre-storage queue, deleting the playing record corresponding to the second playing record in the cache, and executing a second operation.
In this embodiment, if the second target play record exists in the data dictionary, the element corresponding to the second target play record in the pre-stored queue is deleted, the play record corresponding to the second play record in the cache is deleted, and the second operation is executed.
The specific process of executing the second operation is as shown in the steps in fig. 5, and is not described herein again.
In the play recording method provided in the embodiment of the present application, a timing task is preset, and after the preset timing task is triggered, index records in a preset pre-deletion list are obtained, specifically, all index records in the pre-deletion list are obtained.
S102, based on the primary key identification in the index record, deleting the playing record corresponding to the primary key identification in the database and the primary key identification corresponding to the playing record.
In this embodiment, based on the primary key identifier in the index record, the play record corresponding to the primary key identifier in the database and the primary key identifier corresponding to the play record are deleted.
In this embodiment, based on the primary key identifier in the index record, the play record corresponding to the primary key identifier in the database and the primary key identifier corresponding to the play record are deleted, so that deletion efficiency can be improved.
S103, judging whether elements meeting preset storage rules exist in a preset pre-storage queue or not, if not, directly ending, and if so, executing S104.
And judging whether elements meeting preset storage rules exist in a preset pre-storage queue or not.
Specifically, for each element in a preset pre-storage queue, the reporting time and the current time of the element are calculated to obtain a calculated value, whether the calculated value is greater than a preset threshold value or not is judged, if the calculated value is greater than the preset threshold value, it is determined that the element meets a preset storage rule, and if the calculated value is not greater than the preset threshold value, it is determined that the element does not meet the preset storage rule.
Optionally, the process of calculating the reporting time of the element and the current time may be calculating a time difference between the current time and the reporting time.
For example, the preset threshold may be 5 minutes.
In this embodiment, if there is no element satisfying the preset storage rule in the pre-storage queue, the process is directly ended.
And S104, acquiring elements meeting preset storage rules in the pre-storage queue.
In this embodiment, the elements meeting the preset storage rule in the pre-storage queue are obtained, that is, the elements meeting the preset storage rule are extracted from the pre-storage queue.
S105, obtaining a play record corresponding to the first target element in the cache; the first target element is an element meeting a preset storage rule.
In this embodiment, a play record corresponding to a first target element in a cache is obtained, where the first target element is an element that meets a preset storage rule.
That is, the play records corresponding to the elements satisfying the preset storage rule in the cache are obtained.
Specifically, based on the user identifier and the video identifier included in the first target element, the play record corresponding to both the user identifier and the video identifier in the cache is searched.
And S106, writing the playing record corresponding to the first target element into a database, and generating a primary key identifier of the playing record.
In this embodiment, the play record corresponding to the first target element is written into the database, and the primary key identifier of the play record is generated in the database.
According to the playing record warehousing method provided by the embodiment of the application, through the preset pre-stored queue and the pre-deleted list, the index records of the playing records to be deleted are written into the pre-deleted list, the elements of the playing records to be stored are written into the pre-stored queue, after the timed task is triggered, the playing records corresponding to the main key identifiers in the index records of the pre-deleted list in the database are deleted based on the main key identifiers, and the playing records corresponding to the elements meeting the preset storage rule in the cache are written into the database based on the elements meeting the preset storage rule in the pre-stored queue. Instead of writing in the playing record and caching, the playing record is synchronously played and recorded to the database, so that the problems that the database is crashed, the video playing is influenced and the user experience is reduced due to pressure on the handling performance of the database are solved.
According to the playing record warehousing method provided by the embodiment of the application, the playing records warehoused in real time are intelligently screened by introducing the queue form, and warehousing is realized after the user finishes watching, so that the operation frequency of the database is greatly reduced, the pressure of the database is reduced, and the robustness and disaster tolerance performance of the system are improved.
According to the playing record warehousing method provided by the embodiment of the application, the index record of the playing record corresponding to the deletion request can be written in the pre-deletion list in advance; the delete request is for requesting deletion of the play record.
Referring to fig. 6, the process of writing the index record of the play record corresponding to the deletion request in the pre-deletion list in advance includes the following steps:
s601, acquiring a deletion request of a user.
And S602, deleting the playing record corresponding to the deletion request in the cache.
In this embodiment, the play record corresponding to the deletion request in the cache is searched for, and the play record corresponding to the deletion request in the cache is deleted.
S603, judging whether the index record corresponding to the deletion request exists in the pre-deletion list, if so, directly ending, and if not, executing S604.
S604, searching the playing record corresponding to the deleting request in the database and the primary key identification corresponding to the playing record.
In this embodiment, if there is no play record corresponding to the deletion request in the pre-stored list, the play record corresponding to the deletion request and the primary key identifier corresponding to the play record in the database are searched.
S605, based on the play record corresponding to the deletion request and the primary key identifier corresponding to the play record, generating an index record of the play record corresponding to the deletion request, and writing the index record of the play record corresponding to the deletion request into a pre-deletion list.
In this embodiment, based on the play record corresponding to the deletion request and the primary key identifier corresponding to the play record, the index record of the play record corresponding to the deletion request is generated, specifically, the video identifier of the video corresponding to the play record corresponding to the deletion request and the user identifier of the user are used as keys of the index record to be generated, and the primary key identifier corresponding to the play record is used as a value of the index record to be generated. And generating the index record of the playing record corresponding to the deletion request based on the key and the value of the index record to be generated. Wherein the index records are key-value pairs.
In this embodiment, the index record of the play record corresponding to the deletion request is written into the pre-deletion list.
According to the playing record warehousing method provided by the embodiment of the application, the playing records actively deleted by the user are recorded in the list to be deleted, so that the real-time operation of the database is reduced, and the response efficiency of the database is improved.
The playback record warehousing method mentioned in the embodiment of the present application is exemplified as follows:
1. adding a pre-stored queue, where each element in the pre-stored queue is related information (such as user id, reported video id, and the like) of the playing record, sorting the elements in the pre-stored queue in the reporting time, and placing the latest reported element at the tail of the queue, as shown in a in fig. 7. Element 5 is the latest reported element, so element 5 is placed at the end of the pre-stored queue.
2. If the element corresponding to the current play record is stored in the pre-stored queue, the reporting time of the element is updated based on the generation time of the current play record, and the element is moved to the end of the queue because the reporting time is updated, as shown in b in fig. 7, element 2 is the element corresponding to the current play record and is moved to the end of the queue.
3. Due to the characteristics of the playing records, the same video only keeps the latest playing record. Therefore, for the existing play records in the library, the records in the library need to be deleted when the user watches the record again. The list to be deleted is added.
4. After the user generates the play record, first, whether the record of the video (i.e. the above mentioned index record) exists in the deletion list is seen, if so, the record is not repeatedly added, and if not, the main key id (i.e. the above mentioned main key identifier) of the play record of the video in the database is recorded into the deletion list to be deleted, so as to avoid deleting the record by operating the database in real time.
5. And recording the playing records actively deleted by the user in the dictionary to be deleted, so that the real-time operation database is reduced, and the interface response efficiency is improved.
6. And adding a timing task, and regularly taking out all elements before the rated time (such as 5 min) from a pre-stored queue (for example: 14:00 executes the timing task, taking out the elements before 13:55 of the queue, namely taking out the elements, and then 13:55 does not report).
7. And aiming at the taken-out element, acquiring the play record of the element from the cache to carry out warehousing operation.
8. And taking out all index records in the dictionary to be deleted, and deleting the corresponding play records in the database in batch according to the primary key id (namely the primary key identifier) of the index record.
It should be noted that while instructions are depicted in a particular order, this should not be understood as requiring that such instructions be performed in the particular order shown or in sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous.
It should be understood that the various steps recited in the method embodiments disclosed herein may be performed in a different order and/or performed in parallel. Moreover, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the disclosure is not limited in this respect.
Corresponding to the method described in fig. 1, an embodiment of the present application further provides a device for playing, recording and warehousing, which is used for specifically implementing the method in fig. 1, and a schematic structural diagram of the device is shown in fig. 8, and specifically includes:
a first obtaining unit 801, configured to obtain an index record in a preset pre-deletion list after a preset timing task is triggered, where an index record of a play record to be deleted is written in the pre-deletion list in advance;
a deleting unit 802, configured to delete, based on a primary key identifier in an index record, a play record corresponding to the primary key identifier in a database and a primary key identifier corresponding to the play record;
a determining unit 803, configured to determine whether an element meeting a preset storage rule exists in a preset pre-storage queue; writing elements of playing records to be stored into the pre-storing queue in advance;
a second obtaining unit 804, configured to obtain, if an element meeting the preset storage rule exists in the pre-stored queue, an element meeting the preset storage rule in the pre-stored queue;
a third obtaining unit 805, configured to obtain a play record corresponding to the first target element in the cache; wherein the first target element is an element that satisfies the preset storage rule;
a writing unit 806, configured to write the play record corresponding to the first target element into the database, and generate a primary key identifier of the play record.
According to the play record warehousing device provided by the embodiment of the application, through the preset pre-stored queue and the pre-deleted list, the index records of the play records to be deleted are written into the pre-deleted list, the elements of the play records to be stored are written into the pre-stored queue, after the timed task is triggered, the play records corresponding to the main key identifiers in the index records of the pre-deleted list in the database are deleted based on the main key identifiers, and the play records corresponding to the elements meeting the preset storage rule in the cache are written into the database based on the elements meeting the preset storage rule in the pre-stored queue. Instead of writing in the playing record and caching, the playing record is synchronously played and recorded to the database, so that the problems that the database is crashed, the video playing is influenced and the user experience is reduced due to pressure on the handling performance of the database are solved.
In an embodiment of the present application, based on the foregoing solution, when the determining unit 803 is used in the process of writing the element of the play record to be stored in the pre-storage queue in advance, specifically:
after a user generates a play record, acquiring a current play record and the generation time of the current play record;
determining the current playing record as a playing record to be stored, and executing a first operation on the playing record to be stored;
the first operation includes:
judging whether a second target element exists in the pre-storage queue or not; the second target element is an element corresponding to both the user identifier of the user and the video identifier of the playing record to be stored;
if the second target element exists in the pre-stored queue, moving the second target element to the tail of the pre-stored queue, and updating the reporting time of the second target element based on the generation time of the play record to be stored;
if the second target element does not exist in the pre-storage queue, generating an element based on the user identifier of the user and the video identifier of the play record to be stored, writing the generated element into the pre-storage queue, and setting the reporting time of the written element based on the generation time of the play record to be stored.
In an embodiment of the present application, based on the foregoing scheme, when the determining unit 803 is in the process of writing elements in the pre-storage queue in advance, the determining unit is further configured to:
writing the playing record to be stored into a cache;
judging whether a first target playing record exists in a preset data dictionary or not; the first target playing record is a playing record belonging to the same video as the playing record to be stored in the playing records related to the user and included in the data dictionary;
if a first target play record exists in the data dictionary, deleting the play record corresponding to the first target play record in the cache, and executing a second operation;
if the first target playing record does not exist in the data dictionary, judging whether a second target playing record exists in a preset data dictionary or not; the second target playing record is a playing record belonging to the same video album as the playing record to be stored in the playing records related to the user and included in the data dictionary;
if a second target play record exists in the data dictionary, deleting elements corresponding to the second target play record in the pre-storage queue, deleting play records corresponding to the second target play record in the cache, and executing the second operation;
the second operation includes:
judging whether a target index record exists in a preset pre-deletion list or not; the target index record is an index record corresponding to the user and belonging to the same video or the same video album as the to-be-stored playing record;
if the pre-deletion list does not have a target index record, searching a primary key identifier of a play record corresponding to the first target play record or the second target play record in a database;
and generating an index record based on the user identifier of the user, the video identifier and the main key identifier of the video corresponding to the to-be-stored playing record and the main key identifier, and writing the generated index record into the pre-deletion list.
In an embodiment of the present application, based on the foregoing scheme, when the determining unit 803 writes the to-be-stored play record into the cache, it is specifically configured to:
judging whether a play record associated with the user exists in a cache;
if the play record associated with the user does not exist in the cache, synchronizing the play record associated with the user in a database into the cache, and writing the play record to be stored into the cache;
and if the play record associated with the user exists in the cache, writing the play record to be stored into the cache.
In an embodiment of the present application, based on the foregoing solution, when determining whether there are elements meeting a preset storage rule in a preset pre-storage queue, the determining unit 803 is specifically configured to:
the method comprises the steps of calculating the reporting time and the current time of each element in a preset pre-storage queue to obtain a calculated value, judging whether the calculated value is larger than a preset threshold value, if so, determining that the element meets a preset storage rule, and if not, determining that the element does not meet the preset storage rule.
In an embodiment of the present application, based on the foregoing scheme, an index record of a play record corresponding to the deletion request may also be written in the pre-deletion list in advance; the deletion request is used for requesting deletion of the play record.
In an embodiment of the present application, based on the foregoing solution, when the first obtaining unit 801 writes in advance an index record of a play record corresponding to the deletion request in the pre-deletion list, specifically:
receiving a deletion request of a user;
deleting the playing record in the cache and the deletion request;
judging whether an index record corresponding to the deletion request exists in the pre-deletion list or not;
if the index record corresponding to the deletion request does not exist in the pre-deletion list, searching a playing record corresponding to the deletion request and a main key identifier corresponding to the playing record in a database;
and generating an index record of the play record corresponding to the deletion request based on the play record corresponding to the deletion request and the primary key identification of the corresponding play record, and writing the index record of the play record corresponding to the deletion request into a pre-deletion list.
The embodiment of the present application further provides a storage medium, where the storage medium stores an instruction set, and when the instruction set runs, the method for playing, recording and warehousing disclosed in any of the above embodiments is executed.
An electronic device is further provided in the embodiments of the present application, and a schematic structural diagram of the electronic device is shown in fig. 9, and specifically includes a memory 901 for storing at least one set of instruction sets; a processor 902, configured to execute the instruction set stored in the memory, and implement the method for playing, recording and warehousing as disclosed in any of the above embodiments by executing the instruction set.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
While several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.
The foregoing description is only exemplary of the preferred embodiments disclosed herein and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the disclosure herein is not limited to the particular combination of features described above, but also encompasses other arrangements formed by any combination of the above features or their equivalents without departing from the spirit of the disclosure. For example, the above features and (but not limited to) technical features having similar functions disclosed in the present disclosure are mutually replaced to form the technical solution.
Claims (10)
1. A method for playing, recording and warehousing, comprising:
after a preset timing task is triggered, acquiring an index record in a preset pre-deletion list, wherein the index record of a play record to be deleted is written in the pre-deletion list in advance;
deleting a playing record corresponding to the primary key identifier and the primary key identifier corresponding to the playing record in a database based on the primary key identifier in the index record;
judging whether elements meeting preset storage rules exist in a preset pre-storage queue or not; writing elements of playing records to be stored into the pre-storing queue in advance;
if the elements meeting the preset storage rule exist in the pre-stored queue, acquiring the elements meeting the preset storage rule in the pre-stored queue;
acquiring a play record corresponding to the first target element in the cache; wherein the first target element is an element that satisfies the preset storage rule;
and writing the playing record corresponding to the first target element into the database, and generating a primary key identifier of the playing record.
2. The method of claim 1, wherein the pre-writing of the element of the play record to be stored in the pre-storage queue comprises:
after a user generates a play record, acquiring a current play record and the generation time of the current play record;
determining the current playing record as a playing record to be stored, and executing a first operation on the playing record to be stored;
the first operation includes:
judging whether a second target element exists in the pre-storage queue or not; the second target element is an element corresponding to both the user identifier of the user and the video identifier of the playing record to be stored;
if the second target element exists in the pre-stored queue, moving the second target element to the tail of the pre-stored queue, and updating the reporting time of the second target element based on the generation time of the play record to be stored;
if the second target element does not exist in the pre-storage queue, generating an element based on the user identifier of the user and the video identifier of the play record to be stored, writing the generated element into the pre-storage queue, and setting the reporting time of the written element based on the generation time of the play record to be stored.
3. The method according to claim 2, wherein after the performing the first operation on the play record to be stored, further comprising:
writing the playing record to be stored into a cache;
judging whether a first target playing record exists in a preset data dictionary or not; the first target playing record is a playing record belonging to the same video as the playing record to be stored in the playing records related to the user and included in the data dictionary;
if a first target play record exists in the data dictionary, deleting the play record corresponding to the first target play record in the cache, and executing a second operation;
if the first target playing record does not exist in the data dictionary, judging whether a second target playing record exists in a preset data dictionary or not; the second target playing record is a playing record belonging to the same video album as the playing record to be stored in the playing records related to the user and included in the data dictionary;
if a second target play record exists in the data dictionary, deleting elements corresponding to the second target play record in the pre-storage queue, deleting play records corresponding to the second target play record in the cache, and executing the second operation;
the second operation includes:
judging whether a target index record exists in a preset pre-deletion list or not; the target index record is an index record corresponding to the user and belonging to the same video or the same video album as the to-be-stored playing record;
if the pre-deletion list does not have a target index record, searching a primary key identifier of a play record corresponding to the first target play record or the second target play record in a database;
and generating an index record based on the user identifier of the user, the video identifier and the main key identifier of the video corresponding to the to-be-stored playing record and the main key identifier, and writing the generated index record into the pre-deletion list.
4. The method according to claim 3, wherein writing the to-be-stored play record into a cache comprises:
judging whether a play record associated with the user exists in a cache;
if the play record associated with the user does not exist in the cache, synchronizing the play record associated with the user in a database into the cache, and writing the play record to be stored into the cache;
and if the play record associated with the user exists in the cache, writing the play record to be stored into the cache.
5. The method of claim 1, wherein the determining whether the element meeting the preset storage rule exists in the preset pre-storage queue comprises:
the method comprises the steps of calculating the reporting time and the current time of each element in a preset pre-storage queue to obtain a calculated value, judging whether the calculated value is larger than a preset threshold value, if so, determining that the element meets a preset storage rule, and if not, determining that the element does not meet the preset storage rule.
6. The method according to claim 1, wherein an index record of the play record corresponding to the deletion request can be written in the pre-deletion list in advance; the deletion request is used for requesting deletion of the play record.
7. The method according to claim 6, wherein the pre-writing of the index record of the play record corresponding to the deletion request in the pre-deletion list comprises:
receiving a deletion request of a user;
deleting the playing record in the cache and the deletion request;
judging whether an index record corresponding to the deletion request exists in the pre-deletion list or not;
if the index record corresponding to the deletion request does not exist in the pre-deletion list, searching a playing record corresponding to the deletion request and a main key identifier corresponding to the playing record in a database;
and generating an index record of the play record corresponding to the deletion request based on the play record corresponding to the deletion request and the primary key identification of the corresponding play record, and writing the index record of the play record corresponding to the deletion request into the pre-deletion list.
8. A playback record warehousing apparatus, comprising:
the device comprises a first acquisition unit, a second acquisition unit and a third acquisition unit, wherein the first acquisition unit is used for acquiring index records in a preset pre-deletion list after a preset timing task is triggered, and the index records of the play records to be deleted are written in the pre-deletion list in advance;
the deleting unit is used for deleting the playing record corresponding to the main key identifier and the main key identifier corresponding to the playing record in the database based on the main key identifier in the index record;
the judging unit is used for judging whether elements meeting preset storage rules exist in a preset pre-storage queue or not; writing elements of playing records to be stored into the pre-storing queue in advance;
a second obtaining unit, configured to obtain, if an element that meets the preset storage rule exists in the pre-stored queue, an element that meets the preset storage rule in the pre-stored queue;
a third obtaining unit, configured to obtain a play record corresponding to the first target element in the cache; wherein the first target element is an element that satisfies the preset storage rule;
and the writing unit is used for writing the playing record corresponding to the first target element into the database and generating the primary key identifier of the playing record.
9. A storage medium storing a set of instructions, wherein the set of instructions, when executed by a processor, implement a method of playing a record into a library as claimed in any one of claims 1 to 7.
10. An electronic device, comprising:
a memory for storing at least one set of instructions;
a processor for executing the instruction set stored in the memory, and implementing the method of playing and recording according to any one of claims 1-7 by executing the instruction set.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210214211.XA CN114282048B (en) | 2022-03-07 | 2022-03-07 | Playing record warehousing method and device, storage medium and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210214211.XA CN114282048B (en) | 2022-03-07 | 2022-03-07 | Playing record warehousing method and device, storage medium and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114282048A true CN114282048A (en) | 2022-04-05 |
| CN114282048B CN114282048B (en) | 2022-05-27 |
Family
ID=80882252
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210214211.XA Active CN114282048B (en) | 2022-03-07 | 2022-03-07 | Playing record warehousing method and device, storage medium and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114282048B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117827849A (en) * | 2024-03-04 | 2024-04-05 | 支付宝(杭州)信息技术有限公司 | Data dictionary maintenance method and device |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107172492A (en) * | 2017-06-06 | 2017-09-15 | 环球智达科技（北京）有限公司 | A kind of reporting system for playing record |
| WO2017201935A1 (en) * | 2016-05-23 | 2017-11-30 | 乐视控股（北京）有限公司 | Video playing method and apparatus |
| CN110933468A (en) * | 2019-10-17 | 2020-03-27 | 宇龙计算机通信科技(深圳)有限公司 | Playing method, playing device, electronic equipment and medium |
| US20210051301A1 (en) * | 2019-08-16 | 2021-02-18 | Yealink (Xiamen) Network Technology Co., Ltd. | Multi-device recording synchronization method and system, and conference system |
| CN113139081A (en) * | 2021-04-27 | 2021-07-20 | 中山亿联智能科技有限公司 | Method for reporting and reading user online playing information with high efficiency and low delay |
| CN113961743A (en) * | 2021-12-16 | 2022-01-21 | 飞狐信息技术（天津）有限公司 | Data updating method and device, electronic equipment and storage medium |
| CN114051162A (en) * | 2022-01-12 | 2022-02-15 | 飞狐信息技术（天津）有限公司 | Caching method and device based on play records |
-
2022
- 2022-03-07 CN CN202210214211.XA patent/CN114282048B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017201935A1 (en) * | 2016-05-23 | 2017-11-30 | 乐视控股（北京）有限公司 | Video playing method and apparatus |
| CN107172492A (en) * | 2017-06-06 | 2017-09-15 | 环球智达科技（北京）有限公司 | A kind of reporting system for playing record |
| US20210051301A1 (en) * | 2019-08-16 | 2021-02-18 | Yealink (Xiamen) Network Technology Co., Ltd. | Multi-device recording synchronization method and system, and conference system |
| CN110933468A (en) * | 2019-10-17 | 2020-03-27 | 宇龙计算机通信科技(深圳)有限公司 | Playing method, playing device, electronic equipment and medium |
| CN113139081A (en) * | 2021-04-27 | 2021-07-20 | 中山亿联智能科技有限公司 | Method for reporting and reading user online playing information with high efficiency and low delay |
| CN113961743A (en) * | 2021-12-16 | 2022-01-21 | 飞狐信息技术（天津）有限公司 | Data updating method and device, electronic equipment and storage medium |
| CN114051162A (en) * | 2022-01-12 | 2022-02-15 | 飞狐信息技术（天津）有限公司 | Caching method and device based on play records |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117827849A (en) * | 2024-03-04 | 2024-04-05 | 支付宝(杭州)信息技术有限公司 | Data dictionary maintenance method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114282048B (en) | 2022-05-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7271670B2 (en) | Data replication method, device, computer equipment and computer program | |
| CN109034993B (en) | Account checking method, account checking equipment, account checking system and computer readable storage medium | |
| CN108399263B (en) | Time sequence data storage and query method and storage and processing platform | |
| CN113297166B (en) | Data processing system, method and device | |
| CN107229420B (en) | Data storage method, reading method, deleting method and data operating system | |
| CN108920698A (en) | A kind of method of data synchronization, device, system, medium and electronic equipment | |
| CN106874281B (en) | Method and device for realizing database read-write separation | |
| CN111177165B (en) | Method, device and equipment for detecting data consistency | |
| WO2007068600B1 (en) | Generating backup sets to a specific point in time | |
| CN112714359B (en) | Video recommendation method and device, computer equipment and storage medium | |
| CN111506251A (en) | Data processing method, data processing device, SMR storage system and storage medium | |
| EP3438845A1 (en) | Data updating method and device for a distributed database system | |
| CN110457305B (en) | Data deduplication method, device, equipment and medium | |
| CN114282048B (en) | Playing record warehousing method and device, storage medium and electronic equipment | |
| CN109947730A (en) | Metadata restoration methods, device, distributed file system and readable storage medium storing program for executing | |
| US9870385B2 (en) | Computer system, data management method, and computer | |
| CN112000850B (en) | Method, device, system and equipment for processing data | |
| CN113051221A (en) | Data storage method, device, medium, equipment and distributed file system | |
| CN113515518A (en) | Data storage method and device, computer equipment and storage medium | |
| WO2021218626A1 (en) | Data storage method and apparatus, device, and storage medium | |
| CN111522875B (en) | Distributed system data copy consistency monitoring method for full data synchronization | |
| CN113625952A (en) | Object storage method, device, equipment and storage medium | |
| CN111190858B (en) | Method, device, equipment and storage medium for storing software information | |
| CN111147226B (en) | Data storage method, device and storage medium | |
| CN114143486A (en) | Video stream synchronization method and device, computer equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |