Os SSDs reduzem a utilidade dos bancos de dados


28

Eu só ouvi falar de Robert Martin hoje, e parece que ele é uma figura notável no mundo do software, então não quero que meu título apareça como se fosse uma isca de clique ou eu colocando palavras na boca dele, mas isso é simplesmente como interpretei o que ouvi dele com minha experiência e compreensão limitadas.

Eu estava assistindo um vídeo hoje (sobre arquitetura de software), em uma palestra de Robert C. Martin, e na segunda metade do vídeo, o tópico de bancos de dados foi o foco principal.

Pelo meu entendimento do que ele disse, parecia que ele estava dizendo que os SSDs reduziriam a utilidade dos bancos de dados ( consideravelmente ).

Para explicar como cheguei a essa interpretação:

Ele discutiu como, com HDDs / discos giratórios, a recuperação de dados é lenta. No entanto, hoje em dia usamos SSDs, observou ele. Ele começa com "A RAM está chegando" e depois continua mencionando discos de RAM, mas depois diz que não pode chamá-lo de disco de RAM, então recorre apenas a dizer RAM. Portanto, com a RAM, não precisamos dos índices, porque cada byte leva o mesmo tempo para obter. ( este parágrafo é parafraseado por mim )

Então, ele sugerindo RAM (como na memória do computador) como um substituto para DBs (como foi assim que interpretei sua declaração) não faz sentido, porque é como dizer que todos os registros são processados ​​na memória durante a vida útil de um aplicativo ( a menos que você extraia de um arquivo de disco sob demanda)

Então, eu comecei a pensar por RAM, ele quer dizer SSD. Então, nesse caso, ele está dizendo que os SSDs reduzem a utilidade dos bancos de dados. Ele até diz: "Se eu fosse Oracle, ficaria assustado. O próprio fundamento de minha existência está evaporando".

Pela minha pouca compreensão dos SSDs, diferentemente dos HDDs, que são o O(n)tempo de busca (eu acho), os SSDs estão próximos O(1)ou quase aleatórios. Então, a sugestão dele foi interessante para mim, porque nunca pensei nisso assim. Na primeira vez em que fui apresentado aos bancos de dados, há alguns anos, quando um professor descreveu os benefícios do sistema de arquivos regular, concluí que o papel principal de um banco de dados é essencialmente ser um sistema de arquivos muito indexado (além de otimizações, cache, acesso simultâneo, etc), portanto, se não forem necessários índices no SSD, esse tipo de banco de dados será menos útil.

Independentemente disso, prefácio que sou um novato, acho difícil acreditar que eles se tornem menos úteis, pois todos ainda usam DBs como ponto principal de sua aplicação, em vez de um sistema de arquivos puro, e sentiram como se ele estivesse simplificando demais. o papel dos bancos de dados.

Nota : assisti até o final para garantir que ele não dissesse algo diferente.

Para referência: 42:22 é quando todo o tópico do banco de dados aparece, 43:52 é quando ele começa com "Por que temos bancos de dados"

Esta resposta diz que os SSDs aceleram consideravelmente os DBs. Esta pergunta pergunta sobre como a otimização é alterada.

Para TL; DR minha pergunta, o advento do uso generalizado de SSD no mercado de servidores (se já está próximo ou já aconteceu) reduz a utilidade dos bancos de dados?

Parecia que o apresentador estava tentando transmitir era que, com os SSDs, é possível armazenar os dados no disco e não ter que se preocupar com o quão lento seria para recuperá-los, como nos HDDs mais antigos, como nos SSDs, os tempos de busca estão próximos O(1)(Eu acho que). Portanto, caso isso seja verdade, isso hipoteticamente perderia uma das vantagens que tinha: indexação, porque a vantagem de ter índices para tempos de busca mais rápidos se foi.

Respostas:


59

Há algumas coisas em um banco de dados que devem ser aprimoradas quando você usa SSDs. Por exemplo, falando no PostgreSQL, você pode ajustar effective_io_concurrency, e random_page_cost. No entanto, leituras mais rápidas e acesso aleatório mais rápido não são o que um banco de dados faz. Garante

Ele está errado sobre os índices. Se a tabela inteira puder ser lida em ram, um índice ainda será útil. Não acredita em mim? Vamos fazer um experimento mental,

  • Imagine que você tem uma tabela com uma coluna indexada.

    CREATE TABLE foobar ( id text PRIMARY KEY );
  • Imagine que existem 500 milhões de linhas nessa tabela.

  • Imagine que todas as 500 milhões de linhas sejam concatenadas juntas em um arquivo.

O que é mais rápido,

  1. grep 'keyword' file
  2. SELECT * FROM foobar WHERE id = 'keyword'

Não se trata apenas de onde os dados estão, é sobre como você os solicita e quais operações você pode fazer. O PostgreSQL suporta índices B-tree, Hash, GiST, SP-GiST, GIN e BRIN (e Bloom através de uma extensão). Você seria tolo em pensar que toda essa matemática e funcionalidade desaparecem porque você tem acesso aleatório mais rápido.


31
Apenas um adendo - o OP deve ter cuidado para não confundir "acesso aleatório" com "acesso endereçável ao conteúdo". Como observou o OP, "acesso aleatório" significa que chegar a cada byte de memória é O (1). No entanto, a busca de dados nessa "memória de acesso aleatório" ainda requer uma busca sequencial por eles; isto é, você não pode pedir a memória "me encontrar os dados que se parece com isso " e tê-lo magicamente entregue a você.
Bob Jarvis - Restabelece Monica

2
@BobJarvis Você está correto. O seu comentário ajuda a esclarecer ainda mais @ EvanCarroll de "O que é mais rápido" exemplo sobre o porquê de indexação e até mesmo subindexing assunto, e apenas pegar em O(1)não é suficiente para os casos de uso de um DB fornece
Abdul

