NoSQL não é um termo muito bem definido e todas as soluções que funcionam com este nome têm características muito diferentes, portanto, muito pode ser possível ou não, dependendo do que exatamente você está planejando fazer com ele.
Basicamente, você pode usar algumas das soluções mais gerais, como talvez o MongoDB ou o Cassandra, para simplesmente substituir seu banco de dados relacional atual. Em alguns casos, isso faz mais sentido nos outros menos, mas funcionará quando a equipe se acostumar com isso. Certas coisas serão mais fáceis então, outras serão mais difíceis e você deve ponderar essas opções umas contra as outras e decidir (o que muitas vezes significará que não há vantagens grandes o suficiente e o simples fato de que todos na equipe se sentem mais à vontade com os relacionais). e o SQL facilitará a decisão)
Outras soluções NoSQL que são mais especializadas não são boas candidatas para substituir seu banco de dados relacional, como bancos de dados de gráficos ou armazenamentos de valores chave simples. Então, vamos aqui falar principalmente sobre os bancos de dados que são, pelo menos em algum grau, semelhantes aos bancos de dados relacionais.
Cenário 1
Onde eu trabalho, nós temos exatamente este cenário, apesar de bem mais complexo, com muitos atributos diferentes por artigo. Alguns desses atributos em hierarquias como a Apple - > iPad - > Ar.
Os dados ainda são armazenados em um banco de dados relacional. Mas: pesquisar isso em tempo real se tornou uma dor. Com o SQL, era lento e o código teria sido terrivelmente complexo. Seleciona várias tabelas, com a opção adicional de excluir determinados atributos como "não azul".
Neste caso, o Apache Solr ou o Elastic Search são uma solução. Embora, é claro, os dados sejam duplicados do banco de dados relacional.
Mas a partir daqui nossa experiência com esse tipo de armazenamento de documentos mostrou que ele pode lidar com certos problemas muito bem e vamos considerar substituir parte da estrutura relacional existente por algum outro tipo de armazenamento. Portanto, não o banco de dados inteiro onde também armazenamos todos os dados transacionais, como pedidos, etc., mas, por exemplo, retiramos todas as informações de atributos que podem ser manipuladas muito melhor no agregado, como estruturas de dados do NoSQL.
Cenário 2
É difícil dizer, já que o que você descreve provavelmente é apenas uma parte muito pequena do tratamento do usuário. Ter armazenamento sem esquema é uma vantagem em muitos bancos de dados NoSQL. Mas alguns bancos de dados relacionais permitem armazenar esses dados também (desde que você não precise consultá-los via SQL na maioria dos casos).
O Cassandra, por exemplo, permitiria que você definisse famílias de colunas nesse caso, onde seu primeiro conjunto de atributos seria uma dessas famílias e os atributos da variável outro.
Como alguém disse: NoSQL é menos sobre armazenamento e mais sobre a consulta. Então, a questão é qual será o caso de uso típico para essas consultas.
Um problema típico seria os dados transacionais aqui. Se você quiser armazenar pedidos, um caminho seria um esquema em que os usuários e seus pedidos formam um agregado (tipo de documento do usuário que contém os pedidos como subdocumentos). Isso tornaria o usuário junto com seus pedidos muito simples e rápido, mas tornaria muito difícil recuperar todos os pedidos do mês passado para as estatísticas de vendas.
Além disso, os pontos strongs das soluções NoSQL são que pode ser mais fácil executá-los em vários clusters, se você tiver que trabalhar com conjuntos de dados muito grandes.
Conclusão: Ambos os cenários podem ser modelados com certas soluções NoSQL, mas não acho que (supondo que eles tenham que ser executados em um ambiente maior) eles realmente justificam um grande esforço extra no aprendizado , treinamento e implementação e talvez algumas outras desvantagens adicionais, porque ambos não são específicos o suficiente para realmente alavancar os pontos strongs do NoSQL. Pelo menos não nessa forma simples que você descreve. As coisas podem se tornar muito diferentes, uma vez que alguns aspectos que você descreveu seriam muito proeminentes em seu cenário de uso, como no cenário um, os dados do atributo se tornam muito complexos ou no cenário dois, os campos variáveis se tornam a maior parte dos dados armazenados com cada usuário.