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 em sua boca, mas isso é simplesmente como interpretei o que ouvi dele com minha experiência e compreensão limitadas.
Eu estava assistindo a um vídeo hoje (sobre arquitetura de software), sobre uma palestra de Robert C. Martin, e na segunda metade do vídeo, o tópico de bancos de dados era o foco principal.
Pelo que entendi 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 "RAM está chegando" e continua mencionando os discos RAM, mas depois diz que não pode chamá-lo de disco 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 ser obtido. ( este parágrafo foi parafraseado por mim )
Portanto, ele sugerindo RAM (como na memória do computador) como um substituto para os bancos de dados (como interpretei sua declaração) não faz sentido porque é como dizer que todos os registros são processados na memória durante o tempo de vida de um aplicativo ( a menos que você extraia de um arquivo de disco sob demanda)
Então, 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 o Oráculo, ficaria com medo. A própria base de por que existo está evaporando."
Pelo meu pouco conhecimento de SSDs, ao contrário dos HDDs, que são O(n)o tempo de busca (eu acho), os SSDs são próximos O(1)ou quase aleatórios. Então, a sugestão dele me interessou, porque nunca tinha pensado nisso dessa forma. A primeira vez que fui apresentado a bancos de dados alguns anos atrás, quando um professor estava descrevendo os benefícios sobre o sistema de arquivos regular, concluí que a função principal de um banco de dados é essencialmente ser um sistema de arquivos muito indexado (assim como otimizações, cache, acesso simultâneo, etc), portanto, se os índices não forem necessários no SSD, isso tornará os bancos de dados menos úteis.
Independentemente disso, porém, prefaciando que sou um newb, acho difícil acreditar que eles se tornaram menos úteis, já que todos ainda usam bancos de dados como o ponto principal de seu aplicativo, em vez de sistema de arquivos puro, e senti como se ele estivesse simplificando demais o papel dos bancos de dados.
Nota : eu assisti até o final para ter certeza de que ele não disse algo diferente.
Para referência: 42:22 é quando todo o tópico do banco de dados surge, 43:52 é quando ele começa com "Por que ainda temos bancos de dados"
Esta resposta diz que os SSDs aceleram consideravelmente os bancos de dados. Esta pergunta é sobre como a otimização é alterada.
Para TL;DR, minha pergunta, o advento do uso generalizado de SSD no mercado de servidores (seja futuro ou já ocorrido) reduz a utilidade dos bancos de dados?
Parecia que o que o apresentador estava tentando transmitir era que, com SSDs, é possível armazenar os dados no disco e não ter que se preocupar com a lentidão para recuperá-los, pois com HDDs mais antigos, como com SSDs, os tempos de busca estão próximos O(1)(Eu penso). Então, caso isso fosse verdade, isso hipoteticamente perderia uma das vantagens que tinha: a indexação, porque a vantagem de ter índices para tempos de busca mais rápidos acabou.
Existem algumas coisas em um banco de dados que devem ser ajustadas quando você usa SSDs. Por exemplo, falando para PostgreSQL você pode ajustar
effective_io_concurrency, erandom_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. Isso garanteEle está errado sobre os índices. Se toda a tabela puder ser lida no RAM, um índice ainda será útil. Não acredita em mim? Vamos fazer um experimento mental,
Imagine que você tenha uma tabela com uma coluna indexada.
Imagine que existam 500 milhões de linhas nessa tabela.
Imagine que todas as 500 milhões de linhas sejam concatenadas em um arquivo.
O que é mais rápido,
grep 'keyword' fileSELECT * FROM foobar WHERE id = 'keyword'Não se trata apenas de onde os dados estão, mas também de como você os ordena e quais operações você deve fazer para encontrar o que está procurando. 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.
Com base em sua postagem, parece que a mensagem clara é que as otimizações de tempo de pesquisa de RDBMS estão sendo substituídas por hardware, o que torna o tempo de E/S insignificante.
Isso é absolutamente verdade. O SSD em servidores de banco de dados combinado com RAM alta (real) torna a espera de E/S significativamente menor. No entanto, a indexação e o armazenamento em cache do RDBMS ainda são valiosos porque mesmo os sistemas com essa grande vantagem de IO podem e terão gargalos de IO devido a consultas de baixo desempenho causadas por indexação incorreta. Isso normalmente é encontrado apenas em aplicativos de alta carga de trabalho ou aplicativos mal escritos.
O valor chave para sistemas RDBMS em geral é consistência de dados, disponibilidade de dados e agregação de dados. Utilizar uma planilha do Excel, arquivo csv ou outro método de manter um "banco de dados" não oferece garantias.
O SSD não protege você de que seu servidor principal fique indisponível por qualquer motivo (rede, corrupção do sistema operacional, perda de energia). O SSD não protege você de uma modificação de dados incorreta. O SSD não torna mais rápido executar análises em comparação com "apenas tê-las".
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 curta duração (sendo usados como um cache) ou começar carregando tudo do disco e verificando 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 viá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 a RAM em vez de um disco rápido como o SSD. Você pode até continuar usando SQL para alguns deles, se fizer sentido.
Por que isso deveria 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 dedicado a maneiras de tornar a recuperação de dados em discos giratórios realmente rápida. A Oracle precisará se adaptar a um nível 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 escolhesse as estratégias corretas com base no layout das coisas no disco....
Postagem do Community Wiki coletando respostas originalmente deixadas como comentários de perguntas
Eu diria exatamente o contrário. Como as velocidades de leitura/gravação são muito 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, as consultas que as pessoas nem considerariam executar podem ser executadas a uma velocidade razoável. Quanto mais complexo e quanto mais dados, melhor para você - cybernard
Enquanto Bob Martin já existe há muito tempo e suas opiniões geralmente valem a pena ouvir (se não concordar com :-), neste caso eu acho que ele está mergulhando na multidão "A morte dos bancos de dados relacionais está sobre nós" (da qual Sou um membro associado :-). Para algumas coisas , em circunstâncias limitadas, pode-se fazer um argumento um tanto convincente de que as tecnologias de banco de dados não relacionais podem fornecer uma vantagem. Dito isso, no entanto, IMO, o modelo relacional, falho de várias e diversas maneiras, ainda fornece o melhor modelo de banco de dados de propósito geral disponível hoje. YMMV. - Bob Jarvis
A principal razão pela qual usamos bancos de dados não é porque os discos são lentos (na verdade, originalmente, isso foi citado como um motivo para não usar bancos de dados), mas sim 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é mesmo alterá-los simultaneamente de maneira controlada. Fazer isso rapidamente é apenas um objetivo secundário dos bancos de dados. - RBarryYoung
O RDBMS não vai desaparecer tão cedo; eles são a melhor escolha para alguns tipos de aplicativos e NoSQL (Mongo, etc.) é a melhor escolha para outros. Cavalos para cursos. - camisas
O banco de dados ajuda a organizar os dados. Em primeiro lugar, não foi realmente projetado para acesso rápido a dados. -JI Xiang