Base de datos de documentos en el modelado predictivo

El análisis predictivo depende del procesamiento y del análisis de datos de múltiples fuentes diferentes, de la clasificación y luego del procesamiento de dichos datos a través de varias etapas para obtener datos utilizables. Esto implica registrar y almacenar los datos en diferentes formatos, y puede requerir la traducción de la información al PMML. A pesar de la complejidad y la estructura de la información, y de las fuentes que generalmente incluyen datos de fuentes de datos RDBMS tradicionales, existen otras soluciones que ofrecen algunas ventajas. Podemos utilizar la reciente variedad de bases de datos basadas en documentos NoSQL para clasificar la información en un formato estructurado, mientras afrontamos la estructura flexible de los puntos de datos individuales. Muchos entornos NoSQL también brindan apoyo para consultas Map-Reduce exhaustivas y para el procesamiento, lo que las hace ideales para el procesamiento de una gran cantidad de datos en un formato resumido. En este artículo, veremos la transferencia, el intercambio y el formato de la información en entornos NoSQL.

Martin Brown, VP de publicaciones técnicas, Couchbase

Martin BrownMartin Brown, un escritor profesional con más de 15 años de experiencia, es autor y colaborador en más de 26 libros que cubren un conjunto de temas, incluido el recientemente publicado "Getting Started with CouchDB". La extensión de su especialidad incluye miles de lenguajes en desarrollo y plataformas Perl, Python, Java, JavaScript, Basic, Pascal, Modula-2, C, C++, Rebol, Gawk, Shellscript, Windows, Solaris, Linux, BeOS, Microsoft® WP, Mac OS y más. Fue editor de tecnologías LAMP para la revista LinuxWorld y colaborador regular en ServerWatch.com, LinuxPlanet, ComputerWorld y IBM developerWorks. Tiene antecedentes ricos y variados como miembro fundador de una empresa ISP líder en el Reino Unido, gestor de sistemas y consultor TI para una agencia de publicidad y un grupo de soluciones de Internet, también ha sido especialista técnico para una red ISP intercontinental, diseñador de bases de datos y programador y ha confesado ser comprador compulsivo de hardware y software para ordenadores. MC es actualmente el vicepresidente de publicacines técnicas y educación para Couchbase y es responsable por toda la documentación publicada, programas de capacitación y contenido, y por la Techzone de Couchbase.



25-02-2013

Introducción

Estemos al tanto o no de ello, actualmente resulta difícil evitar el análisis predictivo. Se utiliza en una amplia variedad de entornos de datos diferentes, desde cheques con cargo a la tarjeta de crédito hasta la gestión de stock y la supervisión de seguridad y protección.

En cada punto durante el proceso, la entrada de datos y una situación se comparan con el modelo predictivo que incluye los datos requeridos para que el sistema realice una apreciación. Por ejemplo, cuando se supervisan los sensores para un sistema de seguridad, es posible que el sistema deba comparar la información entrante del sensor con un modelo que defina si es una situación de aviso o alarma. Si un gato camina cerca del sensor, puede desencadenar una actividad de menor importancia, como la grabación de un video, pero no activará la alarma completa, que requiere la identificación de una fuente de calor más importante.

En cada una de estas situaciones, el desafío es combinar los datos entrantes con la información de antecedentes, y luego realizar una apreciación. Generalmente, la utilización de estándares abiertos como PMML es fundamental, pero probablemente desee combinar la estructura PMML con una historia anterior, o registrar los desencadenantes de datos entrantes como parte de su entorno completo de análisis.

Por ejemplo, con una transacción de tarjeta de crédito el análisis predictivo generalmente se utiliza para capturar el comportamiento inusual, pero necesita contar con un corpus de información que describa lo que conoce acerca del comportamiento existente de los clientes, dónde hacen sus compras, el tamaño típico de sus transacciones, y la hora y fechas en las que las hacen.

El almacenamiento y procesamiento de esta información y material de antecedentes puede ser una fuente principal de problemas. La insuficiencia de entrada de datos y datos históricos dentro de su modelo traerá aparejada malas decisiones; por ejemplo, declarar una transacción completamente válida como posible fraude o poner en aprietos a su cliente, lo que le demandará tiempo adicional para trabajar con ellos y resolver el problema.

