Clase 03: Arquitecturas de Sistemas Distribuidos

Los sistemas distribuidos son comnmente piezas complejas de software cuyos componentes
estn dispersos en mquinas mltiples! Si se desea tener control sobre esta complejidad" es
crucial que estos sistemas est#n apropiadamente or$anizados!
La or$anizaci%n de los sistemas distribuidos depende mayormente de los componentes
de software que constituyen al sistema! &stas arquitecturas de software establecen como son
or$anizados 'arios componentes del software y c%mo interactan entre ellos!
La implementaci%n de un sistema distribuido requiere de la di'isi%n e identificaci%n de
los componentes de software y su instalaci%n en mquinas reales! La implementaci%n e
instalaci%n final de la arquitectura de software se conoce como arquitectura de software!
Como se e(plic% con anterioridad" un objeti'o importante de los sistemas distribuidos es
separar las aplicaciones de las plataformas subyacentes mediante una capa de middleware! La
adopci%n de esta capa en una importante decisi%n arquitect%nica" y su principal objeti'o es
pro'eer una distribuci%n transparente de la aplicaci%n! La transparencia de la distribuci%n
implica en muc)os casos la necesidad de )acer ciertos sacrificios o concesiones" por lo que es
con'eniente que el middleware sea adaptable! &sta adaptabilidad tambi#n se puede lo$rar
permitiendo que el sistema monitoree su propio comportamiento y que tome las medidas
necesarias cuando se requiera! &stos sistemas distribuidos son or$anizados frecuentemente en
la forma de retroalimentaci%n de control!
3.1 Estilos Arquitectnicos
*ara iniciar la discusi%n sobre arquitecturas" se debe considerar en principio la or$anizaci%n de
sistemas distribuidos en componentes de software" tambi#n conocida como arquitectura de
software!
&l estilo arquitect%nico est formulado en t#rminos de componentes" la forma en que
estos componentes estn conectados unos con otros y los datos intercambiados entre ellos! +n
componente es una unidad modular con interfaces bien definidas" y que puede ser
reemplazado en el sistema!
,al 'ez un t#rmino ms complejo es el de conector" el cual $eneralmente es descrito
como un mecanismo que media la comunicaci%n" coordinaci%n o cooperaci%n entre
componentes! *or ejemplo" un conector puede implementarse mediante -*Cs" transferencia
de mensajes o flujos de datos!
&(isten 'arias confi$uraciones de componentes y conectores que definen el estilo
arquitect%nico de un sistema distribuido! Los estilos ms importantes son:
Arquitecturas en capas
Arquitecturas basadas en objetos
Arquitecturas centradas en datos
Arquitecturas basadas en eventos
Clase 03: Arquitecturas de Sistemas Distribuidos
La idea bsica tras el estilo arquitectnico en capas es simple: los componentes estn
or$anizados en forma de capas" en la que un componente en una determinada capa puede
llamar a componentes en la capa inmediata inferior! +na obser'aci%n cla'e es que el control
$eneralmente fluye de capa en capa: las peticiones 'an de arriba abajo y los resultados de
abajo a arriba" tal como se puede obser'ar en la Figura 3.1(a)!
+na or$anizaci%n" por muc)o ms suelta" se tiene en arquitecturas basadas en objetos"
tal como se muestra en la Figura 3.1(b)! &n esencia" cada objeto corresponde a lo que )emos
definido como componente" y estos componentes estn conectados mediante un mecanismo
-*C! .o es de sorprender que esta arquitectura de software se adapte al modelo cliente-
servidor que trataremos ms adelante!
Figura 3.1. /a0 estilo arquitect%nico en capas1 /b0 estilo arquitect%nico basado en objetos!
Las arquitecturas centradas en datos e'olucionan en torno a la idea de que los
procesos se comunican a tra'#s de un repositorio o medio comn" ya sea pasi'o o acti'o /'er
Figura 3.2 (a)0! *or ejemplo" una cantidad importante de aplicaciones distribuidas en las que la
comunicaci%n se establece por medio de un arc)i'o compartido a tra'#s de un sistema de
arc)i'os distribuidos!
&n las arquitecturas basadas en eventos" los procesos se comunican esencialmente por
medio de la propa$aci%n de e'entos" los cuales de manera opcional pueden lle'ar datos
consi$o" tal como se muestra en la Figura 3.2 (b)! 2eneralmente" en los sistemas distribuidos"
la propa$aci%n de e'entos se )a asociado con lo que se conoce como sistemas
publicar/subscribir /publish/subscribe systems0! La idea bsica es que los procesos publican
e'entos tras los cuales el middleware ase$ura que s%lo esos procesos que se subscribieron a
esos e'entos" los recibirn! La 'entaja principal de esta arquitectura es que los procesos estn
acoplados flojamente! &n principio" no se requiere una referencia e(pl3cita de proceso a
Clase 03: Arquitecturas de Sistemas Distribuidos
proceso! A esto se le conoce como desacoplamiento en el espacio o referencialmente
desacoplados!
Figura 3.2. /a0 arquitectura centrada en datos1 /b0 arquitectura basada en e'entos!
3.2 Arquitecturas de Sistemas
4a que se )a discutido bre'emente sobre al$unos estilos arquitectnicos comunes" se 'er
c%mo muc)os sistemas distribuidos estn or$anizados" considerando la manera en que sus
componentes de software fueron establecidos! &l determinar que componentes de software se
usarn" c%mo interactuarn y c%mo se distribuirn es lo que se conoce como una instancia de
arquitectura de software" tambi#n llamada arquitectura de sistema!
3.2.1. Arquitecturas Centralizadas
A pesar de las diferencias en cuanto a 'arios aspectos de los sistemas distribuidos" solo )ay un
aspecto en los que muc)os e(pertos coinciden: pensar en t#rminos de clientes que solicitan
ser'icios a servidores ayuda a entender y administrar la complejidad de los sistemas
distribuidos!
&n el modelo bsico cliente-servidor" los procesos en un sistema distribuido estn
di'ididos en dos $rupos" que posiblemente se traslapan! +n servidor es un proceso que
implemente un ser'icio espec3fico" por ejemplo" un ser'icio de sistema de arc)i'os distribuido o
de base de datos! +n cliente es un proceso que solicita un ser'icio a un ser'idor" en'indole
una petici%n y subsecuentemente esperando la respuesta del ser'idor! La interacci%n cliente-
servidor" tambi#n conocida como solicitud5respuesta" se muestra en la Figura 3.3!
Clase 03: Arquitecturas de Sistemas Distribuidos
Figura 3.3. 6nteracci%n $eneral entre un cliente y un ser'idor!
La comunicaci%n entre un cliente y un ser'idor puede ser implementada por medio de un
simple protocolo no orientado a la cone(i%n /sin cone(i%n0 cuando la red subyacente es
suficientemente confiable como es el caso de muc)as redes de rea local /LA.s0! &n estos
casos" cuando un cliente solicita un ser'icio" empaca simplemente el mensaje para el ser'idor"
identificando el ser'icio que requiere y ane(ando los datos de entrada necesarios! &l mensaje
es posteriormente en'iado al ser'idor! &l ser'idor se encuentra continuamente en espera de
recibir solicitudes" tras lo cual las procesa" empaqueta los resultados en un mensaje de
respuesta" y finalmente en'3a este mensaje al cliente!
Implementacin de aplicaciones en capas
&l modelo cliente5ser'idor )a sido sujeto de muc)os debates y contro'ersias a lo lar$o de los
a7os! +na de las principales cuestiones es el c%mo establecer una clara distinci%n entre un
cliente y un ser'idor! .o es de sorprender que en muc)as ocasiones esta distinci%n no es tan
clara! *or ejemplo" un ser'idor de una base de datos distribuida a tra'#s de la web puede
actuar continuamente como cliente porque #ste transfiere las solicitudes a 'arios ser'idores de
arc)i'os responsables de implementar las tablas de las bases de datos! &n este caso" el
ser'idor de base de datos por s3 mismo no )ace ms que procesar las solicitudes de bsqueda
o filtrado! La Figura 3.4 muestra este caso!
Clase 03: Arquitecturas de Sistemas Distribuidos
Figura 3.4. &jemplo de ser'idor actuando como cliente!
Sin embar$o" considerando que muc)as aplicaciones cliente5ser'idor estn orientadas
a facilitar al usuario el acceso a la base de datos" muc)a $ente )a establecido una distinci%n
entre los tres ni'eles si$uientes" esencialmente usando el estilo arquitectnico en capas que se
'io pre'iamente:
8! El nivel de interfaz de usuario!
9! El nivel de procesamiento!
3! El nivel de datos!
&l nivel de interfaz de usuario contiene todo lo necesario para establecer una interfaz directa
con el usuario" tal como la administraci%n del desplie$ue de la informaci%n! &l nivel de
procesamiento t3picamente contiene las aplicaciones! &l nivel de datos administra los datos
sobre los cuales se est trabajando!
Los clientes normalmente implementan el nivel de interfaz de usuario! &ste ni'el
consiste de los pro$ramas que permiten al usuario final interactuar con las aplicaciones! :ay
una diferencia considerable en que tan sofisticada puede ser una interfaz de usuario! La ms
simple no es ms que una simple pantalla de caracteres!
Como ejemplo consid#rese un motor de bsqueda en 6nternet! La interfaz es muy
simple: un usuario introduce una cadena de palabras cla'es y subsecuentemente se le
presenta una lista de t3tulos de p$inas web! &l e(tremo opuesto de la operaci%n est
constituido por una $ran base de datos de p$inas web" las cuales )an sido e(tra3das e
inde(adas! &l ncleo del motor de bsqueda es un pro$rama que transforma la cadena de
palabras cla'es que proporcion% el usuario en una o ms peticiones de bsqueda a la base de
datos! Subsecuentemente clasifica los resultados en una lista y transforma esta lista en una
serie de p$inas :,;L! Dentro del modelo cliente5ser'idor" esta parte de e(tracci%n de
informaci%n es t3picamente localizada en el nivel de procesamiento! La Figura 3. muestra esta
or$anizaci%n!
Clase 03: Arquitecturas de Sistemas Distribuidos
Figura 3.. <r$anizaci%n simplificada en tres ni'eles diferentes de un motor de bsqueda!
3.2.2 Arquitecturas !escentralizadas
Las arquitecturas multini'el cliente5ser'idor" como la del ejemplo del motor de bsqueda
mostrado anteriormente" son una consecuencia directa del di'idir las aplicaciones en los tres
ni'eles: interfaz de usuario" componentes de procesamiento y datos! Los diferentes ni'eles
corresponden directamente con la or$anizaci%n l%$ica de las aplicaciones! &n muc)os
ambientes" el procesamiento distribuido es equi'alente a or$anizar una aplicaci%n cliente
ser'idor como una arquitectura multini'el! A este tipo de distribuci%n se le conoce como
distribucin vertical! La caracter3stica rele'ante de una distribuci%n 'ertical es que esta puede
realizarse disponiendo componentes l%$icamente diferentes en mquinas diferentes
mquinas! +na 'ez ms" desde la perspecti'a de administraci%n del sistema" el tener una
distribuci%n 'ertical puede ser una ayuda: las funciones ests l%$ica y f3sicamente di'ididas y
distribuidas en mltiples mquinas" mientras cada mquina est confi$urada para trabajar
%ptimamente con un $rupo espec3fico de funciones!
Sin embar$o" la distribuci%n 'ertical es tan solo una manera de or$anizar aplicaciones cliente5
ser'idor! &n arquitecturas modernas" es comn que la distribuci%n de clientes y ser'idores sea
el factor ms importante" por lo que a este forma de distribuci%n se le conoce como distribucin
horizontal! &n este tipo de distribuci%n" un cliente o un ser'er puede estar f3sicamente di'idido
en partes l%$icamente equi'alentes" pero cada parte opera con su proprio conjunto inte$ral de
datos" balanceando /equilibrando0 la car$a del sistema! &n esta secci%n se analizar los
sistemas peer-to-peer" una de las arquitecturas modernas que soportan la distribuci%n
)orizontal!
+n sistema distribuido peer-to-peer (de iual a iual!" comnmente abre'iado "#"" es una
arquitectura compuesta por participantes que ponen a disposici%n directa de los otros
participantes del sistema parte de sus recursos /poder de procesamiento" almacenamiento de
disco" anc)o de banda" etc!0" sin la necesidad de una instancia de coordinaci%n central" tales
Clase 03: Arquitecturas de Sistemas Distribuidos
como ser'idores o )osts permanentes /'er Figura 3."0! Desde una alta perspecti'a" los peers
(iuales! de un sistema *9* son todos i$uales" lo que si$nifica que las funciones que deben ser
desarrolladas en el sistema pueden ser realizadas por todo peer participante! &n consecuencia"
muc)a de la interacci%n entre los procesos participantes /peers0 es sim#trica" por lo tanto" los
peers pueden ser a la 'ez tanto pro'eedores /ser'idores0 como consumidores /clientes0!
Figura 3.". /a0 Sistema peer5to5peer /*9*0" /b0 Sistema centralizado con cer'idor
&n su concepto ms amplio" los participantes de un sistema peer5to5peer pueden ser
computadoras" aplicaciones" procesos" etc! A fin de desarrollar el tema de esta secci%n" se
considerar que los participantes del sistema distribuido *9* son procesos que conforman una
aplicaci%n distribuida" es decir" componentes de software!
Los sistemas *9* fueron popularizados por aplicaciones para compartir arc)i'os /file sharin!"
tales como .apster! Las redes *9* para compartir arc)i'os )an inspirado nue'as estructuras y
filosof3as en otras reas de la interacci%n )umana! &n tales conte(tos" *9*" como tal" )ace
referencia a una red social i$ualitaria que actualmente est emer$iendo en nuestra sociedad"
)abilitada en muc)o por la 6nternet!
Los sistemas *9* t3picamente se forman dinmicamente mediante la adici%n de nodos /peers
participantes0! La eliminaci%n de nodos no tiene un impacto si$nificati'o en el sistema! La
arquitectura distribuida de una aplicaci%n *9* pro'ee una mayor escalabilidad y ser'icios ms
robustos!
&n los sistemas *9* frecuentemente se implementa" a ni'el de Capa de Aplicacin del
protocolo de comunicaci%n" una red sobreimpuesta sobre la red f3sica! ,al sobreimposici%n es
usada para el inde(ado o descubrimiento de los peers! &n pocas palabras" la or$anizaci%n y
optimizaci%n de la interconecti'idad entre los peers es implementada en la red sobreimpuesta !
&l contenido /informaci%n0 t3picamente es intercambiado directamente sobre la red 6*
subyacente! &(isten dos tipos de redes sobreimpuestas: las que son estructuradas y las no
estructuradas!
Sistemas P2P Estructurados. La conecti'idad en la red sobreimpuesta es fija /la or$anizaci%n
que define que peers se interconectan entre s3 es fija0! &n estos sistemas" la red sobreimpuesta
es construida usando procedimientos o al$oritmos determin$sticos! &l procedimiento ms usado
Clase 03: Arquitecturas de Sistemas Distribuidos
es or$anizar la conecti'idad mediante una %abla &ash 'istribuida ('&%( 'istributed &ash
%able!!
&n un sistema basado en un '&%" a cada dato se le asi$na una llave aleatoria obtenida en un
espacio de identificadores /'alores0 muy $rande1 por ejemplo" podr3a ser un identificador de 89=
o 8>0 bits! 6$ualmente" a los nodos o peers" se les asi$na un identificador obtenido en este
mismo espacio de identificadores! La funci%n crucial de un sistema basado en una '&% es
implementar un esquema eficiente y determin3stico que mapee de manera nica la lla'e
asi$nada al dato con el identificador del nodo" basado en una m#trica de distancia! ;s
importante an" cuando se busca un dato espec3fico" se proporciona la direcci%n de red del
nodo responsable de ese dato! &fecti'amente" esto se lo$ra enrutando una solicitud de dato
con el nodo responsable!
*or ejemplo" en el )istema *hord" los nodos se or$anizan l%$icamente en un anillo de
tal manera que un dato con lla'e + es mapeado /asociado0 a un nodo con el identificador id" el
cual es el nodo con el menor identificador posible que cumple la condici%n id , +! A este nodo
se le llama sucesor de la lla'e + y se denota como succ(+!" tal como se muestra en la Figura
3.#! Al buscar el dato con lla'e +" una aplicaci%n que corre en un nodo arbitrario llamar a la
funci%n L<<?+*/@0" la cual" subsecuentemente" re$resar la direcci%n de red succ(+!! &n este
punto" la aplicaci%n puede contactar el nodo para obtener una copia del dato!
Figura 3.#. ;apeo /asociaci%n0 de datos y nodos en el Sistema C)ord!
Cuando un nodo quiere a$re$arse al sistema" este empieza por $enerar un identificador
id! .ote que el espacio de identificadores es lo suficientemente $rande" por lo que el $enerador
de nmeros aleatorios es de buena calidad1 es decir" la probabilidad de $enerar un identificador
Clase 03: Arquitecturas de Sistemas Distribuidos
que ya )a sido asi$nado a otro nodo es casi nula! &ntonces" el nodo simplemente realiza una
bsqueda usando id" lo cual resulta en la direcci%n de red succ(id!! &n este punto" el nue'o
nodo simplemente contacta a succ(id! y su predecesor" y se inserta entre #stos en el anillo!
Claro" en este esquema es necesario que cada nodo conten$a la informaci%n sobre su
predecesor! La inserci%n del nue'o nodo implica que cada dato cuya lla'e est a)ora asociada
al nodo id" sea transferido desde succ(id!! &l que el nodo id abandone el sistema es tan simple
como informar a su sucesor y predecesor de su partida" y transferir todos sus datos al nodo
succ(id!!
Sistemas P2P No Estructurados. &stos sistemas no pro'een un al$oritmo para la
or$anizaci%n y optimizaci%n de las cone(iones en la red! A continuaci%n" se presentan los tres
modelos de arquitecturas *9* no estructuradas" sin embar$o es oportuno puntualizar que el
primer modelo" Sistemas "#" centralizados" clasifica como la arquitectura centralizada descrita
en la secci%n anterior1 el se$undo modelo" Sistemas "#" puros" es el nico modelo que
podemos definir como descentralizado1 el tercer modelo in'olucra un tercer tipo de arquitectura"
la hibrida" la cual combina la arquitectura centralizada y la descentralizada!
Sistemas P2P centralizados. Se utiliza un ser'idor central para inde(ar las
funciones y coordinar el sistema! Aunque tiene similaridades con la arquitectura
estructurada" las cone(iones entre peers no es determinada por un al$oritmo!
-apster es un ejemplo de sistema no estructurado centralizado!
Sistemas P2P puros (descentralizados). &l sistema consiste en nicamente
en peers equipotentes! &(iste s%lo una capa de enrutamiento" y no )ay nodos
preferidos con una funci%n de infraestructura especial! 2nutella y Areenet son
ejemplos de sistemas *9* puros!
Sistemas P2P hibridos. &l sistema permite la e(istencia de nodos especiales
con una funci%n de infraestructura" comnmente llamados supernodos! ?azaa y
los sistemas Bit,orrent son ejemplos de sistemas *9* )ibridos!
3.2.3 Arquitecturas $ibridas
:asta el momento nos )emos concentrado en arquitecturas cliente5ser'idor y arquitecturas
peer5to5peer! ;uc)os sistemas distribuidos combinan las caracter3sticas de ambas! Como se
mencion% en la secci%n anterior" los )istemas "#" &ibridos pueden ser clasificados en esta
cate$or3a arquitect%nica!
*ara ejemplificar este caso" consid#rese el caso de los sistemas para compartir arc)i'os"
usando el esquema Bit,orrent /'er Figura 3.%0! &n estos sistemas" la idea bsica es que un
usuario que busca un arc)i'o pueda descar$arlo /bajarlo0 en partes obtenidas de otros
usuarios" )asta que todas las partes obtenidas puedan ser ensambladas para reproducir el
arc)i'o de forma inte$ral! +n aspecto importante de este dise7o es el ase$urar la
colaboraci%n! &n la mayor3a de las aplicaciones para compartir arc)i'os" la mayor3a de los
Clase 03: Arquitecturas de Sistemas Distribuidos
usuarios s%lo descar$an arc)i'os" sin contribuir en casi nada! &n un sistema Bit,orrent" un
arc)i'o puede ser descar$ado nicamente cuando el usuario cliente tambi#n pro'ee contenido
a otro usuario!
Figura 3.%. *rincipio de operaci%n de un sistema Bit,orrent!
&n un sistema Bit,orrent para descar$ar un arc)i'o" el usuario debe tener acceso a un
directorio $lobal" el cual es un conjunto de p$inas web! &ste directorio contiene referencial
/enlaces o lin@s0 a lo que se conoce como arc)i'os .torrent! +n arc)i'o .torrent contiene la
informaci%n necesaria para descar$ar un arc)i'o espec3fico! &n particular" se establece una
referencia a lo que se conoce como trac+er (rastreador!" el cual es un ser'idor que mantiene un
re$istro preciso de todos los nodos activos que tienen partes del arc)i'o deseado! +n nodo
activo es aquel que en el momento est descar$ando otro arc)i'o! <b'iamente" )abr 'arios
trac+ers diferentes" aunque $eneralmente solo )abr uno por arc)i'o /o colecci%n de arc)i'os0!
+na 'ez que los nodos de los que se pueden descar$ar partes del arc)i'o )an sido
identificados" el nodo del usuario que desea descar$ar el arc)i'o" se 'uel'e acti'o! &n este
punto" este nodo ser forzado a ayudar a otros" tal 'ez proporcionando a otros las partes que
an no )an obtenido del arc)i'o que se est descar$ando! &sta re$la tiene ori$en en la
si$uiente re$la: si el nodo " nota que el nodo / est descar$ando ms de lo que est
distribuyendo /subiendo0 a otros" " puede decidir reducir la 'elocidad a la que le en'3a
informaci%n /parte de un arc)i'o" en este caso0! &ste esquema trabaja bien" siempre que "
ten$a al$o que descar$ar de /! *or esta raz%n" los nodos obtienen referencias a muc)os otros
nodos" lo cual los sita en una mejor posici%n para ne$ociar datos!
3.3 Arquitectura &.s. 'iddle(are
Cuando se consideran los aspectos arquitect%nicos que se )an considerado )asta el momento"
uno debe pre$untarse d%nde entra el middleware! Como se ense7o en clases pasadas" el
middleware forma una capa entre las plataformas de aplicaci%n y distribuci%n! +n prop%sito
importante es pro'eer un cierto ni'el de transparencia en la distribuci%n" ocultando en lo posible
la distribuci%n de datos" el procesamiento y el control de la aplicaci%n!
Clase 03: Arquitecturas de Sistemas Distribuidos
Lo que comnmente pasa es que el middleware si$ue un estilo arquitect%nico
espec3fico! *or ejemplo" muc)os sistemas de middleware )an adoptado un estilo arquitect%nico
basado en objetos" tales como C<-BA1 otros" como ,6BC-endeznous" si$uen el estilo
arquitect%nico basado en e'entos!
&l moldear el middleware a un estilo arquitect%nico espec3fico tiene la 'entaja de dise7ar
aplicaciones ms simples! Sin embar$o" una des'entaja es que el middleware puede 'ol'erse
dejar de ser %ptimo para lo que el desarrollador ten3a en mente!
Aunque se supone que el middleware tiene como prop%sito transparentar la distribuci%n"
$eneralmente se requiere que el middleware se adapte a las aplicaciones! +na soluci%n ser3a
desarrollar 'arias 'ersiones del middleware y otra ser3a el crear middleware fcilmente
confi$urable y adaptable" se$n lo requiera la aplicaci%n!
3.4 Autoadministracin en Sistemas !istribuidos
Los sistemas distribuidos y el middleware asociado a ellos requieren pro'eer soluciones
$enerales orientadas a crear un escudo contra condiciones indeseables in)erentes a la red" de
tal manera que puedan brindar soporte a tantas aplicaciones como sea posible! Los sistemas
distribuidos deben ser adaptivos" ms en cuanto a su comportamiento de su ejecuci%n y no en
cuanto a los componentes de software que lo conforman!
Cuando se requiere de adaptaci%n automtica" e(iste una fuerte interrelaci%n entre las
arquitecturas del sistema y las arquitecturas del software! *or otro lado" se requiere or$anizar
los componentes de un sistema distribuido en tal forma que se pueda implementar el monitoreo
y ajuste del sistema1 tambi#n decidir d%nde deben ejecutarse los procesos para facilitar la
adaptabilidad!
Conce)tos*
"lataforma0 2eneralmente se refiere a la combinaci%n )ardware D sistema operati'o que
determina las principales caracter3sticas computacionales de una computadora!
Aplicaciones distribuidas0 Aplicaciones de software que consisten en 'arias partes o
componentes que son distribuidos en un sistema distribuido y que se intercomunican entre s3
para lo$rar el objeti'o de la aplicaci%n!
:AS: ,ABL&S:
In computer science, a hash table or hash map is a data
structure that uses a hash function to efficiently map
certain identifiers or keys (e.g., person names) to
associated values (e.g., their telephone numbers). The
Clase 03: Arquitecturas de Sistemas Distribuidos
hash function is used to transform the key into the index (the hash) of an array element (the slot
or bucket) where the corresponding value is to be sought.
Ideally the hash function should map each possible key to a different slot index, but this ideal is
rarely achievable in practice (unless the hash keys are fixed; i.e. new entries are never added to
the table after creation). ost hash table designs assume that hash collisions ! pairs of different
keys with the same hash values ! are normal occurrences and must be accommodated in some
way.
In a well"dimensioned hash table, the average cost (number of instructions) for each lookup is
independent of the number of elements stored in the table. any hash table designs also allow
arbitrary insertions and deletions of key"value pairs, at constant average (indeed, amorti#ed
$%&
)
cost per operation.
$'&$(&
In many situations, hash tables turn out to be more efficient than search trees or any other table
lookup structure. )or this reason, they are widely used in many kinds of computer software,
particularly for associative arrays, database indexing, caches, and sets.
*ash tables should not be confused with the hash lists and hash trees used in cryptography and
data transmission.