Sugestão de banco de dados para uma comunidade de rede social / base de conhecimento?


12

Estou pesquisando vários tipos de banco de dados e DBMS para um novo projeto que pretendo iniciar no verão.

Desenvolvi sistemas no MySQL e no postgreSQL, agora pretendo expandir meu conhecimento e experiência em bancos de dados.

Meu projeto será um tipo de rede social / coisa agregada de conhecimento. (ainda não desenvolveu um termo para descrevê-lo ainda).

Eu estive olhando para:

  • Cassandra (use seu próprio tipo de linguagem de consulta); Parece ser bom para conteúdo rico em recursos e para oferecer execução de consultas de alto desempenho. No entanto, não estou muito interessado nisso, pois requer um ambiente java para trabalhar e eu preferiria não ter nada a ver com o Oracle.
  • MongoDB (tipo de DBMS noSQL); grande escalabilidade, no entanto, você perde todos os recursos já disponíveis na linguagem SQL comprovada, como consultas de informações comerciais.

Requisitos do sistema:

  • Dados Texto, datas, horas, xml, pequenas ints, blob,
  • Estrutura / comportamento : 3NF normalizado, não em tempo real, relacional, escalável, robusto
  • Ambiente: unix / linux, sem JAVA !, de preferência executado em C

Eu queria saber se você poderia me indicar outros sistemas de banco de dados que eu deveria pesquisar.

Também dei uma olhada nos bancos de dados relacionais de objetos, gosto bastante da ideia deles trabalhando com objetos PHP (PDO), no entanto, seu desempenho parece um pouco ruim.

Visto que haverá DBAs aqui, qualquer feedback sobre esses sistemas que você operou será apreciado.

obrigado


3
Se você deseja 3nf normalizado, precisa fazer um armazenamento relacional. Período.
JNK

2
Eu não batia no Java apenas porque é "Oracle". Use a ferramenta certa para o trabalho. Se Java é a melhor ferramenta, eu usaria. Se C é o trabalho certo, use-o. Concentre-se no que cada ferramenta oferece, prós e contras. Tome uma decisão bem educada sobre isso (o mesmo com o lado do DB), em vez de se basear no sentimento.
31512 Chris Aldrich

Respostas:


4

Seus requisitos abstratos gritam "PostgreSQL" para mim. No entanto, acho que vale a pena ficar a par do que a burguesia está fazendo, então aqui está uma lista de várias coisas que você pode querer verificar.

Coisas grátis

  • CouchDB - um dos primeiros bancos de dados NoSQL, poderoso sistema de consulta de mapeamento / redução, altamente distribuído e tolerante a falhas. Um dos melhores candidatos ao NoSQL.
  • Hyperdex - tabela de hash distribuída muito nova, com recursos de pesquisa.
  • Riak - tabela de hash distribuída digna de algum respeito.

Coisas grátis estranhas

  • Metakit - mais um banco de dados incorporado como SQLite, mas não baseado em SQL, portanto, mais processual.
  • FramerD - bem como um banco de dados clássico de "rede", muito centrado em ponteiros. Talvez morto?
  • Magma - Smalltalk OODBMS. Legal, mas não bem documentado.

Material não livre

  • AllegroGraph - banco de dados RDF (gráfico), suporta SPARQL. Lisp-flavored.
  • Caché - um banco de dados relacional / OO híbrido, originalmente baseado em MUMPS (IIRC).
  • Objetividade - Um dos últimos OODBs realmente grandes. Muito poderoso, impressionante e caro.
  • VoltDB - Banco de dados relacional altamente escalonável. Suporta "a maioria" do SQL. Muito novo. Eu acho que eles também têm uma versão da comunidade.

Conclusão

