Usando um banco de dados relacional vs objetos JSON para dados de eventos / atividades

Estou trabalhando em um projeto no qual estou tentando decidir entre usar um banco de dados relacional SQL padrão ou objetos JSON para armazenar dados sobre um evento ou atividade.

O projeto armazenará dados em vários tipos de eventos, por isso decidi descrever apenas um tipo de evento para esta pergunta.

O evento de música ao vivo (descrito na íntegra usando o esquema JSON na parte inferior desta pergunta) é um objeto que armazena dados como onde o evento ocorrerá, a hora / data do evento e o custo do evento. O objeto de evento de música ao vivo tem um para um (evento -> nome, evento -> descrição) e um para muitos (evento -> locais, evento -> datas, evento -> tipos de ticket ) relacionamentos. Além disso, o objeto de evento pode conter um ou mais IDs do artista, que se vinculam ao objeto artista. O objeto executante armazena dados de músicos que estão se apresentando no evento de música ao vivo.

Os dados serão consultados pelos usuários usando simples ("Encontre-me eventos com o nome 'x'") e complexo ("Encontre-me eventos com o gênero musical 'x' e o custo 'y' dentro de um raio de 'z' do meu atual localização "). Os dados serão enviados pelos usuários usando um formulário da web.

Como você provavelmente pode perceber pelo esquema JSON definido, eu originalmente usaria objetos JSON para armazenar esses dados, mas ouvi algumas pessoas dizerem que, como meus dados são puramente relacionais, devo seguir os métodos mais antigos.

Eu apreciaria qualquer opinião sobre os prós e contras de cada abordagem, dadas as minhas necessidades. Se você precisar de algo esclarecido, não hesite em perguntar.

{
    "event": {
        "eventID":{
            "type":"string"
        },  
        "eventType":{
            "type":"array",
            "eventTypeItem":{
                "type":"string"
            }
        },
        "eventName":{
            "type":"string"
        },      
        "eventDescription":{
            "type":"string"
        },
        "eventVenueList":{
            "type":"array",
            "eventVenueListID":{
                "type":"integer"
            }
        },
        "eventURL":{
            "type":"string"
        },
        "eventTwitter":{
            "type":"string"
        },
        "eventFB":{
            "type":"string"
        },
        "eventInstagram":{
            "type":"string"
        },
        "eventEmail":{
            "type":"string",
            "format":"email"
        },
        "eventContactPerson":{
            "type":"string"
        },
        "eventDoorTime": {
            "type":"string",
            "format":"date-time"
        },  
        "eventPerformerIDList":{
            "type":"array",
            "liveMusicPerformerID":{
                "type":"integer"
            }
        },  
        "eventSetList":{
            "type":"array",
            "eventPerformerID":{
                "type":"integer"
            },
            "eventPerformerStartTime":{
                "type":"string",
                "format":"date-time"
            },
            "eventPerformerEndTime":{
                "type":"string",
                "format":"date-time"
            }                                   
        },
        "eventDateList": {
            "type":"array",
            "eventDateItem": {
                "type":"string",
                "format":"date-time"
            }   
        },
        "eventDateStartTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventDateEndTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventTicket":{ 
            "type":"array",
            "eventTicketType":{
                "type":"string" 
            },
            "eventTicketLowPrice":{
                "type":"number"
            },
            "eventTicketHighPrice":{
                "type":"number" 
            },
            "eventDatesAdvancePrice": {
                "type":"number"
            }   
        }
    },  
    "performer": {
        "performerID": {
            "type":"integer"
        },
        "performerType": {
            "type":"string"
        },
        "performerName": {
            "type":"string"
        },
        "performerAlternateName": {
            "type":"array",
            "performerAlterateNameItem":{
                "type":"string"
            }
        },
        "performerGenreList": {
            "type":"array",
            "performerGenreItem":{
                "type":"string"
            }
        },
        "performerURL": {
            "type":"string"
        }                                       
    }
}   

Acho que sua pergunta se resume a: quando devo usar uma abordagem NoSQL vs. RDBMS? Você optou pelo JSON cedo (uma decisão NoSQL-ish), talvez porque tenha consumidores do Ajax.

É claro que a resposta para quando usar as abordagens NoSQL versus RDBMS é basicamente sobre que tipo de dados você está trabalhando e quais consumidores você espera ter. Se seus dados são essencialmente relacionais (hierarquias bastante simples, sem tipos de dados estranhos, como imagens ou áudio, relacionamentos previsíveis entre os esquemas que podem ser facilmente descritos em chaves), e espera-se que seus consumidores incluam pessoas que desejam fazer consultas de Business Intelligence (consulta ad hoc), um RDBMS é o caminho a seguir. É bastante fácil transformar uma consulta em uma representação JSON, para não sobrecarregar significativamente os consumidores do Ajax - apenas adiciona um pouco de codificação de transformação aos seus terminais (REST / SOAP / qualquer que seja). Inversamente, se seus dados são muito hierárquicos (esquemas profundos), contêm tipos de dados estranhos, como imagens, áudio, vídeo etc., existem poucas relações entre entidades e você sabe que seus usuários finais não farão BI, noSQL / storing JSON pode ser apropriado.