En relación a los requisitos, en un nivel más arriba se encuentra un problema secundario, que es la velocidad con la que puede obtener y procesar la información. Las bases de datos están diseñadas para administrar la búsqueda de datos que almacenan, pero también es fundamental el nivel del tiempo de procesamiento que se requiere para obtener esa información y convertirla en un modelo que pueda utilizar dentro de su nivel de análisis predictivo. Seguramente no desea que un cliente espere más de unos cuantos segundos mientras valida una transacción de tarjeta de crédito. Generalmente, mientras más rápido lo hace, mejor. Lo que es más importante, necesitará manejar millones de otras transacciones durante el mismo periodo.

Con una alarma o un sistema de supervisión, la diferencia entre una respuesta inmediata y una de unos cuantos segundos puede marcar la diferencia entre prevenir un delito o poder detener la producción y una alternativa mucho más catastrófica.


La clasificación de datos en NoSQL

La colección y la clasificación de información de antecedentes válida tradicionalmente han implicado registrar esa información en un sistema de gestión de base de datos relacionales (RDBMS), como IBM DB2. El primer paso para utilizar tal sistema para registrar la información consiste en crear una estructura de datos o esquema adecuados. Por ejemplo, podemos utilizar un modelo como el que se muestra en la Figura 1 para registrar transacciones con tarjeta de crédito.

Figura 1. Registro de transacciones con tarjeta de crédito
Recording credit card transactions

Para registrar los datos en este modelo, es necesario que cuente con toda la información disponible, o al menos con la información básica (cliente, comerciante, o costo) en la que basará sus predicciones futuras.

Sin embargo, ¿qué sucede si el nivel de datos en este escenario cambia? Si ha observado el resumen de su tarjeta de crédito recientemente, especialmente online, es posible que note una gran cantidad de información acerca de su transacción, algunas veces con el detalle de lo que ha comprado, el tipo de producto que era, y con detalles que consignan si la compra fue hecha en persona o a través de una transacción online o por teléfono.

A pesar de que podemos alterar el detalle de la información almacenada en nuestra base de datos DB2 agregando campos extras, puede resultar comparativamente más costoso, especialmente cuando podríamos completar esto en una tabla con millones, y hasta mil millones de filas de información.

Considere nuestro sensor de alarma. ¿Qué sucedería si—el sensor detecta que algo ha—sido actualizado con un sensor más avanzado que puede detectar la temperatura del objeto observado? ¿Qué sucedería si fuera actualizado con el tamaño y temperatura aproximados? Alterar la tabla cada vez que la calidad o la cantidad de información cambia no solo genera dificultad y consume mucho tiempo dentro de un RDBMS tradicional, también aumenta la complejidad para extraer la información nuevamente.

Por ejemplo, para crear los datos fundamentales y comparativos, es posible combinar una serie de diferentes consultas SQL, como las siguientes: SELECT MIN(amount),MAX(amount) FROM transactions WHERE customerid = XX.

Para obtener los importes mínimos y máximos de las transacciones del cliente puede utilizar lo siguiente: SELECT UNIQUE(country) FROM transactions WHERE customerid = XX.

Para obtener la información del país del cliente, en caso de que las compras se realicen en forma periódica desde ese lugar, puede utilizar lo siguiente: SELECT COUNT(tid) FROM transactions WHERE customerid = XX and merchantid = YY.

Finalmente, para determinar si el cliente alguna vez utilizó la compañía, puede utilizar lo siguiente: SELECT MIN(amount),MAX(amount) FROM transactions WHERE merchantid = YY.

La combinación de estas consultas es tan sólo una parte del tipo de información que generalmente deseará recolectar. En realidad, es posible que quiera examinar las transacciones más detenidamente, incluso hacer una correlación de las transacciones individuales, su frecuencia y valores para tomar una decisión a fines de construir su modelo.

Estos cambios no solo alteran la base de datos en sí misma, también alteran la manera en que se extrae, recupera y procesa la información durante la etapa de análisis, acciones que llevan tiempo y agregan complejidad.

Bases de datos de documentos

Existen varios aspectos diferentes en el movimiento de NoSQL, pero uno de los más importantes es el alejamiento del modelado tradicional de datos basado en esquemas de RDBMS en busca de un estilo más flexible, basado en documentos y menos en esquemas.

