# Performance and storage of the dense\_vector type

**URL:** https://discuss.elastic.co/t/performance-and-storage-of-the-dense-vector-type/265850
**Category:** Elasticsearch
**Created:** [March 1, 2021, 7:20pm UTC](https://discuss.elastic.co/t/performance-and-storage-of-the-dense-vector-type/265850 "2021-03-01T19:20:27Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![Jacek\_Wolkowicz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jacek_wolkowicz/32/84744_2.png) [@Jacek\_Wolkowicz](https://discuss.elastic.co/u/Jacek_Wolkowicz)
#### Post date: [March 1, 2021, 7:20pm UTC](https://discuss.elastic.co/t/performance-and-storage-of-the-dense-vector-type/265850/1 "2021-03-01T19:20:27Z")

</div>

While testing the dense\_vector type for 'indexing' of deep n-n embeddings, I came up with a very confusing outcome.

I have been testing the impact and performance of the following part of the mapping:

```auto
{ ...
   'embedding_raw': {'type': 'dense_vector', 'dims': 512},
}

```

According to the documntation:

> **[Dense vector field type | Elasticsearch Reference \[7.11\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/dense-vector.html)**

```auto
Internally, each document’s dense vector is encoded as a binary doc value. Its size in bytes is equal to 4 * dims + 4, where dims—the number of the vector’s dimensions.

```

So internally that would mean that each vector is stored as a packed list of float32 types, expecting 2kB per vector.

Then I proceeded to test them with 10k sample documents. Vector values were real data (not randomly generated) yet random enough for the machine, zero centered, mostly `-1<x<1`.  
With that the you would expect the index to take about 20MB, however it took more than 100MB.

So I started testing inserting various values for the vectors, all are vectors of 512 elements, indicating the index size after ingestion:

- `[]` (nothing, control) by removing the dense\_vector field and only adding other meta-data: 1.5MB
- `[0 for range(512)]` : 5.6MB
- `[0.5 for range(512)]`: 5.6MB  
Then I thought maybe vectors are stored plain-text, not as binary data
- `[e/pi for range(512)]`: 5.7MB  
Doesn't seem like, so I started to feed actual vector data
- `[round(x,1) for x in data]`: 24.6MB
- `[round(x,2) for x in data]`: 31.6MB
- `[round(x,4) for x in data]`: 42MB
- `[float(round(4*x))/4.0 for x in data]`: 6MB (mostly 0'es)
- `[sign(x) for x in data]`: 18MB
- `[x for x in data]`: 102MB

What confused me is that the documents indexed this way take significantly more space when you provide more precision. If they are really stored as binary data, then the rest needs to be the spatial indices to speed up brute force nearest neighbour search, yet according to the documentation, the only use for dense vectors is rescore them with script\_score, which by definition cannot use indices.

Is there any 'clever' spatial indexing going on in the background for search? How to use it with scoring? Or maybe unlike the documentation, documents are just stored plain text and dense\_vectors is just a waste of space?  
According to this:

> <https://github.com/elastic/elasticsearch/issues/42326>
>
> ann (approximate nearest neighbours) will be a licensed feature of Elasticsearch (not OSS).
> We plan to implement prototypes of various algorithms for...

There is work done on this topic as we speak, and if dense vectors are indeed building some sort of a spatial index that would explain increasing space needed for the documents, yet documentation still only provides examples of brute-force search using scripts.

Any insights about that would be greatly appreciate.

---

<div class="post-metadata">

### Author: ![Jacek\_Wolkowicz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jacek_wolkowicz/32/84744_2.png) [@Jacek\_Wolkowicz](https://discuss.elastic.co/u/Jacek_Wolkowicz)
#### Post date: [March 2, 2021, 4:56pm UTC](https://discuss.elastic.co/t/performance-and-storage-of-the-dense-vector-type/265850/2 "2021-03-02T16:56:56Z")

</div>

Anyone had some experience with dense vectors and their behaviour?

---

<div class="post-metadata">

### Author: ![mayya](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mayya/32/83147_2.png) [@mayya](https://discuss.elastic.co/u/mayya)
#### Post date: [March 25, 2021, 8:20pm UTC](https://discuss.elastic.co/t/performance-and-storage-of-the-dense-vector-type/265850/3 "2021-03-25T20:20:53Z")

</div>

@Jacek_Wolkowicz Sorry for a late reply, I hope it could still be useful.

We do store a dense\_vector as binary doc value with size `4*dims+4` . But this is size before compression. When we store document values on disk, we compress them. And compressed size depends on actual data (where repeated data can be compressed much better).

We've removed this statement about size from our documentation in later versions so not to confuse users.

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)
#### Post date: [April 22, 2021, 8:21pm UTC](https://discuss.elastic.co/t/performance-and-storage-of-the-dense-vector-type/265850/4 "2021-04-22T20:21:23Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.