Obviamente, mesmo essas diretrizes gerais não são sólidas. O motivo pelo qual o Google desenvolveu o Google File System, o MapReduce (trabalho usado por Doug Cutting para criar o Hadoop no Yahoo) e mais tarde o BigQuery (uma maneira [sem esquemas] orientada por NoSQL] de gerenciar dados em grande escala) foi justamente porque eles tinham muitos ad hoc Solicitações de BI e eles não podiam obter abordagens relacionais para escalar até as escalas tera / peta / exa / zetta / yotta que estavam tentando gerenciar. A única abordagem prática era escalar, sacrificando parte da facilidade de uso ad-hoc-query que um RDBMS fornece e substituindo um algoritmo simples (MapReduce) que poderia ser codificado com bastante facilidade para qualquer consulta.

Dado o seu esquema acima, minha pergunta seria basicamente: Por que você não usaria um RDBMS? Não vejo muita razão para não fazê-lo. Nossa profissão deve ser orientada para a engenharia, não para a moda; portanto, nosso instinto deve ser escolher a solução mais fácil que funcione, certo? Quero dizer, seus pontos de extremidade talvez precisem fazer uma pequena tradução se seus consumidores forem Ajaxy, mas seus dados parecem muito simples e parece provável que os usuários comerciais desejem fazer todos os tipos de consultas ad hoc em eventos como eventos de música (que o evento foi o mais frequentado dentro de 50 milhas de nossa capital no ano passado?)

'Não peça conselhos aos elfos, pois eles dirão não e sim.' - Frodo

Eu acredito que há mais considerações aqui que você pode não estar procurando. Existem duas grandes preocupações aqui:

• Armazenamento
• Pesquisa e Recuperação

Armazenamento

Há muitas opiniões sobre por que usar o armazenamento no-sql ou RDBMS para seus dados. Um dos itens mais importantes que julgamos úteis é que podemos definir e armazenar facilmente objetos json no armazenamento sem ter que se preocupar em definir sua estrutura ou relacionamento completo entre diferentes tipos de objetos. Alguns dos outros motivos para usar um NoSql db seriam a capacidade de compartilhar dados automaticamente, pesquisas baseadas em localização e fácil manutenção. Existem muitos bons bancos de dados NoSql por aí, minha preferência pessoal é o MongoDB. No entanto, se você nunca usou o banco de dados NoSql antes, existe uma curva de aprendizado definida à medida que você aprende a reconectar sua mente. A maioria de nós já usa o RDBMS há um tempo e é preciso um esforço consciente para romper com esse hábito. Além disso, você vai querer refazer seu modelo de dados à medida que prossegue com seus esforços e tem uma melhor compreensão dos conceitos. Se a capacidade de refatorar ou remodelar não for uma opção para o seu projeto, sugiro que você se atenha ao que você já sabe melhor.

Procurar

Se você pretende fornecer qualquer tipo de pesquisa que seja utilizável, sugiro fortemente que você use um mecanismo de pesquisa de texto dedicado, como o SOLR, para realizar suas pesquisas. As pesquisas de texto são lentas e, se você tiver vários shards, é ainda mais lento. O SOLR suporta pesquisas de texto rápidas, incluindo parâmetros de pesquisa ponderada, pesquisas baseadas em localização e muito mais. No entanto, o SOLR não é adequado como armazenamento principal de seus dados. Isso significa que você precisará criar mecanismos para inserção dupla e atualização no banco de dados primário e na camada SOLR ao adicionar ou atualizar eventos. Além disso, você deverá manter o SOLR atualizado posteriormente removendo quaisquer eventos desatualizados / finalizados.

Embora isso pareça muito trabalho extra, você se agradecerá pela previsão de usar um mecanismo de pesquisa de texto completo posteriormente. Nenhum banco de dados NoSql ou RDBMS chega perto do desempenho e agilidade do SOLR / Lucene.

Primeiro, se você estiver tentando armazenar dados JSON em qualquer armazenamento, mas não em um banco de dados NoSQL , eu definitivamente o desencorajaria a usar JSON. O motivo é que, se você armazenar seus dados como um arquivo JSON, por exemplo, será extremamente lento abri-los, analisá-los, percorrer-os etc.

Dito isso, posso refinar sua pergunta para: Quais são os prós e os contras do NoSQL e RDBMS ? E já foi respondido milhares de vezes na rede.

Regravando seu projeto, é claro que você pode usar NoSQL ou RDBMS ; No entanto, o que geralmente posso recomendar a você é pensar fora da caixa e procurar outros fatores menos visíveis que possam ajudá-lo a decidir entre as duas opções. Tente ver qual opção poderia acelerar o desenvolvimento? O que é mais adequado para os outros membros da equipe - se você não é um desenvolvedor único. Se você está vendendo isso, qual é mais barato, mais fácil e geralmente mais adequado para seus clientes que não são desenvolvedores?

