> If you partition across full repository instances as described, you have set > yourself one set of scaling problems. If you instead partition your storage > layers (Low Level Store, RI, SQL DB, etc.) and provide one Fedora web > application (one suite of web services) over them, you can set yourself a > different set of scaling problems. We chose the latter for local reasons, but > it's worth noting that you can make that choice (and several others along the > same lines).
Good way to put it. One of the hopes I had for HighLevelStorage (and the necessary architectural cleanups around it) was that it would make the latter easier, and make it at least theoretically possible to have an arbitrary number of fedora servers configured to operate against a shared set of partitioned storage/index layers. The original HBase proof of concept was looking at the latter. > If I'm not mistaken, NSDL was at one time almost the "canonical" example of a > scaled-out repository infrastructure, although I do not know if that is still > the case. Not any more. They changed their collections policy, and moved toward a small set of highly curated resources. This was a response to re-focusing their mission, and not technical constraints. -Aaron ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
