Quando é hora de alterar os back-ends do banco de dados?

https://stackoverflow.com/questions/74261

09-06-2019
|

Pergunta

Existe uma regra geral a seguir ao armazenar dados de aplicativos da web para saber qual back-end de banco de dados deve ser usado?O número de acessos por dia, o número de linhas de dados ou outras métricas que devo considerar ao escolher?

Minha ideia inicial é que a ordem para isso seria parecida com a seguinte (mas não necessariamente, e é por isso que estou fazendo a pergunta).

Arquivos simples
BDB
SQLite
MySQL
PostgreSQL
servidor SQL
Oráculo

Solução

Não é tão fácil.A única regra geral é que você deve procurar outra solução quando a atual não conseguir mais acompanhar.Isso pode incluir o uso de diferentes softwares (não necessariamente em uma ordem globalmente fixa), hardware ou arquitetura.

Você provavelmente obterá muito mais benefícios ao armazenar dados em cache usando algo como memcached do que mudar para outro back-end de armazenamento aleatório.

Outras dicas

Se você acha que algum dia precisará de um dos pesos pesados (SqlServer, Oracle), você deve começar com um deles no início.As migrações de dados são extremamente difíceis.No longo prazo, custará menos começar do topo e permanecer lá.

Acho que você está sendo excessivamente específico em suas classificações.Você pode começar com arquivos simples e similares para conjuntos de dados muito pequenos, ir para algo como DBM para aqueles um pouco maiores que não requerem sintaxe semelhante ao SQL e depois ir para algum tipo de banco de dados SQL.

Mas quem quer fazer toda essa reescrita?Se o aplicativo se beneficiar do acesso a junções, procedimentos armazenados, gatilhos, validação de chave estrangeira e similares - basta usar um banco de dados SQL, independentemente do tamanho do conjunto de dados.

Qual deles deve depender mais das instalações existentes do cliente e das habilidades de DBA disponíveis do que da quantidade de dados que você mantém.

Em outras palavras, o tamanho do seu banco de dados está longe de ser a única consideração e talvez não seja a mais importante.

Não há uma resposta geral para isso, mas QUASE sempre usar arquivos simples não é uma boa ideia.Você tem que analisá-los (suponho) e eles não escalam bem.Começar com um banco de dados adequado, como Oracle ou SQL Server (ou MySQL, Postgres se você estiver procurando opções gratuitas) é uma boa ideia.Com muito pouca sobrecarga, você economizará muito esforço e dor de cabeça mais tarde.Eles também permitem que você estruture seus dados de uma maneira não estúpida, deixando-o livre para pensar O QUE fará com os dados, em vez de COMO irá inseri-los/retirá-los.

Realmente depende dos seus dados e de como você pretende usá-los.Em uma de minhas posições anteriores, usamos Postgres devido à localização geográfica nativa e extensões de fuso horário que existiam porque nos permitiam gerenciar nossos dados usando tipos de dados poligonais.Para nós, precisávamos fazer isso e também queríamos usar procedimentos armazenados, visualizações e coisas do gênero.

Agora, outro lugar em que trabalhei usava MySQL simplesmente porque os dados eram normalizados, dados padrão linha por linha.

O SQL Server, por muito tempo, teve um limite de banco de dados de 4 GB (consulte SQL Server 2000), mas apesar dessa limitação, ele continua sendo uma plataforma muito estável para aplicativos de pequeno e médio porte para os quais os dados antigos são eliminados.

Agora, trabalhando com Oracle e SQL Server 05/08, tudo o que posso dizer é que se você deseja o melhor em termos de estabilidade, escalabilidade e flexibilidade, então esses dois são sua melhor aposta.Para aplicativos corporativos, eu os recomendo fortemente (simplesmente porque é isso que usamos onde trabalho agora).

Outras coisas a considerar:

Integração de linguagem (armazenamento de sessão ASP.NET, gerenciamento de funções, etc.)
Tipos de consulta (Selecionar, Atualizar, Excluir) [Embora isso seja mais um problema de design de esquema, não um problema de DBMS)
Requisitos de armazenamento de dados

