Data Science on MongoDB...At Last!

MongoDB
November 7, 2012 | Updated: May 2, 2018
#Releases

Today, I’m excited to announce the launch of Precog for MongoDB, a release that bundles all of the really cool Precog technology into a free package that anyone can download and deploy on their existing MongoDB database.

Precog is a data science platform that lets developers and data scientists do advanced analytics and statistics using Quirrel, the “R for big data” language. You can analyze data programmatically with a REST API (or client library) or interactively with Labcoat, an easy-to-use HTML5 application built on the REST API. We provide a cloud-hosted version of Precog, but we’ve known for a long time that we were going to bring a standalone version of our data science Precog to some NoSQL database.

MongoDB makes the perfect choice for many reasons:

  • MongoDB developers share our passion for creating software that developers love to use.

  • Quirrel is designed to analyze JSON, which is natively supported by MongoDB.

  • MongoDB has a basic query and aggregation framework, but to do more advanced analytics, you have to write lots of custom code or export the data into a RDBMS, both of which are very painful.

  • We’re great friends of some of the 10gen developers and have released open source software for MongoDB.
Precog for MongoDB gives you the ability to analyze all the data in your MongoDB database, without forcing you to export data into another tool or write any custom code.

We’re really excited about the release and encourage you to download the release from the official product page and start using it today.

In the remainder of this post, I’m going to quickly walk you through installation and configuration of the Precog for MongoDB release.

Step 1: Unpack the Download

The download is a ZIP file that contains the following files:

config.cfg
precog.sh
precog.bat

The file precog.jar is the Java JAR that bundles all of the Precog dependencies into a single (really big!) file. The file precog.sh and precog.bat are scripts that launch precog.jar.

The file config.cfg contains configuration information.

Step 2: Configure Precog

All the configuration settings for Precog are stored in the file config.cfg, with reasonable defaults

There are two things you need to do at a minimum before you can launch Precog:

  1. Tell Precog where to find the MongoDB server.

  2. Tell Precog what the master account is.

To tell Precog where to find the MongoDB server, simply edit the following settings:

queryExecutor {
  mongo {
    server = "mongodb://localhost:27017"
  }

Change the “localhost:27017” portion to the host and port of your mongo server. For optimal performance, you should launch Precog on the same machine that is running the MongoDB server.

Precog will map the MongoDB databases and collections into the file system by placing the databases at the top level of the file system, and will nest the database collections under the databases (e.g. /mydb/mycollection/).

To tell Precog what the master account is, edit config.cfg and add the following settings:

security {
  masterAccount {
    apiKey = "12345678-1234-1234-1234-123456789abc"
  }
}

The API key for the master account can be anything you like, but you should treat it securely because they whoever has it has full access to all of your MongoDB data.

You may also want to tweak the ports that Precog use for the web server that exposes the Precog REST API and to server labcoat:


 server {
	 port = 8888
    }
    ...
    labcoat {
      port = 8000
}


Step 3: Launch Precog

To run precog.jar, you will need to install JRE 6 or later (many systems already have Java installed). If you’re on an OS X or Linux machine, just run the precog script, which automatically launches Java:

precog.sh


If you’re on a Windows machine, you can launch Precog with the precog.bat script.

Once Precog has been launched, it will start a web server that exposes the REST API as well as labcoat.

Step 4: Try the API

Once Precog is running, you have full access to the Precog REST API. You can find a large number of open source client libraries available on Github, and the Precog developers site contains a bunch of documentation and tutorials for interacting with the API.


Step 5: Try Labcoat

Labcoat is an HTML5 application that comes bundled in the download. You don’t have to use Labcoat, of course, since Precog has a REST API, but Labcoat is the best way to interactively explore your data and develop Quirrel queries.

The precog.jar comes with a bundled web server for labcoat, so once it’s running just point your browser at http://localhost:8000/ (or whatever port you’ve configured it for) and you’ll have a new labcoat IDE pointing at your local Precog REST API.

Step 6: Analyze Data!

Once you’ve got Labcoat running, you’re all set! You should see your MongoDB collections in the file system explorer, and you can query data from the collections, develop queries to analyze the data, and export queries as code that run against your Precog server.

Precog is a beta product, and Precog for MongoDB is hot off the press. You may encounter a few rough corners, and if so, we’d love to hear about them (just send an email to support@precog.com).

If you end up doing something cool with Precog for MongoDB, or if you just want to say hello, feel free to reach out to us via our website, or to me personally at john@precog.com.

Have fun analyzing!

John A. De Goes, CEO/Founder of Precog

← Previous

MongoDB for the PHP Mind, Part 3

This is part 3 in a series, which will focus on the data modeling aspect of working with document databases. The previous parts are also available for reading: Part 1: Getting Started , and Part 2: Queries and Indexes . The Usual Suspects Although there are plenty of existing articles, presentations and webcasts about modeling your data to take advantage of a document database, this post is taking a slightly PHP-centric position as a part of this series. This information is useful to anyone though, regardless of their chosen programming language. We’re going to use two different scenarios to look at data modeling in the document world, chosen as common examples to illustrate differences in implementation between relational and document databases: Blog. Your garden variety of data, covering posts, comments and tags Private Sale / E-Commerce. Taking a look at needs for orders, users and products Scenario 1: Getting All Bloggy I’m kicking off with the tried-but-true blog example as it is a common frame of reference. Part of the biggest challenges of assessing MongoDB is the ability to quickly understand document data modeling, and stepping outside the constraints of relational data modeling. A common scenario helps illustrate that. Your typical blog will have the following elements to consider: AuthorsIn most cases this can point at existing user dataPostsWhere you store the actual data about each blog postCommentsAll blog posts need commentsCategoriesHow you choose to organize your posts by category groupingTagsTagging helps people find posts, and helps you link your related posts together A typical third normal form relational model will produce around six tables. For many-to-many relationships (such as with posts to tags) you need the reference table as well as the link table with the keys. For example, for tags you might have the posts table, the tags table, and a posts_tags table that simply links post_id with tag_id for each reference. This not only complicates your data model, but it shows a disconnect between relational theory and document structure. Here’s an example of how your posts might hook into tags, using a relational model: This approach can complicate your code, as you have to write more sophisticated queries to join multiple tables together. If your application is also expected to create new posts and tags, then that logic will be more complex as well. If you are using a framework, you might find yourself spending more time figuring out how to deal with the database inserts and updates, as opposed to actually writing code. For instance, every time you create a new blog post, you’re going to have to do the following: First check if that category exists, if not then create it Check for tags, create them too Create link between post and tag, for each tag used for this article Link to author Comments of course happen after the post is live, so inserting them is a little less effort: Check to see if this comment is responding to another comment Insert comment With MongoDB you have a few approaches to solve this problem. Equi-join and Embedded Lists Taking our example with posts and tags, you can remove the middle by storing a list of tag_ids in your post document. This is how this might look with a document model: > db.posts.findOne(); { "_id" : ObjectId("508d27069cc1ae293b36928d"), "title" : "This is the title", "body" : "This is the body text.", "tags" : [ ObjectId("508d35349cc1ae293b369299"), ObjectId("508d35349cc1ae293b36929a"), ObjectId("508d35349cc1ae293b36929b"), ObjectId("508d35349cc1ae293b36929c") ], "created_date" : ISODate("2012-10-28T12:41:39.110Z"), "author_id" : ObjectId("508d280e9cc1ae293b36928e"), "category_id" : ObjectId("508d29709cc1ae293b369295"), "comments" : [ ObjectId("508d359a9cc1ae293b3692a0"), ObjectId("508d359a9cc1ae293b3692a1"), ObjectId("508d359a9cc1ae293b3692a2") ] } This approach presumes that you are storing your tags and comments in their own collection. Of course your users are in a separate collection as well. With MongoDB, an equi-join works just like in the relational model, however you have to perform a separate query to fetch that data. You might be asking yourself so why is running separate queries a better idea than one SQL statement with a few joins? Think about the query cache from a relational database. That one query will hit multiple tables, and any of which need to be updated only once and that query gets dropped from the cache. MongoDB caches queries too, however with separate queries for each collection, an update to one of these collections does not invalidate the cache for the others; and for example, a user updating their password will not touch the cached post, comments, categories, or tags. That same event on a relational database will drop the query from the cache, even though the data being updated had nothing to do in particular with that query. One last comment about the monster SQL statement approach: Many platforms and frameworks are breaking out the logic that pulls the content for a page, and separating that from the blocks that typically populate the sidebars and footer. For example, the comments are always rendered from a separate module. If you are using a complex, heavy platform that means you have to run separate queries for the post and comments anyway, as the comments module won’t have access to the post content object. The simplest example is running a single query to fetch the content of your blog post and render it in the main body of your app, and then run a separate query for grabbing all the comments and displaying them in a separate comments module at the bottom of your content area. Although you still can enforce relational integrity, at this point you are getting a minimized benefit from a relational engine as you are displaying related data from separate queries. Some modern platforms will do this with everything, including separating queries for authors, categories, and tags — so you’re running separate queries in the end regardless of database platform. Embedded Lists, No Join You could also just embed all of your tags and comments in each post, dropping your count to just the posts collection, and no longer needing a separate collection for comments or tags. > db.posts.findOne(); { "_id" : ObjectId("508d27069cc1ae293b36928d"), "title" : "This is the title", "body" : "This is the body text.", "tags" : [ "chocolate", "spleen", "piano", "spatula" ], "created_date" : ISODate("2012-10-28T12:41:39.110Z"), "author_id" : ObjectId("508d280e9cc1ae293b36928e"), "category_id" : ObjectId("508d29709cc1ae293b369295"), "comments" : [ { "subject" : "This is coment 1", "body" : "This is the body of comment 1.", "author_id" : ObjectId("508d345f9cc1ae293b369296"), "created_date" : ISODate("2012-10-28T13:34:23.929Z") }, { "subject" : "This is coment 2", "body" : "This is the body of comment 2.", "author_id" : ObjectId("508d34739cc1ae293b369297"), "created_date" : ISODate("2012-10-28T13:34:43.192Z") }, { "subject" : "This is coment 3", "body" : "This is the body of comment 3.", "author_id" : ObjectId("508d34839cc1ae293b369298"), "created_date" : ISODate("2012-10-28T13:34:59.336Z") } ] } This greatly speeds the assembly of data for rendering that page, as one query returns the post, tags and comments. So which approach is better? With document design you need to consider two things: scale and search. Scale MongoDB Documents have a limit of 16MB, which although sounds quite small, can accommodate thousands of documents. However if you are expecting 20,000 comments per post on a high traffic website, or your comments are unlimited in size, then embedding might not work well for you.SearchDepending on how you want to find your documents, you should consider their structure. MongoDB makes it dead simple to embed lists and even other documents, but if you find yourself constantly reaching deeper and deeper to find the data you need, then performance can become a problem as your data set grows. You must weigh both of these to decide what approach makes the most sense for your application’s needs. Outro, or What’s Coming Next The next article in this series covers Example Scenario 2: Private Sales. That article examines the issues of managing inventory and making atomic updates.

November 6, 2012
Next →

Tendencias del 2023: Las Medidas de Modernización en el Sector de los Servicios Financieros

Ante la recesión mundial que se avecina, los bancos se enfrentan a unas condiciones económicas difíciles en 2023. Reducir los costes será vital para que muchas organizaciones sigan siendo competitivas en un entorno con un uso intensivo de datos y altamente regulado. Por ello, es importante que cualquier inversión en IT acelere la transformación digital con tecnologías innovadoras que rompan los silos de datos, aumenten la eficiencia operativa y creen experiencias personalizadas para los clientes. Siga leyendo para conocer las áreas en las que los bancos están buscando modernizarse en 2023 para construir mejores experiencias de cliente con un coste menor y a escala. Diseñando un futuro bancario mejor mediante diseños flexibles En un momento en que los bancos están deseando modernizarse e innovar, las entidades deben alejarse de los sistemas heredados que limitan su capacidad de progresar. Situar a los consumidores en el centro de una experiencia bancaria compuesta por servicios interconectados pero independientes ofrece a los bancos, que apuestan por la tecnología, la oportunidad de remodelar sus modelos de negocio y, en consecuencia, aumentar su cuota de mercado y su rentabilidad. Estas oportunidades han hecho posible un diseño de arquitectura componible que permite una innovación más rápida, una mayor eficiencia operativa y la creación de nuevas fuentes de ingresos mediante la ampliación de la cartera de servicios y productos. De este modo, los bancos pueden adoptar el mejor software de su categoría y el que mejor se adapte a sus necesidades, organizando asociaciones estratégicas con las empresas de tecnología financiera y los proveedores de software pertinentes. Esta nueva generación de proveedores puede ofrecer desde servicios de conocimiento del cliente (KYC, del inglés "Know Your Customer") hasta reservas integradas, servicios de carga o funcionalidades básicas de marketing y gestión de portfolios. Este enfoque es más rentable para las entidades que tener que construir y mantener ellas mismas la infraestructura, y es significativamente más rápido en términos de tiempo de comercialización y tiempo de obtención de ingresos. Los bancos que adoptan este enfoque ven a las fintech menos como competidores y más como parte de un ecosistema con el que colaborar para acelerar la innovación y llegar a los clientes. Eficiencia operativa mediante automatización inteligente Las entidades financieras seguirán centrándose en la eficiencia operativa y el control de costes mediante la automatización de los procesos manuales y basados en papel. Los bancos han hecho algunos progresos en la digitalización y automatización de lo que antes eran procesos manuales basados casi exclusivamente en papel. Sin embargo, el principal motor de esta transformación ha sido el cumplimiento de la normativa local, en lugar de una estrategia global para conocer realmente al cliente y lograr su satisfacción. El mercado demanda mejores decisiones automatizadas y basadas en datos, y los sistemas heredados no pueden seguir el ritmo. Crear las experiencias hiperpersonalizadas que demandan los clientes, como chatbots, portales de autoservicio y análisis forense digital, es difícil para las entidades que utilizan tecnología obsoleta. Además, tener una infraestructura de datos en silos impide cualquier experiencia moderna verdaderamente integrada. Mediante una combinación de automatización robótica de procesos (RPA, del inglés "Robotic Process Automation"), aprendizaje automático (ML, del inglés "Machine Learning") e inteligencia artificial (IA), las entidades financieras pueden agilizar los procesos, liberando así a los empleados para que se centren en tareas que tengan un mayor impacto para el cliente y la empresa. Las entidades no deben digitalizar sin tener en cuenta la interacción humana que será sustituida, ya que los clientes prefieren un enfoque híbrido. La capacidad de actuar sobre los datos en tiempo real es el camino a seguir para impulsar el valor y transformar las experiencias de los clientes, lo que debe ir acompañado de la modernización de la arquitectura de datos subyacente. El prerrequisito para alcanzar este objetivo implica la disociación de los datos y las fuentes en un paisaje de datos holístico. Algunos lo llaman data mesh otros fuentes de datos componibles o datos virtualizados. Resolviendo los retos que plantean los datos ESG (del inglés "Environmental, Social, and Governance") Junto con la elevada inflación, la crisis del coste de la vida, las turbulencias energéticas y la subida de los tipos de interés, los aspectos medioambientales, sociales y de gobernanza (ESG) también están en el punto de mira. Los reguladores presionan cada vez más para que se faciliten datos ESG y los inversores para que los portfolios sean sostenibles. El papel de los datos ESG en la realización de análisis de mercado, el apoyo a la asignación de activos y la gestión de riesgos, y proporcionar información sobre la sostenibilidad a largo plazo de las inversiones sigue creciendo. La naturaleza y variabilidad de muchas métricas ESG es un reto importante al que se enfrentan las empresas hoy en día. A diferencia de los datasets financieros, que son en su mayoría numéricos, las métricas ESG pueden incluir datos cuantitativos y cualitativos para ayudar a los inversores y otras partes interesadas a comprender las acciones e intenciones de una empresa. Esta complejidad, unida a la falta de una norma de información ESG de aplicación universal, significa que las instituciones deben considerar diferentes normas con diferentes requisitos de datos. Para dominar la elaboración de informes ESG, incluida la integración de los KPIs pertinentes, se necesitan datos adecuados y de alta calidad que, además, tengan el nivel de granularidad adecuado y cubran los sectores y la región requeridos. Dado el volumen y la complejidad de los datos, las entidades financieras están construyendo plataformas ESG sustentadas en modernas plataformas de datos capaces de consolidar distintos tipos de datos de varios proveedores, crear vistas personalizadas, modelizar datos y realizar operaciones sin barreras. Pagos digitales - Ofreciendo una experiencia enriquecida Impulsado por las nuevas tecnologías y las tendencias mundiales, el mercado de los pagos digitales está floreciendo en todo el mundo. Con una valoración de más de 68.000 millones de dólares en 2021 y expectativas de crecimiento de dos dígitos en la próxima década, los mercados emergentes lideran la expansión relativa. Este crecimiento se ha visto impulsado por los pagos sin efectivo inducidos por la pandemia, el comercio electrónico, el impulso gubernamental y las fintech. Los pagos digitales están transformando la experiencia de pago. Mientras que antes bastaba con que los proveedores de servicios de pago facilitaran información sobre las cuentas y orquestaran transacciones sencillas, ahora los consumidores exigen una experiencia mucho más completa en la que cada transacción ofrezca nuevas perspectivas y servicios de valor añadido. Satisfacer estas expectativas es difícil, especialmente para las empresas que dependen de tecnologías obsoletas que se crearon mucho antes de que las transacciones se realizaran con unos pocos clicks en un dispositivo móvil. Para satisfacer las necesidades de los clientes, las instituciones financieras están modernizando su infraestructura de datos de pagos para crear experiencias de pago personalizadas, seguras y en tiempo real, todo ello protegiendo a los consumidores del fraude. Esta modernización permite a las entidades financieras ingerir cualquier tipo de datos, poner en marcha servicios más rápidamente, a un coste menor y tener la libertad de ejecutarlos en cualquier entorno, desde el local hasta la multi-nube. Seguridad y gestión de riesgos Los datos son fundamentales para todas las instituciones financieras; se reconocen como un activo esencial para impulsar el crecimiento de los clientes y la innovación. Sin embargo, a medida que aumenta la necesidad de aprovechar los datos de forma eficiente, según el 57% de los responsables de la toma de decisiones , la tecnología heredada que aún sustenta a muchas organizaciones es demasiado cara y no cumple los requisitos de las aplicaciones modernas. Esta infraestructura heredada no sólo es compleja, sino que además es incapaz de cumplir los requisitos de seguridad actuales. Dado el enorme volumen de datos confidenciales de clientes y consumidores que el sector de los servicios financieros maneja a diario -y la estricta normativa que los regula-, la seguridad debe ser la máxima prioridad. El valor percibido de estos datos también convierte a las organizaciones de servicios financieros en el principal objetivo de las filtraciones de datos. La protección contra el fraude, la gestión de riesgos y la lucha contra el blanqueo de dinero son prioridades importantes para cualquier nueva plataforma de datos, según el estudio de Forrester What's Driving Next-Generation Data Platform Adoption in Financial Services . Para hacer frente a estos retos, la adopción de plataformas de datos de nueva generación seguirá creciendo a medida que las instituciones financieras se den cuenta de todo su potencial para gestionar costes, maximizar la seguridad y fomentar la innovación. Descargue el estudio completo de Forrester - What's Driving Next-Generation Data Platform Adoption in Financial Services - para obtener más información.

March 23, 2023