# Rocksdb Query

![left](./student-guide/diagram/03-RocksDB-query-01-01.png)
------------------------------------------------------------
The data is stored in RocksDB, so the query of the data also needs to be done through RoksDB. Let's first understand the query operation of RocksDB. The query operation is slower than the B+ tree, and the query operation needs to read MemTable, Immutable MemTable, SSTable0, SSTABLE1... All collections need to be traversed in reverse order, and because of the write order and merge order, the data in the set with the lower sequence number must be newer than the data in the larger set. So once the data to be read is matched during this reverse order traversal, it must be the latest data, as long as the data is return. But if one piece of data is not in all data sets, it will be traversed in vain.

So it seems that read operations are still clumsy, and RocksDB uses Bloom Filters to speed up read operations. When the bloom filter determines that there is no data to read in the corresponding SSTable, the SSTable is skipped.

Note: The Bloom Filter is actually a very long binary vector and a series of random mapping function. Bloom filters can be used to retrieve whether an element is in a collection. Its advantage is that space efficiency and query time are far greater than the average algorithm, and the disadvantage is that it has a certain misidentification rate. To put it plainly, it's that the Bloom filter determines that the elements of this collection are not necessarily in the collection, but if the Bloom filter determines that they are absent, they must not be there.

Finally, there is also a Block Cache function inside RocksDB. We can set a space in memory for Block Cache. This Block Cache is the data we access frequently, so the query operation will prioritize reading data from the Block Cache, if the data is not cached Block Cache, then we start the reading process described above from MemTable.