| 1.1, Аноним (-), 22:17, 30/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
замечу, что в php упор сделан на mysql, и его либа теперь вылизана и отточена, в отличие от либы для постгре. это всего лишь значит что надо еше дорабатывать | | |
| |
| 2.10, Dvorkin (??), 10:31, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
 ты хоть понял че сказал?
как можно вылизать простой вызов API Postgres или MySQL.
просто линкуется либа и просто вызывается функция. как в обычном приложении. что можно оптимизировать? если и возможен где-то момет оптимизации, так это при fetch(PGSQL_ASSOC), да и то несущественно в глобальном смысле | | |
|
| 1.2, Анонимоус (?), 22:43, 30/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А что вы скажете про Java? :)
Хотя по-моему тестировать надо одинаковом окружении.А то Java сама по себе тот еще тормоз - может, не DB виновата то была? | | |
| |
| 2.14, KuT (?), 11:35, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
 Ктото слабо ориентируется в вопросе. Ява конечно может и тормознее C как прикладной язык -
такова плата за кроссплатформенность. Но не сильно. А вот супротив PHP/Perl и пр. Java
просто реактивный самолет против кукуризника. Вот только почему сравнивали PHP+MySQL с Java+Oracle и Java+DB2 мне не ясно. Гонки между белазами и феррари никому веть в голову не приходит устраивать - задачи у этих машин разные и возможности. | | |
| |
| 3.31, Анонимоус (?), 18:40, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– | |
А как тогда кукурузник натянул реактивный самолет?Получается, что Оракл и DB2 ваще настолько лохи что даже Java их не спасла??? | | |
| |
| 4.34, KuT (?), 20:45, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
Мерили всетаки производительность работы с базой данных а не просто производительность.
И вообще-то, да, Oracle и DB2 медленнее, чего собственно никто и не скрывает. Еще раз повторяю это "тяжелые" базы данных, по своим возможностям превосходящие mysql на порядок. Они принципиально для других вещей сделаны. Сравнивать их просто некорректно. Тем более некорректно сравнивать связку MySQL/PHP со связкой Java/Oracle. Кто-нибуть видел чтоб на java+oracle Вася Пупкин домашнюю страничку рисовал ? | | |
|
|
|
| |
| 2.25, Квагга (?), 14:29, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Рызултаты того, что вы называете "сравнению производительности СУБД" - в стюдию!!!
Неужели тяжело ссылку сюда кинуть???
А почему? Почему так тяжело? | | |
|
| 1.4, ТинПу (?), 03:53, 31/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Ха-ха ... значит постгрес в двадчать раз медленее? Ха-ха ... это _как_ же его надо бояться чтоб такое писать! А боятся правильно - постгре скоро всех зарулит! No doubt. | | |
| |
| 2.26, Квагга (?), 14:31, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Ха-ха ... значит постгрес в двадчать раз медленее? Ха-ха ... это _как_
>же его надо бояться чтоб такое писать! А боятся правильно -
>постгре скоро всех зарулит! No doubt.
Не надо бояться Постгреса, не надо.
Надо ссылочку сюда бросить. Если есть.
| | |
|
| 1.6, dimus (??), 07:21, 31/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Я уверен, что это не постгрес медленный, а у кого-то руки не тем концом и не туда приделаны. | | |
| |
| 2.27, Квагга (?), 14:32, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Я уверен, что это не постгрес медленный, а у кого-то руки не
>тем концом и не туда приделаны.
Вы просто не работали с БЫСТРОЙ базой.
И плохо понимаете, насколько My5 уделывает Постгреса и Оракла.
| | |
| |
| 3.33, CGen (?), 19:03, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– | |
А где, кроме примитивных баз для web можно его использовать? | | |
| |
| 4.35, Dvorkin (??), 22:54, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– | |
>А где, кроме примитивных баз для web можно его использовать?
его отлично можно использовать, например, как высокозагруженный источник данных для Оракл
где Оракл сосет из Мускуля результаты работы клиентов и прокручивает через частично реализованную в себе бизнес-логику, поверх которой например работает биллинг, написанный на чем угодно. отличная схема распределения нагрузки для больших систем
| | |
| |
| 5.37, Квагга (?), 23:04, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Нужно сказать, что неспроста Оракал вдруг заделался Експрессом и вообще в 100 раз снизил цены лицензий. Корячится ему кабзда. Ровно такая, какая пришла Нетвари. Чмякс - и мокрое место.
| | |
| 5.44, sauron (??), 11:49, 01/09/2006 [^] [^^] [^^^] [ответить]
| +/– |
 >его отлично можно использовать, например, как высокозагруженный источник данных для Оракл
