MySQL 4.1.0

Наконец-то IN появился!! Ура!

Успехов, MySQL team!!!

Несчастные люди :) Радуются тому что наконец-то появились вложенные запросы. Сколько у вас еще этих радостей впереди :) Блин, поставьте вы Postgres хотя бы чтобы попробовать - там есть все.

о, добрый человек попался. жалеет всех Ж)

Эххх. А когда это счастье на хостингах появится? Так по опыту могу предположить, что годика через два-три :(

IceD

x-term, а че сразу не САПДБ, например ? у мускула и постгреса все-таки разные весовые категори. И достоинства-недостатки имеются и у того и у другого. Уж бля, сколько раз эту тему обсасывали, а все неймется.

>Блин, поставьте вы Postgres хотя бы чтобы попробовать - там есть все.

Угу. Только вот если надо например человеку сайтик сделать, а денег на хостинг с постгресом денег жаба душит давать, что делать?

IceD

Господа - кто сведущ - подскажите неумному мне - тут упоминалось про OpenGIS - очень бы хотелось мне iPAQ + linux familiar задействовать для просмотра карт (в походе) = не знаю с какой стороны подойти / - у меня есть снимки в проприетарном формате - на вьювлетах - а ПО только для винды

Извините за офтопик

Карлсон

PostgreSQL - рулез форева, а MySQL сколько не разрабатывай - как говном был так и останется!

Oracle - это действительно руль!!!

iceD Насчет весовых категорий Сколько может потянуть постргес записей ? (mysql миллион или чуть больше)

сервер 3 петнтиум колическтво пользователей около 50 основная операция select distinct atr from table where A=1 AND B=2 AND ... N=M order by atr ;

Сколько не читал различные комментарии к новостям , так поражает одно ,какой бы новость не была пусть даже самой нужной, так найдется какой то красноглазый урод , который возможно вообще в жизни ничего полезного не сделал, так все обосрет ! Нафига тогда вообще нужны комментарии ?

Как можно говорить что "Mysql говно" тысячи людей использую и нормально Просто для обычных баз достаточно тех элементов что есть в sql. А вот если уж нужна настояжая реляционная база то уж лучше Interbase, Oracle.

Да я вроде не кого не обижал (чегой то ты взялся)

> Сколько не читал различные комментарии к новостям , так поражает одно ,какой бы новость не была пусть даже самой нужной, так найдется какой то красноглазый урод , который возможно вообще в жизни ничего полезного не сделал, так все обосрет !

Угу, пришел ты и предыдущих обосрал. Об чем и речь.

Вот сча еще кто-нить вылезет и скажет, что M$SQL Server рулит...

IceD

Урааа! По числу фич скоро догонит MS Access 95 :)

Урааа! По числу фич скоро догонит MS Access 95 :)

>iceD Насчет весовых категорий Сколько может потянуть постргес >записей ? (mysql миллион или чуть больше)

Я с большой буквы пишусь ;)

Насчет мускля - вам на sourceforge - насколько я знаю у них сча самая большая мускль база - спросите - мож ответят.

Насчет постгреса - у меня больше 500000 не было, так что точно сказать не могу :) Но была замечена тенденция, что чем больше база тем больше приимущества постгреса перед мукслем.

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

IceD

s/приимущества/преимущества/

IceD

IceD

У меня будет порядка 3-4 миллионов записей и я почему-то думаю mesql не потянет этого ...

2 anonymous (*) (2003-04-17 16:15:58.395318)

Слушай, даун:

А по числу обрабатываемых записей только ХРеновый acce$$ иожно сравнивать с MySQL 3.23

Выводы? Что важнее: фичи или ограничения на обрабатываемые объемы информации?

А теперь задай следующие параметры:

требования к времени отработки запроса, сложность запросов, количество запросов, железо на котором все это крутится.

В принципе на 6-7 миллионов записей MySQL работает.

Требования ко времени обработки порядка 5 секунд( не больше) сложность select distinct atr from table where A=1 AND B=2 AND ... N=M order by atr ; аппаратура сервер 3 петнтиум колическтво пользователей около 50

"Слушай, даун"

Как вы грубы молодой человек (вы также разговариваете со своими клиентами? Вы отрицаете существование синдрома дауна ... Чуть было не сказал У ВАС )

Фичи к коим вы отнесли вложеный запрос использовать уже не удасться заказчик неправильно поймет если ему предложить подождать пол годика до выхода стабильной версии поэтому они не используются (мне искренне жаль) А в через несколько месяцев когда база выростет до искомых 4 миллионов я скорее сменю mysql на постгресс

Круто типа...

Для 3-4 миллионов записей постгрес однозначно... Хотя на sourceforge думаю поболее будет.