Dentro de una base de datos de documentos, en vez de definir un esquema estricto, que implica crear una definición de tabla y luego formarla, la información se almacena como un documento. Por lo tanto, se almacena ya sea serializando un objeto (por ejemplo, una instancia basada en Java de una clase de objeto), o utilizando un estándar de datos reconocido como JavaScript Object Notation (JSON).

El beneficio principal del modelo de documento es que la estructura debe ser predefinida. Echemos un vistazo a una muestra de una transacción con tarjeta de crédito, esta vez como un documento JSON (consulte el Listado 1).

Listado 1. Listado 1. Muestra de una transacción con tarjeta de crédito
{
    "country" : "UK",
    "transaction_country" : "UK",
    "amount" : 23.23,
    "customerid" : "3458983734981294",
    "merchant_country" : "UK",
    "type" : "inperson",
    "merchantid" : "49587",
    "datetime" : "2012-08-23T13:54:00"
}

La estructura de esta información permite la elaboración de un documento que contiene una gran cantidad de información, de la cual una buena parte es constante, y lo que podría esperarse que aparezca en este tipo de documento, pero los campos individuales son opcionales. Es posible hacer cumplir el nivel de requisitos en la capa de aplicación, en vez de hacerlo en la capa de la base de datos, lo que permite que la información sea introducida y actualizada rápidamente, aún si el contenido y la información se amplían.

Para utilizar nuestro ejemplo nuevamente, consideremos que si la transacción incluye información detallada sobre qué se compró, puede ser incluida en la estructura del documento (consulte el Listado 2).

Listado 2. Listado 2. Transacción con información más detallada de la compra
{
    "country" : "UK",
    "merchant_country" : "UK",
    "datetime" : "2012-08-23T13:54:00",
    "amount" : 23.23,
    "transaction_country" : "UK",
    "customerid" : "3458983734981294",
    "type" : "inperson",
    "merchantid" : "49587",
    "items" : [
       {
          "amount" : 10.2,
          "description" : "food"
       },
       {
          "amount" : 13.03,
          "descrition" : "DVD"
       }
    ]
}

Otro registro, esta vez de un comerciante diferente, contiene un nivel diferente de información, suministrada por un sistema de transacción diferente para el mismo cliente (consulte el Listado 3).

Listado 3. Registros con diferentes niveles de información
{ 
    "country" : "US", 
    "description" : "Electrical goods",
    "datetime" : "2012-07-01T01:54:00",
    "transacttype" : "internet",
    "transaction_country" : "US", 
    "value" : 192.48, 
    "tax" : 34.29, 
    "addresssupplied" : "yes", 
    "checkcode" : "474", 
    "customerid" : "3458983734981294", 
    "merchantid" : "12875" 
}

A pesar de las diferencias en los datos de entrada en cada caso, y de la diferencia en el nivel de información suministrada por cada transacción y sistema, existen algunos elementos comunes que puede identificar y extraer de la base de datos. Mejor aún, puede etiquetar los registros para indicar una versión (si es una progresión de datos), o utilizar una estructura de etiquetas para resaltar el formato.

Por ejemplo, si observamos cada documento aún podemos determinar el valor de cada transacción individual, aunque la información esté en un campo de cantidad en un documento, y en un campo de valor en otro.

Dentro de una solución NoSQL basada en un documento, la extracción e identificación de la información puede suceder cuando la información se recupera desde la base de datos, en vez de tener que procesar e insertar la información en los campos correctos cuando se recuperan los datos. El modelo MapReduce, utilizado en bases de datos NoSQL como Couchbase o Hadoop, puede afrontar fácilmente las diferencias en la estructura y el formato en cada caso.

En lugar de eso, inserta datos utilizando diferentes estructuras de documentos (con elementos comunes), lo que permite observar diferencias en el procesamiento, la cantidad o calidad de los datos, y hasta diferencias en los nombres de campos.

La utilización del modelo flexible que ofrece la estructura de documentos proporciona beneficios clave, incluidos los siguientes:

  • Velocidad de inserción

    Muchas alternativas NoSQL dejan de lado la indexación típica y la conformidad de ACID en bases de datos tradicionales para mejorar la velocidad, especialmente cuando se agrega información.

  • Sin esquema

    Sin un esquema fijo, no hay necesidad de construir una tabla compleja de base de datos o formato de base de datos, o de crear una estructura compleja o consulta para actualizarlo.

  • Extensible

    Si su estructura cambia, por ejemplo debido a que el formato de los datos o de la fuente cambia, puede ejecutar este cambio sobre la marcha y manejarlo dentro de la aplicación. Por lo general, con los datos predictivos existen cambios, expansiones y mejoras en los datos de origen.

  • Flexible

    No sólo puede almacenar los datos y los cambios que haga, también puede almacenar registros compuestos e información que resultaría difícil (o que requeriría consultas complejas) dentro de un RDBMS tradicional. Luego de construir un modelo predictivo, puede almacenar el modelo completo en la base de datos NoSQL.

