Are long queries better than short queries?

Trying to understand if there are any fundamental difference between short queries and long queries. I am interested only in term of running Aerospike in-memory only.

  1. What is the difference between long queries and short queries? I understand that they are separated by the query-threshold option. But I want to know if there are any other difference. Are there any query optimization, IO optimization, bottleneck or throttling, any under the hood difference between long and short queries?
  2. Say if I have a record histogram of [40, 40, 10, 5, 1 … etc], does it mean I should change my query-threshold to 2 such that approximately 50% of my workloads are divided between long and short queries?
  3. Does high query-worker-threads affect query performance or just IO? and if so by how much? How should we determine how much query-worker-threads to allocate? Is it just bounded by how much memory we have?
  4. What is query-in-transactions-threads exactly. Does enabling it provides additional set of threads to help during queries? Or is it actually a replacement of existing query threads. Why should it be turned on? And what changes should we observe if we turn it on?

Appreciate for any insights. Cheers

My understanding is that for longer queries, they get offloaded to a different thread, but I am not sure.

The query-in-transaction-threads (which is technically query in service threads as of version 4.8) would process the query on those threads themselves and should be used only for in-memory namespaces and for queries that shouldn’t be too large (otherwise, one could starve those threads which would impact any other transaction…).

In general, a lot of such questions get answered with ‘best thing is to test and measure as it depends on such a large variety of factors…’

© 2015 Copyright Aerospike, Inc. | All rights reserved. Creators of the Aerospike Database.