IceD

Спасибо за разъяснения ! (ушел думать :)

MYSQL? HA SOURCEFORGE??? XEP TAM! IBM DB2!

Около 20 миллионов записей - на IP3 1GHz с выборкой типа select uin from old_list where mail like '%@hotmail.com' and uin < 1000000 занимает около одной секунды :) Таблица проиндексированна.
Так что степень кривизны мускуля лучше расматривайте как кривизну своих рук.

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

GHhost

Ни один массовый хостинг postgres не потянет из-за низкого его КПД. Пока postgress сделает один запрос, mysql успеет 10. Дело
вовсе не в деньгах. И то, и другое бесплатно.

Вот это вот результаты на примерно 60 миллионах записей.

http://www.eweek.com/slideshow/0,3670,p=1&a=23120&po=1&i=1,00.asp

Вот здесь текстовка к этим тестам:

http://www.eweek.com/article2/0,3959,293,00.asp

Это было примерно год назад, использовался mysql 4.0. Кстати тогда постгресу тоже предлагали поучаствовать. Они отказались.

А испытания проводилиь конторой, которую трудно заподозрить в симпатиях к mysql и opensource вообще.

> x-term, а че сразу не САПДБ, например ? А причем тут SAP DB - насколько я читал проего фичи, так ему до Postgres "как до Шанхая босиком".

SadAlex.

Нужно еще учесть, что тест проводился под виндой, где mysql
значительно медленнее, чем под линуксом. Можно смело помножить
результаты mysql в 1.5-2 раза. И в итоге все ближайшие
конкуренты торчат в очень очень глубокой ж.

x-term

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

imho, мускул лучший сервер в своей нише, оракл - в своей, а вот где лучший постгресс - не понятно, ни с тем ни с другим он сравниться не может..

Лучше сразу все возможности встроить в БД (SQL стандарт),
а потом постепенно оптимизировать. Тогда и клиентам не надо
будет переписывать свой софт.
Как я понимаю, так сделали в Mozilla.

2 anonymous (*) (2003-04-17 18:06:29.19723)

>Как вы грубы молодой человек (вы также разговариваете со своими клиентами? Вы отрицаете существование синдрома дауна ... Чуть было не сказал У ВАС )

Да, в дурном расположении духа я не расположен к излишне вежливому обращению.

Относительно фич: давайте загоним в Acce$$ 95 базу раза в 2 меньше той, что обрабатывается MySQL 3.23 и посмотрим как Acce$$ будет работать с ней.

NiKel (*) (2003-04-18 05:03:33.657464):

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

ежели бы разработчики mozilla тебя слушали, то у нас бы щас был самый быстрый в мире браузер с поддержкой HTML 3.0 А через полтора года, в версии 5.0 обещалась бы начальная поддержка CSS. ;

и что характерно, была бы ещё и толпа недоумков, которые кричали бы, что от css, javascript и прочего --- торможение одно, и никому они нафиг не нужны.

> imho, мускул лучший сервер в своей нише

угу, но эта ниша называется "хостинг за 5 баксов" :D

walrus (*) (2003-04-17 21:49:34.97047):

> Вот это вот результаты на примерно 60 миллионах записей.

Нет там ни слова о 60 миллионах записей... А тесты явно мысклеводами делались: 1) Тестирование по(д)строено так, чтобы все базы на чём-то обламывались, кроме MySQL (неродная платформа, неродные интерфейсы доступа). 2) Для одного MySQL проделано больше оптимизаций, чем для всего остального. 2) В исходниках тестов нет ни одно запроса более чем по двум таблицам --- то есть делается только то, что MySQL хорошо умеет делать.

> Кстати тогда постгресу тоже предлагали поучаствовать. Они отказались.

Во-первых, источник?

Во-вторых, у Постгреса родная версия под винду будет только в 7.4. Хотел бы посмотреть, как Microsoft согласились бы на тестирование, где MS SQL пускали бы через Wine под Linux'ом...

> А испытания проводилиь конторой, которую трудно заподозрить в симпатиях к mysql и opensource вообще.

Зато в симпатии к деньгам за заказуху очень даже можно... ;

<цитата> Нет там ни слова о 60 миллионах записей...</цитата>

по условиям того тестирования обьем таблиц должен быть не менее толи двух толи трех обьемов ОЗУ (не помню уже точно), чтобы снизить влияние кэширования. А так как машинка у них там толстенькая использовалась, то организаторы подсчитали - сколько в какой таблице должно быть записей. То что было именно 60 миллионов - я знаю из личной переписки с организаторами.

<цитата> А тесты явно мысклеводами делались: 1) Тестирование по(д)строено так, чтобы все базы на чём-то обламывались, кроме MySQL (неродная платформа, неродные интерфейсы доступа).</цитата>

У вас что-то с логикой. Родная платформа (и самая быстрая) для mysql - linux. Тестирование было под windows 2000 advanced server. Интерфейс, который был использован для доступа - jdbc driver - это была 3-rd party продукция. То есть "левая" для mysql. На тот момент mysql не имел родного jdbc драйвера.

<цитата>2) Для одного MySQL проделано больше оптимизаций, чем для всего остального. </цитата>

SQL Server and MySQL were the easiest to tune, and Oracle9i was the most difficult because it has so many separate memory caches that can be adjusted.

По субьективным ощущениям участников - большего всего времени на настройку потратили для sybase (сразу предвосхищая вопрос - данные из личной переписки с участниками)

<цитата> В исходниках тестов нет ни одно запроса более чем по двум таблицам --- то есть делается только то, что MySQL хорошо умеет делать.</цитата>

Схемы баз и схема тестирования была разработана _до_ того как было принято решение пригласить mysql ab для тестирования. по крайней мере в приглашении эти схемы _уже_ были.

<цитата> > Кстати тогда постгресу тоже предлагали поучаствовать. Они отказались. Во-первых, источник? </цитата>

Личная переписка с организаторами. А отказались они AFAIK - именно по той причине, которую вы указали - под windows у них застой. И мне кстати очень жаль, что они не принимали участие, потому. что по предварительным прикидкам - они бы обогнали многие толстые и снобистски настроенные коммерческие базы.

<цитата>Зато в симпатии к деньгам за заказуху очень даже можно... ;</цитата>

Если вы имеете в виду главного спонсора - то AFAIK он и победил в том тесте. А mysql туда был приглашен "за компанию" (предвосхищая вопрос об источнике - кулуарные разговоры во время тестрования)

> угу, но эта ниша называется "хостинг за 5 баксов" :D

Популярность - не порок :)

С другой стороны, для некоторых сайтов нужна именно скорость мускула - они ни на что другое его не поменяют даже если им за это доплачивать :)

Если я буду делать интенсивные вычисления и гонять по сети сотни тысяч или миллионы строк простых запросов - то я бы даже от оракала отказался в пользу mysql. Именно это и есть настоящая его ниша. Фичастость сервера баз данных - это дополнительное удобство программеру и админу. Но в некоторых случаях если это происходит за счет скорости - нафиг надо. Можно обойтись без подзапросов, внешних ключей и поддержки целостности. Программер если надо может это сделать и проследить за этим сам - если ему нужен качественный и быстрый компонент для его инфосистемы то нередко им оказывается именно mysql.
.. или я, например, иногда cgi на С делаю и этих случаях вся фичастость и удобство php мне даром не нужна.. с базами порой также..

3 goda rabotal s mysql. Vse' prosto i udobno. Zatem resyl poprobovat' postgresql, t.k. nuzno bylo razrabatyvat' ne prostoj websajt a celyj intranet. Pona4alu trudno i nemnogo neprivy4no bylo.. no popol'zovavshys' im god.. uze o mysql ne ho4eca dumat'. Edinstvenno do sih por nikak ne svyknuca s nekotorymi veshami, kotorye v mysql byli proshe, agregatnye zaprosy tipa: [ select a.*,count(b.bid) from a left join b using(aid) group by a.aid ] v mysql-e rabotali bezotkazno.. v to vremja, kak v postgresql-e, nado v group by pere4isljat' vse field-y. A esli ih 30-at'? Parit nemnogo.

gw

select a.*,count(b.bid) from a left join b using(aid) group by a.aid

можно переписать в виде

SELECT a.*, b_count
FROM a LEFT JOIN (
SELECT aid, COUNT(bid)
FROM b
GROUP BY aid
) AS b_group USING (aid)

эээ... в примере запроса COUNT(bid) следует читать как COUNT(bid) AS b_count

walrus (*) (2003-04-18 18:01:28.649729):

> А отказались они AFAIK - именно по той причине, которую вы указали - под windows у них застой.

Застоя как раз нет, порт под win32 будет в следующей стабильной версии, беты можно скачать уже щас.

> А mysql туда был приглашен "за компанию" (предвосхищая вопрос об источнике - кулуарные разговоры во время тестрования)

Я осознал, что мне ещё в той статье не нравится: абзацы про замечательные фичи MySQL, при отсутствии абзацев про таковые фичи других баз:

MySQL 4.0.1's new, extremely fast query cache is also quite notable, as no other database we tested had this feature. If the text of an incoming query has a byte-for-byte match with a cached query, MySQL can retrieve the results directly from the cache without compiling the query, getting locks or doing index accesses. This query caching will be effective only for tables with few updates because any table updates that clear the cache to guarantee correct results are always returned.