Estos beneficios no deben subestimarse; la habilidad para almacenar lo que quiera, sin la estructura rígida y sin tener que cambiar o alterar el formato de su tabla mientras las fuentes de información y la evolución de su aplicación, son ideales para la naturaleza en expansión y en constante cambio del análisis predictivo.

Escalabilidad

Una dificultad clave con muchas soluciones RDBMS está dada por cómo enfrenta el conjunto de datos en constante crecimiento. Existen numerosas estrategias disponibles, como la mejora progresiva del hardware, la utilización de capas de caché como Memcached o IBM solidDB, y la utilización de réplica y otras técnicas para distribuir los datos en máquinas múltiples, además de permitir que los datos puedan ser actualizados y leídos desde múltiples hosts.

A pesar de que cualquiera o todas estas soluciones son completamente viables, presentan una sobrecarga importante al momento de construir y desplegar la solución elegida. La utilización de SQL, especialmente si desea ejecutar consultas que requieren una unión de cualquier tipo, complica el proceso, ya que debe tener acceso no solo a la tabla principal, sino también a todos los datos en las tablas asociadas.

El modelo de documento que generalmente se asocia con la base de datos NoSQL elimina algunos elementos de este proceso. Dado que los datos pueden ser autoencerrados en la estructura del documento, la condición para uniones no se requiere en todas las ocasiones. Asimismo, la naturaleza del sistema que trata la ID del documento (o clave) permite que los datos se distribuyan de manera más fácil sobre múltiples nodos sin tener que enfrentarse al problema de mantener los datos de la otra tabla coherentes y disponibles, o preocuparse del lugar de acceso a estos.

La mayoría de las soluciones NoSQL se diseñan deliberadamente con dicha escalabilidad en mente. Puede utilizar muchas de las grandes soluciones de muchos datos, como Hadoop, para clasificar la información básica y crear el modelo predictivo que necesita para tomar decisiones. Tanto Hadoop como otros están específicamente diseñados para manejar tales cantidades de datos, y pueden utilizar la funcionalidad de MapReduce en estos sistemas para recolectar la información del clúster y crear el modelo de predicción que será utilizado cuando se requiera una transacción.


Procesamiento de datos sin procesar en su entorno NoSQL.

Una de las ventajas más importantes de la base de datos NoQSL es la combinación de la flexibilidad en la que almacena la información (como ya hemos observado), y cómo esa información puede ser extraída, procesada y almacenada en la base de datos nuevamente para un uso fácil y rápido la próxima vez.

Muchas de las diversas bases de datos NoSQL admiten algún tipo de motor de procesamiento que procese y muchas veces reduzca o resuma esa información. Por ejemplo, Hadoop está especialmente diseñado para ejecutar las operaciones de MapReduce en datos de origen y convertir esa información en un formato simplificado.

Con la información de la tarjeta de crédito, una función MapReduce puede ser creada para procesar las transacciones anteriores para que un cliente implemente la transacción típica, los países y otros límites en una estructura adecuada para ejecutar el análisis final. Esto puede tener en cuenta todos los parámetros que necesite, además de todas las transacciones anteriores (que representarían una cantidad importante de información para un usuario frecuente de tarjeta). Hadoop es limitado en cuanto a la no admisión de consultas directas, al menos en el formato más útil para el análisis predictivo.

Couchbase Server 2.0 también proporciona la funcionalidad MapReduce, que puede alcanzar el mismo nivel de análisis. Con Couchbase, la información de MapReduce se almacena en un índice, lo que hace que extraer la información nuevamente resulte más rápido. Asimismo, Couchbase admite MapReduce incremental. Esto le permite cambiar (o expandir) los datos de origen utilizados para crear el índice de MapReduce y actualizar solo la información que ha cambiado.

Por ejemplo, puede crear la función map dentro de Couchbase Server para procesar nuestras cantidades de registros de muestras de tarjetas de crédito, utilizando el código en el Listado 4 a continuación.

