| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | | People, Num projecto que vou fazer, vou ter que optar por mysql ou postgres ( ou outra base de dados open source, se alguém conhecer outra que avise; o projecto vai ser open-source ). A mysql pelo que me parece é muita utilizada e por isso "garante" alguma fiabilidade...mas a falta de store procedures desanima muito o seu uso.
Alguém alguma vez fez esta comparação ( mysql vs postgres )? Gostaria de saber qual a vossa experiência em ambas as bases de dados.
Gostaria de ter termos de comparação como: fiabilidade, disponibilidade, e rapidez ( para uma base de dados de centenas de megas de informação e pode chegar a poucos gigas );
Links de sites com comparações também dava jeito.
|
| |
| |
| | Existe um artigo no phpbuilder sobre o assunto
http://www.phpbuilder.com/columns/tim20000705.php3
vd |
| |
| | http://www.redhat.com/software/database/technical/
É uma ideia... :)
Ah! Existe tambem um projecto interessante de benchmarks...
The Open Source Database Benchmark
http://osdb.sourceforge.net/
vd |
| |
|
| | | O PostgreSQL passa os testes ACID, o MySQL nao... o PostgreSQL ganha por defeito.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded." |
| |
| | Sem querer parecer que estou a tentar passar o atestado de estupidez, andas muito mal informado.
MySQL Database Now Provides Full Transaction Support
http://www.mysql.com/press/release_2002_11.html
MySQL now includes the ACID-compliant InnoDB transactional storage engine, which is designed for very high performance and scalability when processing large data volumes and under high concurrency.
Mais ajuda ?
Está bem!
InnoDB Tables Overview
http://www.mysql.com/doc/en/InnoDB_overview.html
InnoDB
http://www.innodb.com/
Transactions, row level locking, hot backup, and foreign keys for MySQL - without compromising the speed of MySQL
vd |
| |
| | Data integrity NO
Views Support NO
Schemas Support NO
Subselect Support NO
Stored Procedures NO
Triggers Support NO
Podes ter transações e foreign keys com o InnoDB mas o resto não tems.
Pedro Esteves |
| |
| | http://www.mysql.com/doc/en/Differences_from_ANSI.html
Subqueries have been implemented in MySQL version 4.1.
Data Integrity ?
Lock Table
Stored procedures and triggers are currently being implemented in our version 5.0 development tree.
It is planned to implement views in MySQL Server around version 5.0.
Escabilidade, remember?
vd |
| |
| | Ai... Vocês desculpem-me ;)
Da página mencionada passo a citar:
2. More often than not, fatal transactional updates can be rewritten to be atomic. Generally speaking, all integrity problems that transactions solve can be done with LOCK TABLES or atomic updates, ensuring that you never will get an automatic abort from the database, which is a common problem with transactional databases.
Claro que enquanto se "locka" a tabela ninguém trabalha. Isto é giro em coisas com muito poucos utilizadores... mas e quando são muitos? Simples... Não se usa mySQL ou usam-se os outros tipos de tabelas. Mas e se a manipulação destas tabelas estiver dependente de condições sobre outras tabelas? Ele aceita joins entre tabelas de tipos diferentes? Sinceramente não sei.
Mas o delírio é o seguinte:
3. Even a transactional system can lose data if the server goes down. The difference between
PLONK! Isto é preciso ter muita lata para afirmar. Numa base de dados "séria" com transacções nunca há perda de integridade salvo por BUGs
different systems lies in just how small the time-lap is where they could lose data. No system is 100% secure, only ``secure enough.'' Even Oracle, reputed to be the safest of transactional databases, is reported to sometimes lose data in such situations.
Repito... Por BUG ou opção do DBA (ou falha de hardware e mau planeamento e nesse caso há os backups)
A integridade é uma das principais razões de ser das bases de dados. Não há espaço para meios termos. Era bom que assumissem que neste momento não o podem fazer. Mas palpita-me que quando puderem isso vai ser anúnciado como uma excelente feature em vez da desvalorização mentirosa que fazem agora. Estes tipos realmente fazem-me lembrar a MS nas nos RDBMS open source. Quando não fazem não presta. Quando fizerem vai ser a melhor coisa do mundo. Yuck!
Cumprimentos.
|
| |
| | Epa os gajos do Mysql tem sempre a mania de que são mais espertos.
Vê o exemplo dos index's. Todas as bases de dados metem os dados das colunas e os index's no mesmo ficheiro. O mysql para ser diferente mete em ficheiros diferentes.
Ou seja tem de fazer dois acessos ao disco em vez de um e ainda dizem que é melhor, porque ocupa menos espaço e outras baboseiras, como é mais dificil fazer cache só dos index's.
Apenas admitem que é melhor se o ficheiro tiver em cache. Mas que raio todas as bases de dados como deve ser usam Cache aos montes mesmo para isto. Só porque a cache do Mysql é uma bosta dizem que a maneira de eles fazerem as coisas é melhor.
Pedro Esteves |
| |
| | | Vê o exemplo dos index's. Todas as bases de dados metem os dados das colunas e os index's no mesmo ficheiro. O mysql para ser diferente mete em ficheiros diferentes. Hummm... ha' situacoes (varias) em que podes e deves ter indexes e dados separados, particularmente em bases de dados transaccionais.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| |
| | Nope... Como já alguém disse, os índices podem ser criados em zonas diferentes dos dados.
Há razões de performance e outras que justificam isto.
Quanto às caches, baseiam-se na utilização de buffers (que representam blocos de disco). Quanto mais referenciados forem mais probabilidade têm de ficar na memória.
Já agora (e isto é muito estranho vindo de mim ;) ) o mySQL não é necessariamente uma bosta. A postura deles é que é :P
Haverá muitas situações onde o mySQL se dá bem. Aliás são conhecidas referências de sucesso.
|
| |
| | Sim eu tambem não dispenso mysql para php-nukes siteseed, e outras pequenas aplicações.
Nada se compara á sua facilidade de instalação, ocupa poucos recursos e é relativamente rápido.
Tudo depende das aplicações. Mas que o mysql tem muitas limitações isso tem, mas tenho uma grande fé no mysql 4.x. Só é pena ele tar a desenvolver-se tão devagar...
Pedro Esteves |
| |
| | Claro que enquanto se "locka" a tabela ninguém trabalha. Isto é giro em coisas com muito poucos utilizadores... mas e quando são muitos?
read lock, write lock.
Com a possibilidade de inserts e updates.
insert delayed para queue em elementos "locked".
vd |
| |
| | | Ja' ouviste falar de "row-level locking" certamente ?
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| |
| | Da documentação do MySQL: INSERT DELAYED only works with ISAM and MyISAM tables. ...que não suportam transacções...
Além de que INSERTS estão longe de ser a única operação que se faz num RDBMS.
As ReadLocks e WritesLocks, só permitem ter múltiplas operações de leitura em simultâneo. As operações de leitura continuam a ser mutualmente exclusivas, tanto com operações de leitura como com outras operações de escrita.
Já o PostgreSQL utiliza MVCC para lidar com o assunto.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | | Referindo ao teu comentario acima, nao quero te fazer passar por estupido... mas andas muito mal informado.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| |
| | Lock table ? LOL
Bem acrescentando algumas coisas ao bom post do Domus.
Imagina que tens uma tabela lock porque algum user fez um select complexo e que demora muito tempo. Todos os outros users tem de estar á espera que esse select acabe para fazerem outros updates ou selects nessa tabela. Isso simplesmente não é possivel com muitos users.
Agora imagina que um programa externo acede a um tabela lock do mysql e fica á espera que o user dê uma instrução qualquer para ele continuar (ou por exemplo o disco tá cheio). Enquanto o user não acabar de tomar o café o programa tem sempre a tabela locked e mais niguem pode aceder a ela.
Pedro Esteves |
| |
| | Imagina que tens uma tabela lock porque algum user fez um select complexo e que demora muito tempo. Todos os outros users tem de estar á espera que esse select acabe para fazerem outros updates ou selects nessa tabela. Isso simplesmente não é possivel com muitos users.
Lê o meu outro post...
http://www.mysql.com/doc/en/LOCK_TABLES.html
vd |
| |
| | Tirado da tua marivilhosa page ...
"The downside is, of course, that no other thread can update a READ-locked table and no other thread can read a WRITE-locked table."
Pedro Esteves |
| |
| | É um defeito passar os testes ACID? ]:->
|
| |
|
| | Definitivamente. Esta versao mais recente, da serie 7.3 parece-me imbativel.
Resta acrescentar que tambem uso MySQL, mas optei por PostgreSQL nas maior parte das aplicacoes. Como mencionado ha' pouco tempo -- picked the right tool for the job.
Cheers.
^S^ |
| |
| |
| | Ops... isto era mais um comentario que devia estar "abaixo" de "MySQL and PostgreSQL".
mea culpa
^S^ |
| |
