gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Memória em vez de discos
Contribuído por BladeRunner em 03-02-02 21:54
do departamento who'd-say?
News jneves escreve "No sítio do costume encontrei uma entrevista com o CEO da Google. Nesta ele refere que o google usa DRAM em vez de discos para guardar os dados, e que sai mais barato. Não deixa de fazer sentido num motor de pesquisa como o google, mas tenho de admitir que não tinha pensado que esta era a forma de o google continuar a ser tão rápido... "

Linux está no ar... | Nascido [...] pela mão de [...] piratas informáticos  >

 

gildot Login
Login:

Password:

Referências
  • gildot
  • CNN
  • jneves
  • sítio do costume
  • entrevista com o CEO da Google
  • Mais acerca News
  • Também por BladeRunner
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Barato? (Pontos:1)
    por Lameiro em 04-02-02 1:29 GMT (#1)
    (Utilizador Info)
    Sai mais barato?
    OK. As memórias estão baratas mas não sabia que estavam assim tanto... ;)

    Re:Barato? (Pontos:0)
    por Anonimo Cobarde em 04-02-02 1:30 GMT (#2)
    As memórias estão baratas???
    Re:Barato? (Pontos:2)
    por MavicX em 04-02-02 11:43 GMT (#8)
    (Utilizador Info)
    Estavam, entretanto subiram para o dobro em apenas 3 meses.
    Sim, e não é só um bocadinho... (Pontos:2, Esclarecedor)
    por jneves em 04-02-02 3:09 GMT (#5)
    (Utilizador Info) http://silvaneves.org/
    Deixa ver, os discos têm, em média, tempos de acesso 200 000 vezes maiores que a memória. Portanto ter o mesmo tempo de acesso de um computador com DRAM (assumindo um número infinito de acessos), eu teria de ter 200 000 discos para simular a mesma performance.

    É que o problema não é a quantidade de espaço, como num computador normal, nem podes recorrer ao truque de só estares a aceder a uma pequena parte dos dados de cada vez. Num motor de busca é crítico poderes aceder rapidamente a qualquer parte dos dados.

    Desta forma se usares DRAM é muito mais barato do que estar sempre a aceder a discos, para já não falar nas dificuldades de manter cópias dos dados sincronizadas em vários discos e das interfaces para toda essa estrutura redundante de discos.
    DRAM? (Pontos:3, Informativo)
    por Strange em 04-02-02 2:06 GMT (#3)
    (Utilizador Info) http://strange.nsk.yi.org/

    É óbvio que é um CEO, para dizer a barbaridade de que é mais barato guardar os dados em DRAM...

    E imagino a quantidade de UPS e geradores e módulos de memória redundantes, não vá acontecer pifar um módulo, um sistema ou a rede eléctrica, e lá terão eles que voltar a basculhar toda a Internet à procura de futilidades e utilidades...

    Ou isso ou no Google usam-se termos que o resto da comunidade informática usa para outra coisa...

    hugs
    Strange

    Re:DRAM? (Pontos:1, Informativo)
    por Anonimo Cobarde em 04-02-02 2:51 GMT (#4)
    quando ele fala que tem um custo menor ele quer dizer que requer menos tempo de processmanto. Qume já estudou análise de agorítimos, estudou notação O (big o) sabe do que eu estou falando... Não fiquem falando besteira amigos.... Leonardo MC bsb-df
    Re:DRAM? (Pontos:2)
    por leitao em 04-02-02 11:09 GMT (#6)
    (Utilizador Info) http://linuxfreesite.com/~nunoleitao/
    Dude, a medida de complexidade de um algoritmo nao muda consoante corres em RAM, disco ou ervilhas.

    O bubblesort nao passa a ser O(nlog(n)) por correr em RAM, e o quicksort nao passa a ser O(n^2) por correr em disco.

    Alguns falam besteira, e tu falas bosteira.


    -- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias

    Re:DRAM? (Pontos:2)
    por vaf em 06-02-02 16:41 GMT (#22)
    (Utilizador Info) http://students.fct.unl.pt/users/vaf12086/
    A complexidade não muda. Mas o tempo de execução muda radicalmente se considerares que as intruções envolvidas no algoritmo têm custos diferentes, como é a realidade. Agora se assumires (para complicar os cálculos) que as leituras de disco demoram milisegundos e as de memória, dezenas de nanosegundos, é perfeitamente legítimo o raciocínio dele.

    Estar em disco ou ervilhas é apenas uma questão de multiplicar por uma constante característica de cada suporte.

    Na práctica, mais que na teoria, essa constante vai ser importante, sobretudo quando se trata da passagem de ervilhas, perdão, de ram para disco. Parecendo que não, é qualquer coisa como:

    t(ram) = 15ns (com cache)
    t(disco) = 5 ms * = 5 000 000 ns

    Ou seja, temos uma relação de três milhões para um. Daí a sua importância práctica.

    Aliás, provavelmente a ram sai-lhes mais barata (ao google) justamente por não terem de arranjar mecanismos para tornar o acesso a disco mais rápido. Poupam em RAIDs e coisas assim. Ficam apenas com ram da baratucha. Mesmo assim, ainda acho estranho que a ram saia mais barato...

    * Não confirmei o valor
    Re:DRAM? (Pontos:2)
    por vaf em 06-02-02 16:48 GMT (#23)
    (Utilizador Info) http://students.fct.unl.pt/users/vaf12086/
    Ok, ok... antes que me caiam em cima, os números estão mal. Já percebi. Desculpem.
    Re:DRAM? (Pontos:2)
    por cgd em 04-02-02 11:18 GMT (#7)
    (Utilizador Info)

    por acaso quem estudou isso, nao sabe bem do que estás a falar.

    é que uma coisa engracada que a notacao O() tem, é que esconde as constantes. ora, no caso da memoria vs disco, a unica diferenca em termos de processamento. vem exactamente nas constantes.

    Quando se diz que o acesso à memoria é 200k mais rapido, isso é uma constante. Nao depende do numero de dados que se esta a processar. A notacao O() vai ser exactamente a mesma quer se use memoria ou disco...


    -- carlos

    Re:DRAM? (Pontos:3, Esclarecedor)
    por cgd em 04-02-02 17:12 GMT (#13)
    (Utilizador Info)

    tens que desenvolver, porque nao sei do que estas a falar. o meu conhecimento de arquitectura de memorias, limita-se basicamente às que sao feitas via transistor+condensador (dinamicas) e às de matrizes de transistors (estaticas).

    de qualquer modo, estava-se a falar de DRAM, que nao devem cair nos casos que mencionaste, acho eu.

    seja como for, o comentario incial nao fazia sentido-- DRAM nao fica mais barato a nivel assimptotico, mas sim a nivel real (o tempo que as coisas realmente demoram a executar, e nao a sua complexidade funcional).


    -- carlos

    Re:DRAM? (Pontos:2)
    por leitao em 04-02-02 17:15 GMT (#14)
    (Utilizador Info) http://linuxfreesite.com/~nunoleitao/
    Se tivesse pontos de moderacao dava-te +2 :-)

    Very good point.

    -- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
    Re:DRAM? (Pontos:3, Informativo)
    por Strange em 04-02-02 18:11 GMT (#15)
    (Utilizador Info) http://strange.nsk.yi.org/

    Não se trata de tecnologia de memória, mas de acesso e disposição da memória.

    A tecnologia NUMA (Non-Uniform Memory Access) consiste em que o acesso a determinada região de memória pode ter diferentes tempos de acesso do que outra região. Isso acontece porque normalmente a memória é agrupada por processadores (ex: 4 procs c/ acesso directo a 2Gb + outros 4 procs para acesso a outros 2Gb, logo uma máquina com 8 procs e 4 Gb de memória).

    Esta tecnologia torna-se muito necessária na plataforma Intel visto que a largura de banda de acesso à memória é dividida entre os processadores, portanto não se pode ir adicionando processadores e esperar um aumento de performance proporcional...

    A título informativo, o uso de NUMA ou ccNUMA ou tecnologias semelhantes implica o uso de outro protocolo de invalidação da cache dos processadores, e o mais usado é o snoop.

    E a título de continuação de discussão, e assumo que quando te referes ao post inicial te referes ao meu, a minha crítica é que o CEO afirma ser mais económico e eficiente usar memória DRAM em vez de discos rígidos, sem distinguir o seu uso.

    Acredito que possam ter máquinas sem discos e no arranque lerem os dados necessários (SO e índice das páginas) para a memória, ou que tenham programado o motor de pesquisa para por tudo na memória e usar apenas isso, implementando o seu próprio algoritmo de cache, se necessário.

    Mas não acredito que não usem discos rígidos em alguma parte do seu sistema...

    hugs
    Strange

    Re:DRAM? (Pontos:3, Interessante)
    por leitao em 04-02-02 18:35 GMT (#16)
    (Utilizador Info) http://linuxfreesite.com/~nunoleitao/
    O argumento inicial nao era esse -- o argumento inicial era o de que a complexidade dos algoritmos de pesquisa mudam consoante fazes essa pesquisa em RAM ou disco. Isto e' obviamente um argumento idiota.

    O que (acho eu) toda a gente se esta' a esquecer, e' que nao e' necessario ter algoritmos complexos de passagem de dados para RAM. E' para isso que o kernel mantem uma cache de ficheiros -- se tiveres RAM suficiente consegues fazer cache de uma boa quantidade de informacao sobre o qual vais fazer uma pesquisa sem necessitares de I/O algum.

    Regards,


    -- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias

    Re:DRAM? (Pontos:1)
    por jpgm em 04-02-02 19:56 GMT (#18)
    (Utilizador Info)
    O que (acho eu) toda a gente se esta' a esquecer, e' que nao e' necessario ter algoritmos complexos de passagem de dados para RAM. E' para isso que o kernel mantem uma cache de ficheiros -- se tiveres RAM suficiente consegues fazer cache de uma boa quantidade de informacao sobre o qual vais fazer uma pesquisa sem necessitares de I/O algum.

    Era precisamente isto que eu estava a pensar, supostamente se tivermos ram suficiente o proprio sistema encarrega-se de fazer a cache dos ficheiros, bastando um sync de vez em quando para garantir que nao se perdem dados, ou estarei errado?
    E a vantagem disto e que nao sao precisos discos tao rapidos como se o acesso lhes fosse feito directamente...
    cumprimentos!
    Cumprimentos! zp
    Re:DRAM? (Pontos:2)
    por Strange em 04-02-02 20:00 GMT (#19)
    (Utilizador Info) http://strange.nsk.yi.org/

    O comentário inical desta thread é o meu, por isso a minha confusão. :)

    Mas relativamente à necessidade de ter algoritmos complexos para cache, tudo depende do uso final. Se for necessário um tempo de resposta muito baixo para certos dados é melhor colocar todos esses dados em RAM; ou se for necessário fazer vários seeks em dados espalhados pelo disco; ou caso o programa tenha um conhecimento maior sobre o seu comportamento relativamente a I/O do que os algoritmos actuais no kernel baseados em história passada e que apenas podem tentar prever as necessidades do programa.

    hugs
    Strange

    Re:DRAM? (Pontos:2)
    por cgd em 04-02-02 19:03 GMT (#17)
    (Utilizador Info)

    nao, nao, o artigo inicial a que me referia era o do "nao fiquem falando besteira"-man, nao era o teu.

    sobre os custos de pc baseados em memoria, nao tenho grande opiniao sobre o assunto, mas é um tema interessante. eventualmente até se podem ter sistemas realmente diskless com todo o deployment feito via networking (como as antigas x11 workstations por tftp) ou mesmo conservar o estado de memoria com uma pequena corrente electrica, como acontece nos portateis em suspend (to memory).

    de qualquer forma, nao era sobre isto que estava a falar.

    cya


    -- carlos

    Re:DRAM? (Pontos:2)
    por Dehumanizer em 04-02-02 12:02 GMT (#9)
    (Utilizador Info)
    Eu acredito que haja discos também. O que me parece provável é que no boot se copie 1 terabyte (estou a inventar, não faço ideia dos valores) de dados do disco para a ram drive de 1 TB, e depois trabalha-se com essa exclusivamente.

    "We have no choice! Our Communist overlords will slay us if we fail in our mission!"
    - A chinese military officer, "Tales of Suspense" #50, 1964
    Re:DRAM? (Pontos:1)
    por Dante em 04-02-02 13:40 GMT (#10)
    (Utilizador Info)
    Que boot?!?! não te esquecas que se aquilo for abaixo 5 segundos milhares de pessoas começam a pragejar por todo o lado! Portanto as redundancias à memória devem ser muito boas...
    Re:DRAM? (Pontos:2)
    por MacLeod em 04-02-02 15:27 GMT (#11)
    (Utilizador Info)
    Boot sim, porque provavelmente são várias maquinas em regime de redundância. E devem ter um servidor encarregue de distribuir a carga pelas maquinas. E acho que devem ter discos, no caso de uma maquina ir abaixo, quando voltar só tem de mandar tudo o que tá no disco para a memória (não deve demorar muito ;).
    Re:DRAM? (Pontos:2)
    por MavicX em 05-02-02 12:38 GMT (#21)
    (Utilizador Info)
    A base de dados da Google era cerca de 80 terabytes se não estou em erro. Tambem acho bastante improvavel terem isso tudo em RAM, provavelmente devem é ter caches gigantescas em RAM.
    Confusão!!! (Pontos:2, Esclarecedor)
    por Myke em 05-02-02 0:31 GMT (#20)
    (Utilizador Info)
    Não me lembro de ter vista tanta confusão junta :)
    Primeiro, como já alguns esclareceram, a velocidade do suporte não influencia a complexidade de um algoritmo (mesmo em casos de suportes de velocidades diferentes tipo numa ou sistema de disco-cache).
    Segundo, a cache de um sistema de ficheiros é genérica e afinada para usos comuns. O uso de um sistema de ficheiros como base de dados é definitivamente um uso incomum e que requer especial atenção. Senão vejamos, a informação sai de cache por antiguidade, a usar a cache de um sistema de ficheiros como cache de uma base de dados seria sujeitar o sistema a de tempos a tempos deixar sair o index (ou parte) da cache devido a diversos contéudos lidos.

    Por ultimo, no pouco que li sobre o google, o sistema de cluster é dividido. Tem um grupo de máquinas encarregues do crawler, um outro grupo (o maior) que guarda a informação em arrays de discos IDE, um grupo mais pequeno que indexa essa informação (em RAM e deve ser deste grupo que ele se refere) para uma pesquisa mais rápida e, um grupo frontal mais pequeno ainda que aceita os pedidos de pesquisa e faz o balanceamento de carga.

     

     

    [ Topo | Sugerir artigo | Artigos anteriores | Sondagens passadas | FAQ | Editores | Preferências | Contacto ]