zarr v2 metadata access pattern for getitem

[ilan-gold]

At the moment there is something like

zarr-python/src/zarr/core/group.py

Lines 688 to 692 in 40da497

	zgroup_bytes, zarray_bytes, zattrs_bytes = await asyncio.gather(
	(store_path / ZGROUP_JSON).get(),
	(store_path / ZARRAY_JSON).get(),
	(store_path / ZATTRS_JSON).get(),
	)

to check for zarr v2 nodes. Would it be better to do attrs first and then the others? Do we think there is minimal overhead to doing all at once? I ask because previously, doing something like g["foo"] would only access .zarray if foo was a group and I'm looking to do the least fetching of data possible. Or maybe groups should be given precedence? I'm not sure how this used to work - I don't think I ever checked whether fetching group accessed .zarray previously.

[d-v-b]

To your first question, .zattrs is not required, so we probably don't want to fetch that first. The spec also doesn't actually say what to do if .zgroup and .zarray are present 🤡. We and every other zarr implementation are going beyond the spec by making arrays and groups exclusive objects. In zarr-python right now we take .zarray first, and then .zgroup if .zarray is not there.

To the broader point, I think our strategy depends on how much we value latency against the cost of wasted requests.

Breaking this down into cases (I will refer to "failure" in these examples; that means "the metadata did not exist", not a network error or something):

• status quo: we pre-fetch everything in a batch; latency for the batch is determined by the slowest of the 3 requests. If there's no .zgroup or .zarray, then we wasted 3 requests. If we find a .zarray / .zgroup, then we wasted 1 request (unless we feel the need to tell the user that their hierarchy is weird because it contains both .zarray and .zgroup). Assuming that most of the time we are checking arrays / groups that actually exist, we should expect to waste 1 / 3 of our requests here.
• avoid spurious requests: we first fetch .zarray; if that succeeds, we fetch .zattrs. If that fails, we fetch .zgroup, and if that succeeds we fetch .zattrs. Latency here is the sum of the latencies of two requests for an array, and the sum of the latencies for three requests for a group. If neither an array or group are there, we just made 2 requests. We waste no requests, but we wait longer.
• make speculative requests, and cancel them when we don't need the result: we request all 3 documents, but not in a batch. Instead we poll for a resolved .zarray request. if it succeeded, we cancel the .zgroup request and wait for the .zattrs request to complete. If .zarray failed, we wait for a resolved .zgroup request, and if that succeeds we wait for the .zattrs request to complete. If both .zgroup and .zarray failed, then we cancel the .zattrs request. In this case, latency is based on the slowest of two requests, which is an improvement over the status quo. This is probably what we should do.