12

Com base na sua postagem, parece que a mensagem clara é que as otimizações do tempo de pesquisa do RDBMS estão sendo substituídas por hardware, o que torna o tempo de IO negligenciável.

Isto é absolutamente verdade. O SSD nos servidores de banco de dados, combinado com alta RAM (real), reduz a espera de E / S significativamente mais curta. No entanto, a indexação e o armazenamento em cache do RDBMS ainda são valiosos, porque mesmo sistemas com esse grande benefício de IO podem e terão gargalos de IO devido a consultas com desempenho ruim causadas por indexação incorreta. Normalmente, isso é encontrado apenas em aplicativos de alta carga de trabalho ou aplicativos mal escritos.

O valor principal dos sistemas RDBMS em geral é a consistência dos dados, a disponibilidade dos dados e a agregação dos dados. Utilizar uma planilha do Excel, arquivo csv ou outro método para manter uma "base de dados" não oferece garantias.

O SSD não protege você do seu servidor principal e fica indisponível por qualquer motivo (rede, corrupção do SO, perda de energia). O SSD não protege você contra uma modificação de dados incorreta. O SSD não torna mais rápido executar análises em comparação com "apenas tê-las".


Embora tenha adquirido uma visão melhor, eu estava perguntando no contexto de armazenamento de dados SSD brutos versus armazenamento de dados em um banco de dados com disco rígido, e sua resposta está no contexto de banco de dados em SSD (devido ao fracasso de perguntas feitas por mim)
Abdul

4
@Abdul Essa comparação é de pontes de maçãs para suspensão. Um dispositivo bruto oferece uma grande extensão de armazenamento; um banco de dados oferece uma maneira de organizar e acessar esse armazenamento de acordo com um modelo de dados. O ponto de Josh aqui é que, se você entrar nessa com a ideia de que um SSD bruto é uma coisa maravilhosa porque é "rápido" e que você apenas escreverá um código para fazer todo o armazenamento de dados nesse volume bruto , você acabará escrevendo um banco de dados.
Blrfl

8

O tio Bob provavelmente estava falando sobre bancos de dados na memória, como Redis ou Gemfire . Nesses bancos de dados, tudo no banco de dados realmente está contido na RAM. O banco de dados pode começar vazio e ser arquivado com dados de vida curta (sendo usados ​​como cache) ou começar carregando tudo do disco e periodicamente as alterações do ponto de verificação no disco.

Isso está se tornando cada vez mais popular porque a RAM está ficando barata e torna-se possível ter um terabyte de dados armazenados em um banco de dados em cluster na memória. Existem muitos casos de uso em que a velocidade do acesso instantâneo às coisas torna valioso colocar RAM, em vez de um disco rápido como o SSD. Você pode até continuar usando o SQL para alguns deles, se fizer sentido.

Por que isso deve preocupar a Oracle? Os dados estão crescendo e é improvável que os RDBMSes desapareçam. No entanto, muito do tempo de engenharia da Oracle ao longo dos anos foi feito para tornar a recuperação de dados em discos giratórios muito rápida. A Oracle precisará se adaptar a uma camada de armazenamento completamente diferente. Eles são, com o Oracle Database In Memory , mas estão expostos a uma concorrência diferente do que no passado. Pense em quanto tempo foi gasto para garantir que o otimizador de consultas escolha as estratégias corretas com base no layout das coisas no disco ....


Ah Eu nunca soube que as coisas tais como bancos de dados in-memory
Abdul

1
Como outro exemplo SQLite pode ser executado na memória assim não há necessidade de usar um banco de dados diferente
user151019

8

Postagem em wiki da comunidade coletando respostas originalmente deixadas como comentários da pergunta


Eu diria exatamente o oposto. Como as velocidades de leitura / gravação são tão rápidas, agora você pode obter um banco de dados acelerado por GPU (por exemplo, BlazingDB ou Alenka ) para processar números ainda mais rapidamente. Agora você pode ter consultas ainda mais complexas executadas mais rapidamente. Agora, consultas que as pessoas nem considerariam executar podem ser executadas a uma velocidade razoável. Quanto mais complexo e mais dados, melhor você é - cybernard

Enquanto Bob Martin já existe há muito tempo e geralmente vale a pena ouvir suas opiniões (se não concordar com :-), nesse caso, acho que ele está mergulhando na multidão "A morte dos bancos de dados relacionais está em cima de nós" (dos quais Eu sou um membro associado :-). Para algumas coisas, em circunstâncias limitadas, um argumento um tanto convincente pode ser apresentado de que tecnologias de banco de dados não relacionais podem fornecer uma vantagem. Dito isto, no entanto, o modelo relacional da IMO, por mais falho que possa ser, ainda oferece o melhor modelo de banco de dados de uso geral disponível atualmente. YMMV. - Bob Jarvis

A principal razão pela qual usamos bancos de dados não é porque os discos são lentos (de fato, originalmente, isso foi citado como motivo para não usar bancos de dados), mas porque os dados são complicados . O objetivo principal de um banco de dados é permitir que vários aplicativos / usuários possam encontrar os dados corretos e até alterá-los simultaneamente de maneira controlada. Fazer isso rapidamente é apenas um objetivo secundário dos bancos de dados. - RBarryYoung

RDBMS não vai desaparecer tão cedo; eles são a melhor opção para alguns tipos de aplicativos e o NoSQL (Mongo etc.) é a melhor opção para outros. Cavalos para cursos. - sh1rts

O banco de dados ajuda a organizar os dados. De fato, ele não foi projetado para acesso rápido aos dados. - JI Xiang

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.