sql - relacional - principais bancos de dados não relacionais




Boas razões para não usar um banco de dados relacional? (14)

Você pode, por favor, apontar para ferramentas alternativas de armazenamento de dados e dar boas razões para usá-las em vez de bancos de dados relacionais de boa qualidade? Na minha opinião, a maioria dos aplicativos raramente usa todo o poder do SQL - seria interessante ver como criar um aplicativo sem SQL.


Mecanismo de armazenamento personalizado (escrito à mão) / Potencialmente muito alto desempenho em casos de uso necessários

http://www.hdfgroup.org/

Se você tiver conjuntos de dados enormes, em vez de rolar seus próprios, poderá usar o HDF, o Hierarchical Data Format.

http://en.wikipedia.org/wiki/Hierarchical_Data_Format :

O HDF suporta vários modelos de dados diferentes, incluindo matrizes multidimensionais, imagens rasterizadas e tabelas.

Também é hierárquico como um sistema de arquivos, mas os dados são armazenados em um arquivo binário mágico.

O HDF5 é um conjunto que possibilita o gerenciamento de coleções de dados extremamente grandes e complexas.

Pense nos petabytes dos dados de sensoriamento remoto da NASA / JPL.


A resposta de Matt Sheppard é ótima (mod up), mas eu levo em conta esses fatores quando penso em um fuso:

  1. Estrutura: obviamente se fragmenta ou você está fazendo tradeoffs?
  2. Uso: como os dados serão analisados ​​/ recuperados / grokked?
  3. Lifetime: quanto tempo os dados são úteis?
  4. Tamanho: quantos dados existem?

Uma vantagem específica dos arquivos CSV sobre os RDBMSes é que eles podem ser fáceis de condensar e se mover para praticamente qualquer outra máquina. Nós fazemos grandes transferências de dados, e tudo é simples o suficiente, nós apenas usamos um grande arquivo CSV, e fácil de script usando ferramentas como o rsync. Para reduzir a repetição em grandes arquivos CSV, você poderia usar algo como YAML . Não tenho certeza se eu armazenar qualquer coisa como JSON ou XML, a menos que você tenha requisitos de relacionamento significativos.

No que diz respeito às alternativas não mencionadas, não desconsidere o Hadoop , que é uma implementação de código aberto do MapReduce. Isso deve funcionar bem se você tiver uma tonelada de dados vagamente estruturados que precisam ser analisados ​​e desejar estar em um cenário em que possa adicionar mais 10 máquinas para processar dados.

Por exemplo, comecei a tentar analisar o desempenho que era essencialmente 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 no formato agregado para mim. Assim, mantenho os arquivos de log por aí, compactados e, em seguida, deixo os dados agregados em um banco de dados.

