форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[Проследить за развитием треда]

"OpenNews: MySQL победил на соревновании по производительност..."

Сообщение от opennews on 30-Авг-06, 22:17

MySQL занял первое место (http://www.mysql.com/news-and-events/press-release/release_2006_35.html) в соревновании организованном журналом "C’T magazine". В качестве теста оценивалась скорость обслуживания заявок в  виртуальном интернет-магазине (http://firebird.sourceforge.net/connect/ct-dbContest.html). Общие результаты (http://www.mysqlperformanceblog.com/2006/08/29/mysql-wins-ct-database-contest/): -  MySQL5/PHP: 3664 заказов в минуту (opm); -  DB2/Java : 1537 opm; -  Oracle / Java: 1412 opm; -  PostgreSQL / PHP: 120 opm (не опечатка); Следует заметить, что специалистам по тюнингу MySQL удалось (http://www.mysqlperformanceblog.com/2006/08/29/mysql-wins-ct-database-contest/) на том же оборудовании достичь значения в 7000 opm для MySQL5/PHP. Скорее всего низкий результат для PostgreSQL обусловлен использованием конфигурации по умолчанию, не предназначенной для нагруженных серверов. URL: http://www.mysql.com/news-and-events/press-release/release_2006_35.html Новость: http://www.opennet.me/opennews/art.shtml?num=8249

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Сообщения по теме

[Сортировка по времени, UBB]

1. "MySQL победил на соревновании по производительности СУБД"

Сообщение от Аноним on 30-Авг-06, 22:17

замечу, что в php упор сделан на mysql, и его либа теперь вылизана и отточена, в отличие от либы для постгре. это всего лишь значит что надо еше дорабатывать

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	5. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Аноним on 31-Авг-06, 06:11
	И placeholder'ы есть?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	10. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 31-Авг-06, 10:31
	ты хоть понял че сказал? как можно вылизать простой вызов API Postgres или MySQL. просто линкуется либа и просто вызывается функция. как в обычном приложении. что можно оптимизировать? если и возможен где-то момет оптимизации, так это при fetch(PGSQL_ASSOC), да и то несущественно в глобальном смысле
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

2. "MySQL победил на соревновании по производительности СУБД"

Сообщение от Анонимоус on 30-Авг-06, 22:43

А что вы скажете про Java? :) Хотя по-моему тестировать надо одинаковом окружении.А то Java сама по себе тот еще тормоз - может, не DB виновата то была?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	14. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от KuT on 31-Авг-06, 11:35
	Ктото слабо ориентируется в вопросе. Ява конечно может и тормознее C как прикладной язык - такова плата за кроссплатформенность. Но не сильно. А вот супротив PHP/Perl и пр. Java просто реактивный самолет против кукуризника. Вот только почему сравнивали PHP+MySQL с Java+Oracle и Java+DB2 мне не ясно. Гонки между белазами и феррари никому веть в голову не приходит устраивать - задачи у этих машин разные и возможности.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	31. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Анонимоус on 31-Авг-06, 18:40
	А как тогда кукурузник натянул реактивный самолет?Получается, что Оракл и DB2 ваще настолько лохи что даже Java их не спасла???
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	34. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от KuT on 31-Авг-06, 20:45
	Мерили всетаки производительность работы с базой данных а не просто производительность. И вообще-то, да, Oracle и DB2 медленнее, чего собственно никто и не скрывает. Еще раз повторяю это "тяжелые" базы данных, по своим возможностям превосходящие mysql на порядок. Они принципиально для других вещей сделаны. Сравнивать их просто некорректно. Тем более некорректно сравнивать связку MySQL/PHP со связкой Java/Oracle. Кто-нибуть видел чтоб на java+oracle Вася Пупкин домашнюю страничку рисовал ?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

3. "MySQL победил на соревновании по производительности СУБД"

Сообщение от СергейК (??) on 30-Авг-06, 23:12

Этот конкурс не имеет ровным счетом никакого отношения к сравнению производительности СУБД (это сравнение разных решений написаных разными ~ случайными людьми, из которых серьезная только команда разработчиков MYSQL AB) Рекомендую поглядеть: http://groups.google.com/group/pgsql.general/browse_frm/thread/35d3bfd8951a94d4/bd7f4571b4a07055#bd7f4571b4a07055

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	25. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Квагга on 31-Авг-06, 14:29
	Рызултаты того, что вы называете "сравнению производительности СУБД" - в стюдию!!! Неужели тяжело ссылку сюда кинуть??? А почему? Почему так тяжело?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

4. "MySQL победил на соревновании по производительности СУБД"

Сообщение от ТинПу on 31-Авг-06, 03:53

Ха-ха ... значит постгрес в двадчать раз медленее? Ха-ха ... это _как_ же его надо бояться чтоб такое писать! А боятся правильно - постгре скоро всех зарулит! No doubt.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	26. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Квагга on 31-Авг-06, 14:31
	>Ха-ха ... значит постгрес в двадчать раз медленее? Ха-ха ... это _как_ >же его надо бояться чтоб такое писать! А боятся правильно - >постгре скоро всех зарулит! No doubt. Не надо бояться Постгреса, не надо. Надо ссылочку сюда бросить. Если есть.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

6. "MySQL победил на соревновании по производительности СУБД"

Сообщение от dimus (??) on 31-Авг-06, 07:21

Я уверен, что это не постгрес медленный, а у кого-то руки не тем концом и не туда приделаны.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	27. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Квагга on 31-Авг-06, 14:32
	>Я уверен, что это не постгрес медленный, а у кого-то руки не >тем концом и не туда приделаны. Вы просто не работали с БЫСТРОЙ базой. И плохо понимаете, насколько My5 уделывает Постгреса и Оракла.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	33. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от CGen on 31-Авг-06, 19:03
	А где, кроме примитивных баз для web можно его использовать?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	35. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 31-Авг-06, 22:54
	>А где, кроме примитивных баз для web можно его использовать? его отлично можно использовать, например, как высокозагруженный источник данных для Оракл где Оракл сосет из Мускуля результаты работы клиентов и прокручивает через частично реализованную в себе бизнес-логику, поверх которой например работает биллинг, написанный на чем угодно. отличная схема распределения нагрузки для больших систем
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	37. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Квагга on 31-Авг-06, 23:04
	Нужно сказать, что неспроста Оракал вдруг заделался Експрессом и вообще в 100 раз снизил цены лицензий. Корячится ему кабзда. Ровно такая, какая пришла Нетвари. Чмякс - и мокрое место.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	44. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от sauron (??) on 01-Сен-06, 11:49
	>его отлично можно использовать, например, как высокозагруженный источник данных для Оракл >где Оракл сосет из Мускуля результаты работы клиентов и прокручивает через частично >реализованную в себе бизнес-логику, поверх которой например работает биллинг, написанный на >чем угодно. отличная схема распределения нагрузки для больших систем Чем ? У вас может стать узким местом мост между mysql и Oracle. MySQL на данный момент не годится для серьезных проектов. Извините, но СУБД у которой только в 5 версии появились хранимые процедуры это мягко говоря та еще фигня. Насчет java+oracle все зависит от задачи и того как производилась оптимизация запросов и собственно как писали на java. Если же писать как на php то собственно ничего удивительного. PS Кстати ознакомьтесь: http://caucho.com/resin-3.1/quercus/ Рекомедую обратить внимание на: Performance: Quercus outperforms a straight mod_php implementation by about 4x (for Mediawiki and Drupal). Quercus roughly matches PHP performance with accelerators like APC.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	45. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 01-Сен-06, 13:14
	>Чем ? У вас может стать узким местом мост между mysql и >Oracle. MySQL на данный момент не годится для серьезных проектов. Извините, >но СУБД у которой только в 5 версии появились хранимые процедуры >это мягко говоря та еще фигня. мне не нужны хранимые процедуры, мне не нужны сложные GROUP BY и пр. мне нужны простые быстрые селекты, апдейты и инсерты. например, несколько моих мускулей обслуживают каждый около тысячи порстых запросов в секунду. часть результатов периодически переливается в Оракл, где есть все и неспешно пропускается через хранимые процедуры и прочую лабуду. позвольте уж мне из _собственного_ _реального_ опыта создания и поддержки таких систем судить о том, что я утверждаю
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	46. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от sauron (??) on 01-Сен-06, 15:17
	>мне не нужны хранимые процедуры, мне не нужны сложные GROUP BY и >пр. мне нужны простые быстрые селекты, апдейты и инсерты. Как только они станут нужны вы выкините MySQL. >например, несколько моих мускулей обслуживают каждый около тысячи порстых запросов в секунду. У меня один столько лопатит. Но только с InnoDB и после тюнинга. Т.к. у базы в 100гиг в MyISAM слетают индексы. А InnoDB этим не страдает. Но и его надо тюнить надо иначе тормозит. >часть результатов периодически переливается в Оракл, где есть все и неспешно пропускается >через хранимые процедуры и прочую лабуду. А почему сразу не обрабатывать и передавать в Оракл? >позвольте уж мне из _собственного_ _реального_ опыта создания и поддержки таких систем >судить о том, что я утверждаю Позвольте мне так же судить из собственного реального опыта. Для очень простых вещей укладывающихся в SQL89 можно использовать MySQL. Для более сложных нет.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	49. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 01-Сен-06, 16:46
	> Как только они станут нужны вы выкините MySQL. в той части, в которой работает мускуль, хранимые процедуры и пр. не понадобятся никогда :) это достаточно разумно спроектированная система. > А почему сразу не обрабатывать и передавать в Оракл? знаете, это как с протоколами OSI > Позвольте мне так же судить из собственного реального опыта. Для очень простых вещей > укладывающихся в SQL89 можно использовать MySQL. Для более сложных нет. а я считаю что при проектировании надо задумываться о будущем, стремиться сделать максимально просто и максимально быстро и пр. разделить, найти общие точки. так, чтобы одну подсистему можно было безопасно перепроектировать в случае необходимости и чтобы отказ одной не повлиял на остальные части. не буду растекаться мыслью по древу, но считаю что любую систему можно спроектировать так, чтобы она сотояла из максимально простых элементов
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	50. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от sauron (??) on 01-Сен-06, 17:06
	>понадобятся никогда :) это достаточно разумно спроектированная система. Вопрос в другом. Нужен ли вообще mysql. >знаете, это как с протоколами OSI покажите мне где в OSI используется протоколом аналогичный протокол. Не совсем удачное сравнение. >а я считаю что при проектировании надо задумываться о будущем, стремиться сделать >максимально просто и максимально быстро и пр. разделить, найти общие точки. Это зависит от системы. Если в процессе развития системы мне приходится менять СУБД или добавлять СУБД это может говорить о не правильно выбраной СУБД или же ошибке проектирования. >так, чтобы одну подсистему можно было безопасно перепроектировать в случае необходимости >и чтобы отказ одной не повлиял на остальные части. Не совсем понятно зачем при этом использовать MySQL. Или сразу агрегировать данные не что-то не позволяет? >но считаю что любую систему можно спроектировать >так, чтобы она сотояла из максимально простых элементов Систему надо проектировать так чтобы она масштабировалась и видозименялась без особых проблем.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	51. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 01-Сен-06, 18:22
	>>понадобятся никогда :) это достаточно разумно спроектированная система. >Вопрос в другом. Нужен ли вообще mysql. ... >Не совсем понятно зачем при этом использовать MySQL. Или сразу агрегировать данные >не что-то не позволяет? да. мне нужен риалтайм на нижнем уровне
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	54. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от sauron (??) on 02-Сен-06, 08:50
	А теперь вопрос почему СУБД MySQL а не агрегация данных в памяти ? PS Использование СУБД MySQL не даcт реалтайм в правильном понимании этого слова.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	56. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 03-Сен-06, 01:09
	>А теперь вопрос почему СУБД MySQL а не агрегация данных в памяти многова-то для RAM. да и проще запрограммировать >PS Использование СУБД MySQL не даcт реалтайм в правильном понимании этого слова. я понимаю :) если у меня есть простой и очень быстрый инструмент под рукой - молоток. а еще есть молоток, с несколькими наконечниками и двигающейся ручкой... и если я второй молоток правильно настрою (по инструкции и подумавши), то получу такую же скорость забивания, как у первого. поскольку для забивания гвоздей форме 8-ки у меня уже есть специальный электрический лазерный сертифицированный для забивания согнутых в виде 8-ки, 9-ки и 10-ки гвоздей агрегат, у меня останется два инструмента. угадайте, какие?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	32. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Анонимоус on 31-Авг-06, 18:42
	Btw, а дефолты - решают.Если у вас идиотские дефолты, вашу систему обосрут все с ног до головы.И будут правы.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

7. "MySQL победил на соревновании по производительности СУБД"

Сообщение от Nikolay (??) on 31-Авг-06, 09:43

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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

8. "MySQL победил на соревновании по производительности СУБД"

Сообщение от Аноним on 31-Авг-06, 10:19

Не одидал встретить на opennet такой низкосортный материал

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

9. "MySQL победил на соревновании по производительности СУБД"

Сообщение от Pasystem on 31-Авг-06, 10:28

Согласен mysql быстрая база, но pgsql не может настолько отставать в производительности, надо было немного серьезней отнестись к этому, сначала бы выбрали спецов для настройки pgsql :|

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

11. "OpenNews: MySQL победил на соревновании по производительност..."

Сообщение от Dvorkin (??) on 31-Авг-06, 10:37

вот когда разработчики постгреса озаботятся дефолтным тюнингом, тогда и пищщите... а пока что при все свободе выбора я либо куплю Oracle под Линукс либо буду счаслив с MySQL 5 и ее гениальной простотой.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	53. "OpenNews: MySQL победил на соревновании по производительност..."
	Сообщение от northbear (??) on 01-Сен-06, 22:19
	Неужели у вас и Oracle и MySQL используются с дефолтными настройками?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

12. "MySQL победил на соревновании по производительности СУБД"

Сообщение от dvarkin on 31-Авг-06, 10:59

Гон на постер - вывод из всего прочитанного. Все равно кто знает его не променяет.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	13. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 31-Авг-06, 11:09
	>Гон на постер - вывод из всего прочитанного. Все равно кто знает >его не променяет. а кто не знает - лучше не знать. спокойней спать, калега :) особенно когда знаешь что чтобы перенести БД на другой mysql-сервак нужно просто скопировать файл по rsh. это очень способствует здоровому сну, расслаблению в руках и ногах, холодной голове и крепости члена при занатиях сексом с женой
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	15. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Grand piano on 31-Авг-06, 11:44
	Это если у вас MyISAM, колллега, а если InoDB, то с простым копированием вы идёте лесом мелкими шажками, Вы людям голову то не морочьте, простым копированием... мдя. Лично мне не хватает от мускула только внутреннего шедулера, как в Оракле да и в Постгре уже давное реализовано. Ну придётся ждать. Да и кластеризация пока что не супер реализована, много ручного гемора, хотя и достаточно эффективно, ничего не скажешь. Так что, не знаю, то что победила связка php+mysql в принципе показывает только то, что авторы теста хорошо оттюнинговали данную связку, а остальное взлетали на дефолте.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	17. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от walrus on 31-Авг-06, 11:59
	цитата из документации для тех кто думает что ему морочат голову: Like MyISAM data files, InnoDB data and log files are binary-compatible on all platforms having the same floating-point number format. You can move an InnoDB database simply by copying all the relevant files listed in Section 14.2.8, “Backing Up and Recovering an InnoDB Database”. If the floating-point formats differ but you have not used FLOAT or DOUBLE data types in your tables, then the procedure is the same: simply copy the relevant files.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	18. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Grand piano on 31-Авг-06, 12:02
	>цитата из документации для тех кто думает что ему морочат голову: > >Like MyISAM data files, InnoDB data and log files are binary-compatible on >all platforms having the same floating-point number format. You can move >an InnoDB database simply by copying all the relevant files listed >in Section 14.2.8, “Backing Up and Recovering an InnoDB Database”. If >the floating-point formats differ but you have not used FLOAT or >DOUBLE data types in your tables, then the procedure is the >same: simply copy the relevant files. Ню Ню. особенно если у теюя с базой активно работают, и если у тебя в binary logs вагон инфы, НЮ НЮ. А ещё, ооочень хорошо, когда у тебя кластер, НЮ НЮ...
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	19. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от walrus on 31-Авг-06, 12:57
	По порядку: 1) если с базой активно работают, то и myisam не рекомендуется копировать "по живому". innodb ничем в этом от myisam не отличается. Хотя есть способы закопировать консистенто и базу, которая в работе. 2) binary logs в mysql просто хранят информацию о последних insert/updates/deletes и никак не связаны ни с транзакциями ни  с консистентностью базы. Причем здесь binary logs вообше? Обьясните, каким образом по вашему мнению binary logs могут помешать копированию. 3) mysql кластер это отдельная storage engine, никак не связанная ни с myisam, ни с innodb. Почему когда я вам пишу про то что innodb _можно_ копировать, вы мне отвечаете про кластер? Каким от тут вообще боком?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	22. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Grand piano on 31-Авг-06, 13:29
	>По порядку: > >1) если с базой активно работают, то и myisam не рекомендуется копировать >"по живому". innodb ничем в этом от myisam не отличается. Хотя >есть способы закопировать консистенто и базу, которая в работе. > >2) binary logs в mysql просто хранят информацию о последних insert/updates/deletes и >никак не связаны ни с транзакциями ни  с консистентностью базы. >Причем здесь binary logs вообше? Обьясните, каким образом по вашему мнению >binary logs могут помешать копированию. > >3) mysql кластер это отдельная storage engine, никак не связанная ни с >myisam, ни с innodb. Почему когда я вам пишу про то >что innodb _можно_ копировать, вы мне отвечаете про кластер? Каким от >тут вообще боком? Можно вопрос: А нафига мне копировать базу в которой не внесены последние изменения??? Консистентно, опять же, простым копированием??? Да может я и не прав, по поводу InnoDB, однако, по всем рекомендациям самого MySQL AB они не рекомендуют работать с таблицами формата InnoDB простым копированием. (Смотрим книгу "Администрирование MySQL (c) MySQL Press 2005) Кластер... Вот тут можно сказать только одно - либо я дурак, то же кстати возможно, либо читая документацию я не вижу, что у меня binary logs связаны с механизмом репликации связан как "Отче наш", и все разговоры о том, что это не так, должны быть чётко подтверждены документацией. Странно, всегда считал, что понимаю как это работает, и оно так, казалось, и работало, однако меня уже 4 человек убеждает в обратном. Как то прям непонятно, да и ни фига не приятно.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	23. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от yarick on 31-Авг-06, 14:03
	>А нафига мне копировать базу в которой не внесены последние изменения??? >Консистентно, опять же, простым копированием??? То есть, продолжаем читать между строк, что копируем базу данных при работающем демоне ? На "slave"-е, который в данный момент получает обновления ? >Да может я и не прав, по поводу InnoDB, однако, по всем >рекомендациям самого MySQL AB они не рекомендуют работать с таблицами формата >InnoDB простым копированием. (Смотрим книгу "Администрирование MySQL (c) MySQL Press 2005) Ссылку на документацию приводили? Чем не понравилась? Онтосительно рекомендаций. Не рекомендуется делать, если не понимаешь что делаешь. Перезапускать сервера тоже не рекомендуется.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	28. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от walrus on 31-Авг-06, 15:11
	>Кластер... Вот тут можно сказать только одно - либо я дурак, то >же кстати возможно, либо читая документацию я не вижу, что у >меня binary logs связаны с механизмом репликации связан как "Отче наш", Стоп! Я понял! Вы считаете что репликация и кластер - это одно и тоже. На самом деле это различные вещи, которые и реализуются по разному. PS кстати binary logs файлы тоже безпроблемно копируются.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	20. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 31-Авг-06, 13:09
	>>цитата из документации для тех кто думает что ему морочат голову: >> >>Like MyISAM data files, InnoDB data and log files are binary-compatible on >>all platforms having the same floating-point number format. You can move >>an InnoDB database simply by copying all the relevant files listed >>in Section 14.2.8, “Backing Up and Recovering an InnoDB Database”. If >>the floating-point formats differ but you have not used FLOAT or >>DOUBLE data types in your tables, then the procedure is the >>same: simply copy the relevant files. > >Ню Ню. особенно если у теюя с базой активно работают, и если >у тебя в binary logs вагон инфы, НЮ НЮ. А ещё, >ооочень хорошо, когда у тебя кластер, НЮ НЮ... как-то вы мыслите в терминах Постгреса больше... :)
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	21. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от yarick on 31-Авг-06, 13:19
	о да, конечно, предлагалось копировать файлы базы данных при _работающем_ mysqld, желательно очень сильно нагружающем копируемую базу. Как же это я сразу не догадался. > Это если у вас MyISAM, колллега, а если InoDB, то с простым копированием вы идёте лесом > мелкими шажками, Вы людям голову то не морочьте, простым копированием... мдя. Трудно признать свою неправоту, коллега?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	24. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 31-Авг-06, 14:25
	>Это если у вас MyISAM, колллега, а если InoDB, то с простым >копированием вы идёте лесом мелкими шажками, Вы людям голову то не >морочьте, простым копированием... мдя. >Лично мне не хватает от мускула только внутреннего шедулера, как в Оракле >да и в Постгре уже давное реализовано. Ну придётся ждать. Да >и кластеризация пока что не супер реализована, много ручного гемора, хотя >и достаточно эффективно, ничего не скажешь. >Так что, не знаю, то что победила связка php+mysql в принципе показывает >только то, что авторы теста хорошо оттюнинговали данную связку, а остальное >взлетали на дефолте. вам не надоело спорить ради спора? если вы никогда не проделывали операцию экстренного переноса баз, что я вам буду обьяснять? это можно только почувствовать :). вы со своим постресом и базами на несколько гигов если ваш сервак нагнется будете в полной жопе и до секса у вас (простите за каламбур) руки дойдут еще не скоро после всех этих нудных дампов и ресторов
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	29. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от A on 31-Авг-06, 17:23
	не знаю как там в MySQL, но в PostgreSQL делаете таким же образом, только копируете в простейшем случае (если tablespace-ы не раскиданы по разным дискам) 2 каталога - tablespace и wal - лог. те же яйца (одна команда), только с tar-ом. те же яйца и для db2 и для Informix и для Oracle ( если базуха не в raw storage ) . Что с успехом проделывалось лично и неоднократно. так что ваше все - мимо кассы.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	30. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 31-Авг-06, 18:01
	>не знаю как там в MySQL, но в PostgreSQL делаете таким же >образом, только копируете в простейшем случае (если tablespace-ы не раскиданы по >разным дискам) 2 каталога - tablespace и wal - лог. те >же яйца (одна команда), только с tar-ом. те же яйца и >для db2 и для Informix и для Oracle ( если базуха >не в raw storage ) . Что с успехом проделывалось лично >и неоднократно. так что ваше все - мимо кассы. [root@xxx pgsql]# find ./data -type d ./data ./data/global ./data/pg_xlog ./data/pg_xlog/archive_status ./data/pg_clog ./data/pg_subtrans ./data/base ./data/base/1 ./data/base/17229 ./data/base/17230 ./data/base/17231 ./data/base/17231/pgsql_tmp ./data/base/17232 ./data/base/17233 ./data/base/1043832 ./data/base/3796972 ./data/pg_tblspc ./data/pg_log [root@xxx data]# du -d 1 222     ./global 114804  ./pg_xlog 26202   ./pg_clog 122     ./pg_subtrans 418576  ./base 2       ./pg_tblspc 2       ./pg_log 559958  . и где тут wal? куча какой-то херни раскидано по каталогам
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	47. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от bodun on 01-Сен-06, 16:08
	>>Гон на постер - вывод из всего прочитанного. Все равно кто знает >>его не променяет. > >а кто не знает - лучше не знать. спокойней спать, калега :) >особенно когда знаешь что чтобы перенести БД на другой mysql-сервак нужно >просто скопировать файл по rsh. это очень способствует здоровому сну, расслаблению >в руках и ногах, холодной голове и крепости члена при занатиях >сексом с женой Холодные копии можно и в oracle делать. То-же самое без остановки базы сделайте ;)
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	48. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 01-Сен-06, 16:34
	>То-же самое без остановки базы сделайте ;) вы это сказали ради того чтобы что-то сказать?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	55. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от bodun on 02-Сен-06, 17:57
	>>То-же самое без остановки базы сделайте ;) >вы это сказали ради того чтобы что-то сказать? Я это говорю, к тому, что преимущество таскать по rsh файлы mysql яица выеденного не стоит. По поводу темы. Хорошо сработал PR отдел MySQL AB в связке с c't Magazine. Можно их с этим поздравить.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

16. "MySQL победил на соревновании по производительности СУБД"

Сообщение от SubGun (??) on 31-Авг-06, 11:50

Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах MySQL уделает всех. Однако как только база становится сложней по структуре,запросы становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных. Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что у них по четыре ноги. Они же для разных целей.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	36. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 31-Авг-06, 23:00
	>Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах >MySQL уделает всех. Однако как только база становится сложней по структуре,запросы >становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных. >Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что >у них по четыре ноги. Они же для разных целей. абсолютно верное замечание. тем не менее, я бы предпочел использовать максимально простую и производительную систему для простых вещей (MySQL) и максимально фичанутую (Oracle) для сложной бизнес-логики. Постгрес - ни то ни се.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	38. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от KuT on 01-Сен-06, 01:18
	>>Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах >>MySQL уделает всех. Однако как только база становится сложней по структуре,запросы >>становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных. >>Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что >>у них по четыре ноги. Они же для разных целей. > >абсолютно верное замечание. тем не менее, я бы предпочел использовать максимально простую >и производительную систему для простых вещей (MySQL) и максимально фичанутую (Oracle) >для сложной бизнес-логики. Постгрес - ни то ни се. А покупать Oracle для бизнес логикы вы намеряны ?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	39. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 01-Сен-06, 09:54
	>>>Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах >>>MySQL уделает всех. Однако как только база становится сложней по структуре,запросы >>>становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных. >>>Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что >>>у них по четыре ноги. Они же для разных целей. >> >>абсолютно верное замечание. тем не менее, я бы предпочел использовать максимально простую >>и производительную систему для простых вещей (MySQL) и максимально фичанутую (Oracle) >>для сложной бизнес-логики. Постгрес - ни то ни се. > > >А покупать Oracle для бизнес логикы вы намеряны ? почему намерЕны? он куплен
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	40. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Ezh (??) on 01-Сен-06, 10:17
	"максимально фичанутую" - смешно :) ярко выраженный клиент интегратора, который обещает, что SQL у Вас будет SQLистей, а логика логичнее, если конечно вы ему отдадите своё бабло. Обожаю людей с чужими деньгами, которые хотят не что-то конкретное, а просто "максимально фичанутое". Райское удовольствие их разра... с ними работать. По теме - бред это сравнение. Любая эксклюзивная разработка требует тонкого тюнинга БД в зависимости от характера работы. Postgres в дефолтной конфигурации вообще никакой. Планировщик у него очень капризный и настраивать его нужно под конкретную базу, исходя из статистики работы. Зато сложная выборка из таблицы в 3,5-4 млн записей с кучей полей где GROUP BY делаем по одной части, а ORDER BY делаем по другой, WHERE по остальным полям - занимает у posgres до тюнинга несколько минут!!!, после создание составных индексов "по учебнику" около минуты, после создания индексов в соответствии с "капризами" планировщика, оптимизации весов, тюнингов буферов - менее 50ms. На мускуле подобная табличка обрабатывалась после недельной борьбы за скорость в соответствии с лучшими best practics за 150ms, зато другие операции просто летали, не спорю. IMHO Pg медленнее мускуля в простых запросах, но не более чем на 10%-20%, а не на порядки!!! как написано. Дефолтные настройки у Pg правильные - они возволяют всего лишь запустить базу чтоб хоть как-то работало, другого и не надо. В качестве примера есть огромные (несколько Тб) астрологические и биологические базы которые довольно шустро шуршат под Pg. Аффторам сравнения - яда, чтобы своими опусами наивных людей не смущали :-)
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	41. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 01-Сен-06, 10:26
	>"максимально фичанутую" - смешно :) ярко выраженный клиент интегратора, который обещает, что >SQL у Вас будет SQLистей, а логика логичнее, если конечно вы >ему отдадите своё бабло. Обожаю людей с чужими деньгами, которые хотят >не что-то конкретное, а просто "максимально фичанутое". Райское удовольствие их разра... >с ними работать. жаба давит на моск?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	42. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Loky on 01-Сен-06, 11:06
	>>"максимально фичанутую" - смешно :) ярко выраженный клиент интегратора, который обещает, что >>SQL у Вас будет SQLистей, а логика логичнее, если конечно вы >>ему отдадите своё бабло. Обожаю людей с чужими деньгами, которые хотят >>не что-то конкретное, а просто "максимально фичанутое". Райское удовольствие их разра... >>с ними работать. > >жаба давит на моск? Dvorkin, мой Вам респект! Один из немногих homo sapiens среди homo haljavikus :) Позволю себе выразить своем скромное мнение. С каждым днем посетители когда-то мной уважаемого OpenNet все больше похожи на детей в песочнице, выясняющих у кого совочек больше и ведерко глужбе, и все это на фоне проезжающих мимо карьерных самосвалов. Еще немного и OpenNet потеснит с первого места anekdot.ru в рейтинге развлекательных сайтов. К сожалению...
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	43. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от Dvorkin (??) on 01-Сен-06, 11:19
	сенькс
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	52. "MySQL победил на соревновании по производительности СУБД"
	Сообщение от fa (??) on 01-Сен-06, 18:50
	>С каждым днем посетители когда-то мной уважаемого OpenNet все больше похожи на детей в >песочнице, выясняющих у кого совочек больше и ведерко глужбе, и все это на фоне проезжающих >мимо карьерных самосвалов. >Еще немного и OpenNet потеснит с первого места anekdot.ru в рейтинге развлекательных сайтов. К сожалению...   Простите за оффтоп, но такое мнение проскакивало уже несколько раз, что, мол, OpenNet тупеет, зеленеет и т.д. На самом деле "тупение" аудитории - неизбежное следствие роста популярности ЛЮБОГО проекта. Представьте, что у Вас в форуме ежедневно постят 5 "жестких мачо" и 100 "зеленых новичков". Если популярнасть сайта увеличится, скажем, в 100 раз, туда начнут постить 500 "мачо" и 10000 "новичков". В результате эти 500 просто начнут теряться в огромной зеленой массе, и, если Вы один из тех пяти "мачо", кто стоял у истоков, конечно начнете думать "куда катится мир", "одни неучи вокруг" и т.д., хотя соотношение "мачо" к "новичкам" будет таким же, как и на старте проекта.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]