What storage does qdrant use? FAISS or something else? What persistence storage does qdrant?

[martinenkoEduard]

What storage does qdrant use? FAISS or something else? What persistence storage does qdrant?

[timvisee]

What storage does qdrant use?

Qdrant uses a custom storage format that is intended to best suit our use case, though we do utilize RocksDB in some places.

With regards to serving requests, Qdrant can serve data from RAM and from disk, configurable by the user.

FAISS or something else?

Similarity calculations are also custom and make use of architecture-specific optimizations such as SIMD to make this as performant as possible. FAISS is not used anywhere.

What persistence storage does qdrant?

Qdrant stores data on disk. So any storage medium can be used, though it is highly recommended to utilize a fast (IOPS/throughput) storage medium to achieve the best results.

[timvisee]

it is possible to use Qdrant without a disk (completely disable persistence, wal journal and other disk queries)?

It is not possible to run the Qdrant service in memory only mode. You could run it on a ramdisk, but that would definitely be a nasty workaround.

I tried to use QdrantClient(":memory:"), but for some unknown reason it works 10 times slower than working with the Qdrant gRPC server.

We indeed have a memory only mode in our Python client. That is however a very basic implementation that is just intended for testing. For example, it has no indexing at all and always uses a full scan search.

Or maybe I can place qdrant on ramdisk for this and specify "on_disk": true in all create collection parameters (will qdrant then be completely on ramdisk without spending additional RAM to storing vectors or indexes without serious degradation of speed)?

If you want to give using a ramdisk a try, I recommend to not set any on_disk flags. That would enable the use of memmaps, which makes no sense in such configuration. Using a ramdisk you will consume at least double the amount of RAM. That is because vector data is loaded in RAM, and also persisted in the ramdisk.

Update: it turns out that using a ramdisk with on_disk: true (memmap) does efficiently map ramdisk contents into memory (on Linux).

It would of course still have the WAL persisted (on ramdisk), so that will consume some extra memory.

Is it possible to connect to qdrant via unix socket or gRPC is the fastest possible interaction with qdrant server on ramdisk?

No, not possible at this time.

---

Could you elaborate on your use case, why would you like to use Qdrant without any persistence? Then I may be able to give you a better suggestion.

I think the performance impact of persistence on disk in minimal, assuming you have a fast disk and don't set on_disk: true flags.

[martinenkoEduard]

Can qdrant work in a distributed cluster mode? Split the data across different servers.
What about stability and fail-tolerance? Does it work after sudden reboot?

"Qdrant stores data on disk. So any storage medium can be used, though it is highly recommended to utilize a fast (IOPS/throughput) storage medium to achieve the best results." - does it mean that Qdrant keeps all indices in RAM and from time to time flushes it on the disk?

[timvisee]

Can qdrant work in a distributed cluster mode?

Yes. See: https://qdrant.tech/documentation/guides/distributed_deployment/

What about stability and fail-tolerance? Does it work after sudden reboot?

Yes. If running in cluster mode with multiple replicas, nodes will repair themselves automatically.

(...) does it mean that Qdrant keeps all indices in RAM and from time to time flushes it on the disk?

That depends on your configuration. By default, all is stored in RAM and periodically flushed to disk. Note that new updates are directly written to a WAL to recover in case of an unexpected crash/reboot.

If using on_disk: true parameters, data is directly mapped into memory from disk. This also periodically forces a flush. See: https://qdrant.tech/documentation/concepts/storage/#configuring-memmap-storage

[Andrew-MK]

Could you elaborate on your use case, why would you like to use Qdrant without any persistence?

I need a very fast temporary database of about 2500000 vectors with the possibility of real time searching and indexing by new vectors in the stream. I was attracted by a benchmark, according to which a qdrant is 5x+ faster than redis (1000 qdrant rps vs 171 redis rps with same accuracy):

I have enough RAM for storing these vectors, but during the operation of the qdrant, a very slow 7200 HDD disk is 100% utilized, which reduces perfomance to about 30 RPS. I don't know how the results of the benchmark were obtained, but this article describes how great the degradation of performance due to the disk and the disk is really a problem in my case - therefore, I am interested in how to use a qdrant without it and how the redis turned out to be so slower, given that the redis works at RAM speeds without disk utilization, and the qdrant constantly uses the disk to record the WAL and persistance.

[generall]

but during the operation of the qdrant, a very slow 7200 HDD disk is 100% utilized

By default, qdrant utilizes disk only during data insertion. Unless you configured mmaps or on-disk params, it should not touch disk during the search.

[martinenkoEduard]

Can qdrant work in a distributed cluster mode?

Yes. See: https://qdrant.tech/documentation/guides/distributed_deployment/

What about stability and fail-tolerance? Does it work after sudden reboot?

Yes. If running in cluster mode with multiple replicas, nodes will repair themselves automatically.

(...) does it mean that Qdrant keeps all indices in RAM and from time to time flushes it on the disk?

That depends on your configuration. By default, all is stored in RAM and periodically flushed to disk. Note that new updates are directly written to a WAL to recover in case of an unexpected crash/reboot.

If using on_disk: true parameters, data is directly mapped into memory from disk. This also periodically forces a flush. See: https://qdrant.tech/documentation/concepts/storage/#configuring-memmap-storage

But is it possible to have only one replica on each node (without fault tolerance) but spread the data across different nodes? (so I have 500GB of data, but every PC has only 100GB RAM.)

[generall]

But is it possible to have only one replica on each node (without fault tolerance) but spread the data across different nodes? (so I have 500GB of data, but every PC has only 100GB RAM.)

yes, that is what sharding does