Note que estou mais acostumado a pensar com tamanhos "grandes".


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 (ie 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 para validar a estrutura.

Arquivo de planilha / CSV

  • Modelo muito fácil para usuários de negócios entenderem

Subversion (ou sistema de controle de versão baseado em disco similar)

  • Muito bom suporte para versionamento de dados

Berkeley DB (Basicamente, um hashtable baseado em disco)

  • Muito simples conceitualmente (apenas chave / valor não tipado)
  • Muito rápido
  • Nenhuma sobrecarga de administração
  • Suporta transações que acredito

Banco de Dados Simples da Amazon

  • Muito parecido com Berkeley DB eu acredito, mas hospedado

Datastore do Google App Engine

  • Hospedado e altamente escalável
  • Armazenamento de valor-chave por documento (por exemplo, modelo de dados flexível)

CouchDB

  • Foco do documento
  • Armazenamento simples de dados baseados em documentos / semiestruturados

Coleções de idiomas nativos (armazenados na memória ou serializados no disco)

  • Integração de linguagem muito restrita

Mecanismo de armazenamento personalizado (escrito à mão)

  • Potencialmente muito alto desempenho em casos de uso requeridos

Eu não posso afirmar que sei muito sobre eles, mas você também pode gostar de olhar para os sistemas de banco de dados de objetos .


BEIJO: Mantenha-o pequeno e simples


Bancos de dados de texto completo, que podem ser consultados com operadores de proximidade, como "dentro de 10 palavras de" etc.

Bancos de dados relacionais são uma ferramenta de negócios ideal para muitos propósitos - fácil o suficiente para entender e projetar, rápido o suficiente, adequado mesmo quando não são projetados e otimizados por um gênio que poderia "usar o poder total", etc.

Mas algumas finalidades de negócios exigem indexação de texto completo, que os mecanismos relacionais não fornecem ou utilizam como uma reflexão tardia. Em particular, os campos legal e médico têm grandes faixas de texto não estruturado para armazenar e percorrer.


Em alguns casos (dados do mercado financeiro e controle de processos, por exemplo), talvez seja necessário usar um banco de dados em tempo real em vez de um RDBMS. Veja o link da wiki


Eu recomendaria fortemente Lua como uma alternativa ao tipo de armazenamento de dados do 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 Lua para binário, para um desempenho adicional

Esta é a opção "coleção de idiomas nativos" da resposta aceita. Se você estiver usando C / C ++ como o nível do aplicativo, é perfeitamente razoável incluir o mecanismo Lua (100kB de binário) apenas para ler as configurações / dados ou escrevê-los.



Há um grande número de maneiras de armazenar dados - até mesmo o "banco de dados relacional" abrange uma variedade de alternativas de uma biblioteca simples de código que manipula um arquivo local (ou arquivos) como se fosse um banco de dados relacional em uma única base de usuário. sistemas baseados em arquivos que podem manipular múltiplos usuários para uma generosa seleção de sistemas baseados em "servidores" sérios.

Usamos muito os arquivos XML - você obtém dados bem estruturados, boas ferramentas para consultar a mesma capacidade de edição, se apropriado, algo que é legível por humanos e você não precisa se preocupar com o funcionamento do mecanismo de db (ou o funcionamento do motor db). Isso funciona bem para coisas que são essencialmente somente leitura (no nosso caso mais frequentemente do que não 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 multi-usuário - pelo menos de um único arquivo.

Para nós, é sobre isso - ou vamos usar algo que faça SQL (MS oferece um conjunto de ferramentas que vão de um .DLL para fazer um único usuário até o servidor corporativo e todos falam o mesmo SQL (com limitações no extremo inferior)) ou vamos usar XML como um formato porque (para nós) a verbosidade raramente é um problema.

Atualmente, não temos que manipular dados binários em nossos aplicativos para que essa questão não apareça.

Murph


Havia uma ferramenta RAD chamada JADE escrita há alguns anos atrás, que possui um OODBMS embutido. As encarnações anteriores do motor DB também suportaram o Digitalk Smalltalk. Se você quiser testar o desenvolvimento de aplicativos usando um paradigma não-RDBMS, isso pode ser um começo.

Outros produtos OODBMS incluem Objectivity , GemStone (você precisará obter o VisualWorks Smalltalk para executar a versão Smalltalk, mas também há uma versão em java). Havia também alguns projetos de pesquisa de código aberto neste espaço - EXODUS e sua linhagem descendente vêm à mente.

Infelizmente, o conceito parece ter morrido, provavelmente devido à falta de um padrão claramente visível e de uma capacidade de consulta ad-hoc relativamente fraca em relação aos sistemas RDMBS baseados em SQL.

Um OODBMS é mais adequado para aplicativos com estruturas de dados principais 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 Dungeon Multi-usuário (MUD), onde os quartos continham os avatares dos jogadores e outros objetos.


Os arquivos BTree são frequentemente muito mais rápidos que os bancos de dados relacionais. O SQLite contém em si uma biblioteca BTree que está no domínio público (como em genuinamente 'domínio público', não usando o termo livremente).

Francamente, se eu quisesse um sistema multi-usuário, eu precisaria de muita persuasão para não usar um banco de dados relacional de servidor decente.


Pode-se querer considerar o uso de um servidor LDAP no lugar de um banco de dados SQL tradicional se os dados do aplicativo forem fortemente orientados por chave / valor e hierárquicos por natureza.


Uma boa razão para não usar um banco de dados relacional seria quando você tem um conjunto de dados massivo e deseja fazer um processamento maciçamente paralelo e distribuído nos dados. O índice da web do Google seria um exemplo perfeito desse caso.

O Hadoop também tem uma implementação do sistema de arquivos do Google, chamada Hadoop Distributed File System .


Você pode percorrer um longo caminho usando apenas arquivos armazenados no sistema de arquivos. Os RDBMSs estão ficando melhores em lidar com blobs, mas isso pode ser uma maneira natural de manipular dados de imagem e coisas do tipo, especialmente se as consultas forem simples (enumerando e selecionando itens individuais).

Outras coisas que não se encaixam muito bem em um RDBMS são estruturas hierárquicas de dados e acredito que dados geoespaciais e modelos 3D não são tão fáceis de trabalhar com nenhum deles.

Serviços como o Amazon S3 fornecem modelos de armazenamento mais simples (chave-> valor) que não suportam SQL. Escalabilidade é a chave lá.

Os arquivos do Excel também podem ser úteis, principalmente se os usuários precisarem manipular os dados em um ambiente familiar e criar um aplicativo completo para fazer isso não for viável.







nosql