MySQL vs PosgreSQL

firefly,
Одинаково

 

firefly,
вполне возможно, что MySQL даже быстрее будет, так как он попроще в плане всяких там ссылочных целостносстей, транзакций и т.д.

 

Напрашивается вопрос: если время жизни миллиона записей всего один час, должны ли быть эти записи персистентными?

 

1. Что именно за MySQL вы рассматриваете - MyISAM, InnoDB, MaxDB?
2. Какое количество одновременных подключений к базе?
Если у вас не более 10 подключений, то вполне подойдет резкий как понос MyISAM, тем более, что у ваc нет update.
На 50-100 подключениях я бы все же порекомендовал Postgres, несмотря на то, что он версионник и потребует периодического вакуума

 

Засада может быть в другом месте. Файлы больше 2ГБ не есть гут по умолчанию. Реляционная база данных самое быстрое, простое и привычное, что можно предложить, но не самое лучшее... Администратору придется быть на чеку

Для надежности лучше продумать иной бэкэнд (тем более нет конкурентных изменений - нет транзакций), а аггрегации (хотя бы предварительные, что может понадобиться для анализа) можно произвести на лету и хранить уже в реляционной БД.

 

MySQL имеет несколько движков, с разными параметрами.

Из основных есть MyISAM - простой движок без поддержки транзакций и версионности. Быстро работает за счёт того, что ей не требуется поддерживать всяческие журналы. При изменении данных update/delete вся таблица кратковременно лочится и не доступна для остальных конкурирующих запросов, в случае insert данные просто дописываются в конец и поэтому необходимости лочить таблицу нет. Вообщем, накладные расходы на журнализацию минимальны, но есть моменты с локами, что критично, когда у нас есть много разнотипных одновременных запросов.

Так же есть InnoDB, в нём есть поддержка журналов, поэтому операции изменения данных затрагивают не только саму базу, но и её журналы, что медленее, чем просто писать в основную базу, но зато мы получаем поддержку транзакций и версионность, а это значит, что в случае разнотипных конкурентных транзакций мы сможем их разрулить без запирания всей таблицы при изменениях, ну и у нас ест возможность сделать откат таблицы если нужно.

PostgreSQL поддерживает только один движок - Postgres Storage System, для него верно то же, что и для InnoDB в плане журналов и конурентных транзакций. Поэтому вопрос выбора между MySQL InnoDB и PostgreSQL это большей частью вопрос выбора и сравнения высокоуровневых возможностей SQL.

Вероятно, если транзакционность не требутся, то выбором в данной ситуации будет MySQL MyISAM.


SperaSoft Team :: http://www.sperasoft.com

 

SperaSoft,
"... поддержку транзакций и версионность, ..."
под версионностью Вы именно версионность понимаете, именно почти "классическую" или теоретическую, как в Interbase???
это сейчас сделано в MySQL???

 

MySQL IMHO лучше, особенно все что начинается с пятого,с Postgre были траблы,которые решались с MySQL (под FreeBSD правда.... в мастдайке не пробовал)

 

RubiN,
не несите херню.

 

прикольная тема - столкнулись "промышленники", "студенты" и "кустарщики."

Боюс меня счас закидают большими катяхами..... но - мне кажеться при всех исходных - все зависит от количества подключений - чем их больше, тем больше перевес в пользу PostgreSQL.

добавлено через 1 минуту
Чисто интуитивное мнение, не подкрепленное серезным эксперементом с повторением всех условий.

 

RubiN, чем лучше? ну ка факты нам, факты!

"с Postgre были траблы,которые решались с MySQL" - эта пять! вы сами-то поняли что написали?

 

ага, точно подмечено.... Сижу, читаю, молчу....

 

форум, cgi,под апачем, на FreeBSD+Postgre, проработал какое-то время, но с определенного момента резко увеличилось время загрузки первой страницы. В процессе ковыряния выяснилось что в работе оптимизатора произошел какой-то сбой, подробнее не разбирался, переставил на MySQL и забыл.

 

Чтож там за форум такои.. что его понадобилось оптимизировать, все 5 табличек)).

Кстати- очень неконструктивно, решать проблеммы сменой ПО. Если бы оно было прорпиетарным - этого бы сделать наврятли удалось так просто.... а опыта - как небыло так инет.

 

OpenBoy,
"... Кстати- очень неконструктивно, решать проблеммы сменой ПО ..."
я бы даже сказал, просто непрофессионально.
правда однажды у меня была ситуация, что в процессе разработки мы наткнулись на баг в MS SQL, который официально обещали исправить только в следующем сервис паке. так что мы тупо сидели и ждали его выхода.

добавлено через 1 минуту
OpenBoy,
"... Чтож там за форум такои.. что его понадобилось оптимизировать, ..."
да скорее всего хрень какая-то типа семестровой.

 

непрофессионально зато быстро, что в условиях дефицита времени дает результат. самому не нравится так решать вопросы, но по другому сейчас никак

 

Очень даже как, есть такая штука - называетса тестирование перед вводом в эксплуатацию). С однои стороны - не совсем логично, тестировать базу данных с 5 таблицами... зато полезно - много нового узнаеш, и сможеш таки справляться с такими багами - более продвинутыми средствами.
К слову сказать - я тоже не увлекаюсь тестами, но всетаки еще не разу не менял софт, если чтото вдруг заработало не так.

 

RubiN,
опять несете херню. ну вот скажите мне, например, как вы на трех тысячах машин будете заменять ПО?

 

даже спорить не хочу, нафига мне на 3 тысячи? не те у меня масштабы

я не против, даже за, кто бы только мне людей в отдел добавил.
Кстати, от темы отклонились сильно, на личности перешли.
2AlTk,IMHO (ИМХО), для большинства задач MySQL вполне достаточен и лучше Postgre тем - что с ним проще работать,лично для меня

 

RubiN,
я все понял.
Вы идиот

 

--

 

он просто такой же студент как и я, по сути, не нашедший пока по каким то причинам - столь же конкретного как ты применения своему мозгу). За что ты его так... Надо фактами, теорией давить. Если получиться)