Em 20 de setembro de 2012 10:45, Guimarães Faria Corcete DUTRA, Leandro <[email protected]> escreveu: > 2012/9/18 Guimarães Faria Corcete DUTRA, Leandro <[email protected]>: >> >> Interessantemente, parece que o F1 é construído sobre o Spanner >> <http://research.google.com/archive/spanner.html>, que parece ser mais >> relacional que o SQL, requerendo que toda tabela tenha uma chave — ou >> seja, trabalha com relações de fato. > > Alguém chegou a analisar o aspecto relacional do Spanner?
Não li os blue-papers do Spanner, e também não sei se entendi corretamente o F1 (li a apresentação na íntegra agora, cansado...), mas eu diria que ficaram alguns pontos de interrogação que achei interessante discutir: - Se pretende realmente implementar o puro aspecto relacional, como é a API para fazer as consultas à "base de dados'? Isso não seria um /*caveat/* por obrigar aos programadores a aprender toda a teoria relacional, já que muitos mal compreendem a SQL? (eu por exemplo, trabalho com SQL a quase 10 anos e até hoje ainda não entendo completamente o conceito da álgebra relacional); - Ao que vi, a SQL nada mais é que uma extensão, o acesso aos dados será feito inicialmente por uma API. Como seriam tratadas as falhas da SQL - que você mesmo menciona várias vezes na lista. Talvez houvesse a preferência seria por utilizar a extensão SQL ao invés da API, dada a grande portabilidade existente hoje - e facilidade de compreensão em relação às expressões em A.R. - Há uma perda de desempenho na gravação para obter desempenho na leitura. Eu diria que com uma view materializada haveria o mesmo comportamento. Mas ainda assim o desempenho é menor que o MySQL. Parece que não houve vantagem até o momento no ponto de vista desempenho - talvez se usassem PostgreSQL... :) - Índices consistentes (Consistent Indexes). O que significa? Algo como "não é necessário reconstruí-los"? - Leituras em paralelo: excelente. Sem mais comentários a respeito disso. - "Buffer writes in client, send as one RPC": E quando houver concorrência com várias conexões, como fica a capacidade do servidor de responder a tantas requisições, digamos, grandes? - Permite o não-uso de ORM com um OM. Maravilha! Menos frameworks para se configurar, menos componentes intermediando a conversa APP<->SGBD. Mas e a API (Library), como é? Vai usar a linguagem da A.R? Ou a "notação de objetos" a exemplo do Java? Fiquei curioso... Por fim... se eu falei besteira e não entendi, me desculpe e corrige aí, ou pelo menos dá seu ponto de vista. Apesar de algumas funcionalidades apresentadas parecem ter algum sentido/vantagem, eu ainda diria que é cedo para pensar no F1 como a solução dos problemas ORM (e todas suas variações) X SGBD "Relacional" X Álgebra Relacional. Talvez sua complexidade não seja atraente. -- TIAGO J. ADAMI http://www.adamiworks.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
