Record Size Limit in Memory Mode


Is there any limit to record size with data in memory mode ? What if data is stored in ram as well as disk ?


Record size limit comes from write-block-size (1 Mb max, including all overhead) which applies to persistent storage, raw blocks on SSD or file based storage on HDD. If you store records purely in RAM then you are limited only by the various buffers in the food chain from client to Aerospike. If you do storage on disk with data in memory also, the 1MB limitation will apply.


I also observed that with data in memory mode as the size of a map object increases, write into map(insert/update) slows down. I was not expecting this with data in memory mode. What can be the reason for this ?


any update is full rewrite. so with map type bin, if you are inserting new key-value pairs in the map, entire record has to be re-written to a new location. there is no in-situ modification. entire record is stored contiguously in memory.

  1. Is this storage-engine memory or storage-engine device with data-in-memory true?
  2. What is the replication factor for the namespace?


I think prior to 3.8.3 sorted maps, maps were serialized using msg_pack. Storage space difference between bins and maps - i think they are still serialized with msg_pack but added info is added for key/index based sorting. Since msg_pack offers compaction, I would think any change will be a full rewrite regardless of storage being memory or disk. So I would think it is a full rewrite - but perhaps kporter may shed more light on the topic.


You are doing add() operations. Refer to the performance table in the map documentation (link above). Your performance is likely dominated by O(N) for unsorted map types and O(log N) for sorted.

There are a number of O(1) operations in the table. Those are still affected by the record size because "Every modify op has a +C for copy on write for allowing rollback on failure." memcpy performance should scale linearly with size, but it is orders of magnitude smaller than the map traversing operations performance.


I am referring to storage-engine memory only. Replication factor is 2.

Basically I am trying to compare this with hset of redis where hset can be as big as 100MB to 1GB. Can such a record be kept as single record (map) in aerospike with similar performance or it is not feasible for such type of records ?


Strictly speaking …100MB yes, 1 GB No.