Listado 4. función map en Couchbase Server para procesar registros de tarjetas de crédito.
function(doc) {
    if (doc.value) { 
        emit(doc.customerid, doc.value);
    } else { 
        emit(doc.customerid, doc.amount);
    }
}

La función de llamada emit() produce una fila de datos que consiste en la clave (el número de tarjeta de crédito de nuestro cliente) y en un valor (el tamaño de la transacción). El valor podría ser mayor, ya sea una matriz, o hasta un hash de datos, lo que significa que podríamos, de hecho, generar un modelo predictivo completo.

La función map es responsable de hacer una correlación de los campos de entrada con los datos de salida, por lo que es ideal para manejar estos formatos de registro diferentes. La función map está escrita en JavaScript y es posible brindar determinación y cálculos complejos dentro de la función map.

La salida de la función map se procesa y almacena en un índice para un acceso rápido. El proceso solo tendrá lugar una vez para cada documento en la base de datos. La función reduce también almacena su producción en el índice, lo que hace que construir los datos sea más fácil.

La función reduce se utiliza para resumir la información, desde los resúmenes y cuentas más típicos hasta estructuras más complejas, como los altos y bajos que podemos asociar con el modelo predictivo de la tarjeta de crédito (consulte el Listado 5).

Listado 5. La función reduce
function(key, values, rereduce) {
    var result = {total: 0, count: 0};
    for(i=0; i < values.length; i++) {
        if (values[i] < result.min) { 
            result.min = values[i];
        }
        if (values[i] > result.max) { 
            result.max = values[i];
        }
        if(rereduce) {
            result.total = result.total + values[i];
            result.count++;
        } else {
            result.total = result.total + values[i].total;
            result.count = result.count + values[i].count;
        }
    }
    return(result);
}

Observe que la función devuelve un resultado compuesto, integrado por un objeto de JavaScript que contiene los campos del total, del conteo, del mínimo y el máximo. Afortunadamente, nuestra función map() determina el campo correcto en el cual encontrar esa información. La función reduce solo necesita reducirlo a un resultado estructurado.

Podemos producir los datos del modelo predictivo final como parte de este proceso de reducción, y generar un modelo predictivo completamente de la base de datos (y almacenarlo en el índice para un acceso rápido). Podemos utilizar ese modelo inmediatamente para hacer el análisis.


Ciclo de vida de NoSQL Predictive Data

Puede ver un ejemplo del ciclo de vida de la información que puede utilizar con una base de datos NoSQL en la Figura 2.

Figura 2. Ciclo de vida de la información con una base de datos NoSQL
Lifecycle of information with a NoSQL database

El modelo se basa en el modelo de transacción con tarjeta de crédito que hemos analizado en este artículo. El sistema depende de dos conjuntos de datos principales:

  • Transacciones

    Estos son los registros de datos sin procesar de todas las transacciones con tarjeta de crédito históricas. El sistema de predicción completa la información cuando se aprueba una transacción.

  • Modelo predictivo

    Cuando se utiliza MapReduce, las transacciones se procesan en una única estructura del modelo predictivo. La estructura predictiva se almacena en la base de datos NoSQL como un registro único, lo que permite que el sistema de predicción la recupere y almacene cuando una transacción entrante coincida con el sistema.

Pueden agregarse más conjuntos de datos al sistema para utilizar otra información, que luego puede combinarse con los datos de la transacción para formar el documento del modelo predictivo. Por ejemplo, puede combinar lo que sabe acerca de viajes conocidos (de los datos de la transacción).

El procesamiento de la información sin procesar de la transacción crea el modelo predictivo, que se almacena en la base de datos NoSQL, donde el motor de decisión puede utilizarlo para la próxima transacción.


Modelado de datos de entrada en documentos

Ya hemos observado algunos ejemplos sobre cómo puede modelar toda la información diferente es su base de datos NoSQL. Según la base de datos NoSQL que haya elegido, el formato y estructura exactos de la información que desea almacenar pueden ser diferentes.

Las bases de datos NoSQL más prácticas utilizan JSON como formato de almacenamiento, lo que ofrece beneficios adicionales para algunos sistemas. Por ejemplo, con algunas bases de datos NoSQL el uso de JSON le permite actualizar los campos individuales dentro del documento, en vez de recuperar y actualizar el documento completo cada vez que se requiere una modificación.

