O armazenamento distribuído de Richard tem uma falha?

3

Na 4ª temporada do Silicon Valley , em sua tentativa de criar a nova internet, Richard encontra maneiras de armazenar grandes quantidades de dados em dispositivos distribuídos como telefones e até mesmo em geladeiras inteligentes. Escusado será dizer que cópias redundantes dos segmentos de dados residiriam em vários dispositivos. Quando o usuário solicita os dados, o servidor talvez transmita uma mensagem para quem está online e quem pode fornecer os segmentos de dados necessários. Sem saber o código de Richard, é possível que os dispositivos começassem a transmitir os dados imediatamente.

Isso não causará uma quantidade extraordinária de tráfego de rede, mesmo com o algoritmo de compressão de Richard?

    
por jujiro 20.08.2018 / 16:20

2 respostas

Depende ...

O problema com um sistema de armazenamento distribuído não seria tanto ingressar no grupo e solicitar dados. Isso seria comparável ao que a largura de banda é usada para serviços como bittorrent / dropbox / onedrive / google drive / ... hoje. E o uso da largura de banda desses serviços é pequeno em comparação com serviços de streaming de mídia como o Netflix / YouTube / Twitch / ....

No entanto, manter a alta disponibilidade e a confiabilidade dos dados pode ser o problema maior. Se você puder armazenar dados principalmente em dispositivos 'always-on', isso é bastante simples, você escolhe alguns membros do grupo, caga e replica os dados e pode viver lá por um longo tempo. Somente quando um membro morre, você escolhe um novo alvo de replicação.

No entanto, a maioria dos dispositivos de usuários finais com capacidade real de instalação e instalação de aplicativos (ou seja, não frigoríficos) são laptops, desktops, telefones, tablets, consoles de jogos, NAS, .... Apenas alguns deles estão sempre ativos, a maioria tem o hábito irritante de ser desligado ou perder a conectividade regularmente. Se esse for o principal volume de seu grupo de armazenamento / enxame, você precisará de uma taxa de replicação razoavelmente alta para cobrir uma perda de vários dispositivos e toda vez que essa taxa ficar muito baixa, devido a muitas desconexões, você precisará de novas replicações. Se essas operações se tornarem frequentes, você poderá ter um uso enorme de largura de banda apenas para manter o enxame.

Portanto, nesse universo, se a empresa conseguir muito armazenamento em dispositivos sempre ativos, a resposta provavelmente é não, o tráfego não será extraordinário. Se, no entanto, dependem principalmente de dispositivos mais voláteis, a resposta é provavelmente sim. Já que naquele momento do show eles estavam mirando em celulares, eu não acho que isso teria funcionado muito bem, mas nós nunca descobrimos.

Mas quem sabe, além de algoritmos mágicos de compressão sem perdas, o universo do vale do silício também tem largura de banda infinita (sem fio) mágica:).

    
21.08.2018 / 10:38

it is possible that the devices would start streaming the data right away.

Possível, mas altamente improvável - Eu trabalho no campo de armazenamento distribuído corporativo e, embora ele pudesse teoricamente fazer isso, é altamente improvável que ele fizesse isso. Ele é um excelente designer / codificador e, embora pudesse usar essa falha de design por motivos narrativos / humorísticos, na realidade, ele não faria isso e / ou falharia nos testes.

Em geral, e esta é uma explicação muito generalista, o modo como os sistemas de arquivos distribuídos funcionam é que, como você diz, os blocos / fragmentos são criptografados e distribuídos para nós N + 1 e um registro é feito em um banco de dados distribuído um banco de dados / valor em memória em vez de um com integridade referencial, como SQL), indicando o inode, referência de bloco, referências de chave de criptografia e nomes de nós. Essa entrada é replicada entre nós de banco de dados (geralmente os mesmos nós que o código do nó de armazenamento) para resiliência da mesma maneira que os dados de bloco reais. Dessa forma, quando um cliente solicita um arquivo (e a autenticação de acesso é passada), o nó de serviço (novamente pode ser um nó combinado com DB e bloco) procura o arquivo inode reference / s, que é servido pela rede do nó DB, As solicitações get são feitas para os nós de bloco para os vários blocos e o arquivo é então montado em ordem e não criptografado pelo nó de serviço, que serve o arquivo ao cliente e atualiza as várias interfaces de metadados para mostrar que o arquivo foi lido. Então, essencialmente, cada bloco é normalmente lido apenas uma vez (você poderia optar por uma leitura paralela de vários nós se quisesse se beneficiar de condições de corrida) e, portanto, os dados não causariam uma inundação. Tudo bem?

    
23.08.2018 / 17:03