We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
There was an error while loading. Please reload this page.
1 parent f700125 commit 1bc473dCopy full SHA for 1bc473d
images/one-vs-many-files.png
68.2 KB
sections/cloud-scale-data.qmd
@@ -670,16 +670,7 @@ resembles a traditional Zarr store (many addressable pieces as separate
670
files). This highlights two different approaches that you've encountered
671
in this courses:
672
673
-```{mermaid}
674
-flowchart LR
675
- A["Keep data in one file, but make
676
- it so that clients can efficiently
677
- extract subsets of interest"]
678
- <-->
679
- B["Separate data into many
680
- independent files, with metadata
681
- binding them together"];
682
-```
+{fig-align="center" width="90%"}
683
684
Which is better? The likely answer is ... both! Indeed, the community
685
seems to be converging on a hybrid model whereby we use a combination of
0 commit comments