Участники забега: PostgreSQL, MySQL, Oracle, Microsoft's SQL Server, и IBM's DB2 server.
Статья на английском языке, но (имхо) достаточно простая для чтения.
Both databases also support partial rollbacks of transactions...
Может я что-то не так понял, но "partial rollbacks of transactions" это
_неполный/частичный_ откат транзакций. Savepoints и вложенные транзакции в PostgreSQL отсутствуют (пока). Насчет My SQL не знаю.
Действительно, как-то напоминает махание руками в воздухе, сопровождаемоы выкрикиванием знакомых слов. Где хотя бы прикидочные цифры производительности? Где хотя бы примерные таблички с доступной/планируемой фунциональностью? Где рекомендации по использованию (их можно составить, если покопаться в тексте - но в явном, цельном виде я этого не увидел). Короче, текстик очень водянистый. К48 за такой "скришот" поставил бы 1.:)
Re: Re: Re: PostgreSQL vs. MySQL vs коммерческие СУБД
>Ну, скажем так, что есть параметры, по которым MySQL превосходит оракел.
>
>Например, с точки зрения вебдевелопера.
Ну, скажем так, что есть параметры, по которым DOS превосходит виндовс NT.
Статья ламерская. А сравнивать нужно, причем именно MySQL с Oracle и прочими. Чтобы знать, когда что лучше ставить и не соваться с Oracle делать базу с одной таблицей в пару десятков записей.
>я знаю пользователей имеющих более 5TB данных в MySQL
и чёж они с этими 5Тб делають? Хотел бы я посмотреть на тех идиотов которые такой объём доверяю MySQL приходит в голову только одно на х... эти данные никому не нужны. А вооще объём базы сам по себе мало о чём говорит. Хотя я не верю что Мускуль нормально справится с таким объёмом данных даже на очень простых запросах. Ну а на сложной выборке из множества связаных таблиц не дай бог с внешними объединениями Мускуль вооще умрёт.
Re: Re: Re: Re: PostgreSQL vs. MySQL vs коммерческие СУБД
Некоторые присутствующие похоже совсем не понимают о чем говорят,
В последний раз когда я колупал этот НеМойSQL (с год назад) он даже вложенные запросы не поддерживал. Никакими внешними объединениями там даже и не пахло, даже в Оракле внешние объединения не реализованы полностью, согласно стандарту SQL.
Какие 5ТВ базы? Где вы берете эти цифры?
В Oracle 9iR2 максимальный размер файла БД - 64Гб, хотя таких файлов м.б. 64К.
Может 5ТВ это суммарный размер всех мускульных баз какого-нибудь крупного провайдера, гы... это больше похоже.
Мускль создан для всяких вебдизайнеров, которые понятия не имеют даже о назначении индексов, и знать этого не хотят...
Re: Re: Re: Re: Re: PostgreSQL vs. MySQL vs коммерческие СУБД
ОДНОГО файла - может бюыть.... а что мешает сделать ДВА файла или ЧЕТЫРЕ файла или даже 10 файлов...
по моему объем базы дам орагничен что-то порядка 200 - 300 терафайт для 9-ки (не факт - лень смотреть), а вот в 10=ке так там макмимальный объем 10 ПЕТАбайт
мксмальная база данных пож ораклом в какой-то французской компании - порядка 150 терабайт (вчерась на конференции корпоративные СУБД был там преставительно оракла байки травил :-) )
А если вы считаете что база в оракл - это всегда ОДИН файл - мне вас жалко :-)
Хотя может я чего не понял - тогда прошу извинить :-\
Ну, давайте опять сравнивать скутер, ролики, Жигули, Кадиллак, Субару.. Каждый - для своей задачи и в своей области может быть оптимален. Тот же MySQL - да, хорош в силу легкости освоения и использования для вебдевелоперов, но только для очень небольших (по количеству таблиц и логике) проектов. Отсутствие ряда важных фичей типа тех же встроенных процедур вообще имхо не позволяет его сравнивать с нормальными СУБД типа Oracle. Ссылки на TODO и недавно появившиеся фичи в 4-ой версии типа подзапросов - в _серьезном_ проекте не принимаются категорически - нельзя там рисковать. PostgresSQL - в большинстве случаев отличная база, но иногда поддержка и гарантированная стаблильность важнее денег, тогда уже Oracle. Тем более последний имеет массу дополнительного софта.
Ну что за тяга к узкому мышлению :) Кроме вебдизайна никаких вариантов.
А как насчет комплектации операционной среды, идентификацией, хранения логов, записей, использования базы сотнями программ как стандата де факто системы, причем не обязательно линукса или винды.. или представить все это образование не позволяет? :) Или для того чтобы скидывать логи и служебные данные в маленькой программулине например для подсчета трафика туда непременно лепить оракл?
Идиотская статья, кретин автор похоже вообще не понимает, о чём пишет:
> MySQL uses traditional row-level locking. PostgreSQL uses something called Multi Version Concurrency Control (MVCC) by default. MVCC is a little different from row-level locking in that transactions on the database are performed on a snapshot of the data and then serialized. New versions of PostgreSQL support standard row-level locking as an option, but MVCC is the preferred method.
Как в PostgreSQL, так и в MySQL с InnoDB движки версионные. А новую версию PostgreSQL с блокировкой на уровне записи можно было придумать только по большой обкурке.
Таблица с фичами вообще п@#дец. Сравниваются стабильные и работающие версии не то, что с альфой, а вообще с vaporware (покажите мне мыскль 5.1, ась?)
Re: Re: Re: PostgreSQL vs. MySQL vs коммерческие СУБД
Я вообще и писал что MySQL - для людей которым образование или отсутствие времени не позволяет разобраться в том для чего им вообще СУБД нужна. Именно такие люди радостно запихивают в мусклю буквально все - вплоть до вордовских файлов и jpegов по 5Мб (игнорируя все рекомендации разработчиков самого мускля), вместо того чтобы хранить эти вещи в файловой системе, а в мускле только ссылки на них.
Тот же Постгрес справляется со всем этим гораздо лучше, а ресурсов жрет ненамного больше.
Вообще не понимаю чего тут сравнивать.
Re: Re: Re: PostgreSQL vs. MySQL vs коммерческие СУБД
Сдается мне, что когда пару месяцев назад был трид про Oracle vs. PostgreSQL, тогда были одни крики, а теперь как-то более-менее цивилизовано. Или еще ортодоксальные постгрящиеся не проснулись? :)
p.s. как там дела с online бекапом в постгресе? продвинулось? :)
Re: Re: Re: Re: Re: PostgreSQL vs. MySQL vs коммерческие СУБД
Ну да, дампами бекапить это, конечно, круто. Круче наверное только вручную переписывать на бумажку. Настоящее решение для настоящих АБД. :)
p.s. про время восстановления из дампа я промолчу.
Re: Re: Re: Re: Re: Re: PostgreSQL vs. MySQL vs коммерческие СУБД
Тут, по-моему, никто не утверждает, что PostrgeSQL _лучшая_ СУБД. А вот что касается соотношения цена/возможности - то тут как раз PostgreSQL делает многих. А работа в backup направлении, как уже
сказали, ведется. В TODO, помимо инкрементального бэкапа, есть еще и point-in-time recovery, причем в разделе "безотлагательных" задач.
Такая вот задачка например - в системе идут мегабайты логов, но чтобы не делать монструозные текстовые файлы перенаправляем все это в базу. Или непрерывно идут вычисления, или снимаются показания с приборов, или берется какая то статистика, того же трафика например. Данные простые но их очень много, впроследствии они обрабатываются перловой или сишной прогой. Ну и что лучше мускула подойдет для этого?
Ну смотри если идут данные по трафику (например нетфлоу) то пихать это все в SQL полное изврат. Я пробовал как то так делать ... и что ты думаеш за 1 час у меня набежало ~500 тыс строк. Ты знаеш скока потом делался простейший селект для выборки общего объема трафика для определенного IP?
Поэтому такие данные лучше хранить в BerkeleyDB!
Мускул в данном случае работает как еще один слой прослойки до данных ... из SQL преобразовывается в формат хранения (InnoDB or BDB) и потом пишется ... тык зачем нам еще одна прослойка в такой определенной задаче как напр считать и обрабатывать трафик
SQL хорош когда изначально неизвестно какие запрсы будут выполняться ...
(22.04.2004 12:44:45)