- Feed completo
- Feed dos comentários
- Feed do Fórum
- Feed Canal Games
- Feed Canal Fotografia
- Feed Canal Mobile
- Receba o Meio Bit via e-mail
- Home
- Sobre
- Arquivo
- Fórum
- Games
- Mobile
- Fotografia
- Games DB
- Colabore
- Anuncie
- Radar
- Minha conta
- Contato
Fórum
Criar novo tópico no fórum Últimos tópicos no fórumÚltimas respostas no fórum
- Tales of Monkey Island - Pré-venda
- Imagem do dia: Estação Espacial Internacional vs Terra
- Obama no Big Picture
- "Clique e Pronto" - Favoritos com visual
- Finalmente saiu a versão PT-BR do SP2 do Vista.
- No Break - Dúvidas Gerais
- Dificuldade de Navegação na OI/BRT
- Equipamento novo
- Bolsa de Londres poderá trocar Windows por Linux
- A polêmica sobre Codecs de vídeo no HTML5
- Notebooks decretarão a morte dos Desktops?
- Ambiente Gráfico
Newsletter
Mantenha-se informado sobre as nossas novidades com nosso newsletter semanal, todas as segundas-feiras
Categorias
Já há algum tempo surgiu um fenômeno bem interessante : Versões gratuitas de bancos de dados client/server proprietários.
O primeiro foi o MSDE - Microsoft Database Engine - A versão gratuita do SQL Server 7.0. O MSDE, porém, não possuia interface gráfica e precisava ser manipulado ou a partir do Enterprise Manager (ferramenta que acompanha uma versão paga do SQL Server) ou a partir do Visual Studio.
O MSDE evoluiu para MSDE 2000 e na versão 2005 do SQL Server mudou por completo para SQL Server 2005 Express.
Em novembro de 2005 a Oracle, que não tinha a menor intenção de ficar para trás, lançou o Oracle Database XE na versão 10g. Com edições para Windows e Linux, o Oracle XE, assim como o SQL Server Express, é gratuito.
Já a IBM foi a última a aderir a esta nova moda, lançando o DB2 Express-C em janeiro de 2007.
Desta forma temos 3 grandes servidores de bancos de dados, proprietários, gratuitos, entre os quais podemos escolher.
Porém a primeira pergunta que todos farão é : Por que limitar a escolha a estes 3 servidores proprietários, por que não incluir os servidores livres como MySQL, PostGree PostGreSQL, entre outros ?
A escalabilidade (não apenas performance, mas suporte a grandes volumes) de soluções de bancos de dados sempre foi uma grande preocupação das empresas. Como saber se estão escolhendo a solução de banco de dados adequada ? Mudar uma solução de banco de dados definitivamente não é algo que se faça todo dia.
Para auxiliar as empresas na escolha do servidor de dados a ser utilizado foi criada uma organização chamada TPC - Transaction Processing Council - com o objetivo de analisar soluções completas de banco de dados. O trabalho basicamente é estabelecer recordes de performance/escalabilidade em uma solução de banco de dados e publicar tais recordes.
Tudo é feito de forma altamente controlada, com inúmeras regras sobre como cada experiência deve ser tratada e publicada. Se isso já não fosse suficiente para que os resultados tenham confiabilidade, então basta observar a página de membros do TPC : Com empresas concorrentes como IBM, Oracle e Microsoft fazendo parte do TPC, isso garante a confiabilidade dos resultados, já que cada concorrente acabará fiscalizando o resultado do trabalho dos demais. Neste ponto um a parte para o fato de que o Cin/UFPE é um membro associado do TPC, mostrando mais uma vez o pioneirismo Pernambucano.
Tudo bem, mas e dai ? Onde o TPC entra nesta história ?
Se analisarmos os top 10 bancos de dados em relação a performance, veremos que Oracle, SQL Server e DB2 ocupam toda a lista, com diferentes edições e variações de hardware e plataforma de aplicações (observando que essa lista muda com freqência).
Se analisarmos a lista dos top 10 pela relação preço/performance veremos que apenas o DB2 não aparece, a lista fica dividida entre Oracle e SQL Server.
Então, voltando a pergunta, por que limitar a escolha a estes três servidores de banco ?
Resposta simples : Porque, tendo opções gratuitas, são os 3 servidores de banco que melhor oferecem suporte ao crescimento da aplicação. Isso fica definitivamente demonstrado pelos índices TPC. Migrar a aplicação para uma edição do servidor com maior recurso será uma tarefa simples quando a aplicação crescer.
Antes que comecem a pensar em algum tipo de teoria da conspiração contra outros servidores de bancos de dados, é bom lembrar que além de várias notórias apoiadoras do software livre participarem do TPC, alguns dos principais resultados que vocês puderam observar nas imagens acima foram obtidos em sistema operacional Linux.
Existem, porém, dois motivos que poderiam levar a uma escolha de outros servidores de dados (mySQL, PostGree PostGreSQL, entre outros) que não os acima :
- Grande impacto do conhecimento existente na equipe em relação ao TCO (Total Cost of Ownership) da solução
- Sua empresa é uma empresa de desenvolvimento de software, desenvolvem soluções complexas e desejam a liberdade de alterar o código fonte do servidor de banco, assim como o google fez, mas fez para uso interno, não para a ferramenta de busca (http://br-linux.org/linux/google-disponibiliza-suas-melhorias-internas-do-mysql)
Caso em sua análise você não recaia em nenhum dos dois casos acima, não vejo porque não se limitar aos 3 servidores de dados gratuitos - SQL Server, Oracle ou DB2 - na hora de escolher um servidor de dados. Isso porque escolhendo um dos 3, estaremos evitando criar uma limitação ao crescimento das aplicações. É claro que é quase impossível prever qual limitação será essa e se realmente virá a existir um dia ou se o banco escolhido vai dar conta do recado, mas os índices TPC mostram claramente os 3 melhores servidores do mercado e todos os três possuem edições gratuitas.
Então, tendo decidido por escolher entre um dos 3, leve em conta os seguintes pontos para decidir qual escolher :
- Recursos disponíveis na versão gratuita x espectativa de crescimento da aplicação. Todos os 3 são limitados em suas versões gratuitas e essa limitação determinará quando você irá precisar migrar para uma edição paga.
- Custo da versão paga para a qual será necessário fazer a migração
- Conhecimento da equipe de desenvolvimento
- Produtividade da ferramenta (tanto para desenvolvimento como para administração)
Vamos então fazer uma tabela comparativa destes 3 servidores de dados :
|
SQL Server |
DB 2 |
Oracle |
|
|
Infra-estrutura |
|||
| Memória | 1GB | 2GB | 1GB |
| Processadores | 1 | 1 (dual core) | 1 |
| Tamanho do Banco | 4 GB (por banco) | Ilimitado | 4GB (soma total) |
| Sistemas Operacionais | Windows | Linux/Windows | Linux/Windows |
|
Recursos do Servidor |
|||
| Busca Textual | Sim | Não | Sim |
| Ferramenta de Relatórios | Sim | Não | Não |
| Replicação | Sim | Não | Sim |
Por fim, só para dar mais um motivo para brigarem comigo nos comentários : Sem dúvida este é mais um exemplo de como o pioneirismo comercial da Microsoft forçou os concorrentes a aderirem a este recurso, possibilitando que pequenas aplicações dispensem a compra de grandes servidores e ainda assim não sofram horrores se algum dia precisarem ser migradas para um servidor maior.
Para finalizar, seguem abaixo links com informações sobre os 3 servidores :
DB2 Express-C
http://www-306.ibm.com/software/data/db2/express/about.htmlOracle XE
http://www.oracle.com/technology/products/database/xe/index.htmlSQL Server Express
http://msdn2.microsoft.com/pt-br/express/aa718378.aspx
Obs : Esta matéria foi inspirada em informações publicadas nos comentários da matéria "Coisas que quase ninguém sabe sobre a Microsoft". Assim como este artigo, outros ainda serão produzidos, os 272 comentários foram muito produtivos. Me adiantando a pergunta : Não, isso não é matéria patrocinada.
- Feed comentarios deste post
- Blog do Dennes
- entre com seu usuário e senha ou registre-se no site para enviar comentários
Entrar
Mais comentados
- Promoção: de U$$679 por U$$1818 (97)
- Livro: "Linux - Guia Prático" (89)
- A Casa Caiu pros Piratas (85)
- Windows XP resiste bravamente (78)
- Stallman alerta contra os perigos do C# no Debian (77)
- O Ano do Bing vem aí? (70)
- Um Windows que até Linuxeiro queria botar a mão (68)
- Evite meter o dedo na tomada, por favor! (68)
Caracas... esse tópico tomou dois quilômetros da primeira página do MeioBit. Poxa, coloquem o post quebrado da próxima vez...
Grato.
Sinto cheiro de sangue neste post.
Anyway Dennes, boa matéria, uso o MSDE há alguns anos e não sabia dessas informações. Vou explorar estes links aí antes de fazer alguma pergunta.
Obrigado...
-----------
Esta é minha assinatura :)
"Porém a primeira pergunta que todos farão é : Por que limitar a escolha a estes 3 servidores proprietários, por que não incluir os servidores livres como MySQL, Postgree, entre outros?"
São 2 perguntas. Ou 2 versões da mesma. Que não foram respondidas satisfatoriamente. E PostgreSQL tá escrito errado.
É quase um consenso entre o pessoal que trabalha com servidores de bancos de dados (eu não sou um :( ) que o o MySQL é imbatível em velocidade (embora sofra em muitas outras coisas) e de que o Microsoft SQL Server é ruim a beça.
Imbatível pra velocidade em que tamanho de base?
Benchmarks podem ser muitos tendenciosos nessa área, o Oracle mesmo é famoso por ser robusto e aguentar o tranco em aplicações com muita concorrência e com bases muito grandes.
Outra a coisa a se pensar é em como foi criada a base. O MySQL ate a versão 4. alguma coisa não tinha integridade referencial, não tinha suporte a subselect, não tinha suporte a funções e etc.
Dessa maneira é muito fácil ser rápido :)
Não tenho nada contra o MySQL, mas o melhor banco de dados Open Source é o PostGreeSQL. O motivo do mysql ser mais usado acho que é facilidade.
O grande motivo do MySQL ser mais usado que o PostgreSQL é o fato de o MySQL ter uma versão nativa pra Windows há muito tempo, coisa que o PostgreSQL só tem há uns 2 anos. Antes tinha que instalar o cygwin e instalar o PostgreSQL dentro dele, um procedimento um tanto que trabalhoso e, muitas vezes, não possível de ser realizado em servidores de produção.
Seja livre, use software livre.
Opa, disso eu não sabia. Mas tinha ouvido falar que a versão windows possuia um desempenho inferior a versão linux.
[]'s
Eu frequento listas de postgres a muito tempo.
Foi incrível quando começaram a lançar instaladores do PG para Windows. O nível da lista ficou abaixo de um ralo. Toda hora aparecendo algum ser "como instalo no XP, no NT ?". Depois ainda dizem que se tem preconceito com os nobres usuários Winodws :).
Sobre o desempenho...
Por ordem de desempenho: FreeBSD, Linux e Windows.
No Linux e nos xBSD ainda pode se jogar com o desempenho se você instalar um ou outro sistema de arquivos que são mais ou menos eficientes.
Oi, Bigode !
Obrigado pelo aviso sobre o PostGreSQL, vou corrigir.
Desconfie de todo tipo de consenso, em especial na área de informática, onde tudo muda muito rapidamente.
O MySQL pode aparentar ser "imbatível em velocidade" porque muitas instalações padrões do MySQL são feitas com o sistema transacional desativado. Não precisando fazer locks durante as pesquisas, ele fica muito rápido, mas sem integridade transacional. Se adicionar nele um sistema transacional (existem alguns) a performance cairá.
O mesmo efeito em relação ao sistema transacional pode-se obter de diferentes formas com os demais servidores de banco, ocorre que como servidores de banco o sistema transacional é uma funcionalidade padrão.
Porém o MySQL nem merecia ser citado no artigo, já que para criação de aplicações comerciais trata-se de um banco pago.
Quanto ao "SQL Server é ruim a beça" - basta ver os gráficos do índice TPC. Digo ainda que escrevi o artigo em uma má época : SQL Server briga de igual para igual com Oracle e DB 2 e já esteve por várias vezes no topo do índice TPC.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Bem, é exatamente por isso que ele é imbatível em velocidade, por causa da integridade referencial :P
Bem, o MySQL é tão pago quanto o Microsoft SQL Server Gratuito, ou mais. Ele é distribuído por gpl, tu paga se tu quiser suporte.
Dennes, esse índice tpc só testa 4 bancos, os que tu citou e mais um da sybase, sendo que alguns tem várias versões e revisões. Até que eu saiba todos são proprietários. Então ele não ajuda em nada a responder a(s) pergunta :P.
O que eu escutei do Microsoft SQL Server (talvez seja uma versão mais antiga) era que ele travava a tabela inteira quando tu modificava um registro, enquanto o oracle e postgresql só travavam o registro em si. E que era difícil pra trabalhar com ele por causa disso. Bem, talvez ele melhorou, o IIS também a um tempo atrás era um pepino.
Ironman_BR - chiu, o maior banco de dados do mundo roda em myqsl, provavelmente numa versão cheia de gambiarra pra ficar mais rápido ainda. Mas realmente o postgresql, oracle e companhia são bem mais confiáveis.
Oi, Bigode !
"Bem, o MySQL é tão pago quanto o Microsoft SQL Server Gratuito, ou mais. Ele é distribuído por gpl, tu paga se tu quiser suporte."
Esta enganado a respeito disso.
O MySQL apenas é gratuito se ao distribuir seu sistema você fizer a distribuição do fonte do seu sistema junto. Neste caso pode utiliza-lo gratuitamente.
Porém se desejar utilizar o MySQL para criar sistemas comerciais, com código fechado, você precisa pagar por ele, dentro de seus planos de compra. Isso porque o driver de acesso ao MySQL está sob licença GPL - propositalmente - e será compilado e incorporado em sua aplicação. Portanto sua aplicação inteira passa a ter que estar sob licença GPL ou adquirir a versão paga do MySQL.
Essa questão é claramente explicada aqui : http://www.mysql.com/company/legal/licensing/faq.html
"Dennes, esse índice tpc só testa 4 bancos, os que tu citou e mais um da sybase, sendo que alguns tem várias versões e revisões. Até que eu saiba todos são proprietários. Então ele não ajuda em nada a responder a(s) pergunta"
A ausência é, de fato, uma resposta. Você não vê na documentação do TPC nenhum lugar em que ele determine que apenas faz testes de bancos proprietários ou que fica limitado a esses bancos, pelo contrário, você vê o TPC aberto a qualquer um que deseje fazer os testes.
"O que eu escutei do Microsoft SQL Server (talvez seja uma versão mais antiga) era que ele travava a tabela inteira quando tu modificava um registro"
Boatos se espalham indevidamente.
1) Isso aconteceu antes de eu ser maior de idade.
2) Não tem nada a ver com recursos do SQL Server, mas com má programação e aceitação de configurações default.
Você não deve confiar em boatos na área tecnologica.
"o IIS também a um tempo atrás era um pepino"
Um tempo atrás ? O IIS versão 6 foi lançado em 2003 (portanto quase 5 anos atrás) e o número de boletins de segurança criticos não ocupa nem metade dos dedos de uma mão.
"o maior banco de dados do mundo roda em myqsl"
De onde você concluiu isso ? A questão sobre o google ?
Aqui você gerou um boato perigoso. As documentações sobre a relação do google com mySQL são muito claras ao afirmar que o google não usa mySQL para seu banco de busca na web, usa para outros recursos internos, indefinidos, os quais nunca saberemos quais são.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Tem um parametro no MSSQL que determina que se "n" porcento da tabela for requisitada para alteraçao ele fará lock por tabela e não por pagina, ainda assim havia o SELECT...NOLOCK para nao travar e depois mais tarde com a implementacao do lock por linha (antes era só pagina ou tabela) facilitou a vida dos usuarios-acho que isso se deu no MSSQL2000. Hoje o lock por tabela só se dá se for com um comando explicito.
O MSSQL era muito ruim apesar de ferramentas graficas boas, me lembro que corrompia direto tabelas que usassem campo identity onde tive que substitui-los por int e calcular, tambem tinha um database temp que se corrompesse simplesmente voce nao rodava mais o banco e coisas desse naipe, apesar disso ele evoluiu muito, arrancou fora conceitos de administração unix (uso de devices) e tunnings que nao faziam muito sentido. Mas na minha opniao outros BDs Livres são melhores dependendo da aplicação e do perfil da empresa.
O MySQL para mim é só para tratar de aplicações LAMP/GPL onde cai como uma luva no quesito simplicidade, porque no quesito velocidade é apenas uma lenda, o PG e o Firebird são muito mais rápido sob o mesmo hardware, fiz esse um tempo atras com o MySQL4 e a menos que muita coisa tenha ocorrido no MySQL5 ainda é a mesma coisa.
Oi, Hamacker !
"Tem um parametro no MSSQL que determina que se "n" porcento da tabela for requisitada para alteraçao ele fará lock por tabela e não por pagina,"
O que é "requisitada para alteração" para você ?
Muita gente confunde isso com a exibição de dados para o usuário e permitir que o usuário navegue nos dados, quando na verdade não é nada disso.
A requisição para alteração acontece em procedimentos dentro do servidor, quer seja uma transação programada na forma de stored procedure ou uma instrução única de update, por exemplo. De qualquer forma, estamos falando de algo que será executado sem intervenção do usuário, conte essa execução em milisegundos.
"ainda assim havia o SELECT...NOLOCK para nao travar"
A única coisa útil na realização do Select com Nolock é o aumento na performance de execução do Select pelo fato de não ser necessário que a base de dados registre em suas tabelas de sistema a existência dos locks. Performance, quando integridade não for fundamental.
"tambem tinha um database temp que se corrompesse simplesmente voce nao rodava mais o banco"
O tempDB sempre foi utilizado para dar suporte a aplicações client/server com cursores no servidor, um legado que hoje evitamos utilizar.
Quando o serviço do SQL Server é reiniciado, o tempDB é deletado e re-criado e isso ocorre mesmo em versões antigas. Aplicações client/server sim, podem ter problemas dependendo de volume, como foram construidas, etc...
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Tente trabalhar com um banco de 5gb em MySQL e depois venha dizer que ele é rápido, o MySQL é perfeito com BD para internet, para aplicações mais robustas ele não serve.
__________________________________________________
" Não se trata do quão forte você bate, mas sim do quão forte você possa suportar os golpes e seguir em frente..." (Rocky Balboa)
Postgree (sic e sci)????
Não conheço esse SGBD (DBMS).
Não entendi essa (ou é mais uma informação tendenciosa)... Se eu entendi, o texto diz (ou insinua) que as bases de dados de código aberto "não aguentariam o tranco de grandes aplicações", e que por isso seria melhor usar as versões "gratuitas" dos SGBDs proprietários. Então como vão explicar o fato de que para todas as aplicações "sérias" do governo do Paraná para o qual trabalho são baseadas no PostgreSQL? E ele funciona muito bem diga-se de passagem, nunca ouvi do pessoal do data warehouse nenhum comentário que teriam que trocar para um SQL Server ou similar "porquê a base estaria ficando grande/complexa demais". E o MySQL - usando-se o MyISAM (Transações só com o InnoDB) - é rápido mesmo, tanho que costuma ser a opção preferida para uso em sites e qualquer aplicação onde ser rápido é mais importante do que garantir integridade referencial À nível de base de dados (embora eu seja da opinião de que o InnoDB é rápído também).
Em resumo, isso está me cheirando à conversa para boi dormir...
Concordo, trabalho em uma universidade publica e aqui armazenamos grandes quantidades de dados (grandes mesmo) em MySQL e nunca, NUNCA tivemos problemas de performace ou que fosse necessária a uma mudança pra DB propretário que aliás, não teria nem justificativa para uma mudança destas ;-)
TecnoEvidência
Oi, DarkMaster !
Você deixou escapar dois trechos do texto :
"Migrar a aplicação para uma edição do servidor com maior recurso será uma tarefa simples quando a aplicação crescer."
e
"É claro que é quase impossível prever qual limitação será essa e se realmente virá a existir um dia ou se o banco escolhido vai dar conta do recado, mas os índices TPC mostram claramente os 3 melhores servidores do mercado e todos os três possuem edições gratuitas."
Portanto as aplicações que você citou cairam definitivamente no 2o caso que mencionei. O problema será se um dia crescerem mais do que os bancos que elas utilizam hoje suportam...
Quanto ao uso de dataWarehouse com bancos livres, poderia me fornecer mais informações ? Os servidores que citei possuem ferramentas específicas para trabalhar com warehouse, permitindo a partir do warehouse a criação de cubos, execução de algorítimos de data mining e extração de dados com linguagens específicas para cubos. Existe algo semelhante nos bancos livres (é só curiosidade mesmo, sério) ?
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Como eles fazem os clusters eu não sei dizer, sei apenas que é possível. Como analista de sistemas eu só me envolvo na questão de usar os dados do data warehouse, para responder esta questão eu terei que procurar o nosso DBA.
Oi, DarkMaster !
Não quis dizer cluster, mas sim cubos.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
A partir da versão 8.x o PostgreSQL passou a oferecer suporte a Warehouse e "cubos". Até a versão 7.X não havia esse suporte nativo, mas já existiam módulos.
Uma dúvida ficou no ar, Dennes: fui olhar as tabelas completas no TPC e não encontrei nenhum case com bancos de dados livres. Foi ilusão minha ou os testes não os incluíram mesmo?
Seria interessante comparar as últimas versões de todos os BDs comerciais e livres. Daí podíamos tirar algumas conclusões mais substanciais, como melhor intuir o quanto uma solução compensa sobre a outra considerando várias variáveis, como performance, funções avançadas e custos.
Jaime Balbino
Learning Designer e Consultor em automação do ensino
http://www.dicas-l.com.br/educacao_tecnologia
http://mobeduc.blogspot.com
Oi, Jaim !
Curiosidade : Por que os cubos entre aspas ?
Não, você está certo, realmente não tem nenhum teste com bancos livres.
A questão é que estes testes não são simples de fazer, bem além de meros mortais como nós. Mas uma empresa como a MySQL ou outras diversas poderia fazer sem dificuldade.
A pergunta que ronda diversos comentários aqui é : Por que não fez, se o próprio TPC informa ser aberto a qualquer um (e se não fosse já estava sendo denunciado para tudo quanto é lado) ?
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Acredito que o problema seja o custo de se montar um sistema destes.
Enquanto a Oracle, IBM, Microsoft, RedHat e Novell possuem interesse, e dinheiro, em demonstrar seus produtos em cenários abusivos, projetos como o PostgreSQL ou o MySQL não tem o fôlego financeiro necessário para esse tipo de demonstração de força.
[],
AC
Oi, Ac !
O que eu acho muito estranho...
MySQL é uma empresa, deveria ter condições disso.
De qualquer forma, qualquer banco livre que ajudasse a levar o Red Hat ou o suse para o topo da lista teria o apoio das respectivas empresas...
[]'s
---------------------
CidadaoCarioca
BufaloInfo
RedHat - Sistema Operacional
MySQL -- Banco de dados
????? -- Hardware
Faltaria o cara do Hardware. Acredito, que empresas como HP e IBM ficam temerosas quanto o desempenho desses bancos de dados livres. A mesma história de sempre: se está funcionando não mexa.
Até a Itautec, que mais "humilde" do que as citadas, preferiu desembolsar um dinheiro para um banco de dados proprietário, no sistema que eles publicaram.
O risco de bancar um teste deste é muito alto e não apresenta, em princípio, uma vantagem econômica/competitiva significativa.
Uma máquina dessas, TOP 10, é usada para rodar um SAP da vida. Como não há confiança nos bancos livres, não vai vender.
Uma empresa que compra uma máquina por US$4.000.000 para rodar um aplicativo que custou US$1.000.000, não vai sentir diferença, no bolso, ao pagar mais US$50.000 para um banco de dados de grife.
Acredito nessas razões para não vermos um MySQL, PostgreSQL ou Firebird no TPC.
[],
AC
Quanto ao TPC ser "aberto", segundo este link aqui, na própria página deles, http://www.tpc.org/information/about/join.asp , custa USD15MIL ANUAIS para ser membro efetivo. Não fica claro, porém, se vc precisa ser membro do TPC para submeter um benchmark. Mesmo entidades sem fins lucrativos devem pagar USD1500,00 ANUAIS para se tornarem membros associados (q não têm uma série de direitos).
Se vc tiver de ser membro full, de cara temos o porquê de um PostgreSQL da vida não entrar na jogada, bem como uma das possíveis justificativas da MySQL AB tbém não entrar nessa. Afinal, a MySQL AB não é exatamente essa "potência" comercial.
A última vez q eu olhei a sério os TPC foi em 2001, para a seleção de uma engine de BD. À época, o MS SQL Server estava batendo o Oracle (não lembro as respectivas versões), mas o setup do ambiente era um pouco "heterodoxo". O pessoal de banco conversou com o pessoal da MS e da Oracle e, embora a última admitisse o resultado, afirmava q a configuração do ambiente era, digamos, pouco usual em ambientes de produção.
No final das contas, o q eu lembro das DBMS Magazine e DataMagazine da vida lá da década de 90, mais esse caso q citei acima, e mais algumas conversas da minha (breve) época de DBA, é q as empresas faziam todo um tunning voltado para cada teste específico. Daí todo o investimento em hardware, além do software. Felizmente, amenizado pela métrica de transação/$.
Em suma, não vejo projetos de bancos de dados livres investindo para gerar este tipo de resultado pq seu público-alvo é diferente daquele dos "4 majors". E, só para constar, para apps web vc *não* precisa de uma licença proprietária do MySQL. Ele prevê uma série de *exceções* à GPL em sua (confusa) licença de uso. Inclusive, isso foi causa de gde "gritaria" do pessoal do PHP contra o MySQL.
Por outro lado, **todos** os bancos proprietários e gratuitos são de livre redistribuição junto com uma aplicação de terceiros? Ou o cliente é obrigado a instalar e manter um por conta própria?
Em suma, está me cheirando à um benchmark similar ao que o 3DMark faz com as placas de vídeo... Onde diabos acham que vou acreditar nos benchmarks de um programa patrocinado pela nVidia, uma das principais interessadas em ter boa pontuação no mesmo? Só pode ser piada. E esse caso dos SGDBs está parecendo a mesma coisa
DarkMaster,
Eu nem questiono a validade dos benchmarks TPC, eu questiono sua relevância no contexto de uma compra séria. Por explo, é relevante saber q o banco de dados mais "performático" para testes TPC-H 100GB roda sobre Red Hat Linux e é 400% mais *barato* q a solução Microsoft, se meu ambiente for somente Solaris?
Ou ainda, saber que os 6 *melhores* resultados para TPC-H 300GB rodam sobre Red Hat Linux (e continuam até 400% mais baratos q a solução Microsoft melhor classificada) se meu ambiente é mainframe com Adabas?
Saber, então, que nos TPC-H 1000GB o melhor classificado roda sobre Red Hat Linux, sendo 614% mais *barato* q a solução Microsoft q vem em segundo lugar, jamais teria qqr relevância se eu tivesse apenas MS MCEs trabalhando em meu CPD/IT Center/etc.
Enfim, por melhor q sejam os benchmarks, eles refletem uma situação simulada. Os benchmarks indicam apenas q determinado produto é realmente bom para *aquele* benchmark específico.
Quer comprar? Tem de correr atrás para saber qual a carga de seu ambiente (e fazer um planejamento de capacidade), qual a plataforma aceita na empresa, qual o custo de suporte in-house e outsourced, qual o ciclo de vida das versões do produto, qual o tempo médio entre a liberação de patches, etc e tal.
Se alguém aqui compra um produto olhado *só* testes TPC, ou se monta um benchmark TPC interno ao invés de montar um business case relevante para os processos de negócio da própria empresa, então tem muito dinheiro sendo jogado fora por aí...
[ ]s
"[...]é relevante saber q o banco de dados mais "performático" para testes TPC-H 100GB roda sobre Red Hat Linux e é 400% mais *barato* q a solução Microsoft, se meu ambiente for somente Solaris?"
Muito relevante. Agora você tem informações para pensar em uma reforma do seu ambiente atual.
"[...]saber que os 6 *melhores* resultados para TPC-H 300GB rodam sobre Red Hat Linux (e continuam até 400% mais baratos q a solução Microsoft melhor classificada) se meu ambiente é mainframe com Adabas?"
Se você estiver querendo um substituto para o Adabas e seu Mainframe, sim.
"Enfim, por melhor q sejam os benchmarks, eles refletem uma situação simulada. Os benchmarks indicam apenas q determinado produto é realmente bom para *aquele* benchmark específico."
Esse é o principal benefício e relevância de benchmarks como o TCP. Ele te dá um sistema métrico e alguns exemplos de medidas para avaliar o *seu* sistema.
No teste do TCP, a quantidade de registros no banco de dados é a mesma para todos os sistemas testados. A estrutura das tabelas possuem um conjunto de características em comum: índices, chaves, integridade referencial essas coisas.
Você pode rodar o TPC-C em seu sistema e comparar os resultados com os que foram obtidos e publicados, usando eles como referência de performance.
[],
AC
Oi, Olival !
Neste link : http://www.tpc.org/information/about/faq-generic.asp você observa que não é necessário ser membro do TPC para executar os benchmarks.
"as empresas faziam todo um tunning voltado para cada teste específico"
Com certeza, mas os testes em questão são padronizados pelo TPC e se estiverem fora do padrão são rejeitados, conforme menciona a própria FAQ que indiquei ali acima.
"Ele prevê uma série de *exceções* à GPL em sua (confusa) licença de uso. Inclusive, isso foi causa de gde "gritaria" do pessoal do PHP contra o MySQL."
Todas as excessões previstas na licença do MySQL tem por objetivo permitir que o desenvolvedor licencie softwares sob outras licenças de software livre que, de outra forma, não seriam compatíveis com a GPL do MySQL.
A MySQL determina quais são as licenças que o desenvolvedor pode utilizar caso deseje utilizar o MySQL gratuitamente.
Você encontra isso na FAQ : http://www.mysql.com/company/legal/licensing/faq.html
"Por outro lado, **todos** os bancos proprietários e gratuitos são de livre redistribuição junto com uma aplicação de terceiros? Ou o cliente é obrigado a instalar e manter um por conta própria?"
Os 3 bancos proprietários gratuitos podem ser usados comercialmente. Durante a implantação de uma aplicação no cliente o servidor de dados é implantado em conjunto. Mas é claro que, como todo servidor de dados, é necessária manutenção.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Oi, Dennes
Separei por partes a resposta.
---------------------------
"Neste link : http://www.tpc.org/information/about/faq-generic.asp você observa que não é necessário ser membro do TPC para executar os benchmarks."
Pois é. Eu só achei essa parte do site depois de dar um Google no assunto. Vc notou q não há nenhum link para o Generic FAQ a partir da home page?
Enfim, de fato, vc não precisa ser membro, mas isso *não* significa q rodar um teste TPC seja "trivial". Vamos aos requisitos:
(a) Obter a última documentação do TPC a partir do "TPC Administrator's office":: Não me parece q seja só um "download das specs" de um site do TPC.
(b) Se familiarizar com todas as regras e políticas sobre como submeter um benchmark TPC. Por explo, q *todos* os benchmarks TPC *devem* ser aprovados por um Auditor TPC:: Será q alguém faz isso de graça ou esse é um daqueles profissionais q cobram taxas de 3 ou 4 dígitos por 1 hora de trabalho?
(c) Aprender a escrever um relatório de "full disclosure" apropriado e submetê-lo ao TPC antes de poder usar o resultado do bechmark publicamente:: E como exatamente a empresa adquire esses skills em redação de relatórios TPC? Será q isso exige investimento da empresa - tempo, dinheiro, pessoal, etc ? Nos próximos itens me parece q isso fica mais claro. ;-)
(d) Entrar em contato com um Auditor TPC para agendar a auditoria do seu benchmark:: Tendo em vista q os "majors" estão sempre rodando algum benchmark, qual será a disponibilidade desses auditores?
(e) Como conselho (não necessariamente obrigação), o TPC aconselha q vc contrate um consultor familiarizado com os testes deles. A lista dos tais consultores pode ser obtida diretamente com o "TPC Administrator's office":: Bom, pra mim fica claro onde entra uma custo direto no processo (ou investimento se vc for uma "major"). Me surpreenderia se esses consultores não fossem (ou tivessem sido) auditores TPC tbém.
Em suma, me parece q continua sendo algo q *certamente* não é pro bico do PostgreSQL ou para o qual uma empresa *relativamente* pequena como a MySQL teria grana pra investir.
Além disso, se a intenção for fazer publicidade do resultado, é preciso testar "em casa" primeiro. Afinal, ao submeter um benchmark ao TPC vc deve concordar com o "full disclosure". As "majors" têm grana para testar "in house" antes de submeter. Duvido q os bancos "livres" (mesmo os comerciais) tenham recursos para tanto.
---------------------------
"Com certeza, mas os testes em questão são padronizados pelo TPC e se estiverem fora do padrão são rejeitados, conforme menciona a própria FAQ que indiquei ali acima."
De fato, mas isso *não* impede o tunning específico. Contanto q sigam as especificações do TPC, as configurações do ambiente de teste podiam abarcar coisas cuja administração em um ambiente de produção real seriam bem mais complexas.
Por explo, no teste de 2001 q eu citei antes, onde o MS SQL Server bateu o Oracle, lembro q a configuração do SQL Server envolvia um setup q privilegiava a velocidade em dentrimento da confiabilidade. É um arranjo válido, mas acredito q **em ambientes de produção típicos**, onde dados íntegros são bem mais críticos, não seria uma configuração fácil de encontrar (de fato, a MS local não nos apontou ninguém q a utilizasse para podermos bater um papo).
---------------------------
"Todas as excessões previstas na licença do MySQL tem por objetivo permitir que o desenvolvedor licencie softwares sob outras licenças de software livre que, de outra forma, não seriam compatíveis com a GPL do MySQL."
Sim, mas meu pto é q estas exceções cobrem o uso do MySQL "GPL" em ambientes web. Obviamente, não é o caso de seu uso "embedded", o qual exige de fato uma licença proprietária.
---------------------------
Agora, acho importante frisar q os testes TPC já deixaram de ser referência para a aquisição de um produto destes **há muiiito tempo**, pois:
(1) Performance é apenas 1 critério e é bastante relativo. Como diz um dos FAQs TPC, "não há uma resposta fácil" para saber se um teste TPC é relevante para o seu ambiente (http://www.tpc.org/tpcc/faq.asp). Engines fantásticas rodam como lesmas em bancos pouco otimizados. E uma query estilo "produto cartesiano" detona qqr um... :-)
(2) Os testes TPC trazem uma relação preço/performance "crua", mas não entram em meandros de contratos de suporte, disponibilidade de profissionais qualificados no seu ambiente, etc. De nada vale o MS SQL Server bater o Oracle se no meu ambiente eu tenho só DBAs Oracle com mais de 10 anos de experiência ou meu ambiente servidor *não* for Microsoft. Qtos bancos de dados Adabas/Natural o Serpro ainda roda em seus mainframes? ;-)
(3) O custo de descarte da tecnologia tbém é bastante importante em determinados ambientes. Neste pto, mesmo os bancos livres tem vantagens limitadas, pois não há uma solução realmente universal e cada um traz particularidades q acabam por se traduzir em algum grau de lock-in (o q eu desenvolvo para MySQL eu *não* levo direto para o PostgreSQL, por explo). Mas, o caso dos bancos proprietários pode ser mais grave conforme seus requisitos de ambiente. Neste caso, o calcanhar de Aquiles do MS SQL Server é justamente só rodar sobre MS Windows e exigir (ou, ao menos, recomendar) uma série de outros componentes da stack MS para poder tirar proveito de suas funcionalidades.
Enfim, testes TPC são interessantes, mas duvido q hoje em dia sejam tão relevantes para decisões de compra. No máximo, servem de parâmetro inicial. E quem usa bancos de dados livres costuma ter vários motivos para isso (ou está satisfeito com sua configuração). Não creio q sejam o público-alvo de testes TPC.
[ ]s
Oi, Olival !
A faq é acessível pela home->about TPC->What is TPC->FAQ
A MySQL não é uma empresa tão pequenininha assim... estamos falando de uma empresa que produz uma base de dados comercial : http://www.mysql.com/company/investors.html
Quanto ao tunning, ok, isso pode gerar uma diferença de 2, 3 posições no ranking ?
"Sim, mas meu pto é q estas exceções cobrem o uso do MySQL "GPL" em ambientes web. Obviamente, não é o caso de seu uso "embedded", o qual exige de fato uma licença proprietária."
Tem certeza ? Não tenho link, nem tenho mais o e-mail, mas lembro de ter feito uma troca de e-mails com uma funcionaria da mySQL em que ela falou algo como ser necessário o provedor comprar uma licença para cada site que usasse o mySQL. Sim, também achei absurdo. Só consultando novamente para obter alguma informação.
Quanto aos itens :
1) É claro que as características da sua aplicação específica vão influenciar completamente o resultado final. Se sua aplicação for mal escrita, não tem jeito. Mas adquirir um banco de dados que dê suporte para sua necessidade de escalabilidade é um bom começo.
2) É fato que a relação custo/performance do TPC é apenas um indicador. Em momento algum disse "Vá ao TPC e escolha o que estiver no topo". Essa relação custo/performance é apenas um leve começo para um cálculo de TCO.
3) Estou na dúvida se entendi este trecho... isso porque um dos pontos de destaque do artigo é justamente iniciar um novo sistema em uma versão gratuita de um banco proprietário para que quando o crescimento da aplicação acontecer não haja a necessidade de uma drástica migração de ambiente. Quanto a Linux/Windows, é uma das escolhas a ser feita no momento de decidir entre essas 3 opções...
Infelizmente não estão sendo relevantes porque são muito pouco conhecidos, como observa-se pela quantidade de comentários que esse post atraiu...
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Oi, Dennes
"A faq é acessível pela home->about TPC->What is TPC->FAQ"
Como eu disse, tem de entrar em 3 níveis para achar... O Google foi mais rápido. :)
"A MySQL não é uma empresa tão pequenininha assim... estamos falando de uma empresa que produz uma base de dados comercial : http://www.mysql.com/company/investors.html"
A MySQL *não* tem capital aberto, portanto suas informações financeiras não estão à disposição em um SEC da vida. Mas, em http://www.intel.com/capital/news/releases/060213.htm tem um press release q diz q ela recebeu até então (fev/2006) **USD39milhões** em capital de risco. A receita da empresa foi de **apenas USD5milhões em 2002** (http://www.builderau.com.au/architect/database/soa/Will-MySQL-become-the-next-Linux-/0,339024547,320276852,00.htm), quando ela tinha recebido uns USD19milhões em capital de risco. Convenhamos, isso é "micro-empresa" perto dos concorrentes citados no artigo. Infelizmente, não encontrei dados recentes sobre a receita deles, mas, mesmo q tivesse, não temos dados para saber se eles operam no vermelho ou se já estão dando lucro. Além disso, o número de empregados da empresa parece ser relativamente pequeno (coisa de menos de 200 pessoas), mas não tenho um link para essa info.
Enfim, produzir uma "base de dados comercial" não significa q ela venda horrores e tenha um lucro magistral. Vale lembrar q ainda tem muita gente usando a versão GPL por aí. Sem contar os q usam a engine mais antiga (q vêm com as distros comerciais), ainda livre de algumas restrições posteriores de licenciamento.
"Quanto ao tunning, ok, isso pode gerar uma diferença de 2, 3 posições no ranking ?"
Depende. O "tunning" aqui envolve até mesmo a escolha do servidor onde o benchmark irá rodar. Pra mim não adianta nada saber q o Oracle rodando sobre um HP Superdome com 64 cpus e 128 núcleos é super rápido. Assim, a diferença pode ser beeem maior q simplesmente 2 a 3 posições.
Em todo caso, no final das contas, o q eu aprendi com testes TPC e com a convivência com diversas engines é q os "majors" já estão cabeça-a-cabeça faz tempo. Testes TPC já não servem para distinguir um do outro em ambientes "convencionais". A menos q vc realmente tenha um Superdome de 128 núcleos no seu Data Center. :)
"Tem certeza ? (...) uma troca de e-mails com uma funcionaria da mySQL em que ela falou algo como ser necessário o provedor comprar uma licença para cada site que usasse o mySQL."
Tenho certeza q não é preciso. Em primeiro lugar, há uma certa confusão pq a MySQL até 2001 liberava as bibliotecas clientes em LGPL, permitindo q vc fizesse até mesmo software proprietário q conectasse em um banco MySQL GPL e redistribuisse tudo junto em uma mesma mídia numa boa (contanto q o banco não estivesse "embutido" em sua app). Então eles mudaram o licenciamento dos clientes para GPL, barrando esse tipo de uso e gerando uma confusão danada.
Para apps web, o seu site *não* representa uma "redistribuição" do software. Vc *não* está oferecendo *o* software, vc está oferecendo um *serviço*. É isso q permite ao Google usar kernels Linux altamente customizados em seus clusters e não ter de entregar esse código pra ninguém.
Talvez eles tenham passado essa informação tbém pq os drivers deles são GPL, mas, até aí, vc sempre pode usar um driver para o MySQL q venha de outro fornecedor (não tem um no próprio MS .Net?). No fundo, acho q a MySQL AB força a barra na questão dos sites para vender mais licenças proprietárias e serviços de suporte (um pacote só), q é a principal fonte de receita deles.
"3) Estou na dúvida se entendi este trecho..."
Apenas comentei q o custo de descarte é importante. A questão não é apenas começar "pequeno" (mesmo pq para alguns não há essa opção). O problema é se o seu banco de dados exige um investimento em infra-estrutura q tornará a migração dele para um concorrente algo praticamente impossível. Citei o MS SQL Server por questões óbvias (só roda em um sistema operacional). Mas, a Oracle tbém adora tentar verticalizar suas ofertas. E quase todos os seus produtos acabam por embutir alguma engine de banco Oracle no meio, mesmo q seja sob a justificativa de servir apenas de "infra-estrutura". Ou seja, o investimento acaba sendo maior do q apenas na engine q vc queria comprar inicialmente.
"Infelizmente não estão sendo relevantes porque são muito pouco conhecidos, como observa-se pela quantidade de comentários que esse post atraiu..."
Aqui eu discordo. Benchmarks como o TPC são utilizados principalmente para apoiar aquisição de software ou hardware específico. A falta de comentários aqui pode simplesmente significar q esta não é a seara dos frequentadores deste fórum (se fosse um fórum de DBAs, por explo, tenho certeza de q teria lotado de comentários). Tenho uns 15 anos de janela em questões correlatas e sempre vi os TPC aparecendo aqui e ali.
A questão é q lá pelo final dos anos 90 a relevância dos TPC foi sendo cada vez mais questionada e seu uso deixado de lado (lembre-se q o TPC-A e B já caíram em desuso, e há quem diga q o TPC-C está próximo do seu fim). Quer dizer, eles continuam sendo um "ponto de entrada" na hora de avaliar as engines ou o hardware onde os testes rodam, mas como as configurações de alto desempenho envolvem máquinas fora da realidade de muita gente, acabam por ser irrelevantes para muitos "mortais".
[ ]s
O "cubos" ficou entre aspas porque só tinha visto esta estrutura referenciada no inglês.
Quanto ao TPC, a referencia que dei anteriormente demonstra que as características de aplicação deste benchmark já eram conhecidas pela comunidade ao ponto dela referenciar sua própria contribuição a ele.
Deve ser uma questão de custos mesmos e de falta de interesse baseado nos nichos específicos de mercado (baixo custo e necessidades menos críticas, por exemplo).
Um abraço,
Jaime Balbino
Learning Designer e Consultor em automação do ensino
http://www.dicas-l.com.br/educacao_tecnologia
http://mobeduc.blogspot.com
Com certeza parece conversa pra boi dormir, esse TPC é uma união dos 3 mais afetados pelos bancos abertos e ta com cara que vai virar mais um GetTheFacts...
Se existe toda uma metodologia, porque não convidar representantes dos outros Bancos? E comparar todos? Deve ser porque eles não são grátis, são livres!!! hehehhehe
Eu vi uma palestra na Pycon sobre o que o governo do Paraná fez. Resumindo, a solução de banco em cluster do PostgreSQL ficou 30% mais rápida que a do Oracle. E claro que não deve ter sido fácil, mas imaginem que a equipe de implementação aprendeu...
davidkwast.blogspot.com
Oi, David !
É uma pena que não tenha visitado o link para a página dos participantes do TPC. São ao todo 21 participantes - e não 3 - sendo, como citei, muitos apoiadores do software livre, tal como a Sun.
A questão de muitos dos exemplos terem sido feitos com Linux já demonstra que não há distinção.
Já neste aqui TPC FAQ você descobre o seguinte :
- Qualquer empresa pode se tornar membro do TPC
- Não é preciso ser membro do TPC para realizar um benchmark
Se alguem tiver alguma informação adicional, com devido link, sobre porque não existem benchmarks com bancos livres, isso é muito útil.
---------------------
CidadaoCarioca
BufaloInfo
A comunidade livre criou outro benchmark compatível com o TCP-H e mais amplo, o OSDL-DBT3. Acho que e mais fácil encontrar BDs livres testados sob este padrão.
A fonte foi esta análise do Postgres 7.x:
dspace.c3sl.ufpr.br/dspace/bitstream/1884/662/1/Eduardo_Cunha_de_Almeida.pdf
Jaime Balbino
Learning Designer e Consultor em automação do ensino
http://www.dicas-l.com.br/educacao_tecnologia
http://mobeduc.blogspot.com
Oi, Jaim !
O TPC-H é um padrão de benchmark para bases OLAP, não para bases OLTP. Quer dizer : Este padrão de benchmark apenas faz o benchmark para uso de datawarehouse.
Analisar o PostGreSQL para datawarehouse envolve muitas outras coisas. Por exemplo, para datawarehouse o SQL Server possui o Analysis Server, que faz trabalho com cubos e implementa algorítimos de data mining, além de possuir uma linguagem específica para resolver problemas com cubos, que de outra forma seriam muito difíceis de solucionar.
Todos esses recursos teriam que ser considerados como parte de TCO (a favor ou contra) de acordo com a produtividade que fornecem.
Só que, além de todas essas questões, a tese do Eduardo Cunha de Almeida, para onde aponta o link chegou a seguinte conclusão : Não é possível utilizar o PostGreSQL para soluções de datawarehouse, ele não tem capacidade suficiente para isso, a tese acaba por sugerir o que deveria ser alterado neste banco para que ele possibilite este tipo de uso.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Engraçado... "não é possível usar para data warehouse", mas usamos aqui e funciona bem, obrigado. E agora?
Oi, DarkMaster !
Pois é, eu pergunto, e agora ?
Pois a tese fez uma análise detalhada disso e tirou essa conclusão. Será que vocês estão perdendo inúmeras funcionalidades (e consequentemente produtividade) devido a não utilizarem um banco mais específico para esta função e não perceberam isso ?
Seria necessário seu DBA fazer a análise da tese em questão (cujo link está alguns comentários acima) e explicar como conseguiu implementar algo que a tese afirma não ser adequado. Seria uma informação útil a todos.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Opa! A tese citada traz uma análise para o PostgreSQL versão 7.4.2. A versão atual de produção é a 8.2.5, sendo q já estão no Beta 2 da 8.3!
Assim, pra ser mais justo, o correto seria q a tal análise fosse efetuada para a versão corrente, não para uma de uns QUATRO ANOS ATRÁS (estou me baseando na data da tese, pois ela foi apresentada em 2004, sendo necessário pelo menos 1 ano pra escrever direito, deve ter começado a ser escrita lá por 2003).
Inclusive, o próprio autor da tese aponta algumas das melhorias previstas na versão 8.x, q ainda seria lançada. Assim, é bem possível q a versão usada pelo outro comentarista seja justamente uma versão mais moderna. Sem falar q pode ter sido realizado um backtrace de funcionalidades interessantes do 8.x sobre um código 7.x.
No mais, a tese buscava implementar um benchmark TPC-H. Voltando ao q já disse lá em cima, nem sempre o ambiente do benchmark é relevante para um ambiente de produção "de verdade".
[ ]s
Oi, Olival !
Sim, a questão da diferença de versões chamou a atenção. Assim sendo, faltam informações :
- Recursos que o PostGreSQL versão 8.x possui para warehouse
- Existe benchmark TPC-H para ele ?
- Onde ?
[]'s
---------------------
CidadaoCarioca
BufaloInfo
O Google retornou vários links à query "'postegresql 8' TPC-H", mas realmente não tenho tempo de explorar tudo. Só citei a questão pq os comentários anteriores deram a impressão de q a tal tese seria o "estado da arte", mas não é bem esse o caso...
De qqr forma, acho duvidoso q alguém invista neste tipo de teste para um postegresql simplesmente pq é algo oneroso. No máximo, acho q rolam coisas acadêmicas como a tese citada. Em um comentário anterior eu coloquei a seqüência de requisitos para um teste TPC ser aceito como tal e ser publicado/homologado pelo próprio TPC Council. Não é pra qqr um, muito menos pra um projeto open source sem capital pra este tipo de empreitada.
E, se fosse pra ser um benchmark "pra valer", a fim de aparecer no site da TPC, o executor do teste teria q ter acesso tbém aos mais diversos tipos de hardware, de um servidor Dell PowerEdge monoprocessado a um HP SuperDome de 128 núcleos. Essa é uma limitação que os 3 "majors" (Oracle, IBM, Microsoft) decididamente não têm... :)
[ ]s
Já foi atacando sem ler os links?Coisa feia :(
Muito bom o artigo...com certeza tira muitas dúvidas do pessoal, vlw
Eu gostei muito do artigo. Como diz o título, se manteve exclusivamente nos bancos de dados proprietários, deixando de lado as soluções livres. Mostrou um comparativo entre os 3, sendo uma boa dica para quem quer trabalhar com algumas dessas soluções disponíveis de forma gratuita.
Só não dou nota 10 por causa do "fanboyismo" no fim do artigo. Totalmente necessário e um ótimo argumento para flames.
Flancox.
Ficou uma pergunta: nos testes do TPC foram usados as versões gratuitas do MS SQL, DB2 e Oracle?
tsc, tsc, tsc
Acho que na vida real o buraco é mais embaixo. Nenhuma empresa com o mínimo de sanidade vai colocar um SQL Server Express pra rodar alguma aplicação séria, com opções como MySQL, PostgreSQL e até Firebird, que nem foi citado. É dar um tiro no pé, já que com certeza num futuro não muito distante a conta de ter que atualizar pra uma versão paga (e bem cara) acaba chegando.
[]'s
PS: De qualquer forma, um ótimo artigo se valendo de argumentos, muito tendencioso mas explorando "fatos", afinal, Get The Facts certo? ;)
Eu ia perguntar a mesma coisa, as versões express não estão na lista. Claro que não se pode esperar que apareçam por lá mas ficamos sem saber a performance destes bancos freeware.
E lembrando que a lista TPC pelo que pesquisei é uma lista de soluções completas, ou seja vc tem uma parte de hardware e software. Não se pode saber no comparativo até aonde a performance se deve ao banco ou ao hardware em questão.
Eu não sou desenvolvedor mas ficaria com o pé atrás de usar uma solução de uma empresa que ameaça com cobrança de patentes sobre o uso de suas interfaces, imagina se o google usa MSQL ? Lá vem a Microsoft cobrar patente de uso do ODBC ?
Ps:
O search do TPC está dando erro, péssimo para a imagem ;-).
Ps2:
Não sei mas me parece que o Mysql e PostgreSQL não aparecem no TPC porque não há uma solução completa (hardware e software) para estes bancos.
Oi, Daniel !
"E lembrando que a lista TPC pelo que pesquisei é uma lista de soluções completas, ou seja vc tem uma parte de hardware e software. Não se pode saber no comparativo até aonde a performance se deve ao banco ou ao hardware em questão."
Corretissimo. A performance se deve ao conjunto, não exclusivamente ao banco. O banco é parte da solução.
Mas não justifica que soluções completas não tenham sido montadas com MySQL ou PostGreSQL. Poderiam tanto ser feitas em Windows, utilizando COM+ como em Linux, utilizando o BEA Tuxedo (me corrijam se estiver errado nessa possibilidade).
Cobrança de patente sobre o uso de interface ?
A cobrança de patentes que tem sido muito mencionada, mas isso se refere a técnicas, tecnologias, criadas pela Microsoft e re-implementadas em aplicações de software livre (definição apenas - não entro no mérito se é ou não é). Se eu compro um Visual Studio e produzo um software, não pago patente nenhuma, já paguei pelo software de desenvolvimento. Além disso as versões gratuitas permitem desenvolvimento de softwares comerciais e caem no mesmo caso.
O mais próximo que achei sobre o porque dos bancos livres não aparecerem no TPC foi a existência de um software chamado OSDB para realização de benchmarks de bancos livres. Podem ver em OSDB
[]'s
---------------------
CidadaoCarioca
BufaloInfo
"Eu acho" que a lista utiliza soluções completas prontas. Não deve entrar um servidor no qual foi instalado um mysql e postgresql após a compra.
Também deve ser difícil para a Mysql montar um servidor no calibre de uma IBM e Sun.
off-topic.
O comentário da patente foi para cutucar mesmo, mas o engraçado desta história de patentes é a Microsoft "ameaçar" um processo contra desenvolvedores de software que utilizam protocolos publicados para integrar aos seus produtos.
Para mim protocolo não é inovação e não dever ser patenteado.
Oi, Daniel !
Não entendi claramente seu primeiro comentário. Mas vale destacar que o ambiente pode ser montado a partir das especificações existentes no TPC para realização dos testes.
Não acho que a MySQL seja tão pequenininha que não possa montar um bom servidor para fazer os testes. Considerando ainda os diversos apoiadores do software livre, como Novell, entre outros, fica ainda mais fácil.
Se o mySQL no RedHad pudesse aparecer próximo ao topo da lista, com certeza a Novell ajudaria.
Quando o protocolo é padronizado, com certeza não, tal como SOAP, WSDL, entre inúmeros outros.
Agora quando foi criado de forma proprietária, a patente tem sentido. Pelo menos no mundo de hoje, capitalista. Mundos futuros é outra história...
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Não gosto muito de "achismo" Dennes mas é provável que para entrar na TPC tenha de se aliar a um integrador (HP,IBM,SUN) e lançar os testes.
No Google há alguns testes de TPC feitos com mysql mas realizados pela MYSQL (empresa), não é muito confiável.
O chato é não saber "com certeza" porque os bancos open não estão ao menos presentes na competição para verificar sua colocação. Eu não achei nada referenciando, mesmo porque como eu disse a ferramenta de "search" não funciona.
Oi, Daniel !
A única coisa que pode causar essa "exigencia" de aliança com um integrador seriam os custos de hardware, que não deve ser coisa barata não. Mas nesse caso é questão de alguém querer investir.
Bem, se achou algum que seja realmente TPC, o link é muito bem vindo. Em todas as minhas buscas encontrei apenas um software chamado OSBD para benchmark de bancos livres e muitos textos tentando justificar a dificuldade que é fazer um teste TPC ($$$$).
Mas minha opinião é que isso não justifica a falta de uma empresa desejando investir nisso, nem mesmo os próprios fabricantes. A conclusão que eu tiro (que pode estar errada, óbvio, mas vai fazer com que eu apanhe mais ainda aqui nos comentários) é que as empresas não investiram nisso porque sabem que os testes não mostrarão os mesmos índices, não chegarão ao topo.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Segue um, como eu disse não me parecem muito confiáveis:
http://209.85.165.104/search?q=cache:LV9gaTtuHJgJ:corpo.mandriva.com/xwiki/bin/download/Main/Technology/mysql-performance-whitepaper.pdf+Mysql+TPC&hl=pt-BR&ct=clnk&cd=1&gl=br&client=firefox-a
De qualquer forma acredito que para investir num teste TPC a empresa deveria ganhar muito com isto, como o Mysql e o PostgreSQL são livres não haveria um ganho considerável para este investimento (fora que é o produto de uma outra empresa, seria uma propagando gratuita).
Em relação ao PostgreSQL é uma visão correta. A equipe não teria muito a ganhar investindo nisso. Teria que ser algum implementador mesmo. Mas quem implementa o utiliza no background de uma aplicação qualquer que é o carro chefe. Pra quê gastar tempo e dinheiro promovendo o coadjuvante?
No caso do MySQL a questão pode ser a característica do produto mesmo. O MySQL possui boa performance e ótimo custo/benefício mas até a última versão não tinha peito para fazer cócegas em soluções como o Oracle s(será . Daí que bancar tais teste não seria interessante.
Jaime Balbino
Learning Designer e Consultor em automação do ensino
http://www.dicas-l.com.br/educacao_tecnologia
http://mobeduc.blogspot.com
Oi, Daniel !
A partir do seu link pude observar uma outra empresa de benchmarks, SPEC , porém não realiza benchmarks de bancos de dados, mas vários outros tipos, como benchmarks de servidores de aplicação java.
No link que você apontou, a documentação fala ter sido utilizado um benchmark da SPEC que é na verdade um benchmark para servidores de aplicação e não para servidores de banco.
Curiosa a questão : O que é melhor para o benchmark - igualar todo o ambiente e testar aquilo que desejamos (SPEC) ou testar recordes de um conjunto onde pode ser feita a combinação dos elementos que melhor se entendem entre si ? Uma boa questão...
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Olá Dennis.
Antes de mais nada quero relembrar que não me esqueci da nossa outra discusão, ando meio sem tempo, e assim que eu tiver mais "folgado", irei dar continuidade ao que conversávamos, tambem to reunindo um pouco mais de informação sobre o caso, pois nos links que foram apresentados parece que estão faltando algumas informações que estão causando conflito. Em fim, é um papo para outra hora.
Só um comentário em relação a patentes.
Lembre-se tambem que caso a microsoft tenha patenteado a "idéia" tambem já é um futuro problema, como você citou, se ela em algum momento foi a primeira a ter alguma "funcionalidade" em relação aos BD é bem provável que tenha patenteado a "idéia" e qualquer outro banco de dados que usar posteriormente a mesma idéia, poderá ter problemas em relação a isso.
Não estou dizendo que aconteceu, nem que vai acontecer, só exemplificando mesmo um problema que algumas patentes podem gerar. (vide patente do duplo-clique).
Oi, Wallacy !
Sim, isso é um grande problema, e a Microsoft de boazinha não tem nada, é uma empresa pronta a fazer esse tipo de coisa.
Mas não fazer esse tipo de coisa passa pela possibilidade de criar um sistema social diferente do capitalismo no qual quem tem uma idéia seja, de alguma forma, reconhecido e beneficiado pela criação.
De qualquer forma, a Microsoft tem se empenhado muito na área de interoperabilidade e padrões abertos.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Oi, Antony !
É claro que não foram usadas as versões gratuitas dos bancos no TPC, mas você confundiu essa colocação. Veja este trecho :
"Migrar a aplicação para uma edição do servidor com maior recurso será uma tarefa simples quando a aplicação crescer."
Portanto a questão aqui não é o benchmark das versões gratuitas, mas a facilidade de migrar para edições que atingem o topo do índice TPC.
Quanto a este trecho que você citou :
"já que com certeza num futuro não muito distante a conta de ter que atualizar pra uma versão paga"
Neste caso você está contando com o crescimento da sua aplicação, correto ?
Porém é justamente este o problema e solução expostos no artigo !
Com qualquer um destes 3 softwares proprietários a aplicação ganha a liberdade de crescer a vontade, pois eles podem chegar ao topo do TPC, como demonstrado.
Porém e os outros bancos, de software livre ? Até que ponto vão suportar o crescimento da aplicação ? É fato claro que não será o mesmo suporte que os 3 maiores servidores disponíveis no mercado.
Veja este trecho que mencionei :
"Isso porque escolhendo um dos 3, estaremos evitando criar uma limitação ao crescimento das aplicações. É claro que é quase impossível prever qual limitação será essa e se realmente virá a existir um dia ou se o banco escolhido vai dar conta do recado, mas os índices TPC mostram claramente os 3 melhores servidores do mercado e todos os três possuem edições gratuitas."
Assim sendo, em minha opinião, dar um tiro no pé é optar por um banco livre (o que não significa gratuito, já que o próprio MySQL é pago) sem analisar cuidadosamente a expectativa de crescimento da aplicação e sem ter a certeza se o banco em questão vai ou não suportar determinado nível de crescimento.
Quanto a ser tendencioso, por favor, dê mais detalhes para que eu possa corrigir.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
"Quanto a ser tendencioso, por favor, dê mais detalhes para que eu possa corrigir."
"Por fim, só para dar mais um motivo para brigarem comigo nos comentários : Sem dúvida este é mais um exemplo de como o pioneirismo comercial da Microsoft forçou os concorrentes a aderirem a este recurso, possibilitando que pequenas aplicações dispensem a compra de grandes servidores e ainda assim não sofram horrores se algum dia precisarem ser migradas para um servidor maior."
Pioneirismo? Talvez. Mas talvez a qualidade e a fatia do mercado dos bancos livres tenha incomodado a Microsoft ANTES do pioneirismo comercial dela incomodar os concorrentes ;)
Aliás, não tenho acesso à nenhuma base de dados que o PostgreSQL não dê conta. Quando você diz "sofram horrores" para migrar, tem algum caso específico em que o PostgreSQL não deu conta de alguma aplicação? Só curiosidade mesmo ;)
PS: Não citei o MySQL porque na minha cabeça ele é voltado apenas para aplicações menores.
Oi, Antony !
"Pioneirismo? Talvez. Mas talvez a qualidade e a fatia do mercado dos bancos livres tenha incomodado a Microsoft ANTES do pioneirismo comercial dela incomodar os concorrentes ;)"
Pensei que o fato de usar o termo pioneirismo comercial fosse suficiente para demonstrar que não tinha nenhuma intenção de dizer que a Microsoft estava com isso sendo uma boa samaritana sem intenção de ganhar nada.
Ela apenas saiu na frente, foi a primeira a ter a coragem de abrir uma edição de seu banco gratuitamente e, independente das motivações comerciais, isso foi algo pioneiro.
"tem algum caso específico em que o PostgreSQL não deu conta de alguma aplicação? Só curiosidade mesmo ;)"
Pega o script do top 1 no TPC e tenta fazer no PostgreSQL.
Se me faltam exemplos em relação a isso não significa que não existam, as 10 aplicações da lista do TPC já são 10 exemplos.
---------------------
CidadaoCarioca
BufaloInfo
Sim, o PostgreSQL 7.X teve problemas com alguns dos scripts de teste do TPC-H, por isso alguns testadores utilizavam outras metodologias como DBT3, compatível e mais amplo (não quer dizer mais rígido).
Até onde pesquisei estes problemas teriam sido solucionados no PostgreSQL 8.X.
Abraços,
Jaime Balbino
Learning Designer e Consultor em automação do ensino
http://www.dicas-l.com.br/educacao_tecnologia
http://mobeduc.blogspot.com
Oi, Jaim !
Isso é bem legal, se houver uma tese equivalente a que surgiu nos links por ai para o PostGreSQL 8, vai ser uma excelente indicação.
Porém nem estava comentando a questão do TPC-H, pois não é uma simples questão de script de teste, é um teste para objetivo diferente, warehouse. Se este teste já foi aplicado ao PostGreSQL 8, já é alguma coisa para compararmos.
De qualquer forma, a questão que mencionei no comentário anterior seria realmente o TPC-C executado no PostGreSQL
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Não sei em relação ao DB2 e MS SQL, mas o Oracle XE *a princípio* só não tem o suporte a SMP da versão full. De resto, é o mesmo DBMS que você compra (inclusive você pode fazer o upgrade e continuar rodando a mesma base física sem alterações). Mas concordo que seria uma comparação mais apurada se fossem usadas as versões "free as in free beer" de cada um versus os DBMS "free as in free speech".
Em relação à opinião do autor do post, eu concordo em parte. Aplicações corporativas (as chamadas de "missão crítica") exigem um banco onde não exista o risco de ficar na mão por conta de uma queda brutal de performance sob alta carga e/ou impossibilidade de upgrade (ou com um caminho tortuoso e traumático envolvendo migrações de dados) ou ainda falta de mão de obra especializada para administrar. Eu particularmente não ficaria confortável em recomendar um banco sem tradição para uso em missão crítica por um banco ou financeira, por exemplo. POR OUTRO LADO, pequenas aplicações não-críticas são ideais para bancos não tão tradicionais, onde a leveza e agilidade do DBMS são fatores mais importantes do que ter um nome por trás garantindo a integridade dos dados. Como eu já disse em outros posts, cada problema requer uma ferramenta específica. Temos que conhecer todas tão bem quanto possível e saber quando usar uma ou outra.
---
Tecnologia deve ser o meio, não o fim.
Oi, Carlos !
O link que publiquei sobre o Oracle leva você até uma datasheet sobre o XE, mas você também pode acessar em http://www.oracle.com/technology/products/database/xe/pdf/dbxe_datasheet.pdf
Quanto a "leveza e agilidade", procurei colocar isso no artigo indiretamente ao destacar o conhecimento da equipe que vai trabalhar com o banco como fator determinante para o TCO.
Isso porque cada banco, tanto os proprietários como os livres, tem sua configuração default. Saber que a configuração default de alguns é sem uso transacional e de outros é com uso transacional, saber como isso afeta a performance e saber alterar quando necessário, é uma questão de conhecimento técnico da equipe, mais voltado a um do que a outro.
Em minha opinião, a impressão que tenho hoje é que grande parte do "conhecimento" de que X é mais rápido que Y surgem exatamente da não consideração destes fatores de configuração padrão - diferentes nos diversos bancos.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Porque todo mundo diz postgree ?
A pronúncia correta é postgreseequel.
Corrigido.
Sei lá o porquê, me lembro do nome deste jeito.
Quem tem banco de dados gigante e precisa mesmo de performance não vai usar nenhuma dessas versões, com certeza vai pagar uma fortuna pra usar a versão mais parruda do seu banco preferido.
Usar MySQL como o Google usa não para qualquer um, saiu mais barato contratar gente pra aumentar os recursos do MySQL do que comprar licenças de bancos proprietários como Oracle. Como o Google devolveu o código alterado para o MySQL talvez as próximas versões oficiais comecem a ficar mais competitivas ao se tratar de grandes bancos.
Acho que há 2 problemas no modo como está escrito o artigo:
1 -> Dizer que são os 3 melhores databases do mercado(pelo menos pareceu que quis dizer isso) é no mínimo perigoso. Não acredito que a Google por exemplo usaria um Database que não fosse bom o suficiente. A questão de ser melhor depende da ferramente, de quem usa, e do uso que se dará.
2 -> Não acho correto falar das versões grátis(e limitadas) dos bancos, baseando-se no teste, que foi feito com versões full(basta ver as informações no link da página, todos os testes foram feitos com as versões completas dos bancos). Esses testes podem provar o desempenho das versões utilizadas, não uma versão freeware, cortada e minimizada que há disponível. O desempenho pode não ser o mesmo - pra melhor ou pior.
Oi, Puppy !
1) Nesse caso você precisaria contestar o índice TPC e as empresas que fazem parte de sua criação
1B) O google teve uma necessidade específica de mudar o códifo fonte do banco, por isso usou o MySQL, ainda assim ninguém sabe exatamente em que.
2) É claro que não foram usadas as versões gratuitas dos bancos no TPC, mas você confundiu essa colocação. Veja este trecho :
"Migrar a aplicação para uma edição do servidor com maior recurso será uma tarefa simples quando a aplicação crescer."
Portanto a questão aqui não é o benchmark das versões gratuitas, mas a facilidade de migrar para edições que atingem o topo do índice TPC.
---------------------
CidadaoCarioca
BufaloInfo
"[...]ainda assim ninguém sabe exatamente em que."
Aqui tem algumas pistas =D
http://www.informationweek.com/news/showArticle.jhtml?articleID=199201237
http://code.google.com/p/google-mysql-tools/
http://code.google.com/p/google-mysql-tools/wiki/Mysql4Patches
http://www.mysql.com/customers/customer.php?id=75
[],
AC
Oi, ac !
De todos os links, o último é certamente o mais completo. Todos os anteriores apenas descrevem as mudanças que o google fez ao mySQL.
O último, porém, traz a descrição técnica de alguns cenários em que o google usa o mySQL. Mas, mais uma vez, não informa *para que*, apenas sabemos que não é para a ferramenta de busca.
De qualquer forma, tendo a descrição técnica do ambiente talvez o *para que* se torne desnecessário... Mas pelo menos é importante não alimentar a lenda de que o banco de dados de busca do google é mySQL...
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Hummm... Não tinha entendido....
Quando você fala: "para que" você está se referindo ao casos onde o Google usa o MySQL, e não o que o Google mudou nele, certo?
Inicialmente, acreditei que os links poderiam dar sugestões sobre *o que o Google mudou*.
[],
AC
Poxa galera, será que é difícil aceitar que existe algo não-opensource que presta?
Vocês acham realmente que QUALQUER aplicação DB2/Oracle/MSSQL rodam na boa em MySQL/PostGre? Francamente...
Os bancos "open" são excelentes softwares, mas apenas em aplicação de até médio porte. O MySQL é excelente na Web, a IBM mesmo o utiliza em algumas soluções, mas esperar que ele aguente um banco como o de uma Petrobras é sonhar alto demais.
Eu uso o PostgreSQL para uma aplicação web que atende todos os 399 municípios do Paraná, é "pesado" o suficiente? E há aplicações ainda maiores aqui usando também o postgres.
P.S: E não estou afirmando aqui que Oracle e companhia "não prestem". Só não acho interessante pagar os custos de licenças e etc sendo possível fazer o mesmo trabalho com SGBDs open source.
Oi, DarkMaster !
"Só não acho interessante pagar os custos de licenças e etc sendo possível fazer o mesmo trabalho com SGBDs open source"
Acha mesmo que pode fazer o mesmo trabalho ? Qualquer trabalho ?
Nesse caso, em todo o mundo, apenas você vislumbrou isso, pois do contrário não existiriam mais SQL Server, Oracle e DB 2, correto (estou apenas divagando, vendo onde sua afirmação chega) ?
Tente executar a aplicação do TOP 1 do TPC com PostGreSQL e conta para nós o resultado.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Alguém me arruma a senha do SSH do TOP 1 por favor ;)
Eu estou pouco me lixando para benchmarks, quero é resultados. E até agora não achei algo que eu não possa fazer com SGBDs opensource na vida real / ambiente de produção. Além de que, trabalhando para o governo, há coisas mais importantes nas quais gastar dinheiro do que em licenças de software desnecessárias.
Oi, DarkMaster !
Considerando-se o fato de que o TPC utiliza simulações de aplicações transacionais e operações completas, incluindo servidores de aplicação, em seus benchmarks, então diria que sua "vida real/ambiente de produção" andam limitados.
É essa a questão : Você vai colocar uma limitação em até onde pode ir ou vai deixar as possibilidades em aberto para quando encontrar uma aplicação que realmente precise da escalabilidade de um TOP 1 do TPC ?
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Eu esqueci de comentar uma coisa, o uso de SGBDs em aplicações "médias para pequenas". Nesse caso eu também acho desnecessário o uso dessas versões "free" do SQL Server, Oracle e etc e por qual razão? Porquê como descrito no post inicial, se a aplicação crescer você terá que migrar para a versão "completa" e paga, com licenças e etc. Já em um postgresql da vida, se a aplicação crescer eu simplesmente consigo mais hardware e/ou começo um cluster (o mesmo valendo para o MySQL). A única coisa que sinto falta de um SQL server é a capacidade de fazer views editáveis, mas só esta característica não compensa o custo de licenças e etc quando você pode contornar essa limitação na aplicação e/ou na base de dados por outros meios.
Oi, DarkMaster !
Neste ponto você levantou um tópico muito interessante a ser debatido.
Será que o aumento de hardware substitui um software com melhores recursos (bem, foi o que você disse acima) ?
O que é melhor: Um software adequado ou simplesmente aumentar o hardware ?
Será que deveríamos nos preocupar menos com a escalabilidade das aplicações que nós produzimos, afinal, não importa se estão bem otimizadas ou com uma lógica boa, se for necessário é só aumentar o hardware ?
Interessante questão... Temos então os seguintes tópicos em aberto para debate :
1) O aumento de hardware substitui em 100% um software melhor otimizado ?
2) Um aumento de hardware é mais barato nesta substituição em 100% de um software melhor do que a aquisição do software ?
3) Até que ponto vale a pena se preocupar com a escalabilidade de um software (até mesmo das aplicações que desenvolvemos) ou contar com a possibilidade de aumento de hardware ?
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Eu não acredito... você só pode estar sonhando se insinuou agora que os SGBDs proprietários são "tão bons que não precisariam incrementos de hardware" como os opensource para o mesmo trabalho. Cara, sem ofensas mas toda uma equipe de analistas aqui analisou, analisou e decidiram pelo postgres, mesmo tendo orçamento para Oracle / SQL server / etc. Não tente chamar os mesmos de "burros".
Oi, DarkMaster !
Não, eu não. Pergunte aos analistas que fizeram os benchmarks do TPC...
E não, não disse isso, foi você que disse o contrário : "não preciso de um banco com mais performance, se tiver problemas aumento o hardware"
Que existe uma diferença em relação ao aumento de hardware conforme a qualidade da aplicação (neste caso, do servidor de banco), isso é inegável. Existe até um termo para isso : escalabilidade.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Não coloque palavras na minha boca, engraçadinho... Para começo de conversa, não existe uma diferença de performance "oohhhhhhhh" que justifique pagar (bem) mais para usar digamos um Oracle no lugar do Postgres. aliás, devo dizer de experiência própria que essa diferença é difícil de notar (pois temos sistemas "legado" rodando em Oracle e por meio deles dá de comparar performance).
Segundo, Se existisse uma diferença de "qualidade" entre o Oracle e o Postgres pode ter certeza que estariam rodando aqui Oracle, pois temos orçamento para isso se necessário. Mas o pessoal decidiu pelo Postgres, porquê será, hein?
E para matar essa conversa inútil com um "profissional certificado Microsoft" - a qual não sei porquê levei até aqui - Se Postgres não fosse altamente escalável então porquê estaríamos usando o mesmo aqui? Se você depende dessa conversa para vender SGBDs para as empresas, melhor começar à pensar em trabalhar em outra coisa.
Xiii... perdeu totalmente a compostura agora...
[ ]'s
----
"Funcionários públicos têm cura?"
"[...]Será que o aumento de hardware substitui um software com melhores recursos (bem, foi o que você disse acima) ?[...]"
Não seria possível analisar isso comparando as configurações de hardware diferentes mas com os softwares "iguais"?
1) Acredito que não. Mas otimização de software também tem limite, daí um upgrade de hardware seria obrigatório.
2) Acredito que não tenha uma resposta que sirva para todos os casos:
- Upgrade no Hardware mais barato do que o Software;
- Upgrade no Software mais barato do que o Hardware;
- Mesmo preço.
Isso sem se preocupar com a diferença no aumento da performance:
- Hardware mais barato do que o Software
- Upgrade no hardware: Aumento de 10% na performance;
- Upgrade no software: Aumento de 15% na performance;
3) Acredito que a otimização de software deva ser priorizada nas funcionalidades com maior acesso e até o ponto em que a diferença seja perceptível sem a necessidade de um profiler para comprovar.
Dois milésimos de segundo em uma tarefa que eu executo 200 vezes por dia, não fazem diferença.
[],
AC
A Microsoft cresceu porque oferecia o Backoffice com o mesmo numero de licenças para mssql, nt, exchange, proxy-server e sei lá mais oque, tudo junto pelo mesmo preço num só pacote. Daí não tem jeito, a arrogante Oracle teve que descer do pedestal e deixar de cobrar o servidor por perfil (o valor dependia da plataforma,de quantos processadores, RAM, etc...) e se concentrou nas licenças.
A A MS continuou agressiva e passa um tempo e dá um copy/paste da sua versão de desenvolvedor para express edition, flexibilizando o que muita gente já fazia, instalava "temporariamente" a versão de desenvolvimento no cliente (vale para Oracle tambem). E todos os concorrentes são obrigados a prostituir-se se não quiser cair no esquecimento, foi o caso da Sybase que se não me engano foi a primeira que ouvi dizer que tinha uma versão "di gratis" inclusive com uma compatibilidade com os clientes MS (dblib) em detrimento da ctlib que seria nativa dele, acho que o unico limite era 5GB de dados.
O jogo da MS sempre foi abraçar e sufocar até reduzir o numero de players no mercado e francamente conseguiu. Acordos como o da Novell podem ser novidade para alguns, mas o primeiro acordo da MS nesse ramo foi com a Sybase, um banco bastante consolidado que disputava com a Oracle, a MS deu $$$ para participar no codigo do Sybase/NT, ganhou knowhow e depois deu pé na bunda da Sybase com um fork que depois seria um sybase killer. Francamente, a Sybase mereceu porque igual a oracle e novell era muito altiva e se considerava uma "rainha". A sybase nunca mais foi a mesma, tenta ligar para a sybase e pede um orcamento sem ser por integrador, vai decepcionar-se.
O que me surpreende foi o DB2 ter passado a Oracle já há algum tempo, ainda mais porque o produto/serviço deles não é barato. Acho que tem a ver com o setor bancário.
Realmente, faz tempo que não ouço falar do Sybase.
Outro grande SGBD que não vejo tão comentado também é o Ingres:
http://pt.wikipedia.org/wiki/Ingres
Na verdade você, só, não está associando o nome a pessoa:
http://pt.wikipedia.org/wiki/Postgres
[],
AC
Que legal, não sabia que o Postgres era um "fork" antigo do Ingres.
[]'s
Olá Dennes!
Sim, estou contestando o próprio índice, e quem "acredita" nele. Não os valores em si, provavelmente estão corretos, mas o fato de dizerem que são os melhores do mercado, sem testar no mínimo outros caras, não digo todos, mas outros além destes.
Quanto quando diz que confundi, não confundi não, na sua própria mensagem:
"Migrar a aplicação para uma edição do servidor com maior recurso será uma tarefa simples quando a aplicação crescer."
Você está se baseando nos resultados TPC pra usar os bancos free, pensando em quando a aplicação crescer. No mínimo você espera que os resultados do free sejam parecidos com os do índide não?
Mas veja bem, não estou dizendo que esses bancos não são bons, de maneira alguma. Acho inclusive que, o Oracle, sendo robusto como é, o melhor banco de dados. Isso é a minha opinião. SQL Server acho bom todas as ferramentas gráficas, típicas da Microsoft. Ajudam bastante(as ferramentas gráficas), é só ver o Visual Studio(OK, não é banco, mas é um exemplo).
O que quero dizer é que, esse tipo de índice me parece mais uma tentativa de botar um cabresto nas pessoas, dizendo que são as melhores alternativas de banco no mercado. Se simplesmenta aceitarmos sem fazer nenhuma pergunta, bem, que vamos assistir a Globo então.
Não confunda, acho muito legal esse tipo de artigo, e não tenho nada contra nenhum desses caras. Só sou contra índices tendenciosos, e de certa forma, o artigo tendencioso(o que acho que o seu acabou se tornando).
Oi, Puppy !
"sem testar no mínimo outros caras, não digo todos, mas outros além destes."
Na página do TPC tem todas as informações sobre as possibilidades de realizar um benchmark TPC e submeter a eles. Então cabe aos fabricantes de cada um dos outros bancos se explicarem sobre porque não fizeram isso....
"Você está se baseando nos resultados TPC pra usar os bancos free, pensando em quando a aplicação crescer. No mínimo você espera que os resultados do free sejam parecidos com os do índide não?"
Não, extremamente longe disso.
Conforme o trecho que destaquei antes, a intenção é não ter que mudar o formato de banco da aplicação, procedimento que é traumático.
"O que quero dizer é que, esse tipo de índice me parece mais uma tentativa de botar um cabresto nas pessoas, dizendo que são as melhores alternativas de banco no mercado"
Se fosse um índice restrito... analise o site do TPC...
"e de certa forma, o artigo tendencioso(o que acho que o seu acabou se tornando)."
Bem, você está chamando um índice que é totalmente aberto a colaboração de qualquer empresa que assim desejar, além de ser formado por notórios concorrentes no mercado, de tendencioso. Então é natural que ache o artigo tendencioso...
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Sobre os gratuitos, vou falar a respeito do OracleXE, que trabalho desde o lançamento, as versões "light" dos outros só sei de ler um pouco a respeito...
Bem, onde trabalho usamos o OracleXE para clientes que precisam de uma solução mais robusta, onde o Firebird, não dava conta. Pois bem, nossa empresa deve fazer a felicidade da Oracle. Pois destes clientes, uns 3 já ultrapassaram o limite de 4G que ele permite, tivemos de fazer o upgrade para o Oracle Standard (ou Enterprise).
Esse OracleXE é muito limitado. Funciona bem, mas é uma roubada. Quem pensa que um dia, mesmo que distante, vai precisar crescer deveria procurar um banco Livre.
Se for feita uma pesquisa de todos clientes Oracle, vão ver que a grande maioria não utiliza as Features avançadas dele, as que realmente fazem diferença em relação ao PostgreSQL. A grande verdade é que a maioria das pessoas compra a grife Oracle. Como se estivesse comprando uma garantia.
E o que é mais divertido, você paga vários(as vezes milhares) reais pelo Oracle. Então instala, configura, vai rodando feliz e contente. Um dia vê que uma consulta não roda, encontra uma exceção ORA-0600, olha mais a fundo nos logs, vê um código mais específico. Procura no google, acha o patch para o problema. Baixa ? Não, não baixa, a não ser que pague um extra para ter conta no Metalink(site de suporte Oracle).
Como assim, mas paguei, ele não funciona para uma consulta, tenho de pagar extra para uma coisa que já deveria funcionar ?? Absurdo, você é louco, Cafuin!!
Infelizmente, não sou não, hehe.
Oi, Cafuin !
Você trouxe um excelente exemplo ao nosso debate, mas só não sei se chegou nas melhores conclusões...
"Bem, onde trabalho usamos o OracleXE para clientes que precisam de uma solução mais robusta, onde o Firebird, não dava conta"
Quer dizer : Você encontrou exatamente casos em que um banco livre não deu conta do recado e foi necessário utilizar um banco proprietário. Que fique claro : Não é o fato de um ser livre e outro proprietário que faz um ser melhor que o outro. É apenas um momento atual no mercado.
"Pois destes clientes, uns 3 já ultrapassaram o limite de 4G que ele permite, tivemos de fazer o upgrade para o Oracle Standard (ou Enterprise). "
Quer dizer : A aplicação cresceu, quer seja de forma prevista ou não.
Quanto a sua conclusão, em minha opinião pessoal o problema é a escolha pelo OracleXE :
- Dos 3, é o mais limitado em especial no tamanho do banco
- É muito mais caro que o SQL Server
Acredito que teria melhores resultados com o SQL Server.
Quanto a sua recomendação de usar outras opções de banco, assim como suas aplicações encontraram limitação no FireBird, encontrariam em outros bancos, cedo ou tarde.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
O Firebird é tem bom suporte ao padrão SQL, mas é bem fraquinho, não escala bem.
Não é necessariamente a aplicação que cresce, é o fluxo de dados do cliente.
Esse crescimento até é previsto, avisamos na hora do contrato que se chegar a um certo ponto será necessário passar para o Oracle "Full".
"Acredito que teria melhores resultados com o SQL Server."
O caso é que a opção pelo Oracle é mais pelo seu nome no mercado, a "Garantia" que o nome dá.
Se fosse pra escolher, eu escolheria o PG. Se fosse pra escolher um proprietário e gratuito, eu escolheria o DB2. Conversando com quem conhece, dizem ser o mais completo na implementação do padrão SQL e escalar muito bem. Mas... não tem tanto nome quanto o Oracle.
Oi, Cafuin !
"Não é necessariamente a aplicação que cresce, é o fluxo de dados do cliente. "
Eventualmente até os dois, mas nós estamos falando da mesma coisa.
"O caso é que a opção pelo Oracle é mais pelo seu nome no mercado, a "Garantia" que o nome dá."
Isso é um grande problema do nosso mercado. O Oracle teve direito a esse nome na época em que o SQL Server estava em sua versão 6.5, por exemplo. Porém a evolução técnica acontece muito rápido e o Oracle perdeu o direito ao nome, sendo que o SQL Server chegou a dominar o primeiro lugar do TPC por bastante tempo.
Só que o mercado não se adapta tão rápido como a tecnologia e fica essa questão do "nome".
Particularmente, eu não escolheria nenhum banco fora do TPC. Seria dar um tiro no escuro, não há comprovação, por um benchmark padronizado, que o banco consiga a escalabilidade necessária.
Quanto ao DB2, bem, tem vantagens e desvantagens. Enquanto que para o seu caso talvez fosse excelente - afinal ele não tem limite de tamanho de banco em sua versão gratuita - se repentinamente suas aplicações começassem a esbarrar com outros limites (memória, processador, etc), trocar a edição do DB2 não seria algo bom, pois se muito não me engano é o mais caro dos 3.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Sobre o mySQL X PostgreSQL...
A "briga" é mais ou menos como o Windows X Linux.
O mySQL vive da popularidade dele. Faz o básico, enquanto o PG faz muito bem o básico e muitas outras coisas.
MySQL Adora fugir dos padrões, inventando sintaxes, mesmo onde o padrão especifica como deveria ser feito.
MySQL vive de FUDs e Lendas. A principal é que o PG seria difícil instalar. Hoje me dia isso é irrelevante se você tiver um bom sistema de resolução de pacotes (a Fabiane que não leia isso :). Mas mesmo a uns 4 anos, quando eu instalava na mão... o processo era simples, baixar, editar dois arquivos de configuração e pronto.
O outro FUD é o cúmulo da idiotice misturada com desculpa furada....
"Para que vou matar formiga com um canhão?"
Simples... porque é melhor aprender a usar um banco que serve (e muito bem) tanto para "matar formigas" quanto para
"matar baleias".
Obs.: Sim, do PostgreSQL eu me assumo Fanboy, mas ainda não cheguei ao ponto de fazer tatuagens, apesar de achar o logo bem legal :)
Eu já prefiro usar ambos. Se eu quero algo para ser rápido / simples, uso o MySQL com o MyISAM (embora eu também use o InnoBD e me pareça bastante rápido também). E se eu quero algo para usar transações "hardcore" e/ou que eu não faça idéia do quanto vai crescer para frente aí eu uso o PostgreSQL (e sim, ele é chatinho de instalar, em especial se comparar com o MySQL). Eu sou do tipo que prefire usar o canhão certo para o alvo certo hehe.
"(e sim, ele é chatinho de instalar, em especial se comparar com o MySQL)."
Qual dificuldade ? Ah, já sei,
"apt-get install postgresql"
tem 5 caracteres a mais que
"apt-get install mysql"
Muito mais chatinho quando se compara mesmo.
Sinto, só diz isso quem instalou o mySQL 30 vezes e vai instalar o PG uma primeira vez e por ser diferente acha complicado.
A única coisa que as pessoas parecem achar sobrenatural ao instalar o PG é ter de liberar o acesso via rede.
Deve ser por que entender de ip e máscaras de rede é super complexo mesmo...
Ow, você acha que eu uso apt-get? Aqui eu instalo à partir do código-fonte amigo :) Depois do meu Debian "cometer suicídio" por causa dessa mer#$ do apt-get, decidi instalar tudo pelo fonte para não me irritar mais com programas tentando refazer metade do sistema para deixar instalar (ou pior ainda, destruir metade do sistema ao tentar remover o programa)
Ou sendo mais direto, considero o PostgreSQL mais "chatinho" de instalar porquê têm que configurar a estrutura de dados, depois setar os usuários iniciais meio que na mão, depois fazer como voce comentou ajustes nas permissões de acesso e outros ajustes menores (como garantir que o LC_COLLATE seja pt-BR e não o "C" padrão). O MySQL é mais tranquilo nesta parte, é instalar e depois chamar o mySQLAdmin para as configurações. Eu poderia instalar o PostgreSQL com apt-get, mas não confio mais este desastre de gerenciador de pacotes.
Dennes, OK, acabei concordando contigo. Se não era o que queria dizer, OK.
Mas o fato do índice ser aberto não quer dizer que não o torne tendencioso. E mais, o índice pode ser muito bom, mas a forma com que é colocado seja tendenciosa. Tudo depende da forma com que as informações são colocadas. Mas gostaria muito de ver um teste com o postgreSQL na parada também, nem que seja pra ver resultados pífios, o que sinceramente não acredito.
Você disse que não investiria num banco que não tem TPC, que seria como um tiro no escuro. Na minha opinião, isso seria válido se, por exemplo, só entrasse pro TPC um banco com requisitos mínimos, o que não ocorre. Se não quer dar um tiro no escuro, porque investir em versões express então, que não estão no índice?
Oi, Puppy !
Desculpe, não entendi sua conclusão.
"Mas o fato do índice ser aberto não quer dizer que não o torne tendencioso"
Não entendi... como ?
" E mais, o índice pode ser muito bom, mas a forma com que é colocado seja tendenciosa"
Não escondi nada a respeito do índice... Qual é exatamente essa conclusão ?
"Mas gostaria muito de ver um teste com o postgreSQL na parada também, nem que seja pra ver resultados pífios, o que sinceramente não acredito."
Eu também, porque acabaria com o assunto de vez e teríamos um padrão de análise para permitirem as empresas escolherem bem os produtos mais adequados para seu ambiente.
Para o porque da falta do índice só temos especulações.
"Se não quer dar um tiro no escuro, porque investir em versões express então, que não estão no índice?"
Porque usando uma destas versões express, quando precisar de mais escalabilidade a troca para a versão paga é extremamente suave, o que não acontece se o software for iniciado e outro banco qualquer, cuja expectativa a respeito de até onde pode ir é incerta.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Dennes,
"[...]Migrar a aplicação para uma edição do servidor com maior recurso será uma tarefa simples quando a aplicação crescer[...]"
Essa migração não poderia ser resolvida usando um framework de mapeamento objeto relacional? Como o Hibernate para Java, por exemplo.
Neste caso, em tese, não deixaria a aplicação independente do banco de dados?
O que você pensa sobre esta abordagem?
[],
AC
Oi, ac !
Que independência de banco de dados é praticamente uma lenda. Só investiria nisso se for extremamente necessário ou se não tivesse custo adicional significativo.
Considerando especificamente o .NET, quanto a não ter custo adicional significativo, demonstrei isso em Camada de dados em .NET, apesar de não ser uma solução completa.
Porém quando o .NET 2.0 surgiu, o custo adicional surgiu, na forma de termos a necessidade de escolher entre escalabilidade e performance. Demonstrei isso em Camada de dados - .NET 2.0 e vídeo : desenvolvendo em camadas na web.
Observando que fui um ferrenho defensor da implementação de técnicas semelhantes (1o artigo) quando a diferença em trabalho era pequena, mas mudei de idéia na versão 2.0 do .NET - a escolha passou a ter que ser mais cuidadosa.
Agora no .NET 3.5 a Microsoft está lançando o Linq, para fazer o trabalho que hoje é feito pelo NHibernate só que de forma muito mais simples. Não usei o Linq para poder afirmar qualquer coisa, mas posso re-transmitir uma informação que um desenvolvedor conhecido gerou ao trabalhar com Linq : Teve 800% de perda de performance, sendo obrigado a fazer mudanças na estrutura de funcionamento do Linq (o que é possível), para suavizar a diferença.
(um monte de gente vai cair de pau no Linq)
O problema não é o Linq. O problema é a idéia de mapeamento objeto relacional. Os bancos de dados são relacionais e devemos aceitar isso, a tentativa de mapeamento gera altas perdas de performance sem um ganho equivalente para a manutenção (os dois artigos e o vídeo linkados acima mostram alternativas mais simples com o ganho em manutenção).
[]'s
---------------------
CidadaoCarioca
BufaloInfo
"Que independência de banco de dados é praticamente uma lenda. Só investiria nisso se for extremamente necessário ou se não tivesse custo adicional significativo."
Por isso citei o Hibernate. Ele não tem um custo adicional significativo e dá um grande ganho para manutenção.
A perda de performance se dá na conversão do HQL(um SQL orientado a objetos) em SQL específico do banco de dados que está sendo usado. E isso é feito em tempo de execução. Mesmo assim não é uma perda brutal como a citada. Não chega a 10% de perda, na maioria dos casos.
Caso esteja interessado neste assunto, eu poderia te mandar um exemplo.
[],
AC
O problema do Hibernate e da imensa maioria dos frameworks de mapeamentos é que eles são muito focados no desenvolvimento de aplicações novas.
Se você tem uma aplicação pronta e tem de mapear....chora. É possível, mas vai sofrer, ah vai.
E experimentem dizer para um gerente de TI que vai precisar fazer do zero, mas que vai ser melhor, vai funcionar melhor...
O cara vai arregalar os olhos, hehe.
Veja bem... :)
"Se você tem uma aplicação pronta e tem de mapear....chora."
Se já está pronta, porque você está querendo colocar o Hibernate?
Agora, se você está se referindo ao banco de dados pronto, concordo que não será trivial. Mas a maioria dos problemas que você terá, serão conseqüência de uma má modelagem das classes.
O que eu estou querendo dizer é: Quando você for usar o Hibernate você deveria:
- Esquecer da existência do banco de dados;
- Esquecer o que você souber sobre banco de dados relacionais, tabelas e relacionamentos;
- Pensar com *muito carinho e atenção* no seu modelo de classes. Só quando *terminar* o modelo de classes você pode voltar a lembrar que tem que gravá-las em algum lugar.
Dessa forma, a maioria dos problemas relacionado ao uso do Hibernate serão fortemente amenizados.
[],
AC
Sim, eu quis dizer realmente, ter uma aplicação pronta, COM um banco de dados já projetado que será usado em uma nova aplicação com Hibernate.
Os 3 ítens que você falou podiam ser resumidos no que eu disse "Esses frameworks não se dão bem com bancos legados"
"Esses frameworks não se dão bem com bancos legados"
Então, o que eu falei, foi para desmistificar isso. Pelo menos em relação ao Hibernate.
Estou falando isso, porque é minha situação atual. Estou migrando um aplicação feita em Centura para Java. E por conta do uso do Hibernate já achamos muitos erros em SQLs da versão em Centura.
Na prática, a experiência que estou tendo é que o Hibernate é uma opção excelente para mapear um modelo de classes bem feito para um banco de dados legado. Corrigindo os eventuais erros ocorridos nas consultas existentes.
[],
AC
"Na prática, a experiência que estou tendo é que o Hibernate é uma opção excelente para mapear um modelo de classes bem feito para um banco de dados legado. Corrigindo os eventuais erros ocorridos nas consultas existentes."
Mas aqui chegamos a outro problema... quer dizer modelo de classes ou modelo do banco, relacional ?
Porque assim, digamos que você tenha um banco bem modelado, do ponto de vista relacional. Em algumas modelagens o Hibernate não consegue mapear direito, é necessário improvisar. (Ao menos era, quando avaliei para uma aplicação). Por isso falei, para bancos legados é um problema.
Na verdade o que há de problema com o Hibernate, nem é "culpa" propriamente do Hibernate, e sim de quem o usa.
O que acontece muitas vezes é que o garotinho vai lá projeta as classes bem bonitinhas, e deixa o hibernate criar o modelo relacional por baixo. Nunca dá uma revisada, ou ajustada. Esse garotinho aprendeu java, e olha o modelo relacional e xinga "ai, que coisa mal feita, olha, não é nada OO"
Realmente, não é OO, nem é pra ser, é relacional, é diferente.
É como o problema com os ambientes RAD. Leva uma parcela de programadores, preguiçosos geralmente, a criarem aplicativos porcos, se limitarem somente ao que o ambiente oferece. Se não há um componente que ofereça um recurso, pronto, ele nunca vai usar.
"Mas aqui chegamos a outro problema... quer dizer modelo de classes ou modelo do banco, relacional ?"
O que eu defendo é que o Hibernate é muito bom para auxiliar a persistir um *modelo de classes bem feito* para qualquer porcaria que tenha sido feito no relacional.
Porém, o contrário não funciona muito bem. Se o seu modelo de classes não estiver legal, mas o seu banco relacional estiver perfeito o Hibernate, provavelmente, vai atrapalhar mais do que ajudar.
Quanto ao resto eu concordo que a culpa é do programador que não sabe nada sobre banco de dados relacionais.
Por isso que eu defendo que, em geral, o Hibernate gera um grande benefício aos programadores de sistemas de informações. E possui a flexibilidade suficiente para "sair da frente" quando estiver atrapalhando.
[],
AC
Oi, Ac!
"O que eu defendo é que o Hibernate é muito bom para auxiliar a persistir um *modelo de classes bem feito* para qualquer porcaria que tenha sido feito no relacional.
Porém, o contrário não funciona muito bem. Se o seu modelo de classes não estiver legal, mas o seu banco relacional estiver perfeito o Hibernate, provavelmente, vai atrapalhar mais do que ajudar."
Vou levantar uma questão sobre a qual tenho sérias dúvidas de que um dia haja uma conclusão :
Nossos bancos são relacionais
Nossa forma de programação é Orientada a Objetos
Vale a pena manter a forma de programação 100% Orientada a Objetos e criar um mapeamento objeto/relacional (Hibernate) ou seria preferível aceitar o desrespeito a algumas regras da OO para um melhor resultado ?
Quem defende 100% OO : O argumento é que apenas desta forma ganhamos uma gigantesca capacidade de manutenção na aplicação.
Quem defende um desrespeito controlado a regras da OO : O argumento é que existem formas alternativas de chegar na mesma gigantesca capacidade de manutenção fornecida pelo 100% OO, mas deixando de lado a perda de performance natural ao mapeamento objeto/relacional
Não é difícil perceber que pertenço ao 2o grupo e tento provar essa possibilidade nos meus artigos técnicos...
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Oi, Cafuin !
"É como o problema com os ambientes RAD. Leva uma parcela de programadores, preguiçosos geralmente, a criarem aplicativos porcos"
Pega leve ! :-) Em 2002 o RAD alterou por completo sua definição. Da uma olhada no vídeo que indiquei e vai entender.
" se limitarem somente ao que o ambiente oferece. Se não há um componente que ofereça um recurso, pronto, ele nunca vai usar"
Ai concordo, isso é porqueira.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Oi, Ac !
Fiquei agora na dúvida se você está se referindo especificamente ao Hibernate do Java ou ao NHibernate do .NET
Acredito realmente que o Hibernate do Java possal não ter um custo adicional significativo.
Mas no .NET utilizar o NHibernate significa abandonar muitos dos recursos de RAD dele, perdendo produtividade o que se transforma em custo.
Se não houvesse outra saida, tudo bem, mas acredito nas opções que indiquei nos links como saida para evitar esta perda do RAD, mantendo alta produtividade.
Quanto a perda de performance, você tem benchmarks sobre isso ? Sempre estive interessado neste tópico...
[]'s
---------------------
CidadaoCarioca
BufaloInfo
"Fiquei agora na dúvida se você está se referindo especificamente ao Hibernate do Java ou ao NHibernate do .NET"
Estou me referindo ao de Java, que é a plataforma que eu mais trabalho, atualmente.
"Mas no .NET utilizar o NHibernate significa abandonar muitos dos recursos de RAD dele, perdendo produtividade o que se transforma em custo."
No caso de Java, algumas bibliotecas e frameworks(Stripes, por exemplo) são mais produtivos do que outros(Struts) com ferramentas RAD. :)
"Quanto a perda de performance, você tem benchmarks sobre isso ? Sempre estive interessado neste tópico..."
Eu posso disponibilizar uma aplicação que avalia o desempenho das consultas feitas com o Hibernate e uma com SQL. Se estiver interessado.
O pessoal do Hibernate é imparcial ao falar do assunto.
Mas é claro que tem casos em que precisam defender o Hibernate de grupos mal intencionados
[],
AC
Sempre fico com medo desses ORM porque quero ver funcionar com banco com milhões de linhas, muitas transações por minuto.
O pessoal do SqlAlchemy mandou muito bem:
"SQL databases behave less and less like object collections the more size and performance start to matter; object collections behave less and less like tables and rows the more abstraction starts to matter."
Oi, Cafuin !
Pois é, concordo com isso ai mesmo.
Já ouvi falar de uma teoria do triangulo, onde cada ponta do triangulo estaria representando um elemento de desenvolvimento : OO, RAD e Performance/Escalabilidade
Quanto mais nos dirigimos a uma das pontas do triangulo, mais nos afastamos das demais.
Se bem que a relação entre RAD e performance mudou bastante com o surgimento do .NET, que mudou muito o que nós conheciamos a respeito de RAD.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Oi, Ac !
Da uma olhada no vídeo cujo link publiquei alguns comentários atrás e comente sobre a produtividade... é por causa dessa produtividade e por ter encontrado soluções alternativas para a manutenção que considero que no .NET o custo de implementação de um NHibernate é mais considerável...
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Oi, Ac !
Não tive tempo de ler tudo ainda, então corrija onde eu errar, por favor.
Mas observei esse trecho no texto que você linkou : "Hibernate of course will have an overhead in simple scenarios (loading 50.000 objects and doing nothing else is considered trivial) compared to JDBC"
Primeira consideração que eu faço é que o JDBC é um intermediário de acesso a banco, como OLEDB foi (até onde sei sobre JDBC). Dai que as bibliotecas de acesso direto, que ainda assim permitem flexibilidade de banco através de sistemas de factory, teriam ainda mais performance do que o JDBC.
Segunda consideração a fazer é que descartar os benchmarks que o pessoal do Hibernate chama de triviais significa que o Hibernate não poderia ser utilizado indiscriminadamente na aplicação, que haveria pontos específicos da aplicação em que ele ganharia performance mas outros pontos da aplicação poderiam ter severas perdas de performance. Eu concluiria que não seria algo para ser usado na aplicação inteira, mas em alguns trechos.
[]'s
---------------------
CidadaoCarioca
BufaloInfo
Dennes,
"Primeira consideração[...]"
No site da Sun tem uma explicação bem leve sobre o que é o JDBC.
O JDBC é um API, como o OBDC, mas escrita em Java e sem dependência nenhuma do ODBC. No mundo Microsoft está mais próxima da idéia do ADO, enquanto os drivers do banco seriam os Providers.
Portanto, JDBC não é um intermediário, mas um conjunto de interfaces que prevêem acesso aos SGBDs e são implementadas pelos fabricantes dos mesmos.
"Dai que as bibliotecas de acesso direto, que ainda assim permitem flexibilidade de banco através de sistemas de factory, teriam ainda mais performance do que o JDBC."
O driver JDBC *é* a "biblioteca de acesso direto" que você está se referindo.
"[...]descartar os benchmarks que o pessoal do Hibernate chama de triviais significa que o Hibernate não poderia ser utilizado indiscriminadamente[...]"
O próprio Gavin King, criador do Hibernate, sugere que não seja usado em relatórios ou consultas com uma quantidade muito grande de retorno. Onde "quantidade muito grande" equivale a dezenas de milhares de registros.
"[...]haveria pontos específicos da aplicação em que ele ganharia performance mas outros pontos da aplicação poderiam ter severas perdas de performance.[...]"
O ganho de performance é referente a performance do desenvolvimento e manutenção. Não das consultas propriamente ditas.
Usando o Hibernate, você começa não precisando se preocupar com:
- Escrever um insert para a entidade;
- Escrever um update para a entidade;
- Escrever um delete para a entidade;
- Transformar a linha da tabela, retornada por uma consulta, no objeto do seu modelo de classes;
A perda de performance está ligada a composição do SQL. Mas não é uma perda perceptível por um usuário da aplicação.
"[...]Eu concluiria que não seria algo para ser usado na aplicação inteira, mas em alguns trechos[...]"
Lembrando que estou me referindo ao feito em Java e que a aplicação de que estamos falando seja um típico sistema de informação, eu tenho por hábito usar o hibernate em toda a aplicação, principalmente para operações CRUD, e depois de pronto, melhorar a performance onde ela seja um problema.
Um ponto a ser observado aqui é que eu tendo melhorar as consulta usando o HQL(o SQL OO do Hibernate), antes de partir para uma solução usando SQL. Uma vez que a flexibilidade do Hibernate permite que você o mande executar uma consulta SQL, ou uma SP, ou mesmo uma Function que você tenha escrito por apresentar uma performance/escalabilidade nitidamente superior. Mas esses são os casos extremos.
Minha contribuição sobre sua conclusão:
"Eu concluiria que seria algo para ser usado na aplicação inteira, mas nos trechos em que a performance seja prejudicada e melhorias no HQL não sejam suficientes, trocar a consulta por um SQL, ou mesmo uma chamada a uma StoredProcedure."
[],
AC
Oi, Ac !
"No site da Sun tem uma explicação bem leve sobre o que é o JDBC.
O JDBC é um API, como o OBDC, mas escrita em Java e sem dependência nenhuma do ODBC. No mundo Microsoft está mais próxima da idéia do ADO, enquanto os drivers do banco seriam os Providers.
Portanto, JDBC não é um intermediário, mas um conjunto de interfaces que prevêem acesso aos SGBDs e são implementadas pelos fabricantes dos mesmos."
As explicações que você aponta estão de acordo com o que eu conheço sobre JDBC. A comparação com ADO, de certa forma também.
Mas a conclusão de dizer que ele não é um intermediário,não.
ODBC é um intermediário, ADO/OLEDB são intermediários. O ADO.NET possui recursos de acesso direto a banco que evita tais intermediários e gera ganho de performance, sendo porém específico de um banco.
Porém quando aplicado um pattern de Factory obtem-se a independência de banco, com o melhor dos dois mundos.
"O ganho de performance é referente a performance do desenvolvimento e manutenção."
No .NET, o ganho de performance em desenvolvimento não acontece, pelo contrário, há uma perda. Dê uma olhada no vídeo que indiquei e cite sua opinião....
Quanto ao ganho em manutenção, para .NET existem alternativas que evitam a perda no desenvolvimento e mantém o ganho em manutenção...
Então temos uma questão de diferença de ambiente : Hibernate pode ser excelente no Java, mas NHibernate não consegue os mesmos resultados no .NET
"A perda de performance está ligada a composição do SQL. Mas não é uma perda perceptível por um usuário da aplicação."
Bem, existe. Uma perda de performance para ser perceptivel para um usuário precisa ser muito grande. Mas a diferença afeta escalabilidade.
Entendi a conclusão. Para Java. Para .NET ainda colocaria a diferença de produtividade como um fator importante...
[]'s
---------------------
CidadaoCarioca
BufaloInfo