Eu não usei nenhuma dessas coisas extensivamente. Eu brinquei um pouco com a maioria deles e sempre voltei ao PostgreSQL. Analisando seus requisitos, o único que o PostgreSQL não atende prontamente é a escalabilidade. Por outro lado, para meus propósitos, é muito mais fácil jogar US $ 4000 em hardware em uma única máquina de banco de dados dedicada do que jogar US $ 4000 em nós da nuvem ou máquinas de baixo custo nesse problema. E existem maneiras de obter escalabilidade com o PostgreSQL, como o EnterpriseDB .

É muito divertido brincar com essas coisas de lado, mas quando chega a hora de colocar dados valiosos e irreproduzíveis de produção em algo, vários atributos entediantes como confiabilidade, estabilidade e viabilidade a longo prazo acabam surgindo.

Experiência de pensamento para você

Considere isto. Imagine que você é Mark Zuckerberg e precisa desistir de sua base de código ou de seus dados. Você pode manter toda a sua equipe de desenvolvimento, mas precisa desistir de todo o seu código - todas as linhas, dizer até todas as memórias dos desenvolvedores de como tudo foi implementado -, mas você deve manter todas as suas contas de usuário e todos os seus usuários carregados dados e tudo isso, ou você pode desistir de todos os dados. Mantenha todas as estruturas, servidores e configuração, a instalação, mas perca todas as linhas em todas as tabelas e todos os bancos de dados.

Deveria ser óbvio que seria pior perder os dados. Por que todos os seus usuários regeneram todos esses dados? Pense em todos os dados de marketing perdidos, e é assim que o Facebook realmente ganha dinheiro. E há muitos empreendedores que aproveitam a oportunidade para fazer com que as pessoas usem seu clone do Facebook - agora todos os ex-usuários desprivilegiados do Facebook estariam por aí pensando em alternativas. Por outro lado, se eles perderem a base de código, poderão reconstruí-la, provavelmente até melhor do que é agora, mas poderão ter algo online em pouco tempo. Caramba - eles provavelmente poderiam compraro Facebook de outra pessoa clona a base de código e carrega-a com os dados reais, mas você não pode simplesmente copiar os dados deles. Se o Facebook ainda tiver os dados importantes de todos em seus servidores, o incentivo para sair é muito menor. Ainda ruim, mas muito menos. Surpreendentemente menos.

A ironia é que é muito mais fácil perder todos os seus dados em um acidente do que perder todo o seu código. Para a maioria das empresas de internet, porém, os dados são a empresa, é o seu bem mais valioso. E esse é um forte motivo para considerar o uso de um banco de dados relacional tradicional, testado pelo tempo, antiquado e pouco sexy.


Resumo do longo tópico de comentário excluído daqui: "É injusto sugerir que os armazenamentos NOSQL de alguma forma aumentam a probabilidade de perda de dados".
Jack diz que tente topanswers.xyz

O que estou dizendo tem a ver com a idade e o amplo uso, não com o design do mecanismo de armazenamento.
Daniel Lyons

6

Considere também que não há razão para que você não possa usar um banco de dados relacional para algumas coisas e o banco de dados nosql para outras coisas.


0

Falando em nosql, só tenho uma coisa a acrescentar sobre a referência do Facebook:

Se você planeja escalar muito grande, sugiro que você obtenha um sysadmin do mecanismo de banco de dados amigável versus o desenvolvedor.

Saia do MongoDB amigável e super rápido para desenvolvedores, que não pode ser escalonado geograficamente disperso e não tem como fazer backup de maneira eficiente e fácil. Embora aqui usemos o MongoDB, parece que o Riak ou CouchDB parece melhor nas especificações para administradores de sistemas (não tenho experiência com Riak ou CouchDB)


2
Se você optar por escalar grande, é porque você já escalou de micro para minúsculo, e de minúsculo para pequeno, e ao longo do caminho aprendeu algumas coisas que o ajudarão a fazer as escolhas certas. Quando estiver pronto para escalar, você pode pagar aos engenheiros que sabem escalar.
Jcolebrand
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.