--- Atualização ---
Obrigado pelos comentários e pela ajuda até agora. E peço desculpas por não especificar mais a questão. Atualizei a pergunta abaixo.
--- Atualizar ---
Atualmente, sou solicitado a desenvolver uma estrutura de banco de dados para uma quantidade bastante grande de dados. Estou debatendo entre implementar um banco de dados gráfico em vez de um banco de dados de relação "normal" e queria saber quais são as desvantagens se os dados não contiverem necessariamente nenhum relacionamento? Os nós separados e desconectados podem ser utilizados da mesma forma que uma tabela/linha em uma tabela?
Estou perguntando isso porque, no momento, não há necessidade de relacionamentos, mas estou tentando testar o banco de dados no futuro (com a antecipação de relacionamentos) para expandir as habilidades dos dados. Se for de alguma ajuda, estou debatendo entre OrientDB/Neo4j ou mySQL/postgreSQL.
Um exemplo:
digamos que temos um banco de dados cheio de ações. O estoque pode ser comprado e vendido praticamente a qualquer hora / dia por qualquer pessoa (desde que o mercado esteja aberto). Agora este banco de dados pode ser um banco de dados de relação normal: Table 1: IDs | Products | Prices | Sizes | Dates. Mas também poderia ser organizado como um banco de dados de relacionamento Node 1: Stock A | Node 2: Stock B.
Se eu apenas usar o banco de dados para armazenar informações de ações, parece-me que um banco de dados normal será melhor. Mas isso é verdade? Isso me afetará negativamente trabalhando com um banco de dados de relacionamento / será melhor trabalhar com um banco de dados normal? Há desvantagem em organizar meus dados em nós, em vez de linhas?
Uma foto para ilustrar tudo:
O banco de dados será usado principalmente para produtos comprados e vendidos, como estoques, no entanto, eles também possuem outras informações, como locais anexados a eles. Estou tentando antecipar a implementação de recursos como recomendação de produtos ou mesmo a previsão dos próximos produtos a serem comprados por alguém.
A maioria das consultas do banco de dados será por produto.
Retirado do banco de dados: 100 a 1000 vezes por dia.
Empurrado para o banco de dados: 20.000 por dia.
Uma pergunta adicional que pode revelar uma desvantagem:
Quão fácil será ir de relação para gráfico ou de gráfico para relação. Algum lock-in perigoso?
Obrigado por toda a ajuda, os comentários têm sido ótimos até agora! R
Acho que você está cometendo um erro bastante comum aqui ao selecionar tecnologias NoSQL para ser "à prova de futuro" sem entender as compensações. Em caso de dúvida, comece com o PostgreSQL e descubra que você sempre pode configurar um banco de dados gráfico ou outro banco de dados NoSQL ao lado, conforme necessário. Além disso, você pode percorrer gráficos no PostgreSQL, mas lembre-se de que está trabalhando com conjuntos e, portanto, é muito, muito diferente de um banco de dados gráfico com diferentes benefícios e desvantagens.
Sua compensação básica é entre a flexibilidade de entrada de dados e a capacidade de utilizar dados de forma flexível na saída. Os bancos de dados NoSQL (incluindo bancos de dados gráficos) sacrificam o último pelo primeiro e, como muitas vezes você precisa da capacidade de executar consultas ad hoc em conjuntos de dados, provavelmente deseja um RDBMS em algum lugar. Isso significa que, se você tiver um bom modelo de dados, deverá ser capaz de adicionar servidores de banco de dados adjuntos ao seu ambiente para fins especiais de seu RDBMS não irá lidar com isso.
No entanto, existem algumas razões específicas pelas quais, se você está pensando em adicionar várias soluções NoSQL, por que eu recomendaria começar com PostgreSQL em vez de MySQL e isso tem a ver com o desempenho de estruturas de banco de dados compatíveis com NoSQL e o fato de que o PostgreSQL suporta COM RECURSIVE expressões de tabela comuns. Essa abordagem (COM CTEs RECURSIVAS) permite que coisas como hierarquias e gráficos sejam percorridos usando instruções SQL recursivas que podem atravessar caminhos repetidamente. Eles também são relativamente eficientes para uma abordagem baseada em conjunto e, portanto, se você acabar com muitos problemas de modelagem de parte/subparte, poderá fazer isso diretamente no PostgreSQL sem muito trabalho. No entanto, se isso não funcionar, você também pode representar os dados com mais facilidade de uma maneira mais fácil de importar para o banco de dados NoSQL. Assim, você vai mais longe e se integra melhor. Você pode até configurar "tabelas" estrangeiras em seu banco de dados NoSQL e executar consultas nele de dentro do Pg!
Mais sobre a troca 1
Os bancos de dados de gráficos surgiram da necessidade de fazer travessia binária rapidamente em grandes conjuntos de informações. O exemplo óbvio pode ser um site de rede social como o LinkedIn, que pode querer dizer rapidamente a que distância você está de outro usuário (em termos simples, isso significa essencialmente que eles foram projetados para reproduzir "seis graus de Kevin Bacon"). Normalmente, em um banco de dados de gráfico, você está essencialmente percorrendo nós usando o que costuma ser descrito como "frases de três palavras" que representam os gráficos. A esse respeito, você está olhando essencialmente para algo como "John fez amizade com Jane" e percorrendo esse caminho. Normalmente, a API é relativamente navegacional.
Um banco de dados relacional é realmente projetado para trabalhar com conjuntos de informações. Normalmente, ao desistir de bancos de dados relacionais, também se está desistindo de operações de conjunto. Isso pode ser um grande problema. Muitas vezes, é mais rápido operacionalmente e em termos de tempo de desenvolvimento ser capaz de definir operações em vez de navegar, agregar e relatar. Essa é uma grande diferença e, se o seu caso de uso se encaixa em um fluxo de trabalho relacional, tenho dificuldade em imaginar que um banco de dados gráfico o ajudará.
Mais sobre a compensação 2: modelos de consistência
Uma segunda coisa a investigar e ter em mente é a questão de qual modelo de consistência seu banco de dados usa. Mesmo com RDBMS "compatíveis com ACID", há uma variedade de modelos de consistência baseados em diferentes níveis de isolamento de transação que podem ser usados para evitar problemas. Se seus dados forem importantes, os modelos de consistência padrão do RDBMS vão se sair muito melhor do que a maioria dos modelos NoSQL porque oferecem mais garantias tanto para o DBA quanto para o aplicativo. Os bancos de dados gráficos são um campo relativamente grande e cada fornecedor pode ter algumas diferenças em seu modelo de consistência. Isso não é necessariamente algo que irá descartar o uso, mas é algo para ser cauteloso ao olhar para as soluções como um todo.
Observe que a flexibilidade do esquema é uma bênção e uma maldição no mundo NoSQL e isso também afeta os bancos de dados gráficos. É uma bênção porque você pode começar a trabalhar nos estágios iniciais mais rapidamente, mas é uma maldição porque as forças de operação definidas de um RDBMS dependem de um esquema fixo, e aqueles que relaxam isso até certo ponto (Informix, por exemplo, suporta linhas irregulares em conjuntos de retorno) requerem conhecimento do programador dos locais onde esses requisitos foram relaxados.