Сравнение 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.

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

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

a na perle slabo? ;))

Вот и получаем, что до 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.

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

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

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

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

Вот скажите мне, любители 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 в пррриложение не предлагать, ламеры идут на йух.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну, ладно...

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

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

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