Narrative Science Quill™ and MongoDB: A Match Made In Heaven

MongoDB
November 10, 2014
#Releases

This is a guest post by Craig Booth and Katy De Leon of Narrative Science

Big Problems with Big Data

Billions of dollars have been invested in Big Data that have produced innumerable business intelligence and visualization tools. No amount of data is too large. No combination of algorithms is too many. No visualization is too complex. But no spreadsheet or dashboard can tell you what you need to know to improve your business. This you must figure out for yourself. Or rely on someone to figure it out for you.

At Narrative Science, we approach data in a different way. We find the insight hidden in data and communicate it in a form that makes natural sense to everyone: a written narrative. Whether it’s an earnings report, a system performance review or a product description, narratives leave you with nothing left to decipher. All you have to do is read.

Since Big Data is vital to what we do, we require a data storage solution that is reliable, high performing, scalable, flexible and expressive regarding the structure and hierarchy necessary for generating plain English language. MongoDB meets all of these criteria and has been the backend of our entire infrastructure since 2010. Over the years, our MongoDB replica sets have remained available even during region-wide outages in the Amazon cloud computing centers. We also leverage our MongoDB deploys as a job queuing system, and as a store for temporary data for our web services (using TTL indexes).

MongoDB also offers us schematic flexibility — a critical feature since we are constantly adding new data from a diverse range of industries and clients. Changes can be made iteratively and instantaneously, a huge advantage for us over a traditional SQL database. As our data requirements and client demands have grown ever more complex, MongoDB has grown with them; providing access to the data structures necessary to generate natural language directly from data.

Quill Automatically Explains MongoDB Usage

Quill™ is our automated narrative generation platform, powered by Artificial Intelligence. Quill integrates structured data from disparate sources, understands what is important to the end user and then generates perfectly written narratives that convey meaningful information to any intended audience. In essence, we do what data visualizations cannot. Although charts and dashboards look appealing, they still require people to explain them. Quill, on the other hand, adds value to data by identifying relevant data points and relaying them through professional, conversational language that people can immediately comprehend, act on and trust.

In order to diagnose potential performance and scaling issues before they affect us or our clients, we decided to put Quill on the task of monitoring our MongoDB usage. Here is a snapshot from a recent Quill-generated report explaining the weekly performance of one of our environments:

Data Use

This report, generated on July 25, 2014, compares today’s MongoDB usage to that from one week ago. Between last week and today:

The database “prod_ns4” has grown the most in the past week, increasing by 4.07 Gb. The collection inside of “prod_ns4” that drove most of this growth was “metadata”, which now contains 531,126 documents.
The total data size increased from 354.79 Gb to 365.31 Gb.
The total number of collections remained constant at 8407.
The number of documents has increased from 119.4 million to 121.1 million.
The following databases are the largest of those in your MongoDB instance: “prod_pub_service” (with 196 collections, containing a total of 18.4 million objects in 128 Gb) and “prod_harpoon” (with 25 collections, containing a total of 9.9 million objects in 44.54 Gb).
The following databases were dropped: “prod_assignment_service” and “stg_sla_monitor”.
No new databases were created in the past week.

Slow Queries

The three collections that accounted for the largest number of slow queries this week were ‘stg_finance.qm’, 'stg_cft.tweets’, and 'stg_statprovider.latest’ with 8675, 1405 and 601 slow queries respectively.

72% of the total number of slow queries were on the collection 'stg_finance.qmc. Consider adding indexes. The slowest queries were:

Wed Jul 16 05:01:48 [conn61548] query stg_finance.qqm query: { $query: { ticker: “LTG”, exchange: “NYSE” }, $orderby: { date: -1 } } ntoreturn:1 ntoskip:0 nscanned:643 scanAndOrder:1 keyUpdates:0 numYields: 20 locks(micros) r:9929394 nreturned:1 reslen:110 7102ms
Wed Jul 16 04:53:55 [conn61548] query stg_finance.qm query: { $query: { ticker: “ATR”, exchange: “NYSE” }, $orderby: { date: -1 } } ntoreturn:1 ntoskip:0 nscanned:643 scanAndOrder:1 keyUpdates:0 numYields: 18 locks(micros) r:13086372 nreturned:1 reslen:110 7050ms

