Method for reducing conflicts in intelligent large-object high-concurrency scene of database

Abstract

The invention discloses a method for reducing conflicts in an intelligent large object high-concurrency scene of a database, which comprises the following steps of: in a first transaction, responding to a query request, firstly obtaining a first row lock of a table row, reading a first intelligent large object descriptor, recording position information of the table row, and immediately releasing the first row lock; before the actual data of the intelligent large object is prepared to be read, a second row lock of the table row is obtained, the table row is repositioned based on the recorded position information, and a second intelligent large object descriptor is read; reading actual data of the intelligent large object according to the latest second intelligent large object descriptor, and releasing the second row lock after reading is completed; according to the method, secondary locking is carried out at the critical moment before actual data are read, and the descriptor is read again, so that the real-time performance and the effectiveness of the used data pointer are ensured, and the query failure caused by data modification in a lock-free window period is thoroughly avoided; and the stability and the data consistency of the database in a high-concurrency scene are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of database, and in particular to a method for reducing conflicts of database intelligent large objects in high concurrency scenarios. BACKGROUND

[0002] Intelligent large object (LOB) technology of database, such as character large object (CLOB) and binary large object (BLOB), is designed for efficient storage and operation of large volume of unstructured data. Its storage mechanism is usually to separate the actual data from the main table row, and only store an intelligent large object descriptor pointing to the actual data in the main table row.

[0003] In traditional intelligent large object operations, such as query (SELECT) operation, the database system usually performs in two steps: first, lock the table row, read the intelligent large object descriptor in the row, and then immediately release the row lock; second, access the special intelligent large object storage area according to the read descriptor to obtain the actual data.

[0004] This two-step separation and intermediate release mechanism has serious defects. In a high concurrency environment, when a transaction (e.g., transaction 1) has completed the first step, but before executing the second step, the row lock has been released. At this time, another concurrent transaction (e.g., transaction 2) can successfully acquire the lock of the row and perform update (UPDATE) or delete (DELETE) operation. This will cause transaction 2 to modify or delete the intelligent large object data. Subsequently, when transaction 1 continues to execute the second step, it still uses the originally read, but now outdated, descriptor to access the data, which will cause query failure or reading of dirty data due to the data being modified or not existing, resulting in conflicts and errors. SUMMARY

[0005] This section is intended to summarize some aspects of the embodiments of the present application and briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section and the abstract and title of the specification to avoid obscuring the purpose of this section, the abstract and the title, and such simplifications or omissions cannot be used to limit the scope of the present application.

[0006] In view of the above existing problems, the present application is proposed. Therefore, the present application provides a method for reducing conflicts of database intelligent large objects in high concurrency scenarios, aiming to solve the problem of concurrent conflicts caused by step-by-step execution of query operations without lock protection in between.

[0007] To solve the above technical problems, the present application provides the following technical solutions: a method for reducing conflicts of database intelligent large objects in high concurrency scenarios, comprising: In a first transaction, in response to a query request for a table row containing a smart large object, acquiring a first row lock of the table row; After acquiring the first row lock, reading a first smart large object descriptor from the table row, recording location information of the table row, and releasing the first row lock; Before reading actual data of the smart large object according to the first smart large object descriptor, acquiring a second row lock of the table row; After acquiring the second row lock, repositioning based on the recorded table row location information, and reading a second smart large object descriptor from the table row; According to the second smart large object descriptor, reading actual data of the smart large object; After completing the reading of the actual data of the smart large object, releasing the second row lock.

[0008] As a preferred solution of the method for reducing conflicts in high-concurrency scenarios of database smart large objects, wherein: the recording of the location information of the table row includes a row identifier uniquely identifying the table row and an offset position of the smart large object descriptor within the table row.

[0009] As a preferred solution of the method for reducing conflicts in high-concurrency scenarios of database smart large objects, wherein: the query request is a query operation on one or more columns defined as smart large object data types in a database table.

