DistOS 2015W Session 12: Difference between revisions

From Soma-notes
Shivjot (talk | contribs)
Shivjot (talk | contribs)
Line 3: Line 3:
* Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.
* Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.
*Main goals of Haystack:
*Main goals of Haystack:
** High throughput
** High throughput with low latency
**Fault tolerance
**Cost effective
**SImple
*Facebook utilises CDN to serve popular images and further uses haystack to respond to photo requests in the long tail effectively.
*Haystack reduces the memory used for ''filesystem metadata''
*It has 2 types of metadata:
**''Application metadata''
**''File System metadata''
* The architecture consists of 3 components:
**Haystack Store
**Haystack Directory
**Haystack Cache
*


=Comet=
=Comet=

Revision as of 02:52, 31 March 2015

Haystack

  • Facebook's Photo Application Storage System.
  • Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.
  • Main goals of Haystack:
    • High throughput with low latency
    • Fault tolerance
    • Cost effective
    • SImple
  • Facebook utilises CDN to serve popular images and further uses haystack to respond to photo requests in the long tail effectively.
  • Haystack reduces the memory used for filesystem metadata
  • It has 2 types of metadata:
    • Application metadata
    • File System metadata
  • The architecture consists of 3 components:
    • Haystack Store
    • Haystack Directory
    • Haystack Cache
*

Comet

  • Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.
  • Comet model works by offloading the computation intensive process from the mobile to only one server.
  • The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device.

F4

Sapphire

  • Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.
  • Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.
  • Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].