A utilização do banco de dados pelo seu aplicativo é a mais crítica.Principalmente quais consultas são usadas com mais frequência (SELECT, INSERT ou UPDATE)?

Digamos que se você usa SQLite, ele é adequado para aplicativos menores, mas para aplicativos "web", você pode usar um aplicativo maior, como MySQL ou SQL Server.

A maneira como você escreve scripts e suas plataformas de aplicativos da web também é importante.Se você estiver desenvolvendo em uma plataforma Microsoft, o SQL Server é uma alternativa melhor.

Normalmente, eu sigo o que é comumente aceito por qualquer estrutura que estou usando.Então, se estou fazendo .NET => SQL Server, Python (via Django ou Pylons) => MySQL ou SQLite.

Quase nunca uso arquivos simples.

A escolha de uma solução RDBMS envolve mais do que apenas "potência de back-end".A capacidade de ter controle de comprometimento, por exemplo, para poder reverter uma transação com falha é uma delas.razão.

A menos que você esteja no aplicativo de taxa de megatransações, a maioria dos mecanismos de banco de dados seriam adequados - portanto, torna-se uma questão de quanto você deseja pagar pelo software, se ele é executado no hardware e no ambiente de sistema operacional que você deseja e qual conhecimento você possui. no gerenciamento desse software.

Essa progressão parece dolorosa.Se você pretende incluir produtos MS (especialmente o SQL Server pago) em qualquer lugar, é melhor usar a pilha inteira, já que só precisa pagar pelo último deles:

SQL Server Compact -> SQL Server Express -> SQL Server Enterprise (clustered).

Se você direcionar seu aplicativo inicialmente para o SQL Server Compact, todo o seu código SQL terá a garantia de ser escalonado para a próxima versão sem modificação.Se você for maior que o SQL Server Enterprise, parabéns.Isso é o que eles chamam de bom problema para ter.

Também:volte e verifique os podcasts do SO.Acredito que eles conversaram sobre isso brevemente.

Esta questão depende realmente da sua situação.

Se você tiver controle sobre o servidor no qual está implantando e puder instalar todos os serviços necessários, então o tempo para instalar um servidor MySql ou MSSQL Express e codificar em uma estrutura de banco de dados existente VERSUS codificar em uma estrutura de arquivo simples não vale o esforço de considerar.

E o FireBird?Onde isso se encaixaria nessa lista?

E não esqueçamos os requisitos que o “cliente” da sua solução também deve ter.Se você está escrevendo um aplicativo comercial para pequenas empresas, a Oracle pode não ser uma boa escolha...mas se você estiver escrevendo uma solução personalizada para uma grande empresa que deve compartilhar dados entre vários campi e tiver um departamento de TI de bom tamanho, a decisão entre Oracle e Sql Server se resumirá ao que o cliente provavelmente já implantou.

A migração de dados hoje em dia não é tão ruim, já que temos ótimas ferramentas da Embarcadero, então, em vez disso, deixaria que as necessidades do cliente conduzissem a decisão.

Se você tiver a opção, o SQL Server é uma boa escolha desde o início, principalmente porque você tem acesso a procedimentos e funções sólidas e os recursos de backup do banco de dados são totalmente confiáveis.Resumir o máximo possível de sua lógica dentro do próprio banco de dados (em vez de qualquer linguagem que você esteja usando) ajuda a segurança e o desempenho - na verdade, há um bom argumento a ser feito para sempre usar procedimentos para lógica de inserção/atualização, pois isso faz você invulnerável a ataques de injeção.

Se eu tiver escolha, a única vez que considerarei o MySQL de preferência é com um banco de dados grande e bastante simples, usado predominantemente para acesso de leitura.Isso não é para criticar o MySQL, que melhorou acentuadamente ultimamente e eu uso com prazer se não tiver escolha, mas para sistemas mais complexos com atividade de atualização/inserção, o MSSQL geralmente é a opção superior.

Acho que sua lista é subjetiva, mas vou jogar o seu jogo.

Arquivos simples

BDB

SQLite

MySQL

PostgreSQL

servidor SQL

Oráculo

Teradata

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow