Search code examples
aerospikenosql

Aerospike : Delete all bins


I am trying to delete bins from my set.
The thing is when I delete them, they are still shown in

aql> show bins
+-------+------------------+-------+-----------+
| quota | bin              | count | namespace |
+-------+------------------+-------+-----------+
| 32768 | "family"         | 14    | "test"    |
| 32768 | "querybinstring" | 14    | "test"    |
| 32768 | "querybinint"    | 14    | "test"    |
| 32768 | "binstringfoo"   | 14    | "test"    |
+-------+------------------+-------+-----------+

though the data has been deleted from the set.

aql> select * from test.testset
0 rows in set (0.000 secs)

The issue arises when my binNames reaches 32k limit of unique binNames constraint.
I have to restart aerospike for the deleted bin names to be really gone.

So is there any other way than to restart after deleting bins ?
What really happens when aerospike is restarted ? (which deletes the deleted [marked as deleted] bins )

Note : I have tested this by deleting the bins using

  1. client.delete()
  2. set expiration

One more question - Is there any way I can delete all bins from a set through aql ?


Solution

    • Methods to Delete meta data in Aerospike

    Take a look at this discussion forum for a good list of methods to delete meta data of bins in Aerospike.

    https://discuss.aerospike.com/t/bin-names-deletion/731

    • Deleting Bin from AQL

    You can delete a bin using AQL by setting it to NULL

    E.g: Insert into namespace.set (PK, bin) values ('1', NULL) will delete bins from records with primary key '1'

    • Understanding Deletion in general

    Aerospike separates the data into two parts: index and value. The index is always stored in DRAM, the value can be stored in either SSD or DRAM (with or without disk for persistence). When a record is deleted, the reference to it is removed from the index. The actual data is not removed from the disk. Another process will find that the data on disk is not being used and reclaim the space.

    Note that it is possible for deleted object to reappear. For this to happen the following has to occur:

    The node must be configured to load data from disk. And if data has been deleted, but not yet removed from disk. (i.e. the index entry has been removed). In this case when the node starts, it will read the data from disk and rebuild the index. Because the data has not been removed from disk, the node will think it is still active and build a new index entry for it. So the deleted object will return. If you know you will be taking down a node, you can prevent deleted data from returning by using the fast restart feature. This will hold the index in memory even when the database process has gone down.

    Another option in newer releases is by using 'cold-start-empty' configuration which prevents data to be loaded from disk, but only by migration from other nodes in the cluster.

    More information here: http://www.aerospike.com/docs/reference/configuration/#cold-start-empty