>где Оракл сосет из Мускуля результаты работы клиентов и прокручивает через частично
>реализованную в себе бизнес-логику, поверх которой например работает биллинг, написанный на
>чем угодно. отличная схема распределения нагрузки для больших систем
Чем ? У вас может стать узким местом мост между 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. | | |
| |
| 6.45, Dvorkin (??), 13:14, 01/09/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Чем ? У вас может стать узким местом мост между mysql и
>Oracle. MySQL на данный момент не годится для серьезных проектов. Извините,
>но СУБД у которой только в 5 версии появились хранимые процедуры
>это мягко говоря та еще фигня.
мне не нужны хранимые процедуры, мне не нужны сложные GROUP BY и пр. мне нужны простые быстрые селекты, апдейты и инсерты. например, несколько моих мускулей обслуживают каждый около тысячи порстых запросов в секунду. часть результатов периодически переливается в Оракл, где есть все и неспешно пропускается через хранимые процедуры и прочую лабуду.
позвольте уж мне из _собственного_ _реального_ опыта создания и поддержки таких систем судить о том, что я утверждаю | | |
| |
| 7.46, sauron (??), 15:17, 01/09/2006 [^] [^^] [^^^] [ответить]
| +/– |
>мне не нужны хранимые процедуры, мне не нужны сложные GROUP BY и
>пр. мне нужны простые быстрые селекты, апдейты и инсерты.
Как только они станут нужны вы выкините MySQL.
>например, несколько моих мускулей обслуживают каждый около тысячи порстых запросов в секунду.
У меня один столько лопатит. Но только с InnoDB и после тюнинга. Т.к. у базы в 100гиг в MyISAM слетают индексы. А InnoDB этим не страдает. Но и его надо тюнить надо иначе тормозит.
>часть результатов периодически переливается в Оракл, где есть все и неспешно пропускается
>через хранимые процедуры и прочую лабуду.
А почему сразу не обрабатывать и передавать в Оракл?
>позвольте уж мне из _собственного_ _реального_ опыта создания и поддержки таких систем
>судить о том, что я утверждаю
Позвольте мне так же судить из собственного реального опыта. Для очень простых вещей укладывающихся в SQL89 можно использовать MySQL. Для более сложных нет.
| | |
| |
| |
| 9.50, sauron (??), 17:06, 01/09/2006 [^] [^^] [^^^] [ответить] | +/– | Вопрос в другом Нужен ли вообще mysql покажите мне где в OSI используется прот... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 2.32, Анонимоус (?), 18:42, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Btw, а дефолты - решают.Если у вас идиотские дефолты, вашу систему обосрут все с ног до головы.И будут правы. | | |
|
| 1.7, Nikolay (??), 09:43, 31/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
придурки, больше это никак не обзовёшь
ни движок майскла не указан, ни конфигурация железок, ни конфигурация софта.
идиотский пиар | | |
| 1.9, Pasystem (?), 10:28, 31/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Согласен mysql быстрая база, но pgsql не может настолько отставать в производительности,
надо было немного серьезней отнестись к этому,
сначала бы выбрали спецов для настройки pgsql :|
| | |
| 1.11, Dvorkin (??), 10:37, 31/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
вот когда разработчики постгреса озаботятся дефолтным тюнингом, тогда и пищщите...
а пока что при все свободе выбора я либо куплю Oracle под Линукс либо буду счаслив с MySQL 5 и ее гениальной простотой. | | |
| 1.12, dvarkin (?), 10:59, 31/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Гон на постер - вывод из всего прочитанного. Все равно кто знает его не променяет. | | |
| |
| 2.13, Dvorkin (??), 11:09, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Гон на постер - вывод из всего прочитанного. Все равно кто знает
>его не променяет.
а кто не знает - лучше не знать. спокойней спать, калега :) особенно когда знаешь что чтобы перенести БД на другой mysql-сервак нужно просто скопировать файл по rsh. это очень способствует здоровому сну, расслаблению в руках и ногах, холодной голове и крепости члена при занатиях сексом с женой
| | |
| |
| 3.15, Grand piano (?), 11:44, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
 Это если у вас MyISAM, колллега, а если InoDB, то с простым копированием вы идёте лесом мелкими шажками, Вы людям голову то не морочьте, простым копированием... мдя.
