|
2.7, CAHbKA (?), 14:24, 28/10/2009 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Это ответ Ораклу на попытку отделиться и создать собственный дистр
у оракла уже который год "свой" дистр, примерно со времен RHEL 4.5
мысли:
1) Шум оракл-mysql инспирирован ораклом, чтобы придать mysql хоть какую-то ценность в скв
2) считаю redhat в целом достаточно умными, чтобы они купили такое Г, как mysql
| |
|
3.11, vitek (??), 17:36, 28/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
забавно, кто-бы и что-бы не писал, а мускуль по-прежнему основная субд для веб.
и вот таких проектов:
>Компания Amazon в рамках нового сервиса Amazon RDS начала предоставление в аренду облачных окружений с MySQL 5.1 (используется хранилище InnoDB).
http://www.opennet.me/opennews/art.shtml?num=24000
что-то не видно и не слышно ни на оракле, ни на постгискл...
зы:
хм... мускуль - субд одного уровня с мсскл, сайбэйз, информикс и т.д.
но добится вразумительных комментов, почему же оно г... - не представляется возможным.
| |
|
4.14, gleb (?), 09:53, 30/10/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>хм... мускуль - субд одного уровня с мсскл, сайбэйз, информикс и т.д.
>но добится вразумительных комментов, почему же оно г... - не представляется
>возможным.
На вскидку:
InnoDB слишком долго модифицирует большие таблицы (механизм копирования во временную таблицу). В постгресе проблемы нет.
Отвратительный оптимизатор запросов. Лажает в простейших ситуациях. Опять же в постгресе - большая редкость.
Скорость работы Mysql'я на простых операциях (и под нагрузкой) не намного (или совсем не) выше чем в современном постгресе. Сложные mysql выполнять просто не умеет
PS: по мне, так для веба в любом случае нужны дополнительные звенья в архитектуре хранения данных. Нужно активно использовать кеширование (memcache) либо специфичные для задачи решения (например часть данных хранить в tokyo tyrant или memcachedb)
| |
|
5.18, vitek (??), 05:18, 31/10/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
>InnoDB слишком долго модифицирует большие таблицы (механизм копирования во временную таблицу). В постгресе проблемы нет.
а зачем её модифицировать?
>Отвратительный оптимизатор запросов. Лажает в простейших ситуациях. Опять же в постгресе - большая редкость.
и тем не менее, запросы в мускуле выполняются быстрее. :-D
не говоря уж о требуемых ресурсах.
>Скорость работы Mysql'я на простых операциях (и под нагрузкой) не намного (или совсем не) выше чем в современном постгресе. Сложные mysql выполнять просто не умеет
смотря как настроить... в подавляющем большинстве случаев мускуль быстрее... и меньше жрёт. про амазон выше ссылку давал - один (а по-всему видать - решающий) повод в выборе именно мускуля.
зы:
видывал (и к сожалению очень часто) я такое г..., сделанное и на постргри, и на оракле, и т.д. ..... как правило перцами, кричащими, что что-то там г..., а что-то там круть.
но также видел и на мускуле практически гениальные решения.
| |
|
6.23, gleb (?), 15:14, 31/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
> а зачем её модифицировать?
проект растет и развивается => меняются задачи => меняется структура БД
>>Отвратительный оптимизатор запросов. Лажает в простейших ситуациях. Опять же в постгресе - большая редкость.
>и тем не менее, запросы в мускуле выполняются быстрее. :-D не говоря уж о требуемых ресурсах.
как минимум странный аргумент. алгоритмы выборки данных никто не отменял, и если майскуэль использует неверный план выполнения запроса, то время на запрос может быть на порядки выше. в вебе один 8ми секундный запрос может сильно подпортить жизнь.решается это как правило либо "хаками" либо прямым указанием индекса.
PS: а какая у вас область деятельности, что вам не приходится менять структуру таблицы во время жизни проекта?
| |
|
7.24, vitek (??), 15:23, 31/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
>проект растет и развивается => меняются задачи => меняется структура БД
в любом случае - это не штатная ситуация. и подобные работы как правило только этим не заканчиваются. сразу же приплюсовываются расчёты на пространство, память, индексы, планы выполнения и т.д.
как следствие - в большинстве случаев данные строки должны находится рядом, а не по всему рэйду тонким слоем... а если нет, то можно и доп. таблице подумать (master - detail). или просто построить новую (что чаще всего и происходит)
>как минимум странный аргумент. алгоритмы выборки данных никто не отменял, и если майскуэль использует неверный план выполнения запроса, то время на запрос может быть на порядки выше. в вебе один 8ми секундный запрос может сильно подпортить жизнь.решается это как правило либо "хаками" либо прямым указанием индекса.
почему странный? никакой план выполнения не заменит здравый смысл... и факты.
мускуль занял место основной субд для инета по-праву. аргументы я уже приводил. не вижу смысла повторяться.
| |
|
8.25, vitek (??), 15:31, 31/10/2009 [^] [^^] [^^^] [ответить] | +/– | ах, да и что проектируйте б д и пишите запросы правильно да и хинты даже в ор... текст свёрнут, показать | |
|
9.26, gleb (?), 15:53, 31/10/2009 [^] [^^] [^^^] [ответить] | +/– | с таким подходом рынок интернет-сервисов еще в каменном веке бы был сейчас реша... текст свёрнут, показать | |
|
10.27, vitek (??), 17:00, 31/10/2009 [^] [^^] [^^^] [ответить] | +/– | глупости для профи по времени делать что так, что так - один хрен к примеру н... текст свёрнут, показать | |
|
11.28, gleb (?), 20:45, 31/10/2009 [^] [^^] [^^^] [ответить] | +/– | похоже вы не совсем понимаете темпы и условия в которых делаются веб-стартапы р... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
|
1.2, uZver (??), 11:19, 28/10/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
+1. хорошо если RedHat сами купят MySQL у Oracle или EnterpriseDB
| |
|
2.6, аноним (?), 14:01, 28/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
>хорошо если RedHat сами купят MySQL у Oracle или EnterpriseDB
Ну я понимаю они могут купить мускуль у оракла, но у EnterpriseDB как?
| |
|
3.9, Warhead Wardick (?), 16:45, 28/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
Как -как, как обычно!
А вот PostgreSQL - да купить невозможно :)
пЫсЫ: Долгих лет процветания слону! Самя Ъ-db :)
| |
|
|
1.3, Антон (??), 11:45, 28/10/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Готов сделать денежную ставку за то, что в ближайший год Red Hat купит бизнес EnterpriseDB. Сейчас оптимальной сделке мешает волна поднятая из-за Oracle/MySQL. Но вот когда страсти улягутся, готов поспорить Red Hat купит EnterpriseDB, все ведет к этому.
| |
|
2.4, Cobold (??), 12:01, 28/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
В смысле мешает, думаете они на этой волне себе цену набивают? В любом случае интерес налицо.
| |
|
1.5, паралельные запросы (?), 13:44, 28/10/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
EnterpriseDB сидит сверху на бренде постгреса, от них давно нет стоящих патчей, даже коды на исполнение параленых селекты не отдают в постгрес... вобщем богатые станут еще богаче :(
| |
|
2.8, Aleksey (??), 15:36, 28/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
Насколько я помню они замечатальным образом оплачивают работу нескольких разработчиков постгрес. Так что нормально.
| |
|
1.15, Аноним (-), 19:45, 30/10/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
добавили бы слону нормальный partitioning и alter table add column [BEFORE,AFTER] как в мускуле и я буду самым счастливым на ЗЕМЛЕ! ;-)
| |
|
2.19, vitek (??), 05:21, 31/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
>добавили бы слону нормальный partitioning и alter table add column [BEFORE,AFTER] как в мускуле и я буду самым счастливым на ЗЕМЛЕ! ;-)
а мне вот больше нужен стэндбай....
хотя моё личное счастье от этого не зависит.
| |
2.21, Vitaly_loki (ok), 13:01, 31/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
А использовать список полей в select вместо *, чтоб обеспечить нужный порядок выборки? :)
| |
|
|