Bancos de dados de última geração

Estou aprendendo bancos de dados relacionais tradicionais (com o PostgreSQL ) e fazendo algumas pesquisas, encontrei alguns novos tipos de bancos de dados. CouchDB , Drizzle e Scalaris, para citar alguns, quais serão as próximas tecnologias de database a serem tratadas ?

Eu diria database da próxima geração, não SQL de próxima geração.

SQL é uma linguagem para consultar e manipular bancos de dados relacionais. O SQL é ditado por um padrão internacional. Enquanto o padrão é revisado, parece sempre funcionar dentro do paradigma do database relacional.

Aqui estão algumas novas tecnologias de armazenamento de dados que estão recebendo atenção atualmente:

  • O CouchDB é um database não relacional. Eles chamam isso de database orientado a documentos.
  • O Amazon SimpleDB também é um database não relacional acessado de maneira distribuída por meio de um serviço da web. A Amazon também tem um armazenamento de valor-chave distribuído chamado Dynamo , que alimenta alguns de seus serviços S3.
  • Dynomite e Kai são soluções de código aberto inspiradas na Amazon Dynamo.
  • O BigTable é uma solução proprietária de armazenamento de dados usada pelo Google e implementada usando a tecnologia do sistema de arquivos do Google. O framework MapReduce do Google usa o BigTable.
  • O Hadoop é uma tecnologia de código aberto inspirada no MapReduce do Google, e que atende a uma necessidade semelhante, para distribuir o trabalho de armazenamentos de dados de grande escala.
  • Scalaris é um armazenamento de chave / valor transacional distribuído. Também não é relacional e não usa SQL. É um projeto de pesquisa do Instituto Zuse em Berlim, Alemanha.
  • RDF é um padrão para armazenar dados semânticos, em que dados e metadados são intercambiáveis. Ele possui sua própria linguagem de consulta, a SPARQL, que se assemelha ao SQL superficialmente, mas na verdade é totalmente diferente.
  • O Vertica é um database analítico orientado a colunas altamente escalável projetado para arquitetura distribuída (grid). Ele afirma ser relacional e compatível com SQL. Ele pode ser usado através do Elastic Compute Cloud da Amazon.
  • O Greenplum é um DBMS de armazenamento de dados em grande escala, que implementa o MapReduce e o SQL.
  • XML não é um DBMS, é um formato de intercâmbio. Mas alguns produtos DBMS trabalham com dados no formato XML.
  • ODBMS , ou bancos de dados de objects, são para gerenciar dados complexos. Não parece haver nenhum produto ODBMS dominante no mainstream, talvez devido à falta de padronização. O SQL padrão está gradualmente ganhando alguns resources OO (por exemplo, tipos e tabelas de dados extensíveis).
  • O Drizzle é um database relacional, que extrai muito do seu código do MySQL. Ele inclui várias alterações arquitetônicas projetadas para gerenciar dados em uma arquitetura de sistema escalável de “computação em nuvem”. Presumivelmente, ele continuará usando o SQL padrão com alguns aprimoramentos do MySQL.
  • O Cassandra é um armazenamento de valor-chave estruturado, altamente escalável e eventualmente consistente, desenvolvido no Facebook por um dos autores do Amazon Dynamo e que contribuiu para o projeto Apache.
  • O Project Voldemort é um sistema de armazenamento de valor-chave distribuído e não-relacional. É usado no LinkedIn.com
  • Berkeley DB merece alguma menção também. Não é “next-gen” porque remonta ao início dos anos 90. É um popular repository de valor-chave que é fácil de incorporar em uma variedade de aplicativos. A tecnologia é atualmente de propriedade da Oracle Corp.

Veja também este belo artigo de Richard Jones: ” Anti-RDBMS: Uma lista de armazenamentos distribuídos de valores-chave .” Ele entra em mais detalhes descrevendo algumas dessas tecnologias.

Bancos de dados relacionais têm pontos fracos, com certeza. As pessoas têm argumentado que não lidam com todos os requisitos de modelagem de dados desde o dia em que foram introduzidas pela primeira vez.

Ano após ano, os pesquisadores vêm com novas maneiras de gerenciar dados para satisfazer requisitos especiais: requisitos para lidar com relacionamentos de dados que não se encheckboxm no modelo relacional ou requisitos de volume ou velocidade de alta escala que exigem processamento de dados. em collections distribuídas de servidores, em vez de servidores centrais de database.