Очень всё это похоже на пиар довольно сомнительной фичи - встроенного кэша. Особенно учитывая: When we tested without this cache, MySQL's performance fell by two-thirds.

NiKel (*) (2003-04-19 00:35:26.140932)

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

Вся проблема в том, что в любой другой СУБД вычисления можно засунуть внутрь базы и перестать трахать сеть 'сотнями тысяч или миллионами строк простых запросов'.

> Но в некоторых случаях если это происходит за счет скорости - нафиг надо.

Мысль о том, что это происходит за счёт скорости усиленно продвигается в одном месте --- в маркетинговой пропаганде... эээ... документации MySQL.

> Можно обойтись без подзапросов, внешних ключей и поддержки целостности. Программер если надо может это сделать и проследить за этим сам

Программеру придётся делать это во всех интерфейсах доступа и внимательно следить, чтобы пользоваться могли только ими. А что бедный програмер будет делать, когда в базе появится финансовый документ от 31 февраля (вполне нормальная дата с т.з. MySQL) или отрицательная зарплата (слова CHECK MySQL не понимает)?

> или я, например, иногда cgi на С делаю и этих случаях вся фичастость и удобство php мне даром не нужна.. с базами порой также..

PHP и C отличаются граздо сильнее, чем MySQL и прочие СУБД. Тут корректно было бы упомянуть какую-нибудь berkeley db.

Я бы другое сравнение привёл: вместо C использовать "ускоренную" версию PHP --- без поддержки массивов и без else в if. ;

<цитата>Вся проблема в том, что в любой другой СУБД вычисления можно засунуть внутрь базы и перестать трахать сеть 'сотнями тысяч или миллионами строк простых запросов'. </цитата>

надеюсь вы себе отдаете отчет, что "засунутые" внутрь базы вычисления будут _интерпретироваться_. И если вы попросите свою СУБД выдать вам миллион значений - интерпретация будет самым проигрышным вариантом по скорости.

Кроме того, я думаю все СУБД программисты ощущают на определенном этапе эйфорию от триггеров и хранимых процедур, и почти все вслед за этим закономерно перегружают свою базу триггерами и убеждаются, что все стало работать очень медленно. Гораздо медленнее, чем в случае прописанного на С buisness layer application, который и должен выполнять эту работу.

Дело базы - хранить данные. И mysql справляется с этим на 5+

По поводу - "гонять данные по сети". если вы будете гонять данные по unix socket или named pipe - нагрузка будет не больше чем в случае обычного IPC. Или кстати можно просто встроить mysql сервер в свое приложение.

<цитата> > Но в некоторых случаях если это происходит за счет скорости - нафиг надо.

Мысль о том, что это происходит за счёт скорости усиленно продвигается в одном месте --- в маркетинговой пропаганде... эээ... документации MySQL.

</цитата>

Практика - критерий истины. mysql обьективно быстрее большинства других DBMS

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

почему в _интерфейсах_? а не в интерфейсе? Если у вас это, скажем, гостевая книга - тогда конечно проще сделать PHP странички, которые будут напрямую лезти в базу данных. Но если это что-то более серьезное - пишете EJB или CORBA или даже rpc (xmlrpc) сервер, который _один_ лезет в базу. Все клиенты работают через него. Такой сервер способен делать проверки _лучше_, чем (по вашей терминологии) "засунутые" в СУБД процедуры.

<цитата>А что бедный програмер будет делать, когда в базе появится финансовый документ от 31 февраля (вполне нормальная дата с т.з. MySQL) или отрицательная зарплата (слова CHECK MySQL не понимает)? </цитата>

то же самое, что и в случае если зарплата окажется на 50 копеек больше, чем должна быть. Отлаживать логику своих программ. И кстати - для standalone программ это несоизмеримо проще, чем для "всунутых" в СУБД.

<цитата> Застоя как раз нет, порт под win32 будет в следующей стабильной версии, беты можно скачать уже щас. </цитата>

тестирование было год назад, и на тот момент не было реальных перспектив получить быстро версию postgres под win с функциональностью родной версии postgres. Было что - то работающее через cygwin, но видимо по оценке самих постгресовцев - недостаточно хорошее. Еще раз повторю - мне жаль, что postgres не участвовал.

<цитата> Я осознал, что мне ещё в той статье не нравится: </цитата>

Это ваше право - иметь свое мнение по поводу статьи.

2 anonymous (*) (2003-04-19 21:45:51.999825): Ja tak i delaju. No skorost' takogo zaprosa ne o4en'...