Лично мне не хватает от мускула только внутреннего шедулера, как в Оракле да и в Постгре уже давное реализовано. Ну придётся ждать. Да и кластеризация пока что не супер реализована, много ручного гемора, хотя и достаточно эффективно, ничего не скажешь.
Так что, не знаю, то что победила связка php+mysql в принципе показывает только то, что авторы теста хорошо оттюнинговали данную связку, а остальное взлетали на дефолте.
| | |
| |
| 4.17, walrus (?), 11:59, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
 цитата из документации для тех кто думает что ему морочат голову:
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. | | |
| |
| 5.18, Grand piano (?), 12:02, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>цитата из документации для тех кто думает что ему морочат голову:
>
>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 вагон инфы, НЮ НЮ. А ещё, ооочень хорошо, когда у тебя кластер, НЮ НЮ...
| | |
| |
| 6.19, walrus (?), 12:57, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– | |
По порядку:
1) если с базой активно работают, то и myisam не рекомендуется копировать "по живому". innodb ничем в этом от myisam не отличается. Хотя есть способы закопировать консистенто и базу, которая в работе.
2) binary logs в mysql просто хранят информацию о последних insert/updates/deletes и никак не связаны ни с транзакциями ни с консистентностью базы. Причем здесь binary logs вообше? Обьясните, каким образом по вашему мнению binary logs могут помешать копированию.
3) mysql кластер это отдельная storage engine, никак не связанная ни с myisam, ни с innodb. Почему когда я вам пишу про то что innodb _можно_ копировать, вы мне отвечаете про кластер? Каким от тут вообще боком? | | |
| |
| 7.22, Grand piano (?), 13:29, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>По порядку:
>
>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 человек убеждает в обратном. Как то прям непонятно, да и ни фига не приятно. | | |
| |
| 8.23, yarick (?), 14:03, 31/08/2006 [^] [^^] [^^^] [ответить] | +/– | То есть, продолжаем читать между строк, что копируем базу данных при работающем ... текст свёрнут, показать | | |
|
|
| 6.20, Dvorkin (??), 13:09, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>>цитата из документации для тех кто думает что ему морочат голову:
>>
>>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 вагон инфы, НЮ НЮ. А ещё,
>ооочень хорошо, когда у тебя кластер, НЮ НЮ...
как-то вы мыслите в терминах Постгреса больше... :)
| | |
| 6.21, yarick (?), 13:19, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– | |
о да, конечно, предлагалось копировать файлы базы данных при _работающем_ mysqld, желательно очень сильно нагружающем копируемую базу. Как же это я сразу не догадался.
> Это если у вас MyISAM, колллега, а если InoDB, то с простым копированием вы идёте лесом
> мелкими шажками, Вы людям голову то не морочьте, простым копированием... мдя.
Трудно признать свою неправоту, коллега? | | |
|
|
| 4.24, Dvorkin (??), 14:25, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Это если у вас MyISAM, колллега, а если InoDB, то с простым
>копированием вы идёте лесом мелкими шажками, Вы людям голову то не
>морочьте, простым копированием... мдя.
>Лично мне не хватает от мускула только внутреннего шедулера, как в Оракле
>да и в Постгре уже давное реализовано. Ну придётся ждать. Да
>и кластеризация пока что не супер реализована, много ручного гемора, хотя
>и достаточно эффективно, ничего не скажешь.
>Так что, не знаю, то что победила связка php+mysql в принципе показывает
>только то, что авторы теста хорошо оттюнинговали данную связку, а остальное
>взлетали на дефолте.
вам не надоело спорить ради спора?
если вы никогда не проделывали операцию экстренного переноса баз, что я вам буду обьяснять? это можно только почувствовать :). вы со своим постресом и базами на несколько гигов если ваш сервак нагнется будете в полной жопе и до секса у вас (простите за каламбур) руки дойдут еще не скоро после всех этих нудных дампов и ресторов | | |
|
| 3.29, A (?), 17:23, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– | |
не знаю как там в MySQL, но в PostgreSQL делаете таким же образом, только копируете в простейшем случае (если tablespace-ы не раскиданы по разным дискам) 2 каталога - tablespace и wal - лог. те же яйца (одна команда), только с tar-ом. те же яйца и для db2 и для Informix и для Oracle ( если базуха не в raw storage ) . Что с успехом проделывалось лично и неоднократно. так что ваше все - мимо кассы.
| | |
| |
| 4.30, Dvorkin (??), 18:01, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>не знаю как там в 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? куча какой-то херни раскидано по каталогам | | |
|
| 3.47, bodun (?), 16:08, 01/09/2006 [^] [^^] [^^^] [ответить]
| +/– |
>>Гон на постер - вывод из всего прочитанного. Все равно кто знает
>>его не променяет.
>
>а кто не знает - лучше не знать. спокойней спать, калега :)
>особенно когда знаешь что чтобы перенести БД на другой mysql-сервак нужно
>просто скопировать файл по rsh. это очень способствует здоровому сну, расслаблению
>в руках и ногах, холодной голове и крепости члена при занатиях
>сексом с женой
Холодные копии можно и в oracle делать.
То-же самое без остановки базы сделайте ;) | | |
| |
| 4.48, Dvorkin (??), 16:34, 01/09/2006 [^] [^^] [^^^] [ответить]
| +/– |
>То-же самое без остановки базы сделайте ;)
вы это сказали ради того чтобы что-то сказать? | | |
| |
| 5.55, bodun (?), 17:57, 02/09/2006 [^] [^^] [^^^] [ответить]
| +/– |
 >>То-же самое без остановки базы сделайте ;)
>вы это сказали ради того чтобы что-то сказать?
Я это говорю, к тому, что преимущество таскать по rsh файлы mysql яица выеденного не стоит.
По поводу темы. Хорошо сработал PR отдел MySQL AB в связке с c't Magazine. Можно их с этим поздравить.
| | |
|
|
|
|
| 1.16, SubGun (??), 11:50, 31/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах MySQL уделает всех. Однако как только база становится сложней по структуре,запросы становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных.
Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что у них по четыре ноги. Они же для разных целей. | | |
| |
| 2.36, Dvorkin (??), 23:00, 31/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах
>MySQL уделает всех. Однако как только база становится сложней по структуре,запросы
>становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных.
>Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что
>у них по четыре ноги. Они же для разных целей.
абсолютно верное замечание. тем не менее, я бы предпочел использовать максимально простую и производительную систему для простых вещей (MySQL) и максимально фичанутую (Oracle) для сложной бизнес-логики. Постгрес - ни то ни се. | | |
| |
| 3.38, KuT (?), 01:18, 01/09/2006 [^] [^^] [^^^] [ответить]
| +/– |
>>Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах
>>MySQL уделает всех. Однако как только база становится сложней по структуре,запросы
>>становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных.
>>Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что
>>у них по четыре ноги. Они же для разных целей.
>
>абсолютно верное замечание. тем не менее, я бы предпочел использовать максимально простую
>и производительную систему для простых вещей (MySQL) и максимально фичанутую (Oracle)
>для сложной бизнес-логики. Постгрес - ни то ни се.
А покупать Oracle для бизнес логикы вы намеряны ? | | |
| |
| 4.39, Dvorkin (??), 09:54, 01/09/2006 [^] [^^] [^^^] [ответить]
| +/– |
>>>Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах
>>>MySQL уделает всех. Однако как только база становится сложней по структуре,запросы
>>>становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных.
>>>Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что
>>>у них по четыре ноги. Они же для разных целей.
>>
>>абсолютно верное замечание. тем не менее, я бы предпочел использовать максимально простую
>>и производительную систему для простых вещей (MySQL) и максимально фичанутую (Oracle)
>>для сложной бизнес-логики. Постгрес - ни то ни се.
>
>
>А покупать Oracle для бизнес логикы вы намеряны ?
почему намерЕны? он куплен
| | |
|
| 3.40, Ezh (??), 10:17, 01/09/2006 [^] [^^] [^^^] [ответить]
| +/– | |
"максимально фичанутую" - смешно :) ярко выраженный клиент интегратора, который обещает, что SQL у Вас будет SQLистей, а логика логичнее, если конечно вы ему отдадите своё бабло. Обожаю людей с чужими деньгами, которые хотят не что-то конкретное, а просто "максимально фичанутое". Райское удовольствие их разра... с ними работать.
По теме - бред это сравнение. Любая эксклюзивная разработка требует тонкого тюнинга БД в зависимости от характера работы. Postgres в дефолтной конфигурации вообще никакой. Планировщик у него очень капризный и настраивать его нужно под конкретную базу, исходя из статистики работы. Зато сложная выборка из таблицы в 3,5-4 млн записей с кучей полей где GROUP BY делаем по одной части, а ORDER BY делаем по другой, WHERE по остальным полям - занимает у posgres до тюнинга несколько минут!!!, после создание составных индексов "по учебнику" около минуты, после создания индексов в соответствии с "капризами" планировщика, оптимизации весов, тюнингов буферов - менее 50ms. На мускуле подобная табличка обрабатывалась после недельной борьбы за скорость в соответствии с лучшими best practics за 150ms, зато другие операции просто летали, не спорю. IMHO Pg медленнее мускуля в простых запросах, но не более чем на 10%-20%, а не на порядки!!! как написано.
Дефолтные настройки у Pg правильные - они возволяют всего лишь запустить базу чтоб хоть как-то работало, другого и не надо. В качестве примера есть огромные (несколько Тб) астрологические и биологические базы которые довольно шустро шуршат под Pg. Аффторам сравнения - яда, чтобы своими опусами наивных людей не смущали :-)
| | |
| |
| 4.41, Dvorkin (??), 10:26, 01/09/2006 [^] [^^] [^^^] [ответить]
| +/– |
>"максимально фичанутую" - смешно :) ярко выраженный клиент интегратора, который обещает, что
>SQL у Вас будет SQLистей, а логика логичнее, если конечно вы
>ему отдадите своё бабло. Обожаю людей с чужими деньгами, которые хотят
>не что-то конкретное, а просто "максимально фичанутое". Райское удовольствие их разра...
>с ними работать.
жаба давит на моск? | | |
| |
| 5.42, Loky (?), 11:06, 01/09/2006 [^] [^^] [^^^] [ответить]
| +/– |
>>"максимально фичанутую" - смешно :) ярко выраженный клиент интегратора, который обещает, что
>>SQL у Вас будет SQLистей, а логика логичнее, если конечно вы
>>ему отдадите своё бабло. Обожаю людей с чужими деньгами, которые хотят
>>не что-то конкретное, а просто "максимально фичанутое". Райское удовольствие их разра...
>>с ними работать.
>
>жаба давит на моск?
Dvorkin, мой Вам респект! Один из немногих homo sapiens среди homo haljavikus :)
Позволю себе выразить своем скромное мнение.
С каждым днем посетители когда-то мной уважаемого OpenNet все больше похожи на детей в песочнице, выясняющих у кого совочек больше и ведерко глужбе, и все это на фоне проезжающих мимо карьерных самосвалов.
Еще немного и OpenNet потеснит с первого места anekdot.ru в рейтинге развлекательных сайтов. К сожалению...
| | |
| |
| 6.52, fa (??), 18:50, 01/09/2006 [^] [^^] [^^^] [ответить]
| +/– |
 >С каждым днем посетители когда-то мной уважаемого OpenNet все больше похожи на детей в >песочнице, выясняющих у кого совочек больше и ведерко глужбе, и все это на фоне проезжающих >мимо карьерных самосвалов.
>Еще немного и OpenNet потеснит с первого места anekdot.ru в рейтинге развлекательных сайтов. К сожалению...
Простите за оффтоп, но такое мнение проскакивало уже несколько раз, что, мол, OpenNet тупеет, зеленеет и т.д. На самом деле "тупение" аудитории - неизбежное следствие роста популярности ЛЮБОГО проекта. Представьте, что у Вас в форуме ежедневно постят 5 "жестких мачо" и 100 "зеленых новичков". Если популярнасть сайта увеличится, скажем, в 100 раз, туда начнут постить 500 "мачо" и 10000 "новичков". В результате эти 500 просто начнут теряться в огромной зеленой массе, и, если Вы один из тех пяти "мачо", кто стоял у истоков, конечно начнете думать "куда катится мир", "одни неучи вокруг" и т.д., хотя соотношение "мачо" к "новичкам" будет таким же, как и на старте проекта. | | |
|
|
|
|
|
|
