Migre.me Estudo de caso

[Suissa 1]

Então vcs acham q se implementado um NOSQL com sharding e o mesmo replicasse os dados para servidores diferentes esse perrengue de perder tds os dados do Migre.me ocorreria?

[João Batista Neto 448]

Então vcs acham q se implementado um NOSQL com sharding e o mesmo replicasse os dados para servidores diferentes esse perrengue de perder tds os dados do Migre.me ocorreria?

 

O problema no Migre.me foi mais banal que técnico, Jean.

 

O backup foi feito na mesma máquina do sistema, quando caiu 1 caiu tudo.

 

Nesse caso específico, não foi um problema do banco relacional e sim um erro primário do administrador do backup; Se a replicação fosse feita para N servidores virtualizados na mesma máquina, o mesmo teria ocorrido.

 

Se o Migre.me utilizasse MySQL com replicação em diversas máquinas, ele não teria tido o problema.

 

De fato a replicação, seja em um banco relacional ou não relacional, teria evitado essa perda.

[Douglas 6]

O problema do Migre.me foi muito amadorismo.

 

E parece que o administrador do sistema também não tem muitos conhecimentos sobre tecnologia.

[Guilherme Rambo 4]

Eu vi muita gente chingando o Jonny Ken (criador do migre.me), no entanto é importante deixar bem claro que o problema foi com a empresa do datacenter, que não armazenou os backups corretamente. O problema não teve nada a ver com a escolha do banco de dados ou tecnologia server-side utilizados.

[Douglas 6]

Eu vi muita gente chingando o Jonny Ken (criador do migre.me), no entanto é importante deixar bem claro que o problema foi com a empresa do datacenter, que não armazenou os backups corretamente. O problema não teve nada a ver com a escolha do banco de dados ou tecnologia server-side utilizados.

 

Exatamente.

 

Ele até fez um vídeo se desculpando.. para quem ainda não viu - http://migreme.com.br/blog/informacoes-sobre-os-problemas-do-migre-me/

 

A hospedagem também já se manifestou - http://tecnoblog.net/38845/host-do-migre-me-se-manifesta-sobre-a-perda-de-dados/

[Patrique 0]

Galera, como todos devem saber o migre-me foi "salvo" pela uol, que tinha copias da base de dados deles de 2 semanas atrás, ou seja, quando eles ainda estavam hospedados lá.

 

Alguém ai consegue ver alguma lógica do por que do uol ter mantido essa base de dados? a mesma não deveria ter sido excluída com o cancelamento do serviço?

 

Digo isso pois fica uma coisa estranha isso, pois nas tabelas existem dados privados que não podem ficar jogados por ai.

 

Fico contente do migre-me ter conseguido se salvar, mais essa história do uol possuir base de dados de não mais clientes me assusta.

[Prog 183]

Patrique,

 

Toda empresa que se pode chamar de séria possui politicas de segurança bem rígidas, o fato de um contrato que estabelece uma prestação de serviços não afeta estas politicas, a não ser que seja estabelecida por um pedido expresso por parte do cliente. Muitos desses backups ficarão armazenados por meses, até anos. Por isto é importante conhecer as politicas que os provedores de serviços utilizam, ou mesmo aquilo que consta no contrato firmado e, em caso de encerramento do contrato, por quanto tempo seus backups ficarão armazenados nos servidores da prestadora.

[Patrique 0]

Hum saquei Prog, acabei depois lendo um comentário de um gerente do Uolhost aonde ele fala exatamente o que você se referiu, segundo ele no contrato do migre.me estava especificado que o backup deveria ser mantido por pelo menos 1 mês depois da saída deles, graças a Deus este problema ocorreu nesse prazo, caso contrário o migre-me teria que ter começado novamente do zero.

[Mário Monteiro 179]

E o UOL cobrou quanto por esta boa ação?

[Patrique 0]

Nada! Inclusive o UOL deu a opção do Jonny ficar por lá até que ele arrume tudo, segundo relatos dele mesmo, ele pensa em voltar em definitivo pra lá, mais ai só o tempo dira.

[João Batista Neto 448]

E o UOL cobrou quanto por esta boa ação?

 

Nada! Inclusive o UOL deu a opção do Jonny ficar por lá até que ele arrume tudo

 

Pelo contrário, Patrique, hehhe

 

Pode não ter cobrado, financeiramente, nada agora; Mas além de ter sido uma boa postura, comercialmente falando, por parte do UOL,

 

segundo relatos dele mesmo, ele pensa em voltar em definitivo pra lá, mais ai só o tempo dira.

 

eles acabam recuperando um cliente, e ganhando outros que ficaram sabendo dessa postura.

 

 

O fato, pessoal, é que o Jonny não teve culpa pelo ocorrido, muita gente se sensibilizou pelo que ocorreu com ele (eu inclusive) e acreditem, assim que restabelecido, ele contará com o apoio de muita gente, pessoas que utilizavam outros serviços semelhantes passarão a utilizar o migre.me e o Jonny voltará com o serviço dele com muito mais força que antes.

 

