- Feeds completos
- Feeds dos comentários
- Feeds do fórum
- Receba o Meio Bit via e-mail
0 assinantes
Fórum
Últimos tópicos no fórumÚltimas respostas no fórum
- Telão de acrílico?
- [HELP] XBox não enxerga rede wireless
- HDR forçando a barra
- 1o Mobile Expert Worshop - alguém vai?
- Anti Virus
- Nikon d-40 como dslr entrada!
- Software para migrar FTP
- Recuperação de Dados Deletados do HD
- Montando um micro com muita verba
- Site especial do Google sobre as enchentes em SC
- placa de video temporária barata!!!
- E se fosse tivesse toda a internet em suas mãos?
Newsletter
Mantenha-se informado sobre as nossas novidades com nosso newsletter semanal, todas as segundas-feiras
As constantes, diárias e irritantes saídas do ar do Twitter estão deixando muita gente irritada, e a saída de Blaine Cook, arquiteto-chefe do projeto não deixou os fãs muito confortáveis. A grande briga na comunidade de desenvolvedores é se Ruby on Rails, o framework-base do Twitter escala ou não escala.
O Michael Arrington do TechCrunch postou algumas perguntas bem diretas, e o pessoal do Twitter não teve opção a não ser responder. Digamos que Ruby escalar ou não agora é irrelevante, o buraco é muito mais embaixo.
O Twitter aparentemente foi feito nas coxas. Sem nenhuma preocupação com crescimento futuro. A arquitetura não foi pensada para escalar, independente da linguagem utilizada.
O backend do sistema tem UMA MÁQUINA MySQL para gravação e três máquinas para consultas. E só. ~
O MySQL é um excelente banco para aplicações que exijam consultas simples, mas ele simplesmente NÃO funciona com consultas complexas. Perde feio em performance para o SQLServer, Oracle, DB2, PostgreSQL e qualquer outro banco "de verdade".
Talvez sua maior limitação seja na replicação de dados e no fallback entre servidores, quando da queda de um master. Existem soluções de mercado (pagas) para isso, mas o pessoal do Twitter pelo visto não sabia.
Quando o Twitter ameaça cair, um operador MANUALMENTE troca de um servidor de banco de dados para outro.
Agora estão planejando migrar de uma solução baseada em banco de dados para uma baseada em filesystem. Vão literalmente reinventar a roda, para depois descobrir que precisam de um banco de dados decente, e que é impossível gerenciar a quantidade de atualizações do Twitter via filesystem.
A impressão que se tem, vendo o Twitter, estudando o código da maioria das aplicações como o PHPNuke ou mesmo o Drupal é que gente sem qualificação e/ou experiência toca esses projetos. Não há otimização de código, tratamento de exceções, nada. O Drupal por exemplo até pouco tempo sequer tinha um dicionário de dados, que dirá um diagrama de caso e uso, e nem sonhar em uma documentação UML compliant.
Metodologia de desenvolvimento é algo importante. Não é preciso se você vai fazer uma besteirinha em meia-hora de PHP, mas se houver a menor possibilidade daquilo virar um projeto multiusuário e crescer, é melhor planejar desde o princípio.
Do contrário você acaba com um Twitter na mão, tendo que reiniciar servidor só pro bicho conseguir rodar.
Fonte: Twitter
- Ueba
- Rec6
- Blog do Carlos Cardoso
- entre com seu usuário e senha ou registre-se no site para enviar comentários
Po, mysql é bom e aguenta grande volume sim...
acho que o problema pode ser codigo mal feito pra fazer as consultas e gravações
e mesmo que mysql fosse o problema, da pra migrar pra qualquer *sql sem muito esforço...
agora, filesystem... meu, parece idéia do povo que eu tenho que ficar recolhendo cocô no trampo
/***************/
Quer Games online, Xadrez e diversao?
Route10-games - www.route10.com.br
Isso depende do que você considera um grande volume. Quantos GBs de banco e Qual a quantidade de usuários simultâneos caracterizam um grande volume?
Concordo em partes. A migração de um mysql para um Oracle, DB2 pode ser feita em muitos casos sem muito esforço. Mais uma migração de um Oracle para um DB2 ou semelhantes pode ser muito, muito traumática e complexa
Isso depende do que você considera um grande volume. Quantos GBs de banco e Qual a quantidade de usuários simultâneos caracterizam um grande volume?
O MySQL realmente é muito bom, mas não é nem de longe robusto o bastante para aplicações muito grandes.
Concordo em partes. A migração de um mysql para um Oracle, DB2 pode ser feita em muitos casos sem muito esforço. Mais uma migração de um Oracle para um DB2 ou semelhantes pode ser muito, muito traumática e complexa
Mas como no caso em questão o banco está em MySQL, é relativamente fácil migrar para um PostgresSQL, por exemplo. Podem aproveitar que também é free, não vão precisar pagar uma licença e terão toda a robustez necessária, mas isso falando de BD, uma vez que, de acordo com o Cardoso, a aplicação inteira foi mal feita. Não adianta ter um banco de dados super robusto se a aplicação criará um gargalo na comunicação.
Antes de fazer uma pergunta idiota, pesquise!
Isso depende do que você considera um grande volume. Quantos GBs de banco e Qual a quantidade de usuários simultâneos caracterizam um grande volume?
O MySQL realmente é muito bom, mas não é nem de longe robusto o bastante para aplicações muito grandes.
Concordo em partes. A migração de um mysql para um Oracle, DB2 pode ser feita em muitos casos sem muito esforço. Mais uma migração de um Oracle para um DB2 ou semelhantes pode ser muito, muito traumática e complexa
Mas como no caso em questão o banco está em MySQL, é relativamente fácil migrar para um PostgresSQL, por exemplo. Podem aproveitar que também é free, não vão precisar pagar uma licença e terão toda a robustez necessária, mas isso falando de BD, uma vez que, de acordo com o Cardoso, a aplicação inteira foi mal feita. Não adianta ter um banco de dados super robusto se a aplicação criará um gargalo na comunicação.
Antes de fazer uma pergunta idiota, pesquise!
"O MySQL é um excelente banco para aplicações que exijam consultas simples, mas ele simplesmente NÃO funciona com consultas complexas."
Alguém aqui lembrou da wikipédia? wordpress.com? O único campo em que eu não vejo o mysql tento performance semelhante aos grandes banco de dados é não para "consultas complexas" mas para inclusões complexas e bancos relacionados, onde informações mudam o tempo todo, mysql aguenta até 5 twitters, acho que vocês estão esquecendo de procurar ou testar a plataforma pra se admirirar com um caso de incompetencia de um projeto X que tem problemas.
Não tenho nada contra o MySQL, uso e gosto bastante! Mas conheço as suas limitações!
Já vi maravilhas sendo feitas com ele, mas como eu já falei, ele tem limites!
Não estou dizendo que ele não seja o bastante para o twitter, para começo de conversa eu nem USO o twitter.
Eu desenvolvi um sistema para um ministério com PhP+PostgresSQL, o resultado é imbatível, bem melhor do que os testes utilizando o MySQL pra mesma aplicação.
Mas, falando especificamente do Twitter, o problema parece ser mais embaixo... sem um projeto bem feito, não adianta rodar um DB2 em um CRAY que continua ruim...
Antes de fazer uma pergunta idiota, pesquise!
Aonde tem consulta complexa no Wordpress ou na WIkipedia?
Se der mole nem JOIN fazem.
Não compare com um twitter, onde uma simples inserção altera milhares de registros.
Alguém aqui lembrou da wikipédia? wordpress.com? O único campo em que eu não vejo o mysql tento performance semelhante aos grandes banco de dados é não para "consultas complexas" mas para inclusões complexas e bancos relacionados, onde informações mudam o tempo todo, mysql aguenta até 5 twitters, acho que vocês estão esquecendo de procurar ou testar a plataforma pra se admirirar com um caso de incompetencia de um projeto X que tem problemas.
Ai é que está: com certeza existe um fator diferencial na arquitetura da wikipédia, wordpress.com que compensa as deficiencias nativas do mysql.
Veja: Um banco de dados robusto e completo inclui várias coisas no pacote como: Controle das aplicações (threshold de cpu, rowsread, rowsselected, rowswritten), particionamento de bancos e tabelas, ferramentas para monitoramento de performance, reorganização automática de tabelas/indíces, gerenciamento nativo dos filesystems/tablespaces, ferramentas para propiciar a propagação dos dados e redundancia dos bancos, etc.
A maioria dessas "features" não existe no mysql e as que existem ainda não estão maduras o suficiente.
Provavelmente o wikipedia e o wordpress utilizam outras ferramentas para gerenciar o workload e proporcionar a redundância dos ambientes, bem como o gerenciamento das aplicações que utilizam o banco.
Como o cardoso disse logo acima, o que faltou no twitter foi planejamento. O código tem que ser bem feito e a arquitetura do ambiente tem que ser bem estruturada para compensar a deficiencia das aplicações que estão sendo usadas
Tudo que precisou ser falado sobre o MySQL foi dito agora. Ninguém lembra das aplicações de sucesso e BEM FEITAS nessas horas. Criticar sem saber como tirar o melhor da ferramenta é mole
http://logdaselva.com
Cara, desculpe, mas o mySQL NÃO É UM BANCO ENTERPRISE-READY, não posso fazer nada, é um fato.
Wordpress, WIkipedia? Isso nao tem NADA de complexo.
O último sistema que mexi tinha um livrinho de 700 páginas só de regras de negócio. Tudo atuchado no banco, em storeds. Uma delas tinha 6 páginas. Levava 15 minutos para rodar. Um dia fui testar no MySQL, só de farra. Depois de 4 horas a máquina sentou, travou e não tinha terminado de rodar.
Não vejo tal complexidade no twitter. Vejo tráfego de dados intenso. Não procedures demoradas. Não regras de negócio super complexas.
Não vejo o twitter muito longe da wikipedia ou do wordpress se tratando de complexidade, só na intensidade da movimentação de dados que ele é maior. Acho que isso se trata muito mais de se ter somente um servidor e da estrutura da aplicação, do que do banco que ele tá rodando.
Quanto ao MySQL não ser enterprise-ready, vamos aguardar pra ver o que a Oracle vai fazer com ele
http://logdaselva.com
O SAP R/3 adota o MySQL como uma alternativa de BD, só que o nome é Max DB, que na verdade é um MySQL + Tunning.
Até onde eu sei (e muitos também), o SAP é um sistema Enterprise, não?!
--
"Uma pessoa inteligente resolve um problema, um sábio o previne." Albert Einstein
Oi !
Vamos simplificar ?
A MySQL é a fabricante do bichinho.
Se ela quisesse vender mais, bastava provar a eficiência dele para grandes ambientes.
Se quisesse provar a eficiência dele para grades ambientes, colocava ele no índice TPC - http://www.tpc.org
Mas não, ele não está lá. Simples assim.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Oi !
Vamos simplificar ?
A MySQL é a fabricante do bichinho.
Se ela quisesse vender mais, bastava provar a eficiência dele para grandes ambientes.
Se quisesse provar a eficiência dele para grades ambientes, colocava ele no índice TPC - http://www.tpc.org
Mas não, ele não está lá. Simples assim.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
http://www.tpc.org/tpch/results/tpch_perf_results....
seria o terceiro lugar dos testes de 100 e 200gb dessa lista (by performance), ganhando inclusive de sistemas clusterizados com oracle?
e quanto a fabricante, eu não vejo a microsoft ali, mas IBM SUN HP e etc, apesar de usarem muito o MsSQLServer. e ainda assim o MySQL agora é da Sun.
Price/QphH = .70 US $ !! E o preço é bem consideravel!
Quem diria, alguem sabe explicar pq nao tem Postgre la? Como ele é BSD, será que não tem pedaço dele em outros bancos fechados? Do mesmo modo q projetos BSD estão presentes no OSX da Apple.
Pode ter mesmo, a licença permite.
Esses tempos deu um rolo porque o pessoal do PG descobriu umas vulnerabilidades que afetavam os dois bancos. Corrigiu e pronto.
Depois o pessoal do mysql foi lá, "se inspirou", e saiu divulgando como se tivesse descoberto e solucionado.
Não é porque uma licença permite, que não pode ter ao menos um pouco de cordialidade.
Você há de concordar que se o MySQL não tivesse boa performance, a SAP não arriscaria adotá-lo, já que possui somente grandes clientes, tais como empresas do setor de telecom, petroleo, mineração, etc.
Eu gosto do MySQL, apesar de preferir o PostgreSQL.
E sobre o TCP, eu conhecia, muito boa referência.
--
"Uma pessoa inteligente resolve um problema, um sábio o previne." Albert Einstein
Rapaz, já vi servidores de jogo online que usa MySQL como BD e roda muito bem apesar de ser escrito em java
Servidor de jogos só usam o banco para gerenciar logins, e de qualquer jeito não dá pra comparar um servidor com 100 ou 200 simultâneos com um Twitter.
Negativo, o servidor de jogos em questão é o L2J (lineage) e qualquer ação dentro do jogo (matar um mob, matar alguém, dropar um item, conversar com NPC) gera consulta e escrita no servidor MySQL, olha só a máquina de um servidor que tem:
Statistics
Accounts 832695
Characters 181219
Clients 4002
Database Server:
CPU: 2xAMD Opteron 250 (2x2400 Mhz)
Memory:6x1Gb DDR ECC REG Kingston (PC3200, 400MHz)
Hard drive: 6x73.5 Gb Seagate 15000rpm SCSI
SCSI controller: Adaptec ASR-2130SLP SINGLE Ultra320
Motherboard: s940 ATX AMD-8000 Series chipset SM H8DA8
??????: SuperMicro 6xHotSwap SCSI, 550W
Game server:
CPU: 2xAMD Opteron 254 (2x2800 Mhz)
Memory: 6x2Gb DDR ECC REG Kingston (PC3200, 400MHz)
Hard drive: 3x73.5 Gb Seagate 10000rpm SCSI
SCSI controller: PCI 64 RAID BBU Module for LSI 320-1
Platform: SUPERMICRO AS1020A-8
Realmente, os servidores L2J tem uma interação GIGANTE com o banco! Já tive alguns e sei o quanto aquela gracinha suporta, mas também sei que o servidor tem que ser reiniciado de tempos em tempos (no mínimo uma vez por semana) porque o servidor fica sobrecarregado, especialmente se no servidor for permitido jogar ítens no chão (o que gera mais entradas no banco), aí tem que reiniciar quase uma vez por dia. Tudo bem que o L2J é feito em Java e também é culpado por sobrecarregar o computador...
Antes de fazer uma pergunta idiota, pesquise!
insert / update / select.
Como eu disse, queries simples.
Me chame quando tiver uma stored de 6 páginas rodando, aí a gente conversa.
Ops, o suporte a Stored Procedures só veio na última versão do mySQL e NENHUM grande projeto usa, esqueci ;)
A bilhetagem do iBest quando era provedor era feita em mySQL. Foi o único banco que aguentou. Só que consultas complexas eram feitas em Oracle. ENTENDAM, a ferramenta certa para o problema certo. Não adianta os fanboys do mysql baterem cabeça, ele NÃO é bom pra tudo. Nenhum banco é,
Faço suas as minhas palavras.
É impossível comparar o mySQL com um DBMS robusto. Impossível. Alguns poucos motivos eu listei lá no comentário de cima.
Na boa, esse tipo de comparação é uma ofensa a qualquer dba presente
Mas o Twitter usa Stored Procedures? Dúvido muito!
Não adianta trocar o BD, tem que trocar quem desenhou esse DB mal feito, a culpa não é do MySQL, isso que estou dizendo.
Agora BD em filesystem o único que sei que já existe é o SQLite, mas ele é mais simples que o MySQL.
Tá.. nem tão simples assim Cardoso, tem várias queries muito mais complicadas, mas é justamente por causa delas que o servidor fica pesado e tem que ser reiniciado.
Tenho que concordar com você, o MySQL não é bom pra tudo! Os fanboys tinham que se dar conta que ele é muito bom para outro tipo de aplicação...
Mas, a respeito do twitter, o problema dele foi o descaso dos desenvolvedores, que não tomaram providências ao ver o crescimento exponencial do projeto deles.
Antes de fazer uma pergunta idiota, pesquise!
O MySQL tem suas limitações assim como qualquer outro. Mas não diga que a culpa, no caso do Twitter, é dele.
QUALQUER banco senta quando não é bem projetado.
Para o Twitter, MySQL bem projetado e bem gerenciado iria funcionar muito bem assim como funciona em outros projetos maiores que o utilizam.
A questão não é ser fanboy ou não, a questão é culpar algum software quando a culpa é de quem projeta e administra o sistema.
O MySQL é um banco de verdade, o que não é banco de verdade pra mim é MS Access, FileMaker, etc... É meio sem-noção compará-lo com um Oracle, DB2... é a mesma coisa que comparar uma Ferrari e um Gol, cada um serve pra determinada situação.
É claro que uma stored procedure gigantesca como a que você falou não vai rodar legal no MySQL, mas por acaso o Twitter utiliza procedure de 6 páginas? Não.
Se não fosse "enterprise ready", ele não ia rodar em SAP, Microsiga, etc.
As pessoas tem uma mania de querer matar um mosquito com uma bomba nuclear.
Fravo is a robot
http://geekwerk.blogspot.com
Cardoso, parabéns pela coerência.
Reveja seus conceitos. Um MMORPG como o WoW, por exemplo, tem bases de dados com até centenas de tabelas (para armazenar dados do usuarios, seus personagens, manter log das quests, mobs, etc). Se tiver curiosidade de ver o script de criação de uma base destas incompleta (pois é muito complicado copiar 100% do comportamento do original apenas por observação e packet sniffing), procure no Google por ascent, que é um emulador open source para servidor de WoW.
---
Tecnologia deve ser o meio, não o fim.
"A impressão que se tem, vendo o Twitter, estudando o código da maioria das aplicações como o PHPNuke ou mesmo o Drupal é que gente sem qualificação e/ou experiência toca esses projetos. Não há otimização de código, tratamento de exceções, nada. O Drupal por exemplo até pouco tempo sequer tinha um dicionário de dados, que dirá um diagrama de caso e uso, e nem sonhar em uma documentação UML compliant."
hm.. vai lá e ajuda com sua super qualificação e experiência.. ou faz outro melhor.
hm.. vai lá e ajuda com sua super qualificação e experiência.. ou faz outro melhor.
Mais um da linha:se alguém não gostar de ovo, só pode criticar se puder botar um também...
[s]
Mais um da linha: Reclamo quanto eu quero. E reclamo de quem reclama que eu reclamo por reclamar.
Documentação 100% só existe em projetos onde o emprego de que fez a documentação depende dela.
Claro que não são todos os casos.
O ponto em questão seria: Cardoso, se gosta tanto de falar mal do Drupal, POR QUE DIABOS O MEIOBIT USA ELE? Acho que essa é uma boa pergunta.
http://logdaselva.com
Na época parecia uma boa opção, precisávamos migrar rápido do Movable Type.
Depois que vimos as letras miúdas.
Sò um exemplo: Essa bosta não tem NENHUM compromisso de compatibilidade de API com as versões anteriores. TODOS os plugins podem parar de funcionar a cada migração. E em geral páram.
Segundo: NÃO HÁ documentação de sistema.
Terceiro: NÃO HÁ otimização nenhuma. Para exibir a página inicial ele roda mais de 800 queries SQL.
Nem de longe estou defendendo o Drupal. Concordo que não é otimizado, se não usar o eAccelerator no PHP a performance fica ridícula.
Quanto à documentação, a comunidade ajuda bastante, porque é enorme.
E em relação aos modulos, o drupal não se responsabiliza por módulos de terceiros, ele cria as compatibilidades dos modulos oficiais. Eu sinceramente não sou fã dessa ideia de compatibilidade porque se a ferramenta quer MELHORAR, o código muda de verdade, e certos pontos não podem ser mantidos.
http://logdaselva.com
Chama-se API.
melhorar a aplicação não é reescrever do zero e ficar mudando inclusive estrutura de tabela. Imagine se a Microsoft ou o pessoal da FSF mudasse todas as chamadas de API a cada versão do VisualC++ ou do GCC, que beleza que seria.
Na verdade, guardadas as proporções, eles fizeram isso em algumas ocasiões...
---
Tecnologia deve ser o meio, não o fim.
That's the point.
O Drupal teve necessidade de mudar várias coisas da API, e tem melhorado
http://logdaselva.com
Acho que isso ajuda a explicar pq o Google comprou o Jaiku e não o Twitter.
Excelente ponto!
Antes de fazer uma pergunta idiota, pesquise!
Será que eles tinham acesso ao código? Não foi pelo uso de MySQL que o Google não comprou o Twitter.
________
http://nodoadouniverso.wordpress.com
http://cybergalo.wordpress.com
Também duvido que o google tinha acesso ao código, e duvido que ele não teria comprado porcausa do banco.
http://logdaselva.com
de qualquer forma tem o fato do Jaiku usar Google App Engine e ser feito em Phyton que é o amor do google....
--
http://blog.muuzik.net/ << participo aqui também
that's the point!
ººno mundo so existem 10 tipos de pessoas, as que entendem...e as que nao entendemºº
RafaelDFMelo'Blog
Ralmente, na época todo mundo achou estranho, já que nem o Twitter famoso do jeito que estava negaria uma compra do Google
Defô?Defú?Defáulti?
Se eu tivese feito o Twitter, teria feito exatamente igual. Eu jamais teria imaginado que mais de meia dúzia de desocupados usariam essa bagaça.
Eu também não esperaria isso, teria feito num shared host mesmo.
Mas, claro, com o crescimento exponencial eu ia correr pra modificar a aplicação e a estrutura...
http://logdaselva.com
Concordo em gênero, número e grau!
[]s
Já vi Oracle RAC rodando em duas IBM p570 (pSeries RISC rodando AIX) e por culpa dos developers, algumas queries simplesmente travarem o cluster. Claro, depois que contrataram uma consultoria para apontar alguns erros na aplicação nas queries, tudo ficou rodando bonito... mas ai passaram-se 3 meses... e começou tudo de novo...
Resumo;
Não adiante usar o melhor banco de dados, melhor hardware ou melhor S.O., tudo sempre dependerá de como a aplicação foi escrita e também de como os acessos ao banco foram desenhados.
E como nem tudo são críticas, também já vi muito sistema bom usando mysql.
Não adianta usar um Super DB para um sistema simples, pois o custo e o overhead não compensam e ainda por cima podem até ficar mais lento que um DB mais simples. E também não adianta usar um banco não tão parrudo se a aplicação é crítica demais e os problemas que isso pode causar justificam o investimento em uma solução de DB melhor. São muitas variáveis em jogo.
Clap clap clap!
Pra resumir a discussão toda! Muito bom!
Matheus
www.30segundos.com.br
Po.. Tem um pessoal teimoso demais.. Também pago pau para o mysql ter essa inserção sendo opensource.. Mas não é a melhor opção para este caso.. Um pgsql já seria um grande passo pro twitter (e porra.. só eu não uso isso??)..
Pra mim o cardoso era só um gordo tonto que escrevia em blogs.. Não sabia que ele tinha algum conhecimento.. ahehaheaheahehaheahehaehaheiuha
O MySQL é excelente para a Web 1.0, mas não pra 2.0.
Antigamente dava pra segurar a onda em sites como o Slashdot pois apesar da quantidade boçal de conexões, era tudo consulta simples.
As aplicações de hoje não são mais assim. Imagine o Twitter de um Scoble da vida, com 26,143 seguidores. Cada atualização dele, 26,143 inserts, sem contar os contatos indiretos.
Só uma pergunta Cardoso... Quem seria LOUCO o bastante para fazer um insert que faz 26143 outros, quando poderia simplesmente fazer apenas um e depois os demais usuários na hora que usassem atualizar em suas páginas vissem a atualização (selects individuais para ver mudanças)? Isso para mim é de uma insanidade total!
Quanto ao MySQL, eu sou da opinião de que ele é muito bom se você precisa de uma base de dados que responda o mais depressa possível inúmeras consultas normais (selects da vida sem zilhões de inners, outers, lefts, etc etc e etc joins), jogando fora até a integridade referencial na base de dados (embora ela sempre possa ser feita do lado cliente) para conseguir isso. Mas quando começa à se "brincar" com views além da imaginação e selects de várias páginas, aí acho melhor mesmo usar postgres ou similar.
P.S: Particularmente adoro a capacidade do SQLServer de tratar uma view simples como se fosse uma tabela normal (capaz de receber inserts e updates), mas o custo de fazer um servidor usando ele é meio alto (sem contar o fato de ser obrigado à usar Windows como SO)
Se você consegue ler esta mensagem então o seu computador irá se auto-destruir em dez segundos, tenha um bom dia
Não há ganho. Imagine 26.000 consultas à tabela do Scoble determinando se ele atualizou alguma coisa. O Scoble segue 21.000 pessoas. Imagine se a cada xx segundos ele fosse dar um select no banco procurando por alterações sob o usuário de cada uma dessas 21.000 pessoas.
Buscando somente nos registros do SEU usuário fica bem mais gerenciável.
E sim, esse é o uso ideal do MySQL. No cenário que você descreveu ele é imbatível.
Bem, aí depende de como foi modelada a base de dados. Que até onde eu sei é mais "barato" para o SGBD fazer selects do que inserts. Uma possível solução seria fazer uma "tabela de história" que concentra os "posts" (sim, iria ficar absurdamente grande em termos de número de registros hehe), e aí para ver se têm novidades bastaria fazer "select from tabela_grandona where postador = meuconhecido and data_em_que_o_post_foi_feito >= data_da_ultima_vez_que_entrei_aqui" nenhum join
Mas devo dizer que não conheço os recursos do twitter, mas isso resolveria a questão dos milhares de inserts por post
Se você consegue ler esta mensagem então o seu computador irá se auto-destruir em dez segundos, tenha um bom dia
Como disse o Fabio Akita:
"Todo amador acha que pode Consertar o twitter"
E o RoR está lá só como front-end, só para exibir html bonitinho e eles usam PHP, Erlang e C também. O cara do TechCrunch gerou FUD, mesmo que fosse Java ou C(ele disse que se fosse assim e não RoR escalava) era a mesma coisa.
Uma boa explicação do problema do twitter:
http://www.25hoursaday.com/weblog/2008/05/23/SomeT...
e explicações do Akita:
http://akitaonrails.com/2008/5/23/a-est-pida-contr...