NEST非精确数据计数获取方法及与DSL地理距离查询计数不一致问题排查

Hey there! Let's tackle your two Elasticsearch/NEST questions one by one:

Let's break down what you need to know:

• Getting non-exact counts with NEST: If you don’t require a perfectly precise count (especially helpful for large indices where exact counts consume significant resources), you have a couple options:
  • Use the Search API with Size(0) and TrackTotalHits(false)—this returns an approximate count from hits.total.value once the result set exceeds 10,000 documents.
  • Run a Cardinality aggregation on a unique field (like _id) to get an estimated count of distinct documents.
    Note: The CountAsync method returns exact counts by default, so you’ll need to switch to these approaches for non-exact results.
• DSL query count types:
  • The _count API always returns an exact count by default.
  • For the _search API: By default, it returns exact counts for result sets ≤10,000. For larger sets, it returns an approximate count unless you explicitly set track_total_hits: true (this can be resource-heavy for very large indices).

First, let’s align the two queries we’re comparing:

Raw DSL _count request:

{ "query": { "bool": { "must": { "match_all": {} }, "filter": { "geo_distance": { "distance": "872.70344mi", "location": { "lat": 47.52, "lon": -121.87 } } } } }

NEST CountAsync method:

public async Task<long> GetEsDataCountByGeoDistanceAsync<T>(string indexName) where T : class 
{ 
    var searchResponse = await _elasticClient.CountAsync<T>(s => s 
        .Index(indexName) 
        .Query(q => q 
            .Bool(b => b 
                .Must(m => m 
                    .MatchAll()) 
                .Filter(f => f 
                    .GeoDistance(go => go 
                        .Distance("872.70344mi") 
                        .Location(47.52, -121.87)) ))) 
        ).ConfigureAwait(false); 
    return searchResponse.Count; 
}

Here are the most likely culprits for the massive 2237 vs 11093 count difference:

• Index targeting error: Double-check that the indexName passed to your NEST method is exactly design (and not a wildcard, alias pointing to multiple indices, or a different index entirely). It’s easy to accidentally target the wrong index here.
• Document type mismatch (legacy Elasticsearch versions): If you’re using Elasticsearch pre-7.x (where document types were allowed), your raw DSL might implicitly target a specific type, while the generic T in NEST could be mapping to a different type or all types in the index.
• Distance parsing inconsistency: While "mi" should be interpreted as miles in both cases, try replacing the string distance in NEST with a strongly typed value to eliminate parsing edge cases:

  .Distance(d => d.Miles(872.70344))
  

• Index refresh timing: If documents were being indexed between your two queries, one might have hit refreshed shards while the other didn’t. Add .Refresh(Refresh.WaitFor) to both queries to ensure they read the latest data:
  • In raw DSL: Add "refresh": "wait_for" to the request body.
  • In NEST: Chain .Refresh(Refresh.WaitFor) to the CountAsync configuration.
• Hidden query differences: The best way to confirm is to see exactly what JSON NEST is sending to Elasticsearch. Enable debug logging to capture the request:

  var settings = new ConnectionSettings(new Uri("http://your-es-instance:9200"))
      .EnableDebugMode()
      .OnRequestCompleted(response =>
      {
          if (response.RequestBodyInBytes != null)
          {
              Console.WriteLine(System.Text.Encoding.UTF8.GetString(response.RequestBodyInBytes));
          }
      });
  var _elasticClient = new ElasticClient(settings);
  

  Compare this logged JSON directly to your raw DSL—any discrepancy here will be the root cause.

内容的提问来源于stack exchange，提问作者abbas ahmed