Dessa forma, você pode finalmente decidir qual caminho seguir, caso contrário, será realmente difícil decidir com base nas informações fornecidas, pois as duas opções podem se encaixar perfeitamente.

Na maioria das aplicações, existem requisitos para

1. Insira dados, execute algum processamento, salve os dados, recupere os dados e consulte-os. Também pode haver um requisito para gerar relatórios sobre os dados.
2. Troque dados entre diferentes partes do sistema ou com sistemas externos

Para alcançar os requisitos para o Item 1, é necessário um método de persistência de dados. Normalmente, se o volume de dados é muito pequeno e o tipo de dados é simples e não requer amplos recursos de pesquisa, uma estrutura de arquivo simples pode ser usada. À medida que os dados se tornam mais complexos, uma estrutura XML (ou mesmo JSON) pode ser usada com os dados ainda armazenados em arquivos. A pesquisa se torna mais problemática. À medida que o volume de dados aumenta e a complexidade das pesquisas aumenta, normalmente é selecionado um banco de dados que fornece métodos padrão do setor para persistência de dados, consultas etc. Os bancos de dados podem ser projetados para lidar com grandes volumes de dados e armazenar, recuperar e pesquisar os dados de maneira rápida e eficiente .

Para atingir os requisitos do Item 2, existem vários métodos diferentes para permitir o intercâmbio de dados entre sistemas, incluindo XML, JSON etc.

Esses métodos permitem que a estrutura de dados seja definida por um usuário e são independentes da linguagem, permitindo que sistemas diferentes troquem dados.

No seu caso particular, você está usando o JSON corretamente e está descrevendo um conjunto de eventos de música. Embora você possa armazenar os dados no formato JSON, pesquisando esses dados, à medida que o número de eventos de música aumenta, será lento e ineficiente.

Usando uma abordagem de separação de preocupações, a melhor abordagem é coletar dados, armazenar em um banco de dados, executar sua consulta com base na entrada do usuário no banco de dados e retornar os resultados no formato JSON para o lado do Cliente para exibir os dados.

Um problema adicional com a abordagem JSON é uma mudança na estrutura de dados. Atualmente, sua estrutura é relativamente simples. Você pode usar essa estrutura por vários meses e, em seguida, um campo adicional é identificado. O que você faz com todos os seus objetos JSON existentes? Atualizar esses seria problemático.

Se você usou um banco de dados, a adição de um campo adicional é relativamente simples e apenas seu código para gerar o JSON precisaria ser modificado em um único local, fornecendo a você todo o novo JSON com o novo campo.

Em resumo, use cada parte da tecnologia para o que foi projetado para JSON para intercâmbio de dados e um Banco de Dados para persistência de dados.

Eu acho que você terá mais sucesso usando o NoSQL do que o SQL para armazenar esses dados, devido às consultas que você precisa fazer.

Além disso, apenas porque alguns dados são puramente relacionais não significa mais, eles devem ser persistidos em algum RDBMS (SQL). Os dados relacionais da IMO se traduziriam melhor em bancos de dados gráficos.

É claro que você também pode escrever as consultas no SQL, mas o desempenho será péssimo por causa do número de junções que você precisará (considerando que seus dados serão um pouco normalizados e nem todos em uma tabela de Eventos).

Mas, em conclusão, você terá mais liberdade usando o NoSQL (portanto, JSON ou algum outro formato suportado pelo banco de dados), considerando que você pode modificar seu esquema no futuro sem levar em consideração os dados já persistentes.

Considerando o NoSQL, você também pode procurar em bancos de dados de gráficos se planeja usar consultas muito complexas, pois elas oferecem vantagens em criá-las facilmente e também em executá-las muito rapidamente.

Eu acho que você deve usar os dois e não vejo isso como uma decisão 'versus'.

Um banco de dados relacional faz sentido para armazenamento e recuperação rápidos e eficientes de dados que possuem propriedades relacionais.

O JSON é um ótimo formato de dados porque é simples, leve e ideal para transmitir dados brutos em um formato muito básico, com uma sintaxe adequada para armazenar e trocar informações de texto. É ótimo para transmitir pequenas quantidades de dados entre um navegador e um servidor. Não é um formato tão fácil começar a usar para consultas de dados do tipo relacional.

Então, eu recomendaria SQL para o armazenamento de dados e JSON para o formato de transporte de dados.

É verdade que não há opções de valor-chave no SQL, como Mongo, Redis etc. Isso teria a vantagem de mapear possivelmente mais simples para o formato JSON, mas geralmente é um pouco mais difícil de usar para consultas. O principal obstáculo para eles é o desconhecimento da comunidade de TI em geral, especialmente quando comparado ao SQL, que é tão conhecido e possui uma vasta gama de recursos e conhecimentos disponíveis para quase todas as situações imagináveis.