NoSQL: O que são dados não estruturados?

No momento, estamos rodando com recursos limitados com nossa solução baseada em servidor mssql.

Agora temos muitas opções tradicionais em relação ao próximo passo para lidar com a carga:

compre CPUs e IO mais rápidos
dividir alguns clientes para separar o servidor
mover db para o cluster

Todos são caros em termos de licenciamento e hardware ou tempo. Portanto, quero adicionar outra opção, movendo todo o sistema para uma solução escalável que o nosql engine cassandra promete.

No entanto, não tenho certeza e não tenho experiência com bancos de dados noSQL, portanto, preciso entender a estrutura dos dados "não estruturados".

Em nosso aplicativo, basicamente armazenamos os dados inseridos pelos usuários de várias maneiras como listas de "valores-chave". Há uma tabela pai, que contém o elemento principal (como um Pedido) e uma tabela filho com os pares de valores-chave que compreendem o conteúdo do pedido (como Order_Lines).

Em termos de negócios, Order e OrderLines são uma unidade. Porém, devido ao RDBMS, eles são armazenados em tabelas e devem ser unidos o tempo todo.

Durante as operações, às vezes escolhemos carregar apenas a parte superior, mas na maioria das vezes carregamos a linha principal + alguns KVPs para exibir algumas informações úteis.

Por exemplo, em uma lista de visão geral, mostramos o identificador de cabeçalho + alguns valores nas colunas de cada linha.

ATUALIZAÇÃO: Armazenamos formas de qualquer tipo. Então, basicamente nós armazenamos "documentos". No entanto, precisamos preparar e pesquisar esses formulários por qualquer valor, tipo, etc. O controle de acesso a dados adiciona outra camada de compexidade ao banco de dados.

Como você pode imaginar, a quantidade e a disponibilidade de determinados KVPs variam de objeto para objeto. Não há possibilidade válida de criar tabelas únicas para cada tipo de objeto, pois teríamos que criar milhares de tabelas para as diferentes combinações de dados.

Esse tipo de "dicionário", como conjuntos de dados, seria melhor armazenado em um banco de dados noSQL? E teremos benefícios de desempenho com isso? Cassandra modelaria esses head + KVPs como um conjunto de dados? Olhando para a página da web do cassandra e alguns tutoriais, tenho a impressão de que não há muita diferença entre nosso RDBMS e o cassandra em termos de organização de dados - deixando-nos a mesma quantidade enorme de junções se você quiser selecionar 5 KVPs para uma lista para cada linha.

A iluminação é bem-vinda, também há indicações de artigos que explicam os problemas.

— thst
fonte

Respostas:

Existem alguns conceitos que precisam ser distinguidos. Um é sobre estrutura e o outro sobre esquema.

Dados estruturados são aqueles em que o aplicativo conhece antecipadamente o significado de cada byte recebido. Um bom exemplo são as medições de um sensor. Por outro lado, um fluxo do Twitter não é estruturado. Esquema é sobre quanto da estrutura é comunicada ao DBMS e como é solicitado a impor isso. Ele controla quanto o DBMS analisa os dados que armazena. Um DBMS necessário ao esquema, como o SQL Server, pode armazenar dados não analisados (varbinary) ou dados analisados opcionalmente (xml) e dados totalmente analisados (colunas).

Os DBMSs do NoSQL estão em um espectro de sem análise (armazenamento de valores-chave) para cima. Cassandra oferece funcionalidade reativamente rica a esse respeito. Onde eles diferem acentuadamente dos armazenamentos relacionais está na uniformidade dos dados. Depois que uma tabela é definida, apenas os dados que correspondem a essa definição podem ser mantidos lá. No Cassandra, no entanto, mesmo que colunas e famílias sejam definidas, não é necessário que duas linhas na mesma tabela se pareçam. Cabe ao designer do aplicativo decidir quanto vale em uma única linha (também conhecida como documento) e o que é mantido separadamente, vinculado por ponteiros. Com efeito, quanta desnormalização você deseja.

A vantagem é que você pode recuperar um conjunto completo de dados com uma única leitura seqüencial. Isso é rápido. Uma desvantagem é que você, programador do aplicativo, agora é o único responsável por todos os problemas de integridade de dados e compatibilidade com versões anteriores, para sempre, de cada pedaço de código que toca nesse repositório de dados. Isso pode ser difícil de acertar. Além disso, você está bloqueado em um ponto de vista dos dados. Se você digitar suas linhas pelo número do pedido, como informar sobre a venda em um produto, região ou cliente específico?

— Michael Green
fonte