Como alguns poderiam dizer "Há males que vêm para o bem".

[Patrique 0]

Certamente João, eu não queria utilizar a expressão jogada de marketing por esta boa ação, porém ela se encaixa perfeitamente e para falar a verdade foi bom para ambos os lados.

 

O importante é que o migre.me só perdeu 2 semanas de dados e realmente há males que vêm para o bem.

 

[]'s

[Suissa 1]

A unica empresa q ganhou com td isso foi a UOL, pessoal eu sei q o problema foi ter um backup na mesma maquina, mas com nosql ngm iria gerar um slave na mesma maquina neh? Se for se mate antes ehhehhee

[Antonelli Santos 0]

Estou começando a entender os motivos que estão levando as empresas e programadores à migrarem para o NoSQL. Todos falam muito em escalabilidade, mas o NoSQL possui resposta (à consultas e inserções) mais rápidas que o MySQL ou PostgreSQL?

Para todo tipo de aplicativo, seja website, seja funções em tempo-real, vale à pena utilizar o NoSQL (como um todo)?

Como por exemplo, os próximos projetos que forem executados daqui pra frente, forem com NoSQL? Tornando os outros obsoletos? Ou ainda está muito "prematuro" essa idéia de NoSQL para todas as funcionalidades?

 

São tantas perguntas, mas são coisas que ainda "rebatem" dentro do meu cérebro! rs .

 

EDIT.: Poutz, revivi o tópico. Nem tinha prestado atenção pois estava nos "recentos" da seção! Desculpe-me!

[Suissa 1]

Então broder na real ele não é a solução de todos seus problemas, tudo depende do seu contexto, por exemplo o MongoDB usa MTAAAA AM pois tds seus docuemntos ficam persistidos tanto no HD como na RAM, porém usa menos processador que o MySQL que usa pouca RAM.

 

Sim as consultas são de ordem 10x mais velozes pelo menos. Ae você tem que ver se quer ganhar com escalabilidade e agilidade ou uma segurança maior dos relacionais.

 

 

Estou começando a entender os motivos que estão levando as empresas e programadores à migrarem para o NoSQL. Todos falam muito em escalabilidade, mas o NoSQL possui resposta (à consultas e inserções) mais rápidas que o MySQL ou PostgreSQL?

Para todo tipo de aplicativo, seja website, seja funções em tempo-real, vale à pena utilizar o NoSQL (como um todo)?

Como por exemplo, os próximos projetos que forem executados daqui pra frente, forem com NoSQL? Tornando os outros obsoletos? Ou ainda está muito "prematuro" essa idéia de NoSQL para todas as funcionalidades?

 

São tantas perguntas, mas são coisas que ainda "rebatem" dentro do meu cérebro! rs .

 

EDIT.: Poutz, revivi o tópico. Nem tinha prestado atenção pois estava nos "recentos" da seção! Desculpe-me!

[Antonelli Santos 0]

Então broder na real ele não é a solução de todos seus problemas, tudo depende do seu contexto, por exemplo o MongoDB usa MTAAAA AM pois tds seus docuemntos ficam persistidos tanto no HD como na RAM, porém usa menos processador que o MySQL que usa pouca RAM.

 

Sim as consultas são de ordem 10x mais velozes pelo menos. Ae você tem que ver se quer ganhar com escalabilidade e agilidade ou uma segurança maior dos relacionais.

 

Entendo! E qual o motivo dele ser escalavel e o MySQL "não"? Vejo como o NoSQL necessitando de ser pois precisa de RAM para processar os dados e o MySQL necessitando pois precisa de PROCESSADOR para processar os mesmos dados.

Tudo bem, virão milhares à dizer que "escalabilidade" é "nativa" no NoSQL, que ele foi projetado para isso. Mas queria entender o motivo de ter mudado toda a engenharia de processamento de dados... Ainda não compreendo o que é "banco de dados sem vínculo key".

 

Mas enfim... Estou entrando em debate sobre o assunto pois sou um "programador" autodidata (por enquanto) e o que sei é em relação à SQL, e estou tentando "abrir minha cabeça" para essa nova idealidade do NoSQL.

 

Essa "nova história" de escalabilidade é, em linguagem popular, uma setorização do processamento? Escalando (designando) que cada máquina/cluster seja responsável por processar determinada parte da tarefa, ou no caso de uma única tarefa, processar uma parte da mesma tarefa? Se for desta forma, ai sim dá pra entender toda a questão acima, mas diriamos que...

 

Então o NoSQL está voltado para BigData?

 

PS. 1: Caso este tópico não seja ideal para este debate, me avise que posto em outro lugar!

PS. 2: Sei que sou chato, mas estou lendo e me informando sobre esses novos sistemas de gerenciamento de dados pra "me atualizar", e num vi um fórum nacional debatendo o assunto intensamente.

 

Ninguém para discutir o assunto? :(