14 Flashcards
(9 cards)
Distributed shared memory
El objetivo de esta herramienta es brindar la ilusión de una memoria compartida centralizada. Para el desarrollo de sistemas distribuidos es muy intuitivo, ya que los algoritmos no distribuidos pueden ser traducidos fácilmente y la información puede ser compartida entre sin que estos requieran conocerse. Por otro lado, esto desalienta la distribución, genera latencia, cuellos de botella y puntos únicos de falla.
enfoques para implementar DSM
naive, enfoque de migración, enfoque de replicación de páginas de memoria para solo lectura y enfoque de replicación de páginas de memoria para lectura y escritura.
enfoque naive
El enfoque naive consiste en mantener información en la memoria del servidor, a la que los clientes pueden acceder mediante requests. La exclusión mutua queda garantizada mediante la serialización de las requests por parte del servidor. Esto mismo es lo que hace que la performance sea baja.
enfoque de migración
El enfoque de migración de páginas de memoria consiste en delegar la información almacenada a los clientes, quienes pueden optimizar la localidad de acceso pidiendo una página de memoria prestada. Otros clientes pueden pedir la misma página y quedar bloqueados, salvo que se permita una sub-delegación. Esto garantiza la consistencia, ya que no se accede concurrentemente a las páginas.
enfoque de replicación de páginas de memoria para solo lectura
El enfoque de replicación de páginas de memoria para solo lectura favorece los escenarios con muchas lecturas y pocas escrituras. De esta manera, las escrituras son coordinadas por el servidor, y las lecturas implican una replicación de la página en modo read-only. El servidor invalida las réplicas frente a cambios.
enfoque de replicación de páginas de memoria para lectura y escritura.
En este último enfoque pero para el caso de lectura-escritura el servidor mantiene las páginas de memorias hasta que los clientes las requieran, en cuyo instante los clientes toman control total de las réplicas. El servidor se transforma así en un secuenciador de operaciones.
DFS
A la hora de diseñar un DFS es necesario que el acceso, localización, movilidad, performance, concurrencia y heterogeneidad del hardware sean asuntos que le resulten transparentes a los clientes.
HDFS
En el caso particular de HDFS, los fallos de hardware se consideran normales, por lo que es más económico adaptarse que defenderse.
Utiliza TCP entre servidor y RPC con los clientes.
Respecto de la performance, favorece las lecturas por sobre las escrituras (implementa la política write-once-read-many).
La arquitectura está compuesta por dos tipos de nodos: los name nodes, que contienen toda la metadata de los archivos, y los data nodes, que contienen los archivos en sí. Los archivos se particionan en bloques de 128Mb que son replicados en distintos data nodes.
Assumptions and Goals
Hardware Failure
Hardware failure is the norm rather than the exception. An HDFS instance may consist of hundreds or thousands of server machines, each storing part of the file system’s data. The fact that there are a huge number of components and that each component has a non-trivial probability of failure means that some component of HDFS is always non-functional. Therefore, detection of faults and quick, automatic recovery from them is a core architectural goal of HDFS.
Streaming Data Access
Applications that run on HDFS need streaming access to their data sets. They are not general purpose applications that typically run on general purpose file systems. HDFS is designed more for batch processing rather than interactive use by users. The emphasis is on high throughput of data access rather than low latency of data access. POSIX imposes many hard requirements that are not needed for applications that are targeted for HDFS. POSIX semantics in a few key areas has been traded to increase data throughput rates.
Large Data Sets
Applications that run on HDFS have large data sets. A typical file in HDFS is gigabytes to terabytes in size. Thus, HDFS is tuned to support large files. It should provide high aggregate data bandwidth and scale to hundreds of nodes in a single cluster. It should support tens of millions of files in a single instance.
Simple Coherency Model
HDFS applications need a write-once-read-many access model for files. A file once created, written, and closed need not be changed except for appends and truncates. Appending the content to the end of the files is supported but cannot be updated at arbitrary point. This assumption simplifies data coherency issues and enables high throughput data access. A MapReduce application or a web crawler application fits perfectly with this model.
“Moving Computation is Cheaper than Moving Data”
A computation requested by an application is much more efficient if it is executed near the data it operates on. This is especially true when the size of the data set is huge. This minimizes network congestion and increases the overall throughput of the system. The assumption is that it is often better to migrate the computation closer to where the data is located rather than moving the data to where the application is running. HDFS provides interfaces for applications to move themselves closer to where the data is located.
Portability Across Heterogeneous Hardware and Software Platforms
HDFS has been designed to be easily portable from one platform to another. This facilitates widespread adoption of HDFS as a platform of choice for a large set of applications.
Big Table
Solamente almacena pares clave-datos, donde los datos son en realidad un cjto. de valores o columnas. Al tratarse de conjuntos dispersos, los valores no se almacenan en un orden definido, sino que conocen su column family. A un conjunto de filas consecutivas de acuerdo a la clave se las llama Tablets, y son la unidad de balanceo de BigTable, y por lo tanto lo que permite escalar el sistema. En la jerarquía solamente puede haber 3 niveles de tablets (similar a árboles B+).