Better Transparency and Decision-Making

This machine-generated explanation distills thousands of numbers, about over 5TB of data, into an easily digestible, relevant, and informative story that is sent to our engineering team every day and every week. It allows them to zero in on only those issues that are important and ignore the information that’s irrelevant to performance issues. And, unlike what you get from other monitoring tools, even a non-techy type can immediately understand the report. It gives our team what we need, when we need it - actionable insights specific to the performance of our MongoDB deployment.

These reports have already allowed us to make performance tweaks to our deployments. For example, when inefficient MongoDB queries make it into production code, Quill immediately flags them so we can place indexes in the relevant places. It also makes our lives easier by providing transparency into which projects are hogging data space so we can make the relevant collections smaller, either by making different choices about what data we store, or adding TTL indexes that allow irrelevant data to expire.

MongoDB is a powerful tool for dealing with the deeply nested documents that are needed for Natural Language Generation (NLG). It is a tool that is essential to Quill’s performance. At the same time, natural language reporting from Quill provides us with a powerful way to continually understand and improve our MongoDB usage.

Want to learn how Quill can immediately start adding value to your business? We’ve written a white paper that explains how Quill works and outlines examples of how companies are using it today. You can also visit our website, or contact us directly to see a demonstration.

← Previous

Four Ways to Optimize Your Cluster With Tag-Aware Sharding

