Skip to content

Commit cc7f363

Browse files
authored
Merge pull request #163 from scalableminds/ZEP0001-apply-storage-transformer-feedback-main
ZEP1: Apply review feedback for terminology section
2 parents 2af973a + 2ca025e commit cc7f363

File tree

3 files changed

+53
-32
lines changed

3 files changed

+53
-32
lines changed
416 KB
Loading
135 KB
Loading

docs/core/v3.0.rst

Lines changed: 53 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -219,6 +219,13 @@ Concepts and terminology
219219
This section introduces and defines some key terms and explains the
220220
conceptual model underpinning the Zarr format.
221221

222+
The following figure illustrates the first part of the terminology:
223+
224+
..
225+
The following image was produced with https://excalidraw.com/
226+
and can be loaded there, as the source is embedded in the png.
227+
.. image:: terminology-hierarchy.excalidraw.png
228+
222229
.. _hierarchy:
223230

224231
*Hierarchy*
@@ -358,6 +365,44 @@ conceptual model underpinning the Zarr format.
358365
ordering of elements_, but extensions may define other
359366
memory layouts.
360367

368+
.. _metadata document:
369+
.. _metadata documents:
370+
371+
*Metadata document*
372+
373+
Each array_ in a hierarchy_ is represented by a metadata document,
374+
which is a machine-readable document containing essential
375+
processing information about the node. For example, an array_
376+
metadata document will specify the number of dimensions_, shape_,
377+
`data type`_, grid_, `memory layout`_ and codec_ for that
378+
array_.
379+
380+
Groups can have an optional metadata document which provides extra
381+
information about a group.
382+
383+
.. _store:
384+
.. _stores:
385+
386+
*Store*
387+
388+
The `metadata documents`_ and encoded chunk_ data for all nodes in a
389+
hierarchy_ are held in a store as raw bytes. To enable a variety
390+
of different store types to be used, this specification defines an
391+
`Abstract store interface`_ which is a common set of operations that stores
392+
may provide. For example, a directory in a file system can be a zarr store,
393+
where keys are file names, values are file contents, and files can be read,
394+
written, listed or deleted via the operating system. Equally, an S3 bucket
395+
can provide this interface, where keys are resource names, values are
396+
resource contents, and resources can be read, written or deleted via HTTP.
397+
398+
The following figure illustrates the codec, store and storage transformer
399+
terminology for a use case of reading from an array:
400+
401+
..
402+
The following image was produced with https://excalidraw.com/
403+
and can be loaded there, as the source is embedded in the png.
404+
.. image:: terminology-read.excalidraw.png
405+
361406
.. _codec:
362407
.. _codecs:
363408

@@ -394,43 +439,19 @@ conceptual model underpinning the Zarr format.
394439
decoded input of codec ``i+1``, and similarly when decoding, the decoded
395440
output of codec ``i+1`` serves as the encoded input to codec ``i``.
396441

397-
.. _metadata document:
398-
.. _metadata documents:
399-
400-
*Metadata document*
401-
402-
Each array_ in a hierarchy_ is represented by a metadata document,
403-
which is a machine-readable document containing essential
404-
processing information about the node. For example, an array_
405-
metadata document will specify the number of dimensions_, shape_,
406-
`data type`_, grid_, `memory layout`_ and codec_ for that
407-
array_.
408-
409-
Groups can have a optional metadata document which provide extra
410-
information about a group.
411-
412-
.. _store:
413-
.. _stores:
414-
415-
*Store*
416-
417-
The `metadata documents`_ and encoded chunk_ data for all nodes in
418-
a hierarchy_ are held in a store. To enable a variety of different
419-
store types to be used, this specification defines an `Abstract store
420-
interface`_ which is a common set of operations that stores may
421-
provide.
422-
423442
.. _storage transformer:
424443
.. _storage transformers:
425444

426445
*Storage transformer*
427446

428-
To enhance the storage capabilities, storage transformers may
429-
change the storage structure and behaviour of data coming from
430-
an array_ in the underlying store_. Upon retrieval the original data
431-
is restored within the transformer. Any number of `predefined storage
432-
transformers`_ can be registered and stacked.
433-
See the `storage transformers details`_ below.
447+
To provide performance enhancements or other optimizations,
448+
storage transformers may intercept and alter the storage keys and bytes
449+
of an array_ before they reach the underlying physical storage.
450+
Upon retrieval, the original keys and bytes are restored within the
451+
transformer. Any number of `predefined storage transformers`_ can be
452+
registered and stacked. In contrast to codecs, strorage transformers can
453+
act on the a complete array, rather than individual chunks. See the
454+
`storage transformers details`_ below.
434455

435456
.. _`storage transformers details`: #storage-transformers-1
436457

0 commit comments

Comments
 (0)