2012-02-22 18 views
8

Tenemos una gran tienda de documentos que actualmente se ejecuta en 3TB en el espacio y se incrementa en 1 TB cada seis meses. Actualmente están almacenados en un sistema de archivos de Windows que a veces ha causado problemas en términos de acceso y recuperación. Estamos buscando explotar una base de datos de la tienda de documentos basada en Haddop. ¿Es una buena idea seguir adelante con Haddop? ¿Alguien tiene alguna exposición a lo mismo? ¿Cuáles pueden ser los desafíos, obstáculos tecnológicos para lograr lo mismo?Hadoop como base de datos de la tienda de documentos

+0

Tengo curiosidad sobre las ventajas que se ven en Hadoop para este uso. – Bill

+0

@Msdnexpert: ¿qué tipo de funcionalidad estás buscando? Almacenamiento simple compartido? HDFS/Hadoop no es una SAN. Más detalles, por favor. –

+0

Sí, estoy buscando aprovechar HDFS como un sistema de almacenamiento escalable distribuido. ¿Es eso posible? – Msdnexpert

Respuesta

10

Hadoop es más para el procesamiento por lotes que el alto acceso a los datos. Debería echar un vistazo a algunos sistemas NoSQL, como las bases de datos orientadas a documentos. Es difícil de responder sin saber cómo son tus datos.

La regla número uno para el diseño NoSQL es definir primero los escenarios de consulta. Una vez que realmente comprenda cómo desea consultar los datos, entonces puede buscar en las diversas soluciones NoSQL que existen. La unidad de distribución predeterminada es la clave. Por lo tanto, debe recordar que necesita poder dividir sus datos entre las máquinas de su nodo de manera efectiva, de lo contrario terminará con un sistema escalable horizontalmente con todo el trabajo que todavía se está haciendo en un nodo (aunque con mejores consultas según el caso).

También debe pensar en el teorema CAP, la mayoría de las bases de datos NoSQL son finalmente consistentes (CP o AP) mientras que los DBMS relacionales tradicionales son CA. Esto afectará la forma en que manejas los datos y la creación de ciertas cosas, por ejemplo, la generación de claves puede ser engañosa. Obviamente, los archivos en una carpeta son un poco diferentes.

También recuerde que, en algunos sistemas como HBase, no existe un concepto de indexación (me parece que tiene una configuración de indexación de archivos en este almacén de documentos de Windows FS). La lógica de la aplicación deberá generar todos sus índices y las actualizaciones y eliminaciones deberán administrarse como tales. Con Mongo puedes crear índices en los campos y consultarlos de manera relativamente rápida, también existe la posibilidad de integrar Solr con Mongo. No solo necesita consultar por ID en Mongo como lo hace en HBase, que es una familia de columnas (también conocida como la base de datos de estilo Google BigTable) en la que esencialmente tiene pares clave-valor anidados.

Así que una vez más se trata de sus datos, lo que desea almacenar, cómo va a almacenarlo y, lo más importante, cómo quiere acceder a él. El proyecto de Lily parece muy prometedor. El trabajo en el que estoy involucrado nos lleva una gran cantidad de datos de la web y lo almacenamos, lo analizamos, lo desglosamos, lo analizamos, lo transmitimos, lo actualizamos, etc. etc. No solo usamos un sistema sino muchos que son los más adecuados para el trabajo en cuestión. Para este proceso, utilizamos diferentes sistemas en diferentes etapas, ya que nos brinda un acceso rápido donde lo necesitamos, brinda la capacidad de transmitir y analizar datos en tiempo real y, lo que es más importante, realiza un seguimiento de todo a medida que avanzamos (como pérdida de datos en un el sistema es un gran problema). Estoy usando Hadoop, HBase, Hive, MongoDB, Solr, MySQL e incluso buenos archivos de texto antiguos. Recuerde que para producir un sistema que use estas tecnologías es un poco más difícil que instalar Oracle en un servidor, algunas versiones no son tan estables y realmente necesita hacer las pruebas primero.Al final del día, realmente depende del nivel de resistencia del negocio y de la naturaleza de misión crítica de su sistema.

Otra ruta que nadie hasta ahora ha mencionado es NewSQL - es decir, RDBMS escalables horizontalmente ... Hay algunos como el clúster MySQL (creo) y VoltDB que pueden adaptarse a su causa. Pero de nuevo dependiendo de sus datos (son los archivos word docs o text docs con información sobre productos, facturas o instrumentos o algo similar) ...

De nuevo se trata de comprender sus datos y los patrones de acceso, los sistemas NoSQL también son no rel, es decir, no relacionales y están ahí para adaptarse mejor a los conjuntos de datos no relacionales. Si sus datos son intrínsecamente relacionales y necesita algunas características de consulta SQL que realmente necesiten hacer cosas como productos cartesianos (alias uniones), entonces es mejor que se quede con Oracle e invierta algún tiempo en la indexación, fragmentación y ajuste del rendimiento.

Mi consejo sería jugar con algunos sistemas diferentes. Mirar;

MongoDB - Documento - CP

CouchDB - Documento - AP

Cassandra - Columna Familia - Disponible & partición Tolerante (AP)

VoltDB - Un muy producto atractivo, una base de datos de relaciones que se distribuye y podría funcionar para su caso (puede ser una mo ve). También parecen proporcionar soporte empresarial que puede ser más adecuado para un entorno de producción (es decir, dar a los usuarios de negocios una sensación de seguridad).

De cualquier forma esa es mi 2c. Jugar con los sistemas es realmente la única forma en que vas a descubrir lo que realmente funciona para tu caso.

+0

Una gran respuesta ¿puede dar algún recurso para la base de datos como prospecto de ingeniería de datos para principiante cómo puede alguien aprender estas cosas? –

0

HDFS no parece una solución correcta. Está optimizado para el procesamiento parralel masivo de los datos y no para ser un sistema de archivos de propósito general. Específicamente tiene las siguientes limitaciones por lo que es probablemente una mala elección:
a) Es sensible a la cantidad de archivos. El límite práctico debe ser de docenas de millones de archivos.
b) Los archivos son de solo lectura y solo se pueden anexar, pero no editar. Está bien para el procesamiento de datos analíticos, pero podría no satisfacer sus necesidades.
c) Tiene punto único de falla - namenode. Por lo tanto, su fiabilidad es limitada.

Si necesita un sistema con una escalabilidad comparable, pero no es sensible a la cantidad de archivos, sugeriría Swift de OpenStack. Tampoco tiene SPOF.

+0

a) es correcto, b) se puede simular mediante una eliminación seguida de una escritura, c) ya no se mantiene: https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop- hdfs/HDFSHighAvailabilityWithNFS.html. – Matt

0

Mi sugerencia es que usted puede comprar un almacenamiento NAS. Puede ser el tipo de producto EMS isilon que puede considerar.

Hadoop HDFS no es para almacenamiento de archivos. Es de almacenamiento para procesar los datos (para informes, análisis ..)

NAS es para compartir archivos

SAN es más para una base de datos

http://www.slideshare.net/jabramo/emc-sanoverviewpresentation

Declaración: No soy un EMC persona, para que pueda considerar cualquier producto. Acabo de usar EMC como referencia.

Cuestiones relacionadas