Сравнение PostgreSQL vs MySQL

Не ограничение, а масштабируется почти *линейно*. Т.е. при большом числе одновременных запросов удваиваешь кол-во процессоров - получаешь двухкратный (почти!) прирост производительности.

После 16-ти процессоров постгрес начинает утыкаться в блокировки. Но MySQL утыкается намного раньше.

>а я не могу уважать СУБД у которой нет транзакций

Чего-чего?

>То есть это следствие версионности?

Versionnij postgres. Eto sledstvie blokirovs4ika. V PG ty mojesh v transakcii delat' alter(drop) table i ne paritsia. Poprobuj provernut' takoe v mysql.

PS: sorry - translit.ru iz pacavatoj UK ne pinguetsia.

>а как можно уважать СУБД которая стопорит сервер на время вакума?

Niza4et - tolko vo vremia "vacuum full" i ne server stopit a lockaet table.

>После 16-ти процессоров постгрес начинает утыкаться в блокировки. Но MySQL утыкается намного раньше.

бред. время, ожидания ресурса ("проведенное на блокировке") прямо пропорционально количеству процессов (потоков) ожидающих этот ресурс. количество процессоров здесь по барабану.

А почему нет флейма насчет тог очто ядро 2.6.18 дает прибавку в 20% запросто так (простым обновлением ядра) относительно 2.6.15

О чем это говорит? что всё что 2.6.15 было кривым поделием? (20% это ж дофига!)

>а то я с год юзаю транзакции и процедурки пишу под него, а тут оказалось что он их не поддерживает.

a na perle slabo? ;))

Ну будет он рвать, на выборке из таблицы в 15 строк, а на выборке из 9 таблиц с кучей объединений и при одной таблице с 20 млн строк, а в других от полутора до двух млн рвать будет постгрес. Что из этого, задачи у баз данных разные. Где-то мускуль, где-то постгрес, где-то виндус, а где-то линукс и фрибсд. Очередной спор -- что лучше рыба или мясо.

Ни фига не бред. Вот представь *идеализированную* ситуацию: 16 ресурсов на 128 процессов. Каждому процессу нужен один и только один ресурс. Кол-во выполняемых единомоментно процессов ограничивается либо кол-вом CPU (если их меньше 16) либо кол-вом ресурсов.

Вот и получаем, что до 16 процессоров производительность разтет линейно - далее не растет вообще. В реальной жизни все, конечно, сложнее, но принцип такой же.

>бред. время, ожидания ресурса ("проведенное на блокировке") прямо пропорционально количеству процессов (потоков) ожидающих этот ресурс. количество процессоров здесь по барабану.

ne bred. processori staviatsia ne dlia kolorita a 4tobi uveli4it' proizvoditelnost' - to est' uveli4it' kolli4estvo potokov kotorie budut prosit' etot samij resurs. A kak ty verno zametil ot 4ego zavisit eto vremia - potomu u blikirovs4ika buden nabludatsia degradation proizvoditelnosti pri uveli4ennii nagruzki soprovojdajemoj uveli4eniem processorov dlia obrabotki onoj.

откуда ты это взял?

r - юзай tor(http://tor.eff.org/documentation), и достучишься тогда до транстлита..

> курите ссылку до посинения, потом делайте выводы: http://bugs.mysql.com/bug.php?id=15815

> на однопроцессорных и двухпроцессорныхя системах mysql рвал и будет
> рвать постргрес. И на многопроцессорных(многоядерных) с выходом этого
> патча тоже. Вы не забыли что mysql, например, легко держит больше 1000
> соединений и десятки тысяч таблиц в базе?

наконец кто-то в теме, хоть и анонимус!
меня ломало искать ссылку на этот баг, а между тем именно в нем и дело. интересно будет посмотреть, насколько улучшится ситуация для MySQL с этим патчем.

>Для очередного Васи Пупкина киньте ссылкой на мануал по тюнингу производительности PostgreSQL (если в стандартной документации -- то не кидайте) :) Заранее благодарен

А конфиг открыть не судьба? Или там тарабарщина написана?

>легко держит больше 1000 соединений и десятки тысяч таблиц в базе

Я бы сказал и более сотни тысяч таблиц тоже тянет.

http://www.opennet.ru/opennews/art.shtml?num=8895

который ссылается на :

http://www.mysql.com/news-and-events/news/article_1181.html

сомневаюсь только в одном, что это будет под лицензией GPL.

> Следуя ваше логике получается, что все эти ядра нафиг не нужны, зря их делают...

Грубо говоря, если 1 запрос занимает одну секунду времени и предполагаемая/реальная нагрузка на сервер не превышает 1 запрос в секунду, то да - многопроцессорные системы для этого нафиг не нужны.

А если предполагаемая/реальная нагрузка превышает 1 запрос в секунду ? :)