[0010] As a preferred solution of the method for reducing conflicts in high-concurrency scenarios of database smart large objects, wherein: the smart large object data type is a text large object or a binary large object.

[0011] As a preferred solution of the method for reducing conflicts in high-concurrency scenarios of database smart large objects, wherein: within a time window after releasing the first row lock and before acquiring the second row lock, a second transaction is allowed to perform an update or delete operation on the table row, and the content of the second smart large object descriptor is different from that of the first smart large object descriptor.

[0012] As a preferred solution of the method for reducing conflicts in high-concurrency scenarios of database smart large objects, wherein: the first transaction and the second transaction are different transactions executed concurrently.

[0013] As a preferred solution of the method for reducing conflicts in high-concurrency scenarios of database smart large objects, wherein: the write operation performed by the second transaction is an update operation or a delete operation; and the update operation includes modification of the smart large object descriptor in the table row.

[0014] As a preferred scheme of the method for reducing conflicts in a high concurrency scenario of a smart object of a database, the first row lock and the second row lock are exclusive locks or update locks that prevent other transactions from performing write operations on the table row.

[0015] As a preferred scheme of the method for reducing conflicts in a high concurrency scenario of a smart object of a database, if the table row is found to have been deleted when the table row is relocated based on the recorded table row position information, the step of subsequently reading the second smart object descriptor is aborted.

[0016] As a preferred scheme of the method for reducing conflicts in a high concurrency scenario of a smart object of a database, reading actual data of the smart object according to the second smart object descriptor further includes: Before reading the actual data of the smart object according to the second smart object descriptor, an object lock of the smart object is acquired, and the object lock of the smart object is released after the reading of the actual data of the smart object is completed.

[0017] Compared with the prior art, the present application has the following beneficial effects: The present application ensures that the descriptor used to locate the final data is the most current and valid one by relocking the table row and reading the smart object descriptor again before reading the smart object data, thereby ensuring data consistency; even if the data of the table row is modified by other transactions during the interval between the two times of locking, the present application can still obtain the latest data pointer, thereby avoiding query errors. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort. Among them: Figure 1 A general flowchart of the method for reducing conflicts in a high concurrency scenario of a smart object of a database according to an embodiment of the present application; Figure 2 A prior art multi-transaction timing diagram of the method for reducing conflicts in a high concurrency scenario of a smart object of a database according to an embodiment of the present application; Figure 3 A prior art multi-transaction timing diagram of the method for reducing conflicts in a high concurrency scenario of a smart object of a database according to an embodiment of the present application; Figure 4The test result diagram of the prior art solution of the method for reducing conflicts in a high concurrency scenario of a database intelligent large object according to an embodiment of the present application; Figure 5 The test result diagram of the present application solution of the method for reducing conflicts in a high concurrency scenario of a database intelligent large object according to an embodiment of the present application. DETAILED DESCRIPTION

[0019] In order to make the above objectives, features and advantages of the present application more apparent, clear and easy to understand, the specific embodiments of the present application will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work should fall within the protection scope of the present application.

[0020] In the following description, a large number of specific details are set forth in order to facilitate a thorough understanding of the present application. However, the present application can be implemented in other different manners than those described herein, and those skilled in the art can make similar generalizations without departing from the spirit and scope of the present application. Therefore, the present application is not limited to the specific embodiments disclosed below.

[0021] Secondly, the "one embodiment" or "embodiment" referred to herein means that the specific features, structures or characteristics can be included in at least one implementation of the present application. The "in one embodiment" appearing in different places in the specification does not mean the same embodiment, nor is it an independent or alternative embodiment that excludes other embodiments.

[0022] The present application is described in detail in conjunction with the schematic diagram. In the detailed description of the embodiments of the present application, the cross-sectional view of the device structure is locally enlarged without the general proportion for the convenience of description, and the schematic diagram is only an example, which should not limit the protection scope of the present application herein. In addition, the three-dimensional spatial dimensions of length, width and depth should be included in actual manufacturing.

[0023] Meanwhile, in the description of the present application, it should be noted that the terms "up, down, inner and outer" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the indicated device or element must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the present application. In addition, the terms "first, second or third" are only for the purpose of description, and cannot be understood as indicating or implying relative importance.

[0024] Unless otherwise defined, the terms "mounting, connecting, associating" in the present application should be interpreted broadly, for example: can be fixed connection, detachable connection or integral connection; can also be mechanical connection, electrical connection or direct connection, can also be indirectly connected through intermediate medium, can also be the internal communication of two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0025] Embodiment 1 Reference Figure 1 For the first embodiment of the present application, the embodiment provides a method for reducing conflicts in high concurrency scenarios of database intelligent large objects, comprising: S1, in the first transaction, in response to a query request for a table row containing an intelligent large object, acquiring a first row lock of the table row; It should be noted that the first transaction refers to an atomic work unit started in a database session for executing one or more logically related operations; in the scenario of the present application, the purpose of the transaction is to query and read an intelligent large object from the database, that is, for a typical concurrent environment, it is explained that at the same time, other multiple transactions may be trying to access or modify the same data in the database; It should be noted that in response to a query request for a table row containing an intelligent large object, the specific database operation performed by the first transaction, the query request is usually an SQL SELECT statement, and the query target is explicitly pointed to one or more columns defined as an intelligent large object data type (i.e. text large object (CLOB) or binary large object (BLOB)); For example, a typical query request can be SELECT photo_blob FROM employee_table WHERE employee_id = 101, and the row in the employee_table where employee_id is 101 is a table row containing an intelligent large object, and the photo_blob column is an intelligent large object column; Further, when the database system locates the specific table row pointed to by the query request, the first transaction does not immediately read the data, but first applies a row-level lock to the row, which is the first row lock; It should be noted that the purpose of acquiring this first row lock is to ensure the atomicity and consistency of the first intelligent large object descriptor reading operation about to be performed, so as to ensure that no other concurrent transaction can modify or delete this row at the moment when the first transaction reads the descriptor, thereby preventing reading the intermediate state or inconsistent data caused by concurrent modification; Since the granularity of this lock is controlled at the row level, the locking of the entire data page or table is avoided; S2, after acquiring the first row lock, reading the first smart object descriptor from the table row, recording the position information of the table row, and releasing the first row lock; Further, the operation of reading the first smart object descriptor from the table row is performed under the protection of the first row lock acquired by the first transaction; It should be noted that the first smart object descriptor is a small data structure (a 72-byte structure) stored in the table row data, which does not contain smart object data itself, but is a pointer or metadata handle pointing to the actual data stored externally. The purpose of reading this descriptor is to obtain the basic information required to access the actual data; and due to the existence of the row lock at this time, it can be ensured that the descriptor read is complete and not concurrently modified; Further, after reading the descriptor, the operation of recording the position information of the table row is performed, which includes two parts: The first part is the row identifier that uniquely identifies the table row, which is an address used by the database internally to uniquely identify a physical or logical location of a row; by recording the row identifier, the database system does not need to scan the index or full table in subsequent steps, but can directly and quickly access the row data, greatly improving the efficiency of relocation; The second part is the offset position of the smart object descriptor in the table row. Since a row of data is usually composed of multiple columns, the offset position records the starting byte position of the smart object descriptor in the row data structure for this query; by combining the row identifier and the offset position, a coordinate can be formed, and according to the coordinate position, it can be ensured that the subsequent re-reading operation can accurately hit the same descriptor field; It should be noted that the first transaction will save the position information in its internal working memory; Further, after completing the above reading and recording operations, the first transaction will immediately perform the operation of releasing the first row lock; It should be noted that the purpose of releasing the lock is to maximize the concurrency performance of the database, and by shortening the holding time of the row lock to only cover this small time slice of reading the descriptor and recording the position, the table row can be quickly accessed by other concurrent transactions, allowing them to perform update or delete operations; S3, before reading the actual data of the smart object according to the first smart object descriptor, acquiring a second row lock of the table row; Further, since the first transaction has released the first row lock, there is a time window between the release of the first row lock and the execution of the present step, which is a time window without lock protection, in which the first transaction can be performing other computing tasks, or preparing network, memory, etc. resources to receive the smart object data; by allowing one or more second transactions to perform update or delete operations on the table row, and making the content of the second smart object descriptor different from that of the first smart object descriptor, a typical conflict scenario is thus constituted; Specifically, the first transaction and the second transaction are different transactions executed concurrently; Further, the first transaction initiates a lock request for the same table row to the lock manager of the database again, and the lock is the second row lock; Specifically, the first transaction specifies the target row to be locked to the lock manager through the position information recorded in its internal working memory; In addition, the second row lock is of the same type as the first row lock, which is an exclusive lock or an update lock that prevents other transactions from performing write operations on the table row; It should be noted that by applying this type of lock, it is ensured that from this moment on, until the second row lock is released, the content of the table row (including its internal smart object descriptor) will not be modified by any other concurrent transaction; S4, after obtaining the second row lock, repositioning is performed based on the recorded table row position information, and a second smart object descriptor is read from the table row; Specifically, during the repositioning process, there are two possible situations: The first situation is that the repositioning is successful, and the database system successfully finds the table row according to the row identifier of the table row; this situation is the most common one, indicating that the row has not been deleted within the interval between the two lockings; The second situation is that the repositioning fails, and the database system cannot find the table row according to the row identifier of the table row, indicating that another concurrent transaction (i.e. the second transaction) has executed a delete operation to physically or logically delete the row after the release of the first row lock and before the acquisition of the second row lock; when this situation is detected, the subsequent step of reading the second smart object descriptor is aborted, and an error of non-existent table row can be returned to the upper layer application to avoid invalid subsequent operations; Further, after successfully repositioning to the table row, the operation of reading the second smart object descriptor from the table row is performed immediately; this second smart object descriptor refers to the descriptor content stored in the table row at the current time point; since the first transaction holds the second row lock at this time, it can be ensured that the descriptor read is the current latest and transaction-consistent state; It should be noted that the content of the second smart object descriptor can be the same as the read first smart object descriptor (if no concurrent write operation occurs), or different (if the second transaction has updated the row); and the present solution does not care whether the two descriptors are the same or not, but unconditionally trusts and uses the newly acquired second smart object descriptor; It should be noted that through the relocation and re-reading under the protection of the lock, the final confirmation of the table row state is completed, not only the abnormal situation that the table row can be deleted is handled, but also the current absolutely valid "pointer" for accessing the actual data is acquired, thereby solving the root problem of concurrent conflicts caused by using outdated descriptors; S5, reading the actual data of the smart object according to the second smart object descriptor; Further, the specific process of reading the actual data of the smart object is as follows: The smart object manager of the database first parses the second smart object descriptor, which contains all the metadata required for positioning and accessing the actual data, such as the identification of the dedicated storage space where the data is located, the address of the starting data page, the total length of the object, the storage attribute, etc. Before accessing the physical storage according to the parsed metadata, the first transaction will first perform a critical sub-step: Acquiring the object lock of the smart object, which is another lock different from the row lock, and is represented as the data of the smart object itself, rather than the table row of the storage descriptor; the purpose of this lock is to prevent other transactions (for example, a transaction that is executing an update, which may have passed the row lock phase and is waiting for the data in the operation-specific page) from modifying (such as appending, truncating, or replacing) the actual content of the smart object during the reading of the data by the first transaction; It should be noted that by applying the object lock, it is ensured that the content is static during the reading of the data by the first transaction, thereby guaranteeing the integrity and consistency of the read data; After successfully acquiring the object lock, the smart object manager accesses the dedicated page storing the data of the smart object using the metadata parsed from the descriptor. Since the smart object is large in size, its data may span multiple non-contiguous data pages. The manager will sequentially or concurrently read all related data pages according to the internal linking or indexing structure, and then collect and arrange the data blocks before streaming them to the working memory or client buffer of the first transaction initiating the query; After the first transaction completes the reading of the actual data of the smart object, the object lock of the smart object is immediately released, thereby minimizing the locking time of the smart object data, and allowing other waiting transactions to operate on it as soon as the reading is completed, thereby balancing data consistency and system concurrency; It should be noted that, through the above process, the first transaction can obtain smart large object data that is completely consistent with the current database state, ensuring that the correct data read in the end is updated or unmodified, thereby avoiding query failures or data inconsistencies caused by the use of outdated descriptors. S6. After completing the reading of the actual data of the smart large object, release the second row lock. Furthermore, the row lock release operation is triggered only after all data (regardless of its size) has been successfully read from the dedicated storage page and transferred to the first transaction. This ensures that the metadata of the table row (i.e., the smart large object descriptor) remains stable and protected throughout the data read process, preventing potential problems that could arise if the row is modified or deleted by other transactions while the data is being read. In addition, once the second row lock is released, the table row immediately becomes available to all other concurrent transactions for new query, update, or delete operations. This minimizes the blocking time of other businesses caused by querying a large object and ensures high throughput of the entire database system. It should be noted that the consequence of releasing the lock is that the write protection of the table row by the first transaction ends; that is, from this moment on, the first transaction no longer prevents other transactions from modifying the row, but this does not affect the results already achieved by the first transaction.

[0026] Example 2 Reference Figure 2 and Figure 3 , which is the second embodiment of the present invention, provides a method for reducing conflicts in a high-concurrency scenario of a database intelligent large object, including: refer to Figure 2 , the existing technical solution processing process is as follows: Transaction T1 executes a query statement for an intelligent large object at time t1. It first reads the 72-byte intelligent large object descriptor from the table row and then releases the lock on the table row. Transaction T2 executes a delete or update statement at time t2, and the row data is modified; At time t3, transaction T1 reads the smart large object data based on the 72-byte smart large object descriptor found at time t1. Since the smart large object data was modified by transaction T2 at time t2, transaction T1 reports a query error. refer to Figure 3 , the processing process of the present invention is as follows: Transaction T1 executes a query statement for the smart large object at time t1, locking the table row. Read the 72-byte smart large object descriptor from the table row, record table-related information, smart large object offset, and other information, and store them in the 72-byte descriptor; Table row unlocked; T2 transaction executes delete or update statement at t2 time, the row data is modified; T1 transaction locks the table row; T1 transaction re-reads the new 72-byte smart object descriptor of the table row according to the recorded table related information before querying the actual data of the smart object at t3 time; Lock the smart object; T1 transaction queries the smart object data according to the new 72-byte smart object descriptor at t4 time; Unlock the smart object; Unlock the table row; It should be noted that the prior art queries the smart object in two steps: first, query the 72-byte smart object descriptor from the table row, and then query the smart object data according to the queried 72-byte smart object descriptor; while the present application first queries the 72-byte smart object descriptor from the table row, queries the smart object data through the 72-byte smart object descriptor, and then gets the 72-byte smart object descriptor, without querying the smart object data, but according to the table related information in the 72-byte smart object descriptor, re-queries the 72-byte smart object descriptor from the table row, locks the table row, queries the smart object data with the newly queried 72-byte smart object descriptor, and unlocks the table row after querying, so as to prevent the data of the row from being tampered with when querying the smart object data, thereby solving the problem of conflict and query error in the high concurrency scenario of smart object.

[0027] Embodiment 3 Referring to Figure 4 and Figure 5 , the third embodiment of the present application provides a method for reducing conflict in high concurrency scenario of database smart object, comprising: Use jmeter to perform stress testing update and query statements, with concurrency degree of 40, stress test for 10 minutes, it can be found that the query no longer reports error, and the update error is greatly reduced; From Figure 4 It can be seen that the query error rate of the prior art is 55.74%, and the update error rate is 4.89%; from Figure 5 It can be seen that the query error rate of the present application is 0%, and the update error rate is 1.14%; Compared with the prior art, the query error rate is reduced from 55.74% to 0%, and the update error rate is reduced to 1.14%; the improvement effect is obvious, which proves that the present application can reduce the conflict in high concurrency scenario.

[0028] Those skilled in the art will appreciate that embodiments of the application can be readily used as software, hardware, or a combination of software and hardware. In one embodiment, the application can be implemented in software and / or firmware. In addition, the software implementation can be implemented by one or more computer programs.

[0029] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the steps listed in the flowchart

[0030] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the steps listed in the flowchart

[0031] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the steps listed in the flowchart

[0032] While the preferred embodiments of the application have been described, additional variations and modifications can be employed. Therefore, the terms and expressions

[0033] It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application cover modifications and variations of this application provided they come within the scope of the appended claims and their equivalents.

Claims

1. A method for reducing conflicts in a high-concurrency scenario of a database intelligent large object, characterized in that: include: In a first transaction, in response to a query request for a table row containing a smart large object, a first row lock of the table row is acquired; After acquiring the first row lock, reading the first smart large object descriptor from the table row, recording the location information of the table row, and releasing the first row lock; Before reading actual data of the smart large object according to the first smart large object descriptor, acquiring a second row lock of the table row; After acquiring the second row lock, repositioning is performed based on the recorded table row position information, and a second smart large object descriptor is read from the table row; Reading actual data of the smart large object according to the second smart large object descriptor; After the actual data of the smart large object is read, the second row lock is released.

2. The method for reducing conflicts in a high-concurrency scenario of a database intelligent large object according to claim 1, characterized in that: The recorded position information of the table row includes: a row identifier that uniquely identifies the table row, and an offset position of the smart large object descriptor within the table row.

3. The method for reducing conflicts in a high-concurrency scenario of a database intelligent large object according to claim 1, characterized in that: The query request is a query operation on one or more columns in a database table that are defined as smart large object data types.

4. The method for reducing conflicts in a high-concurrency scenario of a database intelligent large object according to claim 3, characterized in that: The smart large object data type is a text large object or a binary large object.

5. The method for reducing conflicts in a high-concurrency scenario of a database intelligent large object according to claim 1, characterized in that: Within a time window after releasing the first row lock and before acquiring the second row lock, a second transaction is allowed to perform an update or delete operation on the table row and make the content of the second smart large object descriptor different from that of the first smart large object descriptor.

6. The method for reducing conflicts in a high-concurrency scenario of a database intelligent large object according to claim 5, characterized in that: The first transaction and the second transaction are different transactions executed concurrently.

7. The method for reducing conflicts in a high-concurrency scenario of a database intelligent large object according to claim 5, characterized in that: The write operation performed by the second transaction is an update operation or a delete operation; the update operation includes modifying the smart large object descriptor in the table row.

8. The method for reducing conflicts in a high-concurrency scenario of a database intelligent large object according to claim 5, characterized in that: The first row lock and the second row lock are exclusive locks or update locks that prevent other transactions from performing write operations on the table row.

9. The method for reducing conflicts in a high-concurrency scenario of a database intelligent large object according to claim 1, characterized in that: If it is found that the table row has been deleted during relocation based on the recorded table row position information, the subsequent step of reading the second smart large object descriptor is terminated.

10. The method for reducing conflicts in a high-concurrency scenario of a database intelligent large object according to claim 1, characterized in that: Reading actual data of the smart large object according to the second smart large object descriptor further includes: acquiring an object lock of the smart large object before reading the actual data of the smart large object according to the second smart large object descriptor, and releasing the object lock of the smart large object after completing reading the actual data of the smart large object.

Images