Title

UUID's: Object Mobility and Merging Stores

Primary ActorDeveloper / Repository Manager
ScopeTechnical
Levelpretty high
Story

Internal identifers should really be UUID's - as used by a number of highly scalable filesystems. The high uniqueness of this identifier even when issued at multiple locations permits several key operations when considering the long term evolution of an object store.

  • An object can be moved to a new store with its identifier intact and not risk a collision with an object in the new store
  • Stores can be merged between Fedora's without object collisions provided they are distributed using UUID's (useful when a repository is orphaned and needs to be absorbed by another)
  • UUID's distribute files evenly across a filesystem - this allows Sun's billion/trillion file approach of nested NFS mounts to evenly utilised for a massive single node store
    • This also works well for a SAM-QFS hierarchical file store which presents a single filesystem image (other similar HSM solutions exist!)
  • It potentially allows multiple Fedora instances to co-exist on a single filesystem with a relatively simple interlocking implementation
    • Also see above
  • UUID's resolve well just by entering them into a search engine - with no URL/URI needed 
      

 

1 Comment

  1. David Wilcox

    Nodes in the repository do have UUIDs, but we probably need a distinct use case for merging two Fedora repositories together and how that would work in practice. Neil Jefferies, perhaps you can provide this use case?

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.