PS. Под каждую задачу свой набор оборудования и софта. Для сайта на тему "Я и моя собака" хватит и электронной записной книжки MySQL.

>>а я не могу уважать СУБД у которой нет транзакций
> есть..

Жжошь :)
Ну ка, давай набодяжим создание/изменение структуры/удаление чего-нибудь в отдельной транзакции, а потом дружно откатимся на исходное состояние. Вот когда мускул сумеет это сделать, тогда можжно говорить, что у него появились нормальные транзакции. То, что есть сейчас - недоделка "для галочки".

>>и процедурного языка. - зачем?
> логику в базе писать?

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

Вот скажите мне, любители MySQL....

Есть у меня таблица mytable с двумя полями, ID int, primary key, и 
text_data TEXT, я хочу построить по полю TEXT полнотекстовый индекс. 

Делаю, я, значится, таблицу типа MyISAM:
CREATE TABLE mytable
(
   id INT NOT NULL,
   text_data TEXT,
   primary key(id),
   fulltext(text_data)
);

А еще я хочу сделать FOREIGN KEY, который ссылается на mytable(ID).
Да вот беда, низзя сделать FOREIGN KEY на таблицу типа MyISAM. 
Точнее, можно, да вот толку от этого ноль.

Ну и у меня вопрос: когда такой бардак закончится?

ээээхъ.... а еще про крутизну мускля рассуждаете.

Вот почему у меня а полнотекстовыми индексами нет проблем в Постгресе? И почему в MySQL все так плохо?

P.S. Вынести проверку FK в пррриложение не предлагать, ламеры идут на йух.

use InnoDB MyISAM не для этого

>use InnoDB MyISAM не для этого

Отличный совет. Просто великолепный. Теперь расскажите общественности, как по тексчтовому полю в InnoDB таблице построить FULLTEXT индекс?

А что тут проблемного?

В документации на сайте мускула даже примеры были.

Криво конечно, хотелось бы удобства, но.. я выношу в отдельную таблицу то, по чему надо делат fulltext. потом LEFT JOIN USING (id).

По ссылкам не нашел какой именно storage engine использовался в MySQL. Кто-нибудь обнаружил? Без этой инфы мало что сказать можно. По оптимизации MySQL есть хороший сайтик: http://mysqlperformanceblog.com/

> а я на sqlite и мне все до .....

Мне бы тоже его хватило, но блин, не работают lower/upper в utf8

> > легко держит больше 1000 соединений и десятки тысяч таблиц в базе

> Я бы сказал и более сотни тысяч таблиц тоже тянет.

Я бы завершил все это фразой, что цианистый калий однозначно лучше всего поможет проектировщику этой базы.

> use InnoDB MyISAM не для этого

а почему по дефолту предлагается MyISAM?

1) Комментарии данных тестов на блоге MySQL Performance: http://www.mysqlperformanceblog.com/2006/11/30/interesting-mysql-and-postgres...

2) Несколько советов по оптимизации PostgreSQL в приложениях (PostgreSQL Application Performance Tips):

PostgreSQL Application Performance Tips, Part 1 - http://blogs.ittoolbox.com/print.asp?i=13172

PostgreSQL Application Performance Tips, Part 2 - http://blogs.ittoolbox.com/print.asp?i=13194

>Я бы завершил все это фразой, что цианистый калий однозначно лучше всего поможет проектировщику этой базы

а причем тут проектировщику? это как правило хостер...

> в реале же (у нас) постоянные тормоза, перешли на мускул. и у нас мускул порвал постгрес как тузик грелку.. и памяти меньше жрал и работал быстрее...

Так базу проектировать сначала надо =)

> небольшой оффтоп - а никто не сравнивал SQLite 3 и MySQL 4.1 на _простых_ запросах (SELECT из одной табл, UPDATE туда же - и так мого раз в секунду) - что из этого будет по быстродействию лучше? А то есть задачка, мучаюсь с выбором. постгрес по ряду причин не пододит.

Berkley DB для простых манипуляций с данным в data storage используй - обоих (mysql и pgsql) порвёт на порядок.

>А что тут проблемного?

>В документации на сайте мускула даже примеры были.

Учите матчасть, чтобы не подставляться.

Full-text indexes can be used only with MyISAM tables, and can be created only for CHAR, VARCHAR, or TEXT columns.

http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html

> Вы не забыли что mysql, например, легко держит больше 1000 соединений и десятки тысяч таблиц в базе?

это же насколько кривыми должны быть руки у пректировщика БД, чтобы держать в одной базе 10k сущностей ?

про 1k коннектов скромно умолчим. потому что руки у тех, кто проектировал приложения, даже ещё более кривые, чем у предыдущего "проектанта".