Mesmo que essas tecnologias avançadas façam grandes coisas para resolver o problema especializado para o qual foram projetadas, os bancos de dados relacionais ainda são uma boa solução de propósito geral para a maioria das necessidades de negócios. SQL não está indo embora.


Eu escrevi um artigo na revista php | Architect sobre a inovação de bancos de dados não relacionais e modelagem de dados em bancos de dados relacionais versus não relacionais. http://www.phparch.com/magazine/2010-2/september/

Eu estou faltando bancos de dados charts nas respostas até agora. Um gráfico ou rede de objects é comum na programação e pode ser útil em bancos de dados também. Ele pode lidar com informações semi-estruturadas e interconectadas de maneira eficiente. Entre as áreas em que os bancos de dados charts ganharam muito interesse estão web semântica e bioinformática. RDF foi mencionado e, na verdade, é uma linguagem que representa um gráfico. Aqui estão algumas dicas para o que está acontecendo na área do database gráfico:

  • Gráficos – uma melhor abstração de database
  • Graphd, o backend do Freebase
  • Mecanismo de database de charts de código aberto Neo4j
  • AllegroGraph RDFstore
  • Camada de abstração Graphdb para bioinformática
  • Graphdb por trás do mecanismo de recomendação Directed Edge

Eu sou parte do projeto Neo4j , que é escrito em Java, mas tem ligações para Python, Ruby e Scala também. Algumas pessoas usam o Clojure ou o Groovy / Grails. Há também uma ferramenta GUI evoluindo.

Pode não ser o melhor lugar para responder com isso, mas eu gostaria de compartilhar essa taxonomia do mundo noSQL criado por Steve Yen (por favor, acesse em http://de.slideshare.net/northscale/nosqloakland-200911021 )

  1. chave-valor-cache

    • memcached
    • encapsulado
    • coerência
    • em finispan
    • eXtreme scale
    • cache do jboss
    • velocidade
    • terracoqa
  2. chave-valor-loja

    • keyspace
    • fl are
    • livre de esquema
    • RAMCloud
  3. armazenamento de chave-valor eventualmente consistente

    • dínamo
    • voldemort
    • Dinomite
    • Sub-registro
    • MongoDB
    • Dovetaildb
  4. pedido-chave-valor-store

    • Tirano de Tóquio
    • nuvem clara
    • NMDB
    • luxio
    • memcachedb
    • actord
  5. servidor de estruturas de dados

    • redis
  6. tuple-store

    • gigaspaces
    • coord
    • rio apache
  7. database de objects

    • ZopeDB
    • db4o
    • Cardume
  8. loja de documentos

    • CouchDB
    • Mongo
    • Jackrabbit
    • Bancos de Dados XML
    • ThruDB
    • CloudKit
    • Perservere
    • Riak Basho
    • Scalaris
  9. loja colunar larga

    • Mesa grande
    • Hbase
    • Cassandra
    • Hypertable
    • KAI
    • OpenNep

Para um olhar sobre o que a pesquisa acadêmica está sendo feita na área de bancos de dados da próxima geração, dê uma olhada nisso: http://www.thethirdmanifesto.com/

Em relação à linguagem SQL como uma implementação adequada do modelo relacional, cito da wikipedia, “SQL, inicialmente pressionado como a linguagem padrão para bancos de dados relacionais, se desvia do modelo relacional em vários lugares. O atual padrão ISO SQL não mencione o modelo relacional ou use termos ou conceitos relacionais.No entanto, é possível criar um database em conformidade com o modelo relacional usando SQL se não usar certos resources SQL. ”

http://en.wikipedia.org/wiki/Relational_model (Referenciado na seção “SQL e o modelo relacional” em 28 de março de 2010

Não é pedante, mas gostaria de salientar que pelo menos o CouchDB não é baseado em SQL. E eu espero que o SQL da próxima geração torne o SQL muito menos … difícil e não intuitivo.

Existem bancos de dados especiais para XML, como MarkLogic e Berkeley XMLDB. Eles podem indexar xml-docs e pode-se consultá-los com XQuery. Espero bancos de dados JSON, talvez eles já existam. Será que alguns googling mas não conseguiu encontrar um.

O SQL existe desde o início dos anos 70, então não acho que vá desaparecer tão cedo.

Talvez o ‘novo (-ish) sql’ seja oql (veja http://en.wikipedia.org/wiki/ODBMS )

Eu também ouvi sobre NimbusDB por Jim Starkey

Jim Starkey é o homem que “cria” o Interbase

quem trabalha em Vulcan (um garfo Firebird)

e quem estava no começo do Falcon para o MySQL