CN114416742A - Key-Value存储引擎实现方法及系统 - Google Patents
Key-Value存储引擎实现方法及系统 Download PDFInfo
- Publication number
- CN114416742A CN114416742A CN202210047341.9A CN202210047341A CN114416742A CN 114416742 A CN114416742 A CN 114416742A CN 202210047341 A CN202210047341 A CN 202210047341A CN 114416742 A CN114416742 A CN 114416742A
- Authority
- CN
- China
- Prior art keywords
- memory
- key
- data
- value
- wal
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2264—Multidimensional index structures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2272—Management thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24552—Database cache management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Software Systems (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种Key‑Value存储引擎实现方法及系统,属于分布式数据库及分布式存储技术领域,本发明要解决的技术问题为如何适配最新的高性能存储设备(NVMe SSDs、Persistent Memory),并确保能够充分发挥这些设备低延迟、高带宽和高并发的特性,采用的技术方案为:该方法是基于NVMe SSDs+SPDK实现WAL的并发写,在内存中保存key的多种全量索引以应对不同的应用场景的点查查询和范围查询,并对value进行冷热数据分离,在内存和存储设备中管理冷热数据,数据落盘时无需进行排序、合并及转储。该系统包括WAL并发写模块、内存全量索引模块、冷热数据分离模块、数据持久化模块及数据检索模块。
Description
技术领域
本发明涉及分布式数据库及分布式存储技术领域,具体地说是一种Key-Value存储引擎实现方法及系统。
背景技术
研究发现,假设一次业务处理的总开销是100%,实际上只有7%不到的资源是在真正处理业务逻辑;34%用于缓冲区管理如缓冲区的加载替换、地址转化等;14%处理Latching;16%处理Locking;然后12%处理Logging;最后16%用于对B树索引的处理。也就是说,机器资源跑满负荷以后,真正用于处理业务逻辑的只有7%。基于磁盘的数据库管理系统虽然做了很多额外的管理工作,这些工作并不处理业务逻辑,但在保证业务逻辑的正确性上却不可或缺。面向磁盘的数据库系统在进行大规模事务处理时瓶颈主要是磁盘I/O。
RocksDB作为数据库存储引擎被广泛应用。RocksDB使用了LSM-Tree(LogStructured Merge Tree i.e.日志结构的合并树)作为其内部存储结构。LSM-Tree的核心思想其实非常简单,就是假定有足够的内存,因此不需要每次有数据更新时都必须将数据立即写入磁盘,而是可以先将最新的数据驻留在内存中,等到积累到足够多之后,再使用归并排序的方式将内存里的数据合并追加到磁盘队尾(因为所有待排序的树都是有序的,可以通过合并排序的方式快速合并到一起)。由于所有的刷盘操作都采用append方式,这种方式对磁盘是相当有诱惑力的,写操作写完WAL(Write Ahead Log)和Memtable就立即返回,写效率非常高,并且由于最终的数据是存储在离散的SST(Sorted Storage Table)中,SST文件的大小可以根据key-value的大小自由配置,因此很适合做变长存储。但是由于Level 0层的文件是按照时间顺序刷盘的,而不是根据key的范围做划分,所以导致各个文件之间key有重叠,再加上文件自上向下的合并,读的时候有可能需要查找Level 0层的多个文件及其他层的文件,这也造成了很大的读放大。尤其是当纯随机写入后,读几乎是要查询Level 0层的所有文件,导致了读操作的低效。针对这个问题,RocksDB中依据Level 0层文件的个数来做前台写流控及后台合并触发,以此来平衡读写的性能,这又导致了性能抖动及不能发挥高速介质性能的问题。同时RocksDB的合并流程难以控制,容易造成性能抖动及写放大,尤其是写放大问题,实际使用中经常达到二十倍左右。RocksDB这些架构上的设计导致了磁盘I/O仍然是数据库的主要瓶颈之一。
近年来,随着NVMe SSD、Persistent Memrory(持久化内存)等高速存储设备的出现和发展,使得存储设备的I/O不再是系统的瓶颈,反而是现有的存储架构无法充分地发挥这些高速设备的I/O性能,成为了新的瓶颈点,即由I/O bound转为了CPU bound。以RocksDB为例,它现有的架构是为早期的存储设备设计的,使用了LSM-tree,为了避免随机访问的逻辑导致了保持磁盘上数据归并排序这样的开销巨大的操作以及同步操作,这些操作使得这些KVs在NVMe SSD上受到CPU限制。以RocksDB的WAL写操作为例,在SATA SSD上日志合并与同步的CPU平均消耗占整个操作的68.1%,但是这个占比在NVMe SSD上却上升到了81%。
故如何适配最新的高性能存储设备(NVMe SSDs、Persistent Memory),并确保能够充分发挥这些设备低延迟、高带宽和高并发的特性是目前亟待解决的技术问题。
发明内容
本发明的技术任务是提供一种Key-Value存储引擎实现方法及系统,来解决如何适配最新的高性能存储设备(NVMe SSDs、Persistent Memory),并确保能够充分发挥这些设备低延迟、高带宽和高并发的特性的问题。
本发明的技术任务是按以下方式实现的,一种Key-Value存储引擎实现方法,该方法是基于NVMe SSDs+SPDK实现WAL的并发写,在内存中保存key的多种全量索引以应对不同的应用场景的点查查询和范围查询,并对value进行冷热数据分离,在内存和存储设备中管理冷热数据,数据落盘时无需像RocksDB那样进行排序、合并及转储。
作为优选,该方法具体如下:
WAL并发写:WAL存储在高端存储设备上或利用NVMe SSD按块寻址加上SPDK4KB原子写实现并发写入;
多种内存全量索引:写完WAL后,在内存中建立key全量索引,并建立value相应的多版本数据链表;
冷热数据分离:将热数据保存在内存、高端NVMe SSD(Intel Optane及ToshibaXL-Flash)或Persistent Memory里;将冷数据保存在相对慢的存储设备中,例如普通NVMeSSD、SATA SSD及HDD;
数据持久化:内存中维护每个key的持久化元数据,无需排序、合并及转储等操作造成的大量的CPU消耗,并充分发挥NVMe SSDs的I/O性能;
检索数据:通过点查检索和范围检索直接从内存返回结果。
更优地,所述高端存储设备为Intel Optane和Persistent Memory。
更优地,在内存中保存key的多种全量索引时,在内存中添加内存释放(Eviction)机制,具体如下:
将冷数据key-value落盘,落盘过程将多版本合并,相应的key的索引保留在内存中,而相应的value变成落盘后的元数据。
更优地,内存中建立索引以支持不同的应用场景,索引包括如下两种:
①、哈希索引:支持高效put/get;
②、ART或B+Tree索引:支持高效scan。
更优地,检索数据时,针对已经落盘的冷数据,内存中保留有相应key的持久化元数据,借助高端NVMe SSD的高速存储设备随机访问的低时延,快速检索到相应的value。
一种Key-Value存储引擎系统,该系统包括,
WAL并发写模块,用于WAL存储在高端存储设备上或利用NVMe SSD按块寻址加上SPDK 4KB原子写实现并发写入;
内存全量索引模块,用于在写完WAL后,在内存中建立key全量索引,并建立value相应的多版本数据链表;
冷热数据分离模块,用于将热数据保存在内存、高端NVMe SSD或PersistentMemory里;并将冷数据保存在相对慢的存储设备中;
数据持久化模块,用于内存中维护每个key的持久化元数据,无需排序、合并及转储等操作造成的大量的CPU消耗,并充分发挥NVMe SSDs的I/O性能;
数据检索模块,用于通过点查检索和范围检索直接从内存返回结果。
作为优选,内存全量索引模块用于在内存中保存key的多种全量索引,并在内存中添加内存释放(Eviction)机制,具体如下:
将冷数据key-value落盘,落盘过程将多版本合并,相应的key的索引保留在内存中,而相应的value变成落盘后的元数据;
内存中建立索引以支持不同的应用场景,索引包括如下两种:
①、哈希索引:支持高效put/get;
②、ART或B+Tree索引:支持高效scan。
一种电子设备,包括:存储器和至少一个处理器;
其中,所述存储器上存储有计算机程序;
所述至少一个处理器执行所述存储器存储的计算机程序,使得所述至少一个处理器执行如上述的Key-Value存储引擎实现方法。
一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机程序,所述计算机程序可被处理器执行以实现如上述的Key-Value存储引擎实现方法。
本发明的Key-Value存储引擎实现方法及系统具有以下优点:
(一)本发明充分发挥了高端存储设备(例如:NVMe SSDs、Persistent Memory)的I/O性能(高带宽、低时延),同时因为没有了排序、合并、转储等操作大幅降低存储引擎对CPU的消耗;
(二)本发明基于NVMe SSD+SPDK的WAL并发写,由于WAL的特殊性,在RocksDB中WAL的写是串行的,虽然有group logging,但是在leader完成WAL落盘之前,是无法写memtable的,新的架构设计中,借助NVMe SSD和SPDK,可以实现WAL的并发写,虽然key-value的内存写仍然需要等待WAL落盘,但是时延大大缩短;
(三)本发明在内存中全量缓存索引,并且有不同索引应对不同场景,可以实现高效的点查和范围查询,虽然数据仍然有可能已经落盘,但是内存中保留有相应key的持久化元数据,借助NVMe SSD等高速存储设备随机访问的低时延,仍然可以快速检索到相应的value;
(四)由于key-value落盘时不再需要提前按key进行排序,所以也不需要后续的合并和转储,这大大节省了CPU的消耗。
附图说明
下面结合附图对本发明进一步说明。
附图1为Key-Value存储引擎实现方法的流程框图。
具体实施方式
参照说明书附图和具体实施例对本发明的Key-Value存储引擎实现方法及系统作以下详细地说明。
实施例1:
如附图1所示,本发明的Key-Value存储引擎实现方法,该方法是基于NVMe SSDs+SPDK实现WAL的并发写,在内存中保存key的多种全量索引以应对不同的应用场景的点查查询和范围查询,并对value进行冷热数据分离,在内存和存储设备中管理冷热数据,数据落盘时无需像RocksDB那样进行排序、合并及转储;具体如下:
S1、WAL并发写:WAL存储在高端存储设备上或利用NVMe SSD按块寻址加上SPDK4KB原子写实现并发写入;
S2、多种内存全量索引:写完WAL后,在内存中建立key全量索引,并建立value相应的多版本数据链表;
S3、冷热数据分离:将热数据保存在内存、高端NVMe SSD(Intel Optane及ToshibaXL-Flash)或Persistent Memory里;将冷数据保存在相对慢的存储设备中,例如普通NVMeSSD、SATA SSD及HDD;
S4、数据持久化:内存中维护每个key的持久化元数据,无需排序、合并及转储等操作造成的大量的CPU消耗,并充分发挥NVMe SSDs的I/O性能;
S5、检索数据:通过点查检索和范围检索直接从内存返回结果。由于在内存中全量缓存索引,并且有不同索引应对不同场景,可以实现高效的点查和范围查询,因为系统的冷热数据分离,绝大多数检索可能直接从内存返回结果,即使是冷数据,已经落盘,但是内存中保留有相应key的持久化元数据,借助NVMe SSD等高速存储设备随机访问的低时延,仍然可以快速检索到相应的value。
本实施例中的高端存储设备为Intel Optane和Persistent Memory。
本实施例中的在内存中保存key的多种全量索引时,在内存中添加内存释放(Eviction)机制,具体如下:
将冷数据key-value落盘,落盘过程将多版本合并,相应的key的索引保留在内存中,而相应的value变成落盘后的元数据。
本实施例中的内存中建立索引以支持不同的应用场景,索引包括如下两种:
①、哈希索引:支持高效put/get;
②、ART或B+Tree索引:支持高效scan。
本实施例中的检索数据时,针对已经落盘的冷数据,内存中保留有相应key的持久化元数据,借助高端NVMe SSD的高速存储设备随机访问的低时延,快速检索到相应的value。
实施例2:
本发明的Key-Value存储引擎系统,该系统包括,
WAL并发写模块,用于WAL存储在高端存储设备上或利用NVMe SSD按块寻址加上SPDK 4KB原子写实现并发写入;
内存全量索引模块,用于在写完WAL后,在内存中建立key全量索引,并建立value相应的多版本数据链表;
冷热数据分离模块,用于将热数据保存在内存、高端NVMe SSD或PersistentMemory里;并将冷数据保存在相对慢的存储设备中;
数据持久化模块,用于内存中维护每个key的持久化元数据,无需排序、合并及转储等操作造成的大量的CPU消耗,并充分发挥NVMe SSDs的I/O性能;
数据检索模块,用于通过点查检索和范围检索直接从内存返回结果。
本实施例中的内存全量索引模块用于在内存中保存key的多种全量索引,并在内存中添加内存释放(Eviction)机制,具体如下:
将冷数据key-value落盘,落盘过程将多版本合并,相应的key的索引保留在内存中,而相应的value变成落盘后的元数据;
内存中建立索引以支持不同的应用场景,索引包括如下两种:
①、哈希索引:支持高效put/get;
②、ART或B+Tree索引:支持高效scan。
实施例3:
本发明实施例还提供了一种电子设备,包括:存储器和处理器;
其中,存储器存储计算机执行指令;
处理器执行所述存储器存储的计算机执行指令,使得处理器执行本发明任一实施例中的Key-Value存储引擎实现方法。
实施例4:
本发明实施例还提供了一种计算机可读存储介质,其中存储有多条指令,指令由处理器加载,使处理器执行本发明任一实施例中的Key-Value存储引擎实现方法。具体地,可以提供配有存储介质的系统或者装置,在该存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码,且使该系统或者装置的计算机(或CPU或MPU)读出并执行存储在存储介质中的程序代码。
在这种情况下,从存储介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能,因此程序代码和存储程序代码的存储介质构成了本发明的一部分。
用于提供程序代码的存储介质实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RYM、DVD-RW、DVD+RW)、磁带、非易失性存储卡和ROM。可选择地,可以由通信网络从服务器计算机上下载程序代码。
此外,应该清楚的是,不仅可以通过执行计算机所读出的程序代码,而且可以通过基于程序代码的指令使计算机上操作的操作系统等来完成部分或者全部的实际操作,从而实现上述实施例中任意一项实施例的功能。
此外,可以理解的是,将由存储介质读出的程序代码写到插入计算机内的扩展板中所设置的存储器中或者写到与计算机相连接的扩展单元中设置的存储器中,随后基于程序代码的指令使安装在扩展板或者扩展单元上的CPU等来执行部分和全部实际操作,从而实现上述实施例中任一实施例的功能。
最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。
Claims (10)
1.一种Key-Value存储引擎实现方法,其特征在于,该方法是基于NVMe SSDs+SPDK实现WAL的并发写,在内存中保存key的多种全量索引以应对不同的应用场景的点查查询和范围查询,并对value进行冷热数据分离,在内存和存储设备中管理冷热数据,数据落盘时无需进行排序、合并及转储。
2.根据权利要求1所述的Key-Value存储引擎实现方法,其特征在于,该方法具体如下:
WAL并发写:WAL存储在高端存储设备上或利用NVMe SSD按块寻址加上SPDK4KB原子写实现并发写入;
多种内存全量索引:写完WAL后,在内存中建立key全量索引,并建立value相应的多版本数据链表;
冷热数据分离:将热数据保存在内存、高端NVMe SSD或Persistent Memory里;将冷数据保存在存储设备中;
数据持久化:内存中维护每个key的持久化元数据,无需排序、合并及转储,并充分发挥NVMe SSDs的I/O性能;
检索数据:通过点查检索和范围检索直接从内存返回结果。
3.根据权利要求2所述的Key-Value存储引擎实现方法,其特征在于,所述高端存储设备为Intel Optane和Persistent Memory。
4.根据权利要求2所述的Key-Value存储引擎实现方法,其特征在于,在内存中保存key的多种全量索引时,在内存中添加内存释放机制,具体如下:
将冷数据key-value落盘,落盘过程将多版本合并,相应的key的索引保留在内存中,而相应的value变成落盘后的元数据。
5.根据权利要求2或4所述的Key-Value存储引擎实现方法,其特征在于,内存中建立索引以支持不同的应用场景,索引包括如下两种:
①、哈希索引:支持高效put/get;
②、ART或B+Tree索引:支持高效scan。
6.根据权利要求2所述的Key-Value存储引擎实现方法,其特征在于,检索数据时,针对已经落盘的冷数据,内存中保留有相应key的持久化元数据,借助高端NVMe SSD的高速存储设备随机访问的低时延,快速检索到相应的value。
7.一种Key-Value存储引擎系统,其特征在于,该系统包括,
WAL并发写模块,用于WAL存储在高端存储设备上或利用NVMe SSD按块寻址加上SPDK4KB原子写实现并发写入;
内存全量索引模块,用于在写完WAL后,在内存中建立key全量索引,并建立value相应的多版本数据链表;
冷热数据分离模块,用于将热数据保存在内存、高端NVMe SSD或Persistent Memory里;并将冷数据保存在存储设备中;
数据持久化模块,用于内存中维护每个key的持久化元数据,无需排序、合并及转储,并充分发挥NVMe SSDs的I/O性能;
数据检索模块,用于通过点查检索和范围检索直接从内存返回结果。
8.根据权利要求7所述的Key-Value存储引擎系统,其特征在于,内存全量索引模块用于在内存中保存key的多种全量索引,并在内存中添加内存释放机制,具体如下:
将冷数据key-value落盘,落盘过程将多版本合并,相应的key的索引保留在内存中,而相应的value变成落盘后的元数据;
内存中建立索引以支持不同的应用场景,索引包括如下两种:
①、哈希索引:支持高效put/get;
②、ART或B+Tree索引:支持高效scan。
9.一种电子设备,其特征在于,包括:存储器和至少一个处理器;
其中,所述存储器上存储有计算机程序;
所述至少一个处理器执行所述存储器存储的计算机程序,使得所述至少一个处理器执行如权利要求1至6任一项所述的Key-Value存储引擎实现方法。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机程序,所述计算机程序可被处理器执行以实现如权利要求1至6中任一项所述的Key-Value存储引擎实现方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210047341.9A CN114416742A (zh) | 2022-01-17 | 2022-01-17 | Key-Value存储引擎实现方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210047341.9A CN114416742A (zh) | 2022-01-17 | 2022-01-17 | Key-Value存储引擎实现方法及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114416742A true CN114416742A (zh) | 2022-04-29 |
Family
ID=81273577
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210047341.9A Pending CN114416742A (zh) | 2022-01-17 | 2022-01-17 | Key-Value存储引擎实现方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114416742A (zh) |
-
2022
- 2022-01-17 CN CN202210047341.9A patent/CN114416742A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109213772B (zh) | 数据存储方法及NVMe存储系统 | |
US11288252B2 (en) | Transactional key-value store | |
US9672235B2 (en) | Method and system for dynamically partitioning very large database indices on write-once tables | |
US9858303B2 (en) | In-memory latch-free index structure | |
US10496283B2 (en) | Adaptive prefix tree based order partitioned data storage system | |
CN109933570B (zh) | 一种元数据管理方法、系统及介质 | |
US11023453B2 (en) | Hash index | |
US8868926B2 (en) | Cryptographic hash database | |
US20180011892A1 (en) | Foster twin data structure | |
US20170351543A1 (en) | Heap data structure | |
WO2014015828A1 (zh) | 数据存储空间的处理方法、处理系统及数据存储服务器 | |
CN109800185B (zh) | 一种数据存储系统中的数据缓存方法 | |
CN105117417A (zh) | 一种读优化的内存数据库Trie树索引方法 | |
US10891202B2 (en) | Recovery of in-memory databases using a backward scan of the database transaction log | |
CN113821171B (zh) | 一种基于哈希表与lsm树的键值存储方法 | |
US20180004798A1 (en) | Read only bufferpool | |
KR20210123236A (ko) | 키-값 장치들을 위한 키-값 저장소 아키텍처 | |
Tulkinbekov et al. | CaseDB: Lightweight key-value store for edge computing environment | |
US20180011897A1 (en) | Data processing method having structure of cache index specified to transaction in mobile environment dbms | |
CN102955787A (zh) | 一种文件目录表的使用方法、文件写入方法及应用的主电路板、cpu和外部存储器 | |
Akram | Exploiting intel optane persistent memory for full text search | |
Doekemeijer et al. | Key-Value Stores on Flash Storage Devices: A Survey | |
CN112732725A (zh) | 基于nvm混合内存的自适应前缀树构建方法及其系统、介质 | |
CN114416742A (zh) | Key-Value存储引擎实现方法及系统 | |
US11093169B1 (en) | Lockless metadata binary tree access |
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 | ||
TA01 | Transfer of patent application right | ||
TA01 | Transfer of patent application right |
Effective date of registration: 20221130 Address after: Room 305-22, Building 2, No. 1158 Zhangdong Road and No. 1059 Dangui Road, China (Shanghai) Pilot Free Trade Zone, Pudong New Area, Shanghai, 200120 Applicant after: Shanghai Yunxi Technology Co.,Ltd. Address before: Building S02, 1036 Gaoxin Langchao Road, Jinan, Shandong 250100 Applicant before: Shandong Inspur Scientific Research Institute Co.,Ltd. |