>на однопроцессорных и двухпроцессорныхя системах mysql рвал и будет рвать >постргрес. И на многопроцессорных(многоядерных) с выходом этого патча тоже. Вы >не забыли что mysql, например, легко держит больше 1000 соединений и десятки >тысяч таблиц в базе?

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

Да, прочтешь вот такое вот обсуждение, и начинаешь понимать что в этой стране 1С еще долго будет находить свои жертвы.

а как кстати с фуллтекстиндексом в постгресе? раньше tsearch2 был просто не просто. надо было долго шаманить пока такой индекс начинал работать. сделали ли это так же просто как в MyISAM?

> сделали ли это так же просто как в MyISAM?

нет, и врядли сделают. объяснить почему ?

>а почему по дефолту предлагается MyISAM?

чтобы пионеры, слабавшие базу и позапускавшие скриптом SELECT * FROM table 100000 раз, поняли бы, что MySQL быстр :)

да.

>Дайте угадаю: настройки PostgreSQL были по умолчанию?

Как можно относиться к продукту, разработчики которого уже много лет не могут прописать оптимальные значения настроек по умолчанию? Сколько лет уже этот аргумент звучит...

> Как можно относиться к продукту, разработчики которого уже много лет > не могут прописать оптимальные значения настроек по умолчанию? > Сколько лет уже этот аргумент звучит...

Оптимальные для какой задачи? Каких объемов данных? Сколько доступно оперативки? Сколько еще сервисов кроме БД крутится на сервере? Сколько и какие винты?

Достаточно вопросов чтобы понять что абстрактых оптимальных настроек не существует? ИМХО postgreSQL делает правильно, что задает дефолтные настройки работающий в любой конфигурации и дает подробные разъяснения по поводу оптимизации. Иначе будет складываться ложное ощущение, что у тебя все оптимально.

Ты gentoo ставишь с настройками по-умолчанию?
Или все же руки и голову прикладываешь?

>Как можно относиться к продукту, разработчики которого уже много лет не могут прописать оптимальные значения настроек по умолчанию? Сколько лет уже этот аргумент звучит...

Оптимальные значения ДЛЯ КАКОГО РОДА ЗАДАЧ?

Оптимальные значения ДЛЯ КАКОЙ ОС?

Оптимальные значения ДЛЯ КАКОЙ НАГРУЗКИ?

Оптимальные значения ДЛЯ КАКОГО ЖЕЛЕЗА?

Любая современная СУБД требует настройки перед использованием.

> Как можно относиться к продукту, разработчики которого уже много лет не могут прописать оптимальные значения настроек по умолчанию? Сколько лет уже этот аргумент звучит...

Ну вообще-то логика такова: никто не знает на какое железо встанет эта программа. Цель БД работать - настройки такие, чтобы смогло завестись абсолютно везде. А кому нужна скорость должен озадачится и прочитать настроечный файл.

>Любая современная СУБД требует настройки перед использованием.

Ага, т.е. mysql - это не современная СУБД? :) В смысле, что широчайший набор задач определяется настройкой менее, чем десятка параметров, при чём с подачей образцов под 4..5 типичных конфигураций. Так что с БД с довольно оптимальной производительностью можно начать работать сразу после запуска. Вот у меня сейчас сервер обрабатывает в среднем за сутки по 800 запросов в секунду, из которых 65% - update. Пиковая нагрузка, полагаю, раза в два выше - всё это на практически дефолтном конфиге.

Ну, ладно...

>Ну вообще-то логика такова: никто не знает на какое железо встанет эта программа. Цель БД работать - настройки такие, чтобы смогло завестись абсолютно везде.

Неужели так сложно приложить десяток типовых оптимальных конфигураций? И не было бы тогда многолетнего повторения той же самой мантры - "А, Вы опять запускали на дефолтовом конфиге!" - смешно...

>Как можно относиться к продукту, разработчики которого уже много лет не могут прописать оптимальные значения настроек по умолчанию? Сколько лет уже этот аргумент звучит...

А вы любезный считаете что это влзможно ("прописать оптимальные значения настроек по умолчанию")? Oracle или Informix или DB2 или что там у вас тоже гоняете с настройками по умолчанию? прежде чем говорить не мешает иногда поумать мозгом и желательно головным, если таковой есть в наличии.

не смешите мои тапочки :) mysql современная субд на уровне oracle/db2 80x :)))

>Ага, т.е. mysql - это не современная СУБД? :) В смысле, что широчайший набор задач определяется настройкой менее, чем десятка параметров, при чём с подачей образцов под 4..5 типичных конфигураций.

MySQL 5 находится где-то посередине между уровнем PostgreSQL 7.0.3 и Oracle 6. Еще три-пять лет и функционал доведут до PostgreSQL 8. При этом, разумеется, чуда не случится и хваленая скорость MySQL еще уменьшится.