Bons motivos para NÃO usar um banco de dados relacional?
https://stackoverflow.com/questions/37823
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Você pode apontar ferramentas alternativas de armazenamento de dados e dar bons motivos para usá-las em vez dos bons e velhos bancos de dados relacionais?Na minha opinião, a maioria dos aplicativos raramente usa todo o poder do SQL – seria interessante ver como construir um aplicativo sem SQL.
Solução
Arquivos de texto simples em um sistema de arquivos
- Muito simples de criar e editar
- Fácil para os usuários manipularem com ferramentas simples (ou seja,editores de texto, grep etc.)
- Armazenamento eficiente de documentos binários
Arquivos XML ou JSON no disco
- Como acima, mas com um pouco mais de capacidade de validar a estrutura.
Planilha/arquivo CSV
- Modelo muito fácil para usuários corporativos entenderem
Subversion (ou sistema de controle de versão baseado em disco semelhante)
- Muito bom suporte para versionamento de dados
Banco de dados de Berkeley (Basicamente, uma tabela hash baseada em disco)
- Muito simples conceitualmente (apenas chave/valor não digitado)
- Muito rápido
- Sem sobrecarga de administração
- Suporta transações, acredito
Banco de dados simples da Amazon
- Muito parecido com o Berkeley DB, acredito, mas hospedado
Armazenamento de dados do App Engine do Google
- Hospedado e altamente escalável
- Armazenamento de valores-chave por documento (ou seja,modelo de dados flexível)
- Foco do documento
- Armazenamento simples de dados semiestruturados/baseados em documentos
Coleções de idiomas nativos (armazenadas na memória ou serializadas em disco)
- Integração de linguagem muito forte
Mecanismo de armazenamento personalizado (escrito à mão)
- Desempenho potencialmente muito alto em casos de uso obrigatórios
Não posso afirmar que sei muito sobre eles, mas você também pode querer dar uma olhada sistemas de banco de dados de objetos.
Outras dicas
A resposta de Matt Sheppard é ótima (mod up), mas eu levaria em conta estes fatores ao pensar em um fuso:
- Estrutura:obviamente se quebra em pedaços ou você está fazendo concessões?
- Uso:como os dados serão analisados/recuperados/grokkados?
- Vida :por quanto tempo os dados são úteis?
- Tamanho :quantos dados existem?
Uma vantagem específica dos arquivos CSV sobre os RDBMS é que eles podem ser fáceis de condensar e mover para praticamente qualquer outra máquina.Fazemos grandes transferências de dados e tudo é bastante simples, basta usar um grande arquivo CSV e fácil de criar scripts usando ferramentas como rsync.Para reduzir a repetição em grandes arquivos CSV, você poderia usar algo como YAML.Não tenho certeza se armazenaria algo como JSON ou XML, a menos que você tivesse requisitos de relacionamento significativos.
Quanto às alternativas não mencionadas, não descarte Hadoop, que é uma implementação de código aberto do MapReduce.Isso deve funcionar bem se você tiver uma tonelada de dados pouco estruturados que precisam ser analisados e quiser estar em um cenário em que possa adicionar mais 10 máquinas para lidar com o processamento de dados.
Por exemplo, comecei a tentar analisar o desempenho que consistia essencialmente em todos os números de tempo de diferentes funções registradas em cerca de 20 máquinas.Depois de tentar colocar tudo em um RDBMS, percebi que realmente não preciso consultar os dados novamente depois de agregá-los.E só é útil em seu formato agregado para mim.Então, mantenho os arquivos de log compactados e deixo os dados agregados em um banco de dados.
Observação Estou mais acostumado a pensar em tamanhos "grandes".
O sistema de arquivos é bastante útil para armazenar dados binários, o que nunca funciona muito bem em bancos de dados relacionais.
Experimente o Prevayler:http://www.prevayler.org/wiki/Prevayler é uma alternativa ao RDBMS.No site tem mais informações.
Se você não precisa ÁCIDO, você provavelmente não precisará da sobrecarga de um RDBMS.Portanto, determine se você precisa disso primeiro.A maioria das respostas não RDBMS fornecidas aqui não forneça ÁCIDO.
Mecanismo de armazenamento personalizado (escrito à mão)/Desempenho potencialmente muito alto em casos de uso necessários
Se você tiver conjuntos de dados enormes, em vez de criar os seus próprios, poderá usar HDF, o formato de dados hierárquicos.
http://en.wikipedia.org/wiki/Hierarchical_Data_Format:
HDF oferece suporte a vários modelos de dados diferentes, incluindo arrays multidimensionais, imagens raster e tabelas.
Também é hierárquico como um sistema de arquivos, mas os dados são armazenados em um arquivo binário mágico.
HDF5 é uma suíte que possibilita o gerenciamento de coleções de dados extremamente grandes e complexas.
Pense em petabytes de dados de sensoriamento remoto da NASA/JPL.
Bom dia,
Um caso em que consigo pensar é quando os dados que você está modelando não podem ser facilmente representados em um banco de dados relacional.
Um exemplo disso é o banco de dados usado pelas operadoras de telefonia móvel para monitorar e controlar estações base para redes de telefonia móvel.
Eu quase todos esses casos, um OO BD é utilizado um produto comercial ou um sistema auto-rolado que permite hierarquias de objetos.
Trabalhei em um aplicativo de monitoramento 3G para uma grande empresa que permanecerá sem nome, mas cujo logotipo é uma mancha de vinho tinto (-:, e eles usaram esse banco de dados OO para controlar todos os vários atributos de células individuais na rede.
A interrogação desses bancos de dados é feita usando técnicas proprietárias que, geralmente, são completamente livres de SQL.
HTH.
saúde,
Roubar
Bancos de dados de objetos não são bancos de dados relacionais.Eles podem ser muito úteis se você quiser apenas colocar alguns objetos em um banco de dados.Eles também suportam controle de versão e modificam classes para objetos que já existem no banco de dados. db4o é o primeiro que vem à mente.
Em alguns casos (dados do mercado financeiro e controle de processos, por exemplo), pode ser necessário usar um banco de dados em tempo real em vez de um RDBMS.Ver link wiki
Havia uma ferramenta RAD chamada JADE escrito há alguns anos que possui um OODBMS integrado.Encarnações anteriores do mecanismo DB também suportavam Digitalk Smalltalk.Se você deseja testar a construção de aplicativos usando um paradigma não RDBMS, isso pode ser um começo.
Outros produtos OODBMS incluem Objetividade, Pedra preciosa (Você precisará obter Trabalhos Visuais Smalltalk para executar a versão Smalltalk, mas também existe uma versão java).Houve também alguns projetos de pesquisa de código aberto neste espaço - EXODUS e seu descendente SHORE vêm à mente.
Infelizmente, o conceito pareceu morrer, provavelmente devido à falta de um padrão claramente visível e à capacidade de consulta ad hoc relativamente pobre em relação aos sistemas RDMBS baseados em SQL.
Um OODBMS é mais adequado para aplicações com estruturas de dados centrais que são melhor representadas como um gráfico de nós interconectados.Eu costumava dizer que o aplicativo OODBMS por excelência era um Calabouço Multiusuário (MUD), onde as salas conteriam avatares dos jogadores e outros objetos.
Você pode percorrer um longo caminho apenas usando arquivos armazenados no sistema de arquivos.Os RDBMSs estão melhorando no tratamento de blobs, mas essa pode ser uma maneira natural de lidar com dados de imagem e similares, principalmente se as consultas forem simples (enumerar e selecionar itens individuais).
Outras coisas que não se encaixam muito bem em um RDBMS são estruturas de dados hierárquicas e acho que dados geoespaciais e modelos 3D também não são tão fáceis de trabalhar.
Serviços como Amazon S3 fornecem modelos de armazenamento mais simples (chave-> valor) que não suportam SQL.Escalabilidade é a chave aqui.
Os arquivos Excel também podem ser úteis, principalmente se os usuários precisarem manipular os dados em um ambiente familiar e não for viável construir um aplicativo completo para fazer isso.
Há um grande número de maneiras de armazenar dados - até mesmo o "banco de dados relacional" cobre uma gama de alternativas, desde uma simples biblioteca de código que manipula um arquivo (ou arquivos) local como se fosse um banco de dados relacional de um único usuário, até sistemas baseados em arquivos que podem lidar com vários usuários até uma seleção generosa de sistemas sérios baseados em "servidores".
Usamos muito arquivos XML - você obtém dados bem estruturados, ótimas ferramentas para consultar a capacidade de fazer edições, se apropriado, algo que seja legível por humanos e você não precisa se preocupar com o funcionamento do mecanismo de banco de dados (ou com o funcionamento do mecanismo de banco de dados).Isso funciona bem para coisas que são essencialmente somente leitura (no nosso caso, mais frequentemente geradas a partir de um banco de dados em outro lugar) e também para sistemas de usuário único onde você pode simplesmente carregar os dados e salvá-los conforme necessário - mas você está criando oportunidades para problemas se você quiser edição multiusuário - pelo menos de um único arquivo.
Para nós, é isso - usaremos algo que fará SQL (a MS oferece um conjunto de ferramentas que são executadas a partir de um .DLL para fazer coisas de usuário único até o servidor corporativo e todos falam o mesmo SQL (com limitações na extremidade inferior)) ou usaremos XML como formato porque (para nós) a verbosidade raramente é um problema.
Atualmente não precisamos manipular dados binários em nossos aplicativos para que essa questão não surja.
Murph
Pode-se considerar o uso de um servidor LDAP no lugar de um banco de dados SQL tradicional se os dados do aplicativo forem fortemente orientados a chave/valor e de natureza hierárquica.
Os arquivos BTree costumam ser muito mais rápidos que os bancos de dados relacionais.SQLite contém uma biblioteca BTree que é de domínio público (como genuinamente 'domínio público', não usando o termo vagamente).
Francamente, porém, se eu quisesse um sistema multiusuário, precisaria de muita persuasão para não usar um banco de dados relacional de servidor decente.
Bancos de dados de texto completo, que podem ser consultados com operadores de proximidade, como "dentro de 10 palavras de" etc.
Os bancos de dados relacionais são uma ferramenta de negócios ideal para muitos propósitos – fáceis de entender e projetar, rápidos o suficiente, adequados mesmo quando não são projetados e otimizados por um gênio que poderia “usar todo o poder”, etc.
Mas alguns propósitos de negócios exigem indexação de texto completo, que os mecanismos relacionais não fornecem ou acrescentam posteriormente.Em particular, as áreas jurídica e médica têm grandes extensões de texto não estruturado para armazenar e percorrer.
Também:* Cenários incorporados - Onde normalmente é necessário usar algo menor que um RDBMS completo. Db4o é um ODB que pode ser facilmente usado nesse caso.* Desenvolvimento rápido ou de prova de conceito - onde você deseja focar no negócio e não se preocupar com a camada de persistência
Teorema CAP explica sucintamente.SQL fornece principalmente "Consistência Forte:todos os clientes veem a mesma visualização, mesmo na presença de atualizações".
BEIJO:Mantenha-o pequeno e simples
Eu ofereceria RDBMS :) Se você não terá problemas com a configuração/administração, vá para SQLite.RDBMS integrado com suporte SQL completo.Ele ainda permite armazenar qualquer tipo de dados em qualquer coluna.
Principal vantagem em relação, por exemplo, ao arquivo de log:Se você tiver um enorme, como vai pesquisar nele?Com o mecanismo SQL você apenas cria índices e acelera drasticamente a operação.
Sobre a pesquisa de texto completo:SQLite também possui módulos para pesquisa de texto completo.
Apenas aproveite a interface padrão agradável para seus dados :)
Um bom motivo para não usar um banco de dados relacional seria quando você tem um conjunto enorme de dados e deseja fazer um processamento massivamente paralelo e distribuído nos dados.O índice web do Google seria um exemplo perfeito de tal caso.
O Hadoop também possui uma implementação do Sistema de arquivos do Google Chamou o Sistema de arquivos distribuído Hadoop.
Eu recomendaria fortemente Lua como uma alternativa ao armazenamento de dados do tipo SQLite.
Porque:
- A linguagem foi projetada como uma linguagem de descrição de dados para começar
- A sintaxe é legível por humanos (XML é não)
- Pode-se compilar pedaços de Lua em binário, para aumentar o desempenho
Esta é a opção "coleção de idioma nativo" da resposta aceita.Se você estiver usando C/C++ como nível de aplicativo, é perfeitamente razoável incluir o mecanismo Lua (100kB de binário) apenas para ler configurações/dados ou escrevê-los.
