CN102521304A - 基于哈希的聚簇表存储方法 - Google Patents
基于哈希的聚簇表存储方法 Download PDFInfo
- Publication number
- CN102521304A CN102521304A CN2011103922746A CN201110392274A CN102521304A CN 102521304 A CN102521304 A CN 102521304A CN 2011103922746 A CN2011103922746 A CN 2011103922746A CN 201110392274 A CN201110392274 A CN 201110392274A CN 102521304 A CN102521304 A CN 102521304A
- Authority
- CN
- China
- Prior art keywords
- hash
- tuple
- clusters
- row
- storage means
- 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.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种基于哈希的聚簇表存储方法,包括以下步骤:步骤1:预先初始化空的数据表页面空间;步骤2:指定数据表的一个或多个列为哈希列;步骤3:根据各个元组的哈希列的值来计算哈希值,作为相应元组的存储位置;步骤4:根据哈希值映射出相应元组在页面空间上的行指针;步骤5:根据行指针,将相应元组***到页面空间。本发明对现有哈希聚簇技术做了进一步改进,可以实现跨过索引直达元组的数据库存储管理机制,从而在大规模数据库***的使用过程中避免了索引对缓存资源的大量占用,改善了数据库***的使用性能。
Description
技术领域
本发明涉及一种数据库存储方法,尤其涉及一种面向数据库存储管理的需要,基于哈希(hash)的聚簇表存储方法,属于数据库存储技术领域。
背景技术
数据库(Database)是依照某种数据模型组织起来并存放二级存储器中的数据集合。在数据库技术中,可以使用两种形式描述客观现实的数据:物理数据描述和逻辑数据描述。物理数据描述是指数据在存储设备上的存储方式,物理数据是实际存放在存储设备上的数据,这些数据也称为物理记录。逻辑数据描述是指用户或程序员用于操作的数据形式,逻辑数据是一种抽象的概念,是对客观现实世界的反映和记录,这些数据也可以称为逻辑记录。物理数据和逻辑数据之间的转换通过数据库管理***实现。
在数据库管理***中,采用字段来标记实体属性的可以命名的最小信息单位。字段的集合称为元组。一个元组表示一个具体的实体。在现有的关系型数据库中,往往将一个数据表中的行作为元组,列作为字段。一个数据表由行(元组)和列(字段)构成,组成一个二维关系表。若干个数据表、视图及相关的文件等组成一个统一的相关联的数据库***。
在数据库***中,索引是对数据表中一列或多列的值进行排序的一种结构,使用索引可以快速访问数据表中的特定信息。索引分为聚簇索引和非聚簇索引两种。所谓聚簇是指为了提高某个字段(或字段组)的查询速度,将这些字段上具有相同值的元组集中存放在连续的物理块中。因此,聚簇索引能够提高多行检索的速度,而非聚簇索引适合于单行的检索。
哈希聚簇(hash cluster)是指通过预先分配空间的方式,将相同关键字(key)的数据存放在一起,以提高查询性能的一项技术。目前,仅仅在Oracle系列数据库产品有哈希聚簇功能,其它的数据库产品,例如SQL Server、IBM DB2以及达梦DM等中均没有类似功能。在实际使用中,该项技术仍然存在一定的缺陷,例如关键字(key)的数量难以精确估计,造成哈希聚簇技术的应用场景非常有限。
发明内容
鉴于现有技术所存在的不足,本发明所要解决的技术问题在于提供一种基于哈希的聚簇表存储方法。该方法能够提供跨过索引直达元组的数据库存储管理机制。
为实现上述的发明目的,本发明采用下述的技术方案:
一种基于哈希的聚簇表存储方法,所述数据表由元组和列构成,其特征在于包括以下步骤:
步骤1:预先初始化空的数据表页面空间;
步骤2:指定所述数据表的一个或多个列为哈希列;
步骤3:根据各个元组的所述哈希列的值来计算哈希值,作为相应元组的存储位置;
步骤4:根据所述哈希值映射出所述相应元组在所述页面空间上的行指针;
步骤5:根据所述行指针,将所述相应元组***到所述页面空间。
其中较优地,根据可能用到的元组的、哈希列的哈希值的个数,对所述页面空间进行动态预分配。
其中较优地,在所述步骤3中,当各个元组的哈希列的哈希值中出现两个或多个哈希值相同时,对相应的哈希值增加溢出链,将该元组存储到溢出链中。
其中较优地,还包括对所述聚簇表的查询步骤:
根据指定的哈希列的值计算出相应的哈希值,通过所述哈希值按照已建立的映射关系找到行指针,根据所述行指针找到相应的元组。
其中较优地,当所述聚簇表是非独特类型聚簇表时,所述查询步骤还包括:对查询得到的、符合行指针的多条元组的哈希列的值进行验证。
其中较优地,当所述聚簇表是独特类型聚簇表时,对查询得到的符合行指针的多条元组的哈希列的值,不进行验证。
其中较优地,如果在查询过程后面有***操作,那么还包括动态扩充聚簇表的页面空间的步骤:
获得需要***的元组的哈希列的值,然后计算出哈希值,并通过一对一的映射得到所述需要***的元组存储在页面上的行指针,然后根据所述行指针找到对应的页面进行***。
其中较优地,如果所述行指针找到的页面的页面空间不够,则将所述需要***的元组存储在溢出链中。
其中较优地,如果查询列包括所述数据表的所有哈希列,或者使用特定哈希函数时的查询列为哈希列的前缀以及排序操作,使用聚簇扫描方式进行扫描。
本发明所提供的聚簇表存储方法对现有哈希聚簇技术做了进一步改进,可以实现跨过索引直达元组的数据库存储管理机制,从而在大规模数据库***的使用过程中避免了索引对缓存资源的大量占用,改善了数据库***的使用性能。
附图说明
下面结合附图和具体实施方式对本发明做进一步的详细说明。
图1为通过哈希聚簇表获取数据表中元组的示意图。
具体实施方式
在大规模数据库***的使用过程中,使用索引进行扫描时索引本身将会占用大量的缓存资源,从而降低了缓存资源的利用率。为了解决这一问题,需要实现能够跨过索引直达元组的数据库存储管理机制。为此,本发明所提供的聚簇表存储方法首先建立通过元组列的哈希值(harsh value,哈希值)到页面存储位置的一种映射,使得根据查询时指定的查询列的值可以直接计算出页面中元组的位置,从而达到直接定位元组的目的。下面对此展开具体的说明。
在本发明所提供的聚簇表存储方法中,所述数据表由元组和列构成,具体包括以下步骤:
步骤1:预先初始化空的数据表页面空间;
步骤2:指定所述数据表的一个或多个列为哈希列;
步骤3:根据各个元组的所述哈希列的值来计算哈希值,作为相应元组的存储位置;
步骤4:根据所述哈希值映射出,所述相应元组在所述页面空间上的行指针;
步骤5:根据所述行指针,将所述相应元组***到所述页面空间。
具体而言,首先是在建立聚簇表的过程中预先初始化空的数据表页面空间。其次是指定数据表的一个或多个列为hash列,根据各个元组的hash列的哈希值,来确定元组存储的位置,以便使元组按照哈希值***到指定位置中。
为了支持聚簇表的使用,本发明采用了表的预分配技术和表的溢出链处理技术。表的预分配技术是指在创建表时,即根据哈希值动态预分配空间,这样元组在操作时可以直接***到指定位置,维护了元组根据索引列的哈希值进行聚簇的特性。
表的溢出链处理技术则是针对聚簇表的特殊处理。特殊情况下,建立聚簇表时得到的各个元组的hash列的哈希值中,可能有两个或多个哈希值相同,这就会使某个哈希值对应两个或更多个元组。当某个哈希值对应的元组过多时,只需要对相应的哈希值增加溢出链,将该元组存储到溢出链中,而不用影响到其它哈希值的元组的维护。
在建立聚簇表之初,可以根据数据库应用可能用到的元组的哈希列的哈希值的个数动态预分配聚簇表的存储空间,这样使得大多数情况下元组可以根据hash列的哈希值直接定位。对于hash列的哈希值重复的情况,如果在预先分配的页面中没有足够的空间存储元组,则可以在溢出链中进行元组的存储。但在这种情况下,由于不能实现对元组的直接定位,可能造成数据库***的性能下降。
在本发明所提供的聚簇表存储方法中,可以使用两种类型的哈希聚簇表:非unique(独特)类型的哈希聚簇表和unique(独特)类型的哈希聚簇表。两种哈希聚簇表在存储方式上存在一定的差异。在前者中,多个元组可以对应一个哈希值,因此同一个哈希值槽中将预留多个元组的空间,而且还可能需要溢出链的支持,在实际操作中略显复杂,但通用性较强。在后者中,不同的元组必须具有不同的哈希值。由于存在不同元组的哈希值不同的限制,应用范围比较小,但一旦应用则可以起到直接定位当前元组的作用,极大提升了数据库***的管理性能。用户可以根据实际应用选择合适的聚簇表类型。
下面以TPCC(基准测试)应用中的c_stock表为例,具体说明本聚簇表存储方法的实现过程。假设该c_stock表有一个主键(s_w_id,s_i_id),两列均为整型数,且在TPCC应用中,这两列的值依次为(1,1),(1,2),…,(1,100000),(2,1),…,(2,100000),…,(n,100000),共100000n条元组。
基于以下的技术原因,选择unique类型的哈希聚簇表来建立该c_stock表,且hash列即为(s_w_id,s_i_id):
(1)主键列的值的规律性好。主键列的分布非常有规律,可以避免不同元组的哈希列的哈希值相同。它采用递增的序列,因此可以使用整型hash列递增函数作为元组分布的哈希函数。由于s_i_id列是100000进位到s_w_id的,所以这个自动生成的整型hash列递增函数为f(s_w_id,s_i_id)=(s_w_id-1)*100000+(s_i_id-1)。
(2)查询条件的指向性好,即根据查询条件能获得相应的一条元组。在TPCC应用的查询过程中,多以两列的值为查询条件获得相应的一条元组进行查询或更新操作,因此在多数情况下可以直接使用哈希扫描算法,达到优化数据吞吐(IO)的目的。
(3)查询过程无***操作。在TPCC应用的查询过程中,不会在c_stock表上进行***操作,因此c_stock表的条数自测试开始前灌入数据后保持不变,在建表时即可计算出c_stock表的实际大小,在后续操作中不需要继续扩充该c_stock表的使用空间。
在建立c_stock表的过程中,首先在创建表时初始化100000n条元组的空间,在灌入数据时根据hash列的值计算hash函数的哈希值(hashvalue),然后映射出行指针以便进行元组***,保证所有元组按照hash列值的顺序***到c_stock表中。此时,c_stock表中即填满了所需要的数据。
如图1所示,在作为哈希聚簇表的c_stock表创建完成之后,如果需要进行查询,可以根据hash列的值计算出相应的哈希值,然后通过已经建立的映射关系找到行指针,进而根据行指针找到相应的元组。由于c_stock表为unique类型的哈希聚簇表,且使用整型hash列递增函数作为哈希函数,因此根据行指针找到相应元组时不必进行s_w_id和s_i_id列值的验证。
在本聚簇表存储方法的一个实施例中,对于如下的查询:
SELECT*from c_stock where s_w_id=5 order by s_i_id;
则直接根据hash列值(5,1)计算出哈希值,进而进行元组的定位。由于内存堆(heap)中的元组顺序即按照s_i_id的顺序排序,因此直接进行内存堆上的扫描即完成排序过程,需要扫描的元组最多为100000条。
在扫描过程中,本聚簇表存储方法除了可以使用传统的顺序扫描、索引扫描之外,还可以使用聚簇扫描方式。对于查询列包括表的所有hash列,或者特定哈希函数时查询列为hash列的前缀以及排序操作时,优选使用聚簇扫描方式进行,从而直接定位元组。
在哈希聚簇表的查询过程中,如果为非unique类型的哈希聚簇表,则需要对符合行指针的多条元组一一验证其是否满足查询的条件。如果在溢出链存在的情况下,可能会多扫描几个页面,对数据库***的性能造成一定影响。而对于unique类型的哈希聚簇表,同时使用了整型hash列递增函数作为哈希函数,则表明一个行指针仅对应相应列值的一条元组,不必验证其查询条件的满足性,可以直接返回。
对于某些基于哈希值的等值查询,可以根据计算出的hash列的值一次性定位到相应的元组。这样相对于使用索引的数据库应用来说,在节省索引存储和读取的同时,达到了使用索引时直接定位元组的效果。
如果在查询过程后面有***操作,则可以动态扩充哈希聚簇表的页面空间。在执行元组***操作时,首先获得元组对应的hash列的值,然后调用用户指定的哈希函数计算出哈希值,并通过一对一的映射得到元组存储在页面上的行指针,然后根据行指针找到对应的页面进行***。如果当前页面空间不够用,则可引入溢出链机制,将元组存储在溢出链中。
在执行哈希聚簇表的更新、删除等操作时,如果在过滤条件中指明了hash列的值,则同样可以应用类似查询的过程,找到元组所在的页面执行相应的操作。例如在进行更新操作时,执行如下的SQL语句:
UPDATE c_stock SET s_quantity=36 WHERE s_i_id=38426 ANDs_w_id=3;
则根据hash列的值(3,38426)计算出哈希值为338425,从而计算出相应的行指针,即可获得相应的元组进行更新操作。
在本发明中,可以使用不同类型的hash函数。除了默认的hash函数之外,本发明还可以使用用户自定义的hash函数或者整型hash列递增函数。后两种函数的使用使得元组的存储对用户来说基本可见。对于unique类型的哈希聚簇表而言,通常使用的是用户自定义的hash函数。用户可以选择合适的hash函数,通过尽可能形成unique类型的哈希聚簇表,从而提升尽可能多的数据库性能。
以上对本发明所提供的基于哈希的聚簇表存储方法进行了详细的说明。对本领域的技术人员而言,在不背离本发明实质精神的前提下对它所做的任何显而易见的改动,都将构成对本发明专利权的侵犯,将承担相应的法律责任。
Claims (9)
1.一种基于哈希的聚簇表存储方法,所述数据表由元组和列构成,其特征在于包括以下步骤:
步骤1:预先初始化空的数据表页面空间;
步骤2:指定所述数据表的一个或多个列为哈希列;
步骤3:根据各个元组的所述哈希列的值来计算哈希值,作为相应元组的存储位置;
步骤4:根据所述哈希值映射出,所述相应元组在所述页面空间上的行指针;
步骤5:根据所述行指针,将所述相应元组***到所述页面空间。
2.如权利要求1所述的聚簇表存储方法,其特征在于:
根据可能用到的元组的、哈希列的哈希值的个数,对所述页面空间进行动态预分配。
3.如权利要求1所述的聚簇表存储方法,其特征在于:
所述步骤3中,当各个元组的哈希列的哈希值中出现两个或多个哈希值相同时,对相应的哈希值增加溢出链,将该元组存储到溢出链中。
4.如权利要求1所述的聚簇表存储方法,其特征在于:
还包括对所述聚簇表的查询步骤:
根据指定的哈希列的值计算出相应的哈希值,通过所述哈希值按照已建立的映射关系找到行指针,根据所述行指针找到相应的元组。
5.如权利要求4所述的聚簇表存储方法,其特征在于:
当所述聚簇表是非独特类型聚簇表时,所述查询步骤还包括:
对查询得到的、符合行指针的多条元组的哈希列的值进行验证。
6.如权利要求4所述的聚簇表存储方法,其特征在于:
当所述聚簇表是独特类型聚簇表时,对查询得到的符合行指针的多条元组的哈希列的值,不进行验证。
7.如权利要求4所述的聚簇表存储方法,其特征在于:
如果在查询过程后有***操作,则还包括动态扩充聚簇表的页面空间的步骤:
获得需要***的元组的哈希列的值,然后计算出哈希值,并通过一对一的映射得到所述需要***的元组存储在页面上的行指针,然后根据所述行指针找到对应的页面进行***。
8.如权利要求7所述的聚簇表存储方法,其特征在于:
如果所述行指针找到的页面的页面空间不够,则将所述需要***的元组存储在溢出链中。
9.如权利要求1所述的聚簇表存储方法,其特征在于:
如果查询列包括所述数据表的所有哈希列,或者使用特定哈希函数时的查询列为哈希列的前缀以及排序操作,则使用聚簇扫描方式进行扫描。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2011103922746A CN102521304A (zh) | 2011-11-30 | 2011-11-30 | 基于哈希的聚簇表存储方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2011103922746A CN102521304A (zh) | 2011-11-30 | 2011-11-30 | 基于哈希的聚簇表存储方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102521304A true CN102521304A (zh) | 2012-06-27 |
Family
ID=46292225
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2011103922746A Pending CN102521304A (zh) | 2011-11-30 | 2011-11-30 | 基于哈希的聚簇表存储方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102521304A (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104021161A (zh) * | 2014-05-27 | 2014-09-03 | 华为技术有限公司 | 一种聚簇存储方法及装置 |
CN104462124A (zh) * | 2013-09-22 | 2015-03-25 | 中国电信股份有限公司 | 基于线性哈希表的数据存储平台组织方法和数据存储平台 |
CN105335475A (zh) * | 2015-09-30 | 2016-02-17 | 中国科学院计算技术研究所 | 一种基于流式数据的局部性非聚簇索引方法及*** |
CN106302179A (zh) * | 2016-07-29 | 2017-01-04 | 杭州迪普科技有限公司 | 一种管理索引表的方法及装置 |
CN108304460A (zh) * | 2017-12-25 | 2018-07-20 | 中国电力科学研究院有限公司 | 一种改进数据库的定位方法及*** |
CN112256698A (zh) * | 2020-10-16 | 2021-01-22 | 美林数据技术股份有限公司 | 一种基于多哈希函数的表关系自动关联方法 |
CN114356226A (zh) * | 2021-12-17 | 2022-04-15 | 广州文远知行科技有限公司 | 一种传感器数据存储方法、装置、设备及存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1926517A (zh) * | 2004-03-12 | 2007-03-07 | 国际商业机器公司 | 用于相似性管理的方法和*** |
CN101477524A (zh) * | 2008-12-11 | 2009-07-08 | 金蝶软件(中国)有限公司 | 基于物化视图的***性能优化方法及*** |
-
2011
- 2011-11-30 CN CN2011103922746A patent/CN102521304A/zh active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1926517A (zh) * | 2004-03-12 | 2007-03-07 | 国际商业机器公司 | 用于相似性管理的方法和*** |
CN101477524A (zh) * | 2008-12-11 | 2009-07-08 | 金蝶软件(中国)有限公司 | 基于物化视图的***性能优化方法及*** |
Non-Patent Citations (3)
Title |
---|
EDWINGU: "《哈希聚簇读取(Hash Cluster Access)[摘]》", 《EDWINKOO的专栏》 * |
JACKY: "《Oracle Cluster使用场景分析》", 《HELLO DATABASE》 * |
SHARANAM SHAH ETAL,: "《Oracle for Professionals-Covers Oracle 9i,10g&11g》", 17 June 2008 * |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104462124A (zh) * | 2013-09-22 | 2015-03-25 | 中国电信股份有限公司 | 基于线性哈希表的数据存储平台组织方法和数据存储平台 |
CN104462124B (zh) * | 2013-09-22 | 2018-04-06 | 中国电信股份有限公司 | 基于线性哈希表的数据存储平台组织方法和数据存储平台 |
CN104021161A (zh) * | 2014-05-27 | 2014-09-03 | 华为技术有限公司 | 一种聚簇存储方法及装置 |
WO2015180432A1 (zh) * | 2014-05-27 | 2015-12-03 | 华为技术有限公司 | 一种聚簇存储方法及装置 |
US10817258B2 (en) | 2014-05-27 | 2020-10-27 | Huawei Technologies Co., Ltd. | Clustering storage method and apparatus |
RU2663358C2 (ru) * | 2014-05-27 | 2018-08-03 | Хуавэй Текнолоджиз Ко., Лтд. | Устройство и способ кластерного хранения |
CN105335475B (zh) * | 2015-09-30 | 2018-07-10 | 中国科学院计算技术研究所 | 一种基于流式数据的局部性非聚簇索引方法及*** |
CN105335475A (zh) * | 2015-09-30 | 2016-02-17 | 中国科学院计算技术研究所 | 一种基于流式数据的局部性非聚簇索引方法及*** |
CN106302179A (zh) * | 2016-07-29 | 2017-01-04 | 杭州迪普科技有限公司 | 一种管理索引表的方法及装置 |
CN106302179B (zh) * | 2016-07-29 | 2020-02-11 | 杭州迪普科技股份有限公司 | 一种管理索引表的方法及装置 |
CN108304460A (zh) * | 2017-12-25 | 2018-07-20 | 中国电力科学研究院有限公司 | 一种改进数据库的定位方法及*** |
CN108304460B (zh) * | 2017-12-25 | 2022-10-25 | 中国电力科学研究院有限公司 | 一种改进数据库的定位方法及*** |
CN112256698A (zh) * | 2020-10-16 | 2021-01-22 | 美林数据技术股份有限公司 | 一种基于多哈希函数的表关系自动关联方法 |
CN112256698B (zh) * | 2020-10-16 | 2023-09-05 | 美林数据技术股份有限公司 | 一种基于多哈希函数的表关系自动关联方法 |
CN114356226A (zh) * | 2021-12-17 | 2022-04-15 | 广州文远知行科技有限公司 | 一种传感器数据存储方法、装置、设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102129458B (zh) | 关系型数据库的存储方法及装置 | |
CN110321344B (zh) | 关联数据的信息查询方法、装置、计算机设备及存储介质 | |
CN108874971B (zh) | 一种应用于海量标签化实体数据存储的工具和方法 | |
CN102521304A (zh) | 基于哈希的聚簇表存储方法 | |
JP6025149B2 (ja) | データを管理するシステムおよび方法 | |
CN107818115B (zh) | 一种处理数据表的方法及装置 | |
EP2069979B1 (en) | Dynamic fragment mapping | |
CN100468402C (zh) | 一种数据存储及查询方法 | |
CN101840400B (zh) | 一种多级分类检索方法及*** | |
CN104112008A (zh) | 一种多表数据关联查询优化方法和装置 | |
CN102682108B (zh) | 一种行列混合的数据库存储方法 | |
CN104102710A (zh) | 一种海量数据查询方法 | |
CN102362273A (zh) | 用于关系数据库***中高效数据存取的动态散列表 | |
CN102968503A (zh) | 数据库***的数据处理方法以及数据库*** | |
CN103177061A (zh) | 分区表中的唯一值估计 | |
US9235613B2 (en) | Flexible partitioning of data | |
CN103914483B (zh) | 文件存储方法、装置及文件读取方法、装置 | |
CN104063376A (zh) | 多维度分组运算方法及*** | |
CN103440245A (zh) | 数据库***的行列混合存储方法 | |
Wang et al. | Distributed storage and index of vector spatial data based on HBase | |
CN102737123B (zh) | 一种多维数据分布方法 | |
CN104573112A (zh) | Oltp集群数据库中页面查询方法及数据处理节点 | |
CN113177090A (zh) | 数据处理方法及装置 | |
CN104572785A (zh) | 一种分布式创建索引的方法和装置 | |
CN114185895A (zh) | 数据导入导出方法、装置、电子设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20120627 |