Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The <code>get_keys()</code> function calls <code>list_keys</code> in the back end and is considered to be an expensive operation because it performs a full scan of the key space. Depending on your Riak back end, this could also involve a full scan of the data as stored on disk (InnoStore springs to mind). The default storage back end (Bitcask) stores all of your keys in memory, so performance shouldn't be as much of a problem.</p> <p>The other reason <code>list_keys</code> was considered expensive is because it was formerly a blocking operation as it involved what the Basho developers refer to as a 'fold' over all of the keys. <code>list_keys</code> now uses a snapshot of the bucket (instead of reading the live key space) and this makes it a lighter weight operation as well.</p> <p>This is made easier with an upgrade to Riak 1.0. If you're using the LevelDB back end, you can enable secondary indexes on a bucket and use the <code>$key</code> index (automatically provided by Riak) to get you a list of all keys in a bucket.</p> <p>As for why Riak doesn't ship with a better implementation of something like this: ask what the functionality is for. In an RDBMS, getting all primary keys of a table involves a full table scan. In Riak, getting all keys from a bucket requires scanning all data in every node and then shipping the key names back to the originating node, combining that data, and then sending it to the calling client. Because of Riak's distributed, unordered, state this operation is expensive no matter how you slice it. There are, as I outlined above, ways to make it better.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload