Consider adding some sanity check to ensure the benchmark queries are actually succeeding

[leoger]

As mentioned in PR #7, it would be good to introduce some safety check that could add some confidence that the generated data store, populated with random data, is in fact not some degenerate case or silently behaving as a no-op.

Ideas:

• In addition to a the existing inquireNitrite invocation that just searches for one random value, we could run an "analytical workload benchmark" that calculates the average of all of the "index1" values in the repository. (And then we assert that this average is non-zero?)
• Instead of truly random data each time, maybe use a known seed for Random, and then we'd be able to assert some specific values.
• Instead of inquireNitrite searching for entries in the repository where("index1").eq(RANDOM.nextInt()).and(where("number1").eq(RANDOM.nextDouble()), which would almost always return 0 documents, we can select some values that are known to be present. Otherwise, this is a very strange benchmark that is simulating a workload for applications that are always looking for records that are not present. This could hide a lot of areas for performance improvement because large portions of the Nitrite code would never even be invoked. (e.g. conversion from Document to entity object!)
  • NOTE: to ensure I wasn't misinterpreting the code and misunderstanding the behavior, I added a simple println debugging statement. I have confirmed that no records are returned.

    > inquireNitrite found 0 records
    > inquireNitrite found 0 records
    ...
    > inquireNitrite found 0 records
    > inquireNitrite found 0 records
    > inquireNitrite found 0 records
      0.015 ms/op
    

[anidotnet]

It's great idea. These checks should have been there in the first place. Would you mind working on it if you have some time? Otherwise, I'll work on it once I have some time.

[leoger]

I've got some changes coming to make a minimal adjustment to the current benchmark workload and get what I think are more useful numbers. (e.g. constraining "index1" values to increase the chance of hits)

I jumped over to this work from the spatial index stuff because I wanted to see if I could reproduce a performance bottleneck I'm seeing in my real-life Nitrite usage with a simpler case in JMH. Since I'm already in there fiddling with things, I'll gladly add that check.