> For the complete documentation index, see [llms.txt](https://thryec.gitbook.io/dev-compedium/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://thryec.gitbook.io/dev-compedium/near/collections.md).

# Collections

* When deciding on data structures to use for the data of the application, it is important to minimize the amount of data read and written to storage but also the amount of data serialized and deserialized to minimize the cost of transactions.
* The collections within `near-sdk` are designed to split the data into chunks and defer reading and writing to the store until needed. These data structures will handle the low-level storage interactions and aim to have a similar API to the [`std::collections`](https://doc.rust-lang.org/std/collections/index.html).
* When using `std::collections`, each time state is loaded, all entries in the data structure will be read eagerly from storage and deserialized. This will come at a large cost for any non-trivial amount of data.&#x20;

#### Existing Data Structures&#x20;

<table data-header-hidden><thead><tr><th width="166.33333333333334"></th><th width="138"></th><th></th></tr></thead><tbody><tr><td>SDK collection</td><td><code>std</code> equivalent</td><td>Description</td></tr><tr><td><code>LazyOption&#x3C;T></code></td><td><code>Option&#x3C;T></code></td><td>Optional value in storage. This value will only be read from storage when interacted with. This value will be <code>Some&#x3C;T></code> when the value is saved in storage, and <code>None</code> if the value at the prefix does not exist.</td></tr><tr><td><code>Vector&#x3C;T></code></td><td><code>Vec&#x3C;T></code></td><td>A growable array type. The values are sharded in memory and can be used for iterable and indexable values that are dynamically sized.</td></tr><tr><td><code>LookupMap&#x3C;K, V></code></td><td><code>HashMap&#x3C;K, V></code></td><td>This structure behaves as a thin wrapper around the key-value storage available to contracts. This structure does not contain any metadata about the elements in the map, so it is not iterable.</td></tr><tr><td><code>UnorderedMap&#x3C;K, V></code></td><td><code>HashMap&#x3C;K, V></code></td><td>Similar to <code>LookupMap</code>, except that it stores additional data to be able to iterate through elements in the data structure.</td></tr><tr><td><code>TreeMap&#x3C;K, V></code></td><td><code>BTreeMap&#x3C;K, V></code></td><td>An ordered equivalent of <code>UnorderedMap</code>. The underlying implementation is based on an <a href="https://en.wikipedia.org/wiki/AVL_tree">AVL tree</a>. This structure should be used when a consistent order is needed or accessing the min/max keys is needed.</td></tr><tr><td><code>LookupSet&#x3C;T></code></td><td><code>HashSet&#x3C;T></code></td><td>A set, which is similar to <code>LookupMap</code> but without storing values, can be used for checking the unique existence of values. This structure is not iterable and can only be used for lookups.</td></tr><tr><td><code>UnorderedSet&#x3C;T></code></td><td><code>HashSet&#x3C;T></code></td><td>An iterable equivalent of <code>LookupSet</code> which stores additional metadata for the elements contained in the set.</td></tr></tbody></table>

{% embed url="<https://docs.rs/near-sdk/latest/near_sdk/collections/index.html>" %}

####
