Quais sistemas de banco de dados uma empresa de startups deve considerar?

StackOverflow https://stackoverflow.com/questions/2839505

Pergunta

No momento, estou desenvolvendo o protótipo de um aplicativo da Web que agrega grande número de entradas de texto de um grande número de usuários. Esses dados devem ser exibidos com frequência e frequentemente atualizados. No momento, eu armazenei o conteúdo dentro de um banco de dados MySQL e uso a camada Nibernate ORM para interagir com o banco de dados. Eu tenho uma tabela definida para usuários, funções, envios, tags, notificações e etc. Gosto dessa solução porque funciona bem e meu código parece bom e sensato, mas também estou preocupado com o desempenho do MySQL assim que o tamanho do nosso banco de dados atinge um número significativo. Eu sinto que isso pode ter dificuldade em executar operações de junção com rapidez suficiente.

Isso me fez pensar em sistema de banco de dados não relacional, como MongoDB, Couchdb, Cassandra ou Hadoop. Infelizmente, também não tenho experiência. Eu li algumas boas críticas no MongoDB e parece interessante. Fico feliz em passar o tempo e aprender se alguém é o caminho a percorrer. Eu apreciaria muito qualquer um que oferecesse pontos ou problemas a serem considerados quando não houver DBMs relacionais?

Foi útil?

Solução

As outras respostas aqui se concentraram principalmente nos aspectos técnicos, mas acho que há pontos importantes a serem feitos que se concentram no Empresa start-up aspecto das coisas:

  • Disponível de talento. O MySQL é muito comum e você provavelmente achará mais fácil (e, mais importante, mais barato) encontrar desenvolvedores, em comparação com os sistemas de banco de dados mais rarificados. Essa base maior de desenvolvedores também significará mais tutoriais, uma comunidade de apoio mais ativa etc.
  • Facilidade de desenvolvimento. Novamente, como o MySQL é tão comum, você descobrirá que é o banco de dados para muitos sistemas / serviços. Esse terreno comum pode tornar qualquer integração externa um pouco mais fácil.
  • Você está se preparando para uma situação que pode nunca existir e é gerenciável se o fizer. Muito poucas empresas (startups de esquecimento) chegam perto dos limites do MySQL e com todo o respeito (e estou apenas adivinhando aqui); A probabilidade de sua startup atingir o tipo de taxa de transferência de dados para prejudicar um mysql db de adequadamente estruturado e com recursos bem zero.

Basicamente, não gaste seu tempo (== dinheiro) preocupando -se com qual banco de dados usar, pois o MySQL pode lidar muito de dados, é bem comprovado e bem suportado.

Voltando ao lado técnico das coisas ... algo que terá um distante Maior impacto na velocidade do seu aplicativo do que a escolha do banco de dados é com que eficiência os dados podem ser em cache. Um cache eficaz pode ter efeitos dramáticos na redução da carga de banco de dados e acelerar a responsividade geral de um aplicativo. Eu gastaria seu tempo investigando soluções de cache e garantindo que você esteja desenvolvendo seu aplicativo de tal maneira que ele possa fazer o melhor uso dessas soluções.

FYI, minha solução de cache de escolha é Memcached.

Outras dicas

Até agora, ninguém mencionou o PostgreSQL como alternativa ao MySQL no lado relacional. Esteja ciente de que o MySQL Libs são Pure GPL, não LGPL. Isso pode forçá -lo a lançar seu código se você vincular a eles, embora talvez alguém com mais experiência legal possa lhe dizer melhor as implicações. Por outro lado, vincular a uma biblioteca MySQL não é o mesmo que apenas se conecta aos comandos do servidor e emitir, você pode fazer isso com a fonte fechada.

Postresql é geralmente a melhor substituição gratuita do Oracle e a licença BSD deve ser mais amigável aos negócios.