JSON además presenta otros aspectos prácticos, ya que puede ser leído, formateado e intercambiado, independientemente de la plataforma o lenguaje de aplicación. Esto lo hace ideal para intercambiar información en una gran variedad de entornos de aplicación diferentes. Finalmente, puede utilizar JSOM como un formato de intercambio de datos para objetos de aplicación. Muchos entornos admiten la traducción de un objeto interno en una estructura JSON, y viceversa.

Existen algunas prácticas comunes y recomendadas para modelar sus datos en un documento o estructura JSON, especialmente cuando almacena datos para un modelo predictivo, como las siguientes:

  • Almacene la información común y fácil de usar en el nivel superior dentro del documento. Los importes de las transacciones, los países y otra información directa se almacena en un único campo. Esto hace que el acceso y el proceso sean más fáciles.
  • Utilice matrices para almacenar las recopilaciones de datos que normalmente procesaría en su integridad. Por ejemplo, si su modelo específicamente utiliza los elementos individuales en una transacción cada vez, entonces almacene esa información en una matriz que pueda repetirse fácilmente.
  • Utilice hashes cuando desee ejecutar una verificación rápida de información en un formato estructurado. Esto se debe a que puede verificar la existencia de un campo dentro de un hash en una sola línea. Si almacena la información en una matriz, deberá repetir toda la matriz, lo que puede llevar mucho tiempo.

Si utiliza estas reglas básicas puede modelar cualquier fuente de datos (relativamente) estructurada en un JSON o documento similar que puede almacenarse en una base de datos NoSQL.


Convertir PMML a documentos y viceversa

Si el entorno de modelado predictivo que ha elegido utiliza el lenguaje estándar Predictive Model Markup Language (PMML), asegúrese de que la generación de su documento en las etapas de NoSQL MapReduce tenga un formato que sea fácil de convertir a PMML. El abordaje más eficaz consiste en no crear una estructura de documento PMML que pueda volver a leerse, sino utilizar la habilidad de una base de datos NoSQL para almacenar documentos,—es decir, el modelo predictivo completo—y utilizar éste como la base de sus datos PMML.

Existen varias maneras de hacer esto dentro de la capa de procesamiento NoSQL.

  • Genere una estructura en JSON (o en el formato de salida que haya elegido) que coincida con el formato PMML. Puede generar las porciones del diccionario de datos como una matriz de diferentes elementos dentro del JSON mismo. Para convertir este formato a PMML es necesario utilizar una capa adicional de conversión, pero también le permite consumir y volver a procesar más fácilmente la información de origen sin re-generar la estructura del PMML.
  • Genere el PMML junto con los datos de JSON. Este proceso es más largo y consume más tiempo (y puede ser más propenso a tener errores), pero tiene la ventaja de que el modelo PMML ya existe en el momento en que se requiere.
  • O utilice una combinación de ambos. Genere el formato JSON del modelo, y almacene el formato en la base de datos NoSQL. Luego genere un modelo PMML, si es necesario, y almacene el modelo en la base de datos NoSQL para poder actualizarlo la próxima vez que se requiera. Esta solución requiere más espacio de almacenamiento en su almacén de datos NoSQL, pero puede utilizar el TTL o la funcionalidad de vencimiento de la base de datos NoSQL si se ofrece para suprimir automáticamente el modelo PMML, si no se ha utilizado durante un tiempo.

Por supuesto, cualquier solución que necesite regenerar el modelo de los datos de entrada (como en nuestro ejemplo de la tarjeta de crédito) implicará la utilización de recursos CPU adicionales.


Conclusión

Las bases de datos NoSQL eliminan de manera completa la necesidad de crear un esquema para los datos que desea almacenar y cuenta con enormes ventajas cuando necesita consumir información de una gran variedad de fuentes diferentes, pero en última instancia brindará algún tipo de información básica de la misma información. En este artículo hemos observado cómo las diferentes estructuras que pueden ser almacenadas en NoSQL pueden almacenar la misma información, pero de diferentes maneras, y cómo puede utilizar la habilidad de procesamiento de la base de datos NoSQL para convertir estas estructuras diferentes en un formato estandarizado, y luego utilizarlo para crear un modelo predictivo.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Big data y analytics
ArticleID=859247
ArticleTitle=Base de datos de documentos en el modelado predictivo
publish-date=02252013