A Full Table Scan of Indexing in NoSQL by Will LaForest (MongoDB).
One slide reads:
What Indexes Can Help Us Do
- Find the “location” of data
- Based upon a value
- Based upon a range
- Geospatial
- Fast checks for existence
- Uniqueness enforcement
- Sorting
- Aggregation
- Usually covering indexes
The next slide is titled: “Requisite Book Analogy” with an image of a couple of pages from an index.
So, let’s copy out some of those entries and see where they fit into Will’s scheme:
Bears, 75, 223
Beds, good, their moral influence, 184, 186
Bees, stationary civilisation of, 195
Beethoven on Handel, 18
Beginners in art, how to treat them, 195
The entry for Bears I think qualifies for “location of data based on a value.
And I see sorting, but those two are the only aspects of Will’s indexing that I see.
Do you see more?
What I do see is that the index is expressing relationships between subjects (“Beethoven on Handel”) and commenting on what information awaits a reader (“Beds, good, their moral influence”).
A NoSQL index could replicate the strings of these entries but without the richness of this index.
For example, consider the entry:
Aurora Borealis like pedal notes in Handel’s bass, 83
One expects that the entry on Handel to contain that reference as well as the one of “Beethoven on Handel.” (I have only the two pages in this image and as far as I know, I haven’t seen this particular index before.)
Question: How would you use the indexes in MongoDB to represent the richness of these two pages?
Question: Where did MongoDB (or other NoSQL) indexing fail?
Important to remember that indexes prior to the auto-generated shallowness of recent decades were highly skilled acts of authorship, that were a value-add for readers.