Como você prefere um banco de dados não relacionado, considere que a transição será mais dramática. Se você precisar personalizar seu banco de dados, também deverá considerar o fator de tipo de licença.

Há três coisas que realmente têm um impacto profundo em qual é a sua melhor opção de banco de dados e você não menciona:

  1. O tamanho dos seus dados ou se você precisar armazenar arquivos no seu banco de dados.
  2. Um grande número de leituras e muito poucas (até restritas) escreve. Nesse caso mais do que um banco de dados, você precisa de um diretório como LDAP
  3. A importância da distribuição de dados e/ou replicação. A maioria dos bancos de dados relacionais pode ser mais ou menos bem replicada, mas devido ao seu conceito/design, não lida com a distribuição de dados também ... mas você lidará com o máximo de dados que não se encaixam em um servidor ou têm direitos de acesso que precisam de separados especiais separados /servidores extras?

No entanto, a maioria das pessoas irá para um banco de dados não relacional apenas porque não gosta de aprender SQL

O que você acha que é uma quantidade significativa de dados? Mysql, e basicamente a maioria dos mecanismos de banco de dados relacionais, pode lidar com uma quantidade bastante grande de dados, com índices adequados e esquema de banco de dados SANE.

Por que você não tenta como o MySQL se comporta com maior quantidade de dados na sua configuração? Faça alguns scripts que geram dados realistas para o banco de dados de teste MySQL, e gerem alguma carga no sistema e veja se é rápido o suficiente.

Somente quando não for rápido o suficiente, comece a considerar otimizar o banco de dados e alterar para diferentes mecanismos de banco de dados.

Tenha cuidado com Nibernate, é fácil fazer uma solução agradável e fácil de codificar, mas tem um desempenho ruim com grande quantidade de dados. Por exemplo, se deve usar preguiçosos ou ansiosos com as associações deve ser cuidadosamente considerado. Não quero dizer que você não deve usar o Nibernate, mas certifique -se de entender como o Nibernate funciona, por exemplo, o que significa "n + 1 seleciona" -Problem.

Meça, não assuma.

Bancos de dados relacionais e bancos de dados NoSQL podem escalar enormemente, se o aplicativo for escrito corretamente em cada caso e se o sistema em que ele executar estiver ajustado corretamente.

Portanto, se você tiver um caso de uso para o NOSQL, codifique -o. Ou, se você estiver mais confortável com o relacional, codifique isso. Em seguida, meça o desempenho do desempenho e como é escalado, e se estiver tudo bem, vá em frente, se não, analise o porquê.

Somente depois de entender seu problema de desempenho, você procurar tecnologia exótica, a menos que você esteja confortável com essa tecnologia ou deseje experimentá -la por algum outro motivo.

Eu sugiro que você experimente cada banco de dados e escolha o que torna mais fácil desenvolver seu aplicativo. Vamos para http://try.mongodb.org para experimentar o MongoDB com um tutorial simples. Não se preocupe tanto com a velocidade, pois no início do desenvolvedor é mais valioso que o tempo da CPU.

Sei que muitos usuários do MongoDB conseguiram abandonar o ORM e a camada de cache. O modelo de dados de Mongo está muito mais próximo dos objetos com os quais você trabalha do que as tabelas relacionais, para que você possa armazenar diretamente diretamente seus objetos como é, mesmo que eles contenham listas de objetos aninhados, como uma postagem no blog com comentários. Além disso, como o Mongo é rápido o suficiente para a maioria dos sites, você pode evitar lidar com as complexidades do cache e geralmente entrega um site mais em tempo real. Por exemplo, wordnik.com relatado 250.000 leituras/s e 100.000 inserções/s com um objeto de 1,2 TB/5 bilhão DB.

Existem algumas maneiras de se conectar ao MongoDB da .NET, mas não tenho experiência suficiente com essa plataforma para saber qual é o melhor:

Isenção de responsabilidade: trabalho para 10gen no MongoDB, por isso sou um pouco tendencioso.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top