No nosso caso, os dados que armazenamos são basicamente dados. O usuário define o formulário no tempo de execução e pode modificá-lo a qualquer momento. Um formulário pode ser construído a partir de milhares de campos. Isso pode acontecer se os dados do tipo lista forem capturados. Se soubéssemos os dados antecipadamente - no momento do design do banco de dados, nós os normalizaríamos. Seu comentário sobre a visão dos dados me faz pensar: se os formulários são escritos como documento, como você os cria para uma lista ou classifica os dados por um campo na vida real? Mapeie-reduza os dados, lembre-se e prepare a lista no código?

— Th

Historicamente, era tudo do lado do cliente - você recuperava seus documentos e fazia o que precisava. O CQL possui cláusulas com as quais qualquer desenvolvedor SQL estaria familiarizado. Map Reduce é a arquitetura básica para grandes conjuntos de dados. E parece que o Cassandra 3.0 terá vistas materializadas .

— Michael Green

Apesar do mainstream das bases de dados noSQL IMHO, a decisão sobre a adoção dessa tecnologia deve ser tomada de acordo com as realizações necessárias de acordo com as informações armazenadas, não apenas atendendo ao desempenho que você tem atualmente. Isso significa que talvez sua melhor opção seja manter o banco de dados SQL e melhorar seu HW.

Além disso, li algo na sua pergunta que me fez pensar. Não há muito sobre o status atual do seu banco de dados, mas sua frase "nós basicamente armazenamos os dados inseridos pelos usuários de várias maneiras como listas de" valores-chave "" me faz pensar se o problema não seria um modelo de dados ruim, e não a falta de recursos físicos. Eu gerenciei tabelas realmente grandes (+10 bilhões de linhas) com desempenho incrível em bancos de dados SQL "tradicionais".

Não estou dizendo que está errado, apenas, pois é claro que não posso avaliá-lo no modelo de dados certo com tão pouca informação sobre sua solução atual, mas pense em revisitar seu modelo de dados como uma opção adicional junto com o resto, pois você pode encontrar alguma pista arranhando lá.

Geralmente, as listas de valores-chave são excelentes como compensação quando você não pode implementar o modelo em seu estado final, porque você não conhece as diferentes chaves que terá de enfrentar ou quando precisará dos valores de uma das opções possíveis. teclas para um determinado elemento. Mas, quando implementado, geralmente gosto de repensar essas decisões depois de um tempo, quando você reuniu quantidade suficiente de informações para identificar o caso comum de uso e decidir se a decisão do modelo de dados é a melhor. Se você sabe que terá um certo número de chaves, tente fazer um benchmark com o design de uma tabela regular da maneira tradicional

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

... e adicionando os índices correspondentes. Experimente e meça os planos de execução com as duas abordagens. Você pode se surpreender especialmente se reunir mais de uma chave de cada vez, pois, entre outras vantagens, o tamanho do bloco de dados deve ser reduzido e, portanto, o desempenho seria melhorado.

Espero que isso ajude, ou pelo menos amplie as possibilidades e abra uma nova linha de investigação.

— LironCareto
fonte

Agradeço sua resposta, mas, de fato, a situação é assim, que realmente não sabemos a estrutura dos dados. Armazenamos dados de formulários e não conhecemos a estrutura do modelo do formulário. Sabemos, é claro, no aplicativo, mas é dinâmico e pode ser alterado a qualquer momento.

— Th

Entendido. Eu não sei o quão desafiador é isso, mas como uma idéia para tentar, funcionaria para criar uma tabela contendo o conjunto de chaves comuns referenciadas na tabela preenchida pelo usuário por um FK em execução, talvez um INTEGER? Talvez tenha um desempenho um pouco melhor do que indexar uma coluna varchar que, se estiver mudando muito dinamicamente, acho que não será curta. E isso reduziria o tamanho do índice também.

— LironCareto 28/08/2015

Isso nos afasta da questão, mas discutimos certas limitações nas possibilidades do usuário. Por exemplo, reduza os campos máximos da tabela de aplicativos para 10 campos db baunilha varchar db. Essa é uma desnormalização do esquema para selecionar basicamente o conjunto de dados principal e os 10 valores da coluna do aplicativo de uma só vez ou com um máximo de uma junção na tabela db extra. Ao alterar os valores relevantes, teríamos que modificar essa linha de banco de dados também. Isso parece viável e reduz a quantidade de junções em até 10 para um select exibir a tabela de aplicativos. No entanto, alterar a definição da coluna de aplicativos do usuário é muito caro.

— thst

Está tudo bem, não se preocupe. Penso que entendo o seu ponto de vista e sua abordagem me parece uma boa troca entre melhoria de desempenho e viabilidade. É importante ter estatísticas de uso, obviamente, para determinar esses campos. Você comparou? Pelo menos, pode levar algum tempo até você encontrar uma solução (melhor? Definitiva?) Ou talvez descobrir que você pode executar isso por um longo tempo.

— LironCareto 28/08/2015