scalability - tecnologia - tipos de escalabilidad
tienda de valor de clave escalable dinámicamente horizontal (12)
Puedo sugerirte dos posibles soluciones:
1) Compre el servicio de Amazon (Amazon S3). Por 100 TB le costará 14 512 $ mensuales.
2) solución mucho más barata:
Construya dos módulos de almacenamiento backblaze personalizados ( enlace ) y ejecute un MogileFS encima.
Actualmente estoy investigando cómo almacenar petabytes de datos usando soluciones similares, por lo que si encuentra algo interesante al respecto, publique sus notas.
¿Hay un almacén de valores clave que me dé lo siguiente?
- Permítanme simplemente agregar y eliminar nodos y redstribuirán los datos automáticamente
- Permítame eliminar nodos y aún tener 2 nodos de datos adicionales para proporcionar redundancia
- Permitirme almacenar texto o imágenes de hasta 1GB de tamaño
- Puede almacenar datos de tamaño pequeño hasta 100TB de datos
- Rápido (por lo tanto, permitirá realizar consultas en la parte superior)
- Haga todo esto transparente para el cliente
- Funciona en Ubuntu / FreeBSD o Mac
- Fuente gratis o abierta
Básicamente quiero algo que pueda usar como "único", y no tener que preocuparme por tener memcached, un db y varios componentes de almacenamiento, así que sí, quiero una base de datos que me diga "bala de plata".
Gracias
Zubair
Respuestas hasta ahora: MogileFS encima de BackBlaze: por lo que puedo ver, esto es solo un sistema de archivos, y después de algunas investigaciones, parece ser apropiado solo para archivos de imágenes grandes.
Tokyo Tyrant - Necesita lightcloud. Esto no escala automáticamente al agregar nuevos nodos. Investigué esto y parece que es muy rápido para consultas que se ajustan a un solo nodo
Riak: este es uno en el que me estoy mirando, pero todavía no tengo ningún resultado
Amazon S3: ¿Alguien está usando esto como su única capa de persistencia en producción? Por lo que he visto, parece que se usa para almacenar imágenes, ya que las consultas complejas son demasiado caras
@shaman sugirió a Cassandra, definitivamente una que estoy buscando
Hasta ahora, parece que no existe una base de datos o una tienda de valores clave que cumpla con los criterios que mencioné, ¡ni siquiera después de ofrecer una recompensa de 100 puntos se respondió la pregunta!
Eche un vistazo a Tokyo Tyrant . Es un daemon de replicación muy liviano y de alto rendimiento que exporta una tienda de valor clave del gabinete de Tokio a la red. He oído cosas buenas sobre eso.
Es posible que desee echar un vistazo a MongoDB .
Por lo que puedo decir, estás buscando una mezcla de sistema de archivos / base de datos distribuida, que puede ser difícil o incluso imposible de encontrar.
Es posible que desee echar un vistazo a los sistemas de archivos distribuidos como MooseFS o Gluster y mantener sus datos como archivos. Ambos sistemas son tolerantes a fallas y distribuidos (puedes poner y sacar nodos como quieras), y ambos son transparentes para los clientes (construidos encima de FUSE) - estás usando operaciones simples del sistema de archivos. Esto cubre las siguientes características: 1), 2), 3), 4), 6), 7), 8). Estamos utilizando MooseFS para almacenamiento de películas digitales con algo así como 1,5 PB de almacenamiento y cargar / descargar es tan rápido como lo permite la configuración de red (por lo que el rendimiento depende de la E / S, no del protocolo o de la implementación). No tendrá consultas (función 5) en su lista), pero puede acoplar dicho sistema de archivos con algo como MongoDB o incluso algún motor de búsqueda como Lucene (tiene índices agrupados) para consultar los datos almacenados en el sistema de archivos.
Amazon S3 es una solución de almacenamiento, no una base de datos.
Si solo necesita una clave / valor simple, su mejor opción sería utilizar Amazon SimpleDB en combinación con S3. Los archivos grandes se almacenan en S3, mientras que los metadatos para la búsqueda se almacenan en SimpleDB. esto le da un sistema de clave / valor escalable horizontalmente con acceso directo a S3.
Por lo que veo en tu pregunta, el Proyecto Voldemort parece ser el más cercano. Echa un vistazo a su página de diseño .
El único problema que veo es cómo manejará archivos enormes, y de acuerdo con este hilo , las cosas no son todas buenas. Pero siempre puedes evitarlo con bastante facilidad usando archivos. Al final, este es el propósito exacto de un sistema de archivos. Echa un vistazo a la lista de sistemas de archivos de Wikipedia : la lista es enorme.
Hay otra solución, que parece ser exactamente lo que estás buscando: El proyecto Apache Cassandra: http://incubator.apache.org/cassandra/
Por el momento, Twitter está cambiando a Cassandra de clúster memcached + mysql
HBase y HDFS juntos cumplen la mayoría de estos requisitos. HBase se puede usar para almacenar y recuperar objetos pequeños. HDFS se puede usar para almacenar objetos grandes. HBase compacta objetos pequeños y los almacena como más grandes en HDFS. La velocidad es relativa - HBase no es tan rápido en las lecturas aleatorias del disco como mysql (por ejemplo) - pero es bastante rápido sirviendo lecturas de la memoria (similar a Cassandra). Tiene un excelente rendimiento de escritura. HDFS, la capa de almacenamiento subyacente, es totalmente resistente a la pérdida de nodos múltiples. Se replica en los bastidores y permite el mantenimiento del nivel de rack. Es una pila basada en Java con licencia de Apache: funciona prácticamente con la mayoría del sistema operativo.
Las principales debilidades de esta pila son un rendimiento de lectura de disco aleatorio menos que óptimo y la falta de soporte de centro de datos cruzado (que es un trabajo en progreso).
Zubair,
Estoy trabajando en una tienda de clave-valor que hasta ahora es más rápido que cualquier otra cosa .
No (todavía) usa la replicación, faltando sus 2 primeros requisitos, pero esta pregunta me inspiró, ¡gracias por eso!
no: permítame simplemente agregar y eliminar nodos y redstribuir los datos automáticamente
no: Permítame eliminar nodos y aún tener 2 nodos de datos adicionales para proporcionar redundancia
ok: Permitirme almacenar texto o imágenes de hasta 1GB de tamaño (sí: ilimitado)
ok: puede almacenar datos de tamaño pequeño hasta 100TB de datos (sí: ilimitado)
ok: rápido (por lo tanto, permitirá realizar consultas en la parte superior) (sí: más rápido que el conjunto TC-FIXED de Tokyo Cabinet)
ok: haga todo esto transparente para el cliente (sí: integrado al servidor web)
ok: funciona en Ubuntu / FreeBSD o Mac (sí: Linux)
ok: fuente gratuita o abierta (sí: freeware)
Además de las prestaciones de un solo hilo superiores a las tablas hash y B-trees, esta tienda KV es la ÚNICA QUE SÉ que es "WAIT-FREE" (no bloquea ni retrasa ninguna operación).
MarkLogic va en esta dirección. Para nada gratis, sin embargo ...
Además de lo que otros han mencionado, puede echar un vistazo a OrientDB - http://code.google.com/p/orient/ un documento y una tienda de K / V que parece muy prometedor.
Usted está pidiendo demasiado del software de código abierto.
Si tiene un par de cientos de miles de dólares en su presupuesto para algún software de clase empresarial, hay un par de soluciones. Nada va a hacer lo que quiere de la caja, pero hay compañías que tienen productos que están cerca de lo que está buscando.
"Rápido (por lo tanto, permitirá realizar consultas en la parte superior)"
Si tiene una tienda de valores-clave, todo debería ser muy rápido. Sin embargo, el problema es que sin una ontología o un esquema de datos creado sobre el almacén de clave-valor, terminará revisando toda la base de datos para cada consulta. Necesita un índice que contenga la clave para cada "tipo" de datos que desea almacenar.
En este caso, generalmente puede realizar consultas en paralelo contra todas las ~ 15,000 máquinas. El cuello de botella es que los discos duros baratos topan a 50 búsquedas por segundo. Si su conjunto de datos se ajusta a la memoria RAM, su rendimiento será extremadamente alto. Sin embargo, si las claves se almacenan en la RAM pero no hay suficiente RAM para almacenar los valores, el sistema mostrará el disco en casi todas las búsquedas de valores clave. Las teclas están ubicadas en posiciones aleatorias en la unidad.
Esto lo limita a 50 búsquedas de clave-valor por segundo por servidor. Mientras que cuando los pares clave-valor se almacenan en la RAM, no es inusual obtener 100k operaciones por segundo por servidor en hardware básico (por ejemplo, Redis).
El rendimiento de lectura de disco en serie es sin embargo extremadamente alto. Tengo unidades de búsqueda de 50 MB / s (800 Mb / s) en lecturas en serie. Por lo tanto, si está almacenando valores en el disco, debe estructurar el almacenamiento para que los valores que se deben leer del disco se puedan leer en serie.
Ese es el problema. No puede obtener un buen rendimiento en un almacén de valores-clave estándar a menos que almacene los pares clave-valor completamente en RAM (o claves en RAM con valores en unidades SSD) o si define algún tipo de esquema o sistema de tipos en la parte superior del y luego agrupar los datos en el disco para que todas las claves de un tipo determinado puedan recuperarse fácilmente a través de una lectura de disco serie.
Si una clave tiene varios tipos (por ejemplo, si tiene relaciones de herencia de tipo de datos en la base de datos), la clave será un elemento de múltiples tablas de índice. En este caso, tendrá que hacer intercambios de tiempo y espacio para estructurar los valores para que puedan leerse en serie desde el disco. Esto implica almacenar copias redundantes del valor de la clave.
Lo que quiere va a ser un poco más avanzado que una tienda de valores-clave, especialmente si tiene la intención de hacer consultas. Sin embargo, el problema de almacenar archivos grandes no es un problema. Haga de cuenta que su sistema puede tener claves de hasta 50 megas. Luego, divide un archivo de 1 gig en segmentos de 50 meg y asocia una clave para cada valor del segmento. Con un servidor simple, es sencillo traducir la parte del archivo que desea en una operación de búsqueda de clave-valor.
El problema de lograr la redundancia es más difícil. Es muy fácil "código de fuente" o "archivo de pieza" la tabla de clave-valor para un servidor, para que los datos del servidor puedan reconstruirse a velocidad de cable (1 Gb / s) en un servidor en espera, si un servidor en particular muere. Normalmente, puede detectar la muerte del servidor utilizando un sistema de "latido del corazón" que se activa si el servidor no responde durante 10 segundos. Incluso es posible realizar búsquedas de valores clave en comparación con las tablas de valor-clave codificadas en el archivo parcial, pero es ineficiente hacerlo, pero aún así le da una copia de seguridad para el caso de falla del servidor. A problemas mayores es casi imposible mantener la copia de seguridad actualizada y los datos pueden tener 3 minutos de antigüedad. Si está haciendo muchas escrituras, la funcionalidad de copia de seguridad va a presentar cierta sobrecarga de rendimiento, pero la sobrecarga será insignificante si su sistema está haciendo principalmente lecturas.
No soy un experto en el mantenimiento de la coherencia de la base de datos y las restricciones de integridad en los modos de falla, por lo que no estoy seguro de qué problemas introduciría este requisito. Si no tiene que preocuparse por esto, simplifica enormemente el diseño del sistema y sus requisitos.
Rápido (por lo tanto, permitirá realizar consultas en la parte superior)
En primer lugar, olvídese de las uniones o cualquier operación que tenga una escala más rápida que n * log (n) cuando su base de datos sea tan grande. Hay dos cosas que puede hacer para reemplazar la funcionalidad que normalmente se implementa con las uniones. Puede estructurar los datos para que no tenga que hacer uniones o puede "precompilar" las consultas que está realizando y hacer una compensación de tiempo-espacio y precalcular las uniones y almacenarlas para buscarlas con anticipación. .
Para las bases de datos web semánticas, creo que veremos personas precompilando consultas y haciendo intercambios de tiempo y espacio para lograr un rendimiento decente incluso en conjuntos de datos de tamaño modesto. Creo que esto se puede hacer de forma automática y transparente por el back-end de la base de datos, sin ningún esfuerzo por parte del programador de la aplicación. Sin embargo, solo estamos comenzando a ver bases de datos empresariales que implementan estas técnicas para bases de datos relacionales. Por lo que yo sé, ningún producto de código abierto lo hace, y me sorprendería que alguien esté tratando de hacerlo para los datos enlazados en bases de datos escalables horizontalmente.
Para estos tipos de sistemas, si tiene RAM o espacio de almacenamiento extra, lo mejor que puede hacer es precomputar y almacenar el resultado de subconsultas comunes por motivos de rendimiento, en lugar de agregar más redundancia al almacén de valores-clave. Precalcule los resultados y ordene con las teclas que va a consultar para convertir una combinación n ^ 2 en una búsqueda de log (n). Cualquier consulta o sub consulta que tenga una escala peor que n * log (n) es algo cuyos resultados deben realizarse y almacenarse en caché en el almacén de clave-valor.
Si realiza una gran cantidad de escrituras, las subconsultas almacenadas en caché se invalidarán más rápido de lo que se pueden procesar y no habrá ningún beneficio de rendimiento. Lidiar con la invalidación de caché para subconsultas en caché es otro problema difícil de resolver. Creo que una solución es posible, pero no la he visto.
Bienvenido al infierno. No deberías esperar obtener un sistema como este gratis por otros 20 años.
Hasta ahora, parece que no existe una base de datos o una tienda de valores clave que cumpla con los criterios que mencioné, ¡ni siquiera después de ofrecer una recompensa de 100 puntos se respondió la pregunta!
Usted está pidiendo un milagro. Espere 20 años hasta que tengamos bases de datos de milagros de código abierto o debería estar dispuesto a pagar por una solución personalizada según las necesidades de su aplicación.
Echa un vistazo a BigCouch . Es CouchDB, pero optimizado para clusters (y todos los clústeres de problemas de Big Data son apropiados). BigCouch se está fusionando con el proyecto CouchDB mientras hablamos, por parte de la gente de Cloudant , muchos de los cuales son los principales comprometidos con CouchDB.
Resumen de sus requisitos:
Permítanme simplemente agregar y eliminar nodos y redstribuirán los datos automáticamente
Permítame eliminar nodos y aún tener 2 nodos de datos adicionales para proporcionar redundancia
Sí. BigCouch utiliza el concepto de Quórum de Dynamo para establecer cuántos nodos conservan la cantidad de copias de sus datos.
Permitirme almacenar texto o imágenes de hasta 1GB de tamaño
Sí. Al igual que CouchDB, puede transmitir blobs (como archivos) de tamaño arbitrario a la base de datos.
Puede almacenar datos de tamaño pequeño hasta 100TB de datos
Sí. El equipo que creó BigCouch lo hizo porque enfrentaban un sistema que generaba petabytes de datos por segundo.
Rápido (por lo tanto, permitirá realizar consultas en la parte superior)
Sí. Las consultas son hechas por MapReduce en el tiempo O (log n) .
Haga todo esto transparente para el cliente
Funciona en Ubuntu / FreeBSD o Mac
Fuente gratis o abierta
¡Sip! Código abierto bajo la licencia de Apache 2.0. Las instrucciones de instalación predeterminadas son para un sistema Debian, como Ubuntu.