By Francesca Krihely, Community Manager and Asya Kamsky, Principal Developer Advocate MongoDB supports partitioning data using either a user-defined shard key index (composed of one or more fields present in all documents) or based on a hashed index on a single field (which also much be present in all documents). A lesser known feature is tag-aware sharding , which allows you to create (and adjust) policies that affect where documents are stored based on user-defined tags and tag ranges. Tag-aware sharding is a very versatile feature: it can be used to maximize the performance of your cluster, optimize storage, and implement data center-awareness in your application. In this post, we’ll go through a few use cases for tag aware sharding. Optimizing Physical Resources In some cases, an application needs to store data that is not frequently accessed. Financial institutions are often required to save transaction details or claims for a number of years to stay in compliance with government regulation. It can be very expensive to keep several years worth of data on high-performance hardware, so a useful approach would be to use periodic batch jobs to move data to a more cost-effective archive storage–an operational headache for most applications. There are a number of failure points when moving data from one machine to the next and there is a lot of tedious application logic needed in order to execute these operations. Using MongoDB’s Tag-Aware sharding feature, you could assign tags to different storage tiers, associate a unique shard key range to a tag, and documents will move from one shard to the next during normal balancing operations. To ensure you’re moving the right number of document from one machine to the next over time, you could write a script to update shard tags once a month. This method is great because it keeps all the data in one database, so your application code doesn’t need to change as data moves between storage tiers. You can read an in-depth overview of this implementation in our blog post on tiered storage . Location-Based Separation of Data If you have a large, global user base, it is often preferable to store specific user information in localized data centers. In this case, you can use shard tags to keep documents to specified data center(s). There is a great tutorial on this in the (MongoDB Manual)[http://docs.mongodb.org/manual/data-center-awareness/]. While this is a classic use case for tag-aware sharding, there are a few things to look out for when implementing this new approach yourself. Remember that Shard Keys are immutable: you cannot change the value of your shard key, so if a user happens to change their location, they will in turn change their shard key, and you will need to delete and re-insert that document to change that information. See more about Shard Keys in our blog post here . You should include the shard key with every operation to avoid scattering the query to all shards. This may seem counter-intuitive if your shard key is “region, customerId” but it’s necessary to make sure that only shards holding a particular value of “region” field are sent the query. If you’re interested in learning more about this example, take a look at our new white paper on multi datacenter deployments which discusses sharding along with other configurations for distributing databases across regions. Balancing unsharded collections across a sharded cluster Sharding can help with many dimensions of scalability, including read and write scalability. With tag aware sharding, you can take this one step further, by balancing collections across shards to distribute read and write load. This would happen in a case where you have a large number of medium sized collections on a single shard – not typically big enough to warrant sharding– that make your workload unbalanced. Instead of splitting all of these medium-sized collections across all shards, you can distribute them “round-robin” style–one or several collections living on each shard. Some examples of how to implement that are here In the wild, we have seen this implemented for a “platform as a service” (i.e. an application development platform). If you have many tenants–or individual apps– and none of them are large enough to need sharding, there still may be too many to live on a single replica set. Having each tenant’s application on an individual shard would help distribute the load by splitting individual collections on to specific shards or a subset of shards. You would not have to partition any of the collections (which you would do if you sharded the collection) but they would live on individual shards, enabling you to balance your read and write load. Targeting data to individual servers Balancing collections can also be used to optimize physical resources. In some cases, your collections will have heavy indexes that are taking up a lot of memory. Rather than spreading them out on different machines, you can target that collection to a shard with more RAM, allowing you to separate it from other collections to reduce contention for limited physical resources. There are a number of ways to implement tag-aware sharding into your infrastructure to increase read and write efficiency, get better use of your hardware and improve overall performance in your application. If you want to learn more: See how Bugsnag implemented tag aware sharding to optimize their read and write load on specific collections Read more about the Tiered Storage model Learn more about multi-data center deployments in our free whitepaper Need help with your sharding configuration? MongoDB’s Technical Support Engineers can help you plan and architect your sharding setup and offer you guidance to ensure you’re on the right track. Learn more about MongoDB’s 24x365 Production Support , which will offer you proactive advice on your MongoDB deployment.

November 5, 2014

Next →

Melhores práticas de desempenho: indexação

Bem-vindo ao terceiro de nossa série de postagens de blog que abordam as práticas recomendadas de desempenho para MongoDB. Nesta série, abordamos as principais considerações para alcançar o desempenho em escala em uma série de dimensões importantes, incluindo: Modelagem de dados e dimensionamento de memória (o conjunto de trabalho) Padrões de consulta e criação de perfil Indexação, que abordaremos hoje Fragmentação Transações e preocupações de leitura/gravação Configuração de hardware e sistema operacional Aquecimento de bancada Tendo ambos trabalhado para alguns fornecedores de bancos de dados diferentes nos últimos 15 anos, podemos dizer com segurança que não definir os índices apropriados é o principal problema de desempenho que as equipes de suporte técnico precisam resolver com os usuários. Portanto, precisamos acertar… aqui estão as melhores práticas para ajudá-lo. Índices no MongoDB Em qualquer banco de dados, os índices suportam a execução eficiente de consultas. Sem eles, o banco de dados deve examinar todos os documentos de uma collection ou tabela para selecionar aqueles que correspondem à instrução da consulta. Se existir um índice apropriado para uma consulta, o banco de dados poderá usar o índice para limitar o número de documentos que deve inspecionar. O MongoDB oferece uma ampla variedade de tipos de índices e recursos com ordens de classificação específicas de linguagem para oferecer suporte a padrões de acesso complexos aos seus dados. Os índices MongoDB podem ser criados e eliminados sob demanda para acomodar requisitos de aplicativos e padrões de consulta em evolução e podem ser declarados em qualquer campo de seus documentos, incluindo campos aninhados em matrizes. Então, vamos abordar como você faz o melhor uso dos índices no MongoDB. Use índices compostos Índices compostos são índices compostos por vários campos diferentes. Por exemplo, em vez de ter um índice em "Sobrenome" e outro em "Nome", normalmente é mais eficiente criar um índice que inclua "Sobrenome" e "Nome" se você consultar ambos os nomes. . Nosso índice composto ainda pode ser usado para filtrar consultas que especificam apenas o sobrenome. Siga a regra ESR Para índices compostos, esta regra prática é útil para decidir a ordem dos campos no índice: Primeiro, adicione os campos nos quais as consultas de igualdade são executadas Os próximos campos a serem indexados devem refletir a ordem de classificação da consulta Os últimos campos representam o intervalo de dados a serem acessados Use consultas cobertas quando possível As consultas cobertas retornam resultados diretamente de um índice, sem precisar acessar os documentos de origem e, portanto, são muito eficientes. Para que uma consulta seja coberta todos os campos necessários para filtrar, ordenar e/ou retornar ao cliente devem estar presentes em um índice. Para determinar se uma consulta é coberta, use o método explain() . Se a saída de explain() exibir totalDocsExamined como 0, isso mostra que a consulta é coberta por um índice. Leia mais na documentação para explicar os resultados . Um problema comum ao tentar obter consultas cobertas é que o campo ID é sempre retornado por padrão. Você precisa excluí-lo explicitamente dos resultados da consulta ou adicioná-lo ao índice. Em clusters fragmentados, o MongoDB precisa acessar internamente os campos da chave do fragmento. Isso significa que as consultas cobertas só são possíveis quando a chave de fragmento faz parte do índice. Geralmente é uma boa ideia fazer isso de qualquer maneira. Tenha cuidado ao considerar índices em campos de baixa cardinalidade Consultas em campos com um pequeno número de valores exclusivos (baixa cardinalidade) podem retornar grandes conjuntos de resultados. Os índices compostos podem incluir campos com baixa cardinalidade, mas o valor dos campos combinados deve apresentar alta cardinalidade. Elimine índices desnecessários Os índices consomem muitos recursos: mesmo com compactação no mecanismo de armazenamento MongoDB WiredTiger, eles consomem RAM e disco. À medida que os campos são atualizados, os índices associados devem ser mantidos, incorrendo em sobrecarga adicional de CPU e E/S de disco. O MongoDB fornece ferramentas para ajudá-lo a entender o uso do índice, que abordaremos mais adiante nesta postagem. Os índices curinga não substituem o planejamento de índices baseado em carga de trabalho Para cargas de trabalho com muitos padrões de consulta ad hoc ou que lidam com estruturas de documentos altamente polimórficas, os índices curinga oferecem muita flexibilidade extra. Você pode definir um filtro que indexe automaticamente todos os campos, subdocumentos e matrizes correspondentes em uma collection. Como acontece com qualquer índice, eles também precisam ser armazenados e mantidos, portanto, adicionarão sobrecarga ao banco de dados. Se os padrões de consulta do seu aplicativo forem conhecidos antecipadamente, você deverá usar índices mais seletivos nos campos específicos acessados pelas consultas. Use a pesquisa de texto para combinar palavras dentro de um campo Os índices regulares são úteis para combinar o valor inteiro de um campo. Se você deseja corresponder apenas uma palavra específica em um campo com muito texto, use um índice de texto . Se você estiver executando o MongoDB no serviço Atlas, considere usar o Atlas Full Text Search , que fornece um índice Lucene totalmentemanaged e integrado ao banco de dados MongoDB. O FTS oferece maior desempenho e maior flexibilidade para filtrar, classificar e classificar seu banco de dados para exibir rapidamente os resultados mais relevantes para seus usuários. Use índices parciais Reduza o tamanho e a sobrecarga de desempenho dos índices incluindo apenas os documentos que serão acessados por meio do índice. Por exemplo, crie um índice parcial no campo orderID que inclua apenas documentos de pedido com um orderStatus de "Em andamento" ou indexe apenas o campo emailAddress para documentos onde ele existir. Aproveite as vantagens dos índices multichave para consultar matrizes Se seus padrões de consulta exigirem acesso a elementos individuais da matriz, use um índice multichave . O MongoDB cria uma chave de índice para cada elemento do array e pode ser construído sobre arrays que contêm valores escalares e documentos aninhados. Evite expressões regulares que não estejam ancoradas ou enraizadas Os índices são ordenados por valor. Os curingas iniciais são ineficientes e podem resultar em varreduras completas do índice. Os curingas finais podem ser eficientes se houver caracteres iniciais que diferenciam maiúsculas de minúsculas suficientes na expressão. Evite expressões regulares que não diferenciam maiúsculas de minúsculas Se o único motivo para usar um regex for a insensibilidade a maiúsculas e minúsculas, use um índice que não diferencia maiúsculas de minúsculas , pois eles são mais rápidos. Use otimizações de índice disponíveis no mecanismo de armazenamento WiredTiger Se você estiver autogerenciando o MongoDB, poderá opcionalmente colocar índices em seu próprio volume separado, permitindo paginação de disco mais rápida e menor contenção. Consulte as opções WiredTiger para obter mais informações. Use o Plano Explicar Abordamos o uso do plano de explicação do MongoDB na postagem anterior sobre padrões de consulta e criação de perfil, e esta é a melhor ferramenta para verificar a cobertura do índice para consultas individuais. Trabalhando a partir do plano de explicação, o MongoDB fornece ferramentas de visualização para ajudar a melhorar ainda mais a compreensão de seus índices e fornece recomendações inteligentes e automáticas sobre quais índices adicionar. Visualize a cobertura do índice com MongoDB Compass e Atlas Data Explorer Como a GUI gratuita do MongoDB Compass oferece muitos recursos para ajudá-lo a otimizar o desempenho da consulta, incluindo a exploração do seu esquema e a visualização dos planos de explicação da consulta – duas áreas abordadas anteriormente nesta série. A guia de índices do Compass adiciona outra ferramenta ao seu arsenal. Ele lista os índices existentes para uma collection, informando o nome e as chaves do índice, juntamente com seu tipo, tamanho e quaisquer propriedades especiais. Através da guia de índice você também pode adicionar e eliminar índices conforme necessário. Um recurso realmente útil é o uso do índice, que mostra com que frequência um índice foi usado. Ter muitos índices pode ser quase tão prejudicial ao seu desempenho quanto ter poucos, tornando esse recurso especialmente valioso para ajudá-lo a identificar e remover índices que não estão sendo usados. Isso ajuda a liberar espaço no conjunto de trabalho e elimina a sobrecarga do banco de dados resultante da manutenção do índice. Se você estiver executando o MongoDB em nosso serviço Atlas totalmentemanaged , a visualização dos índices no Data Explorer lhe dará a mesma funcionalidade do Compass, sem que você precise se conectar ao seu banco de dados com uma ferramenta separada. Você também pode recuperar estatísticas de índice usando o estágio aggregation pipeline $indexStats . Recomendações de índice automatizado Mesmo com toda a telemetria fornecida pelas ferramentas do MongoDB, você ainda é responsável por extrair e analisar os dados necessários para tomar decisões sobre quais índices adicionar. O limite para consultas lentas varia com base no tempo médio de operações no seu cluster para fornecer recomendações pertinentes à sua carga de trabalho. Os índices recomendados são acompanhados por consultas de amostra, agrupadas por formato de consulta (ou seja, consultas com estrutura de predicado, classificação e projeção semelhantes), que foram executadas em uma collection que se beneficiaria com a adição de um índice sugerido. O Performance Advisor não afeta negativamente o desempenho do seu Atlas cluster. Se você estiver satisfeito com a recomendação, poderá implementar os novos índices automaticamente, sem incorrer em tempo de inatividade do aplicativo. Qual é o próximo Isso encerra esta última edição da série de práticas recomendadas de desempenho. A MongoDB University oferece um curso de treinamento gratuito baseado na Web sobre o desempenho do MongoDB . Esta é uma ótima maneira de aprender mais sobre o poder da indexação.

October 2, 2023