Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>База в 4 ГБ далеко не всегда является такой мелкой как хотелось бы некоторым. G>>Видел множество случаев где мускл загибался на базе в 200 метров (правда какая-то древняя версия), тогда как "урезанная версия" ms sql вполне достойно работала. T>Бла-бла-бла ни о чем.
Гы-гы. Съехал.
G>>Если же действительно нгужна большая база (десятки гигов), то и цена БД в цене такого решения будет занимать минимум. T>Не понял логики: как связан размер базы со стоимостью решения?
Непосредственно. Огромные объемы данных просто так никому не нужны. Программы обрабатывающие такие объемы данных стоят недешево.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
G>>Дай ссылку на тоже самое для mysql. T>http://dev.mysql.com/downloads/mysql/5.1.html
Ну так где 8-ядерная машина c 16GB оперативки и 300GB базой?
G>>А также дай сравнение производительности mysql и oracle\mssql на таких объемах. T>Бесплатные версии oracle\mssql на таких объемах не работают вообще.
Судя по тому что ссылок нету бесплатный mysql тоже на таких объемах не работает, да и платный вряд ли.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, kuj, Вы писали:
kuj>>Здравствуйте, mrTwister, Вы писали:
kuj>>>>MS SQL и Oracle тоже. kuj>>>>Что еще?
T>>>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
kuj>>Дай ссылку на MySQL, чтобы эффективно работал на 8-ядерной машине c 16GB оперативки и 300GB базой. :]
T>http://dimitrik.free.fr/db_STRESS_MySQL_540_and_others_Apr2009.html#note_5443
T>В два раза быстрее, чем Postgrees
Да уж, на интеловских тестах интеловские процессоры всегда были быстрее всех.
Здесь аналогичный случай
Здравствуйте, gandjustas, Вы писали:
G>>>А также дай сравнение производительности mysql и oracle\mssql на таких объемах. T>>Бесплатные версии oracle\mssql на таких объемах не работают вообще. G>Судя по тому что ссылок нету бесплатный mysql тоже на таких объемах не работает,
Хватит торллить. В ссылке объемы еще больше.
G>да и платный вряд ли.
Платный от бесплатного отличается только наличием поддержки (АФАИК).
G>>>Если же действительно нгужна большая база (десятки гигов), то и цена БД в цене такого решения будет занимать минимум. T>>Не понял логики: как связан размер базы со стоимостью решения? G>Непосредственно. Огромные объемы данных просто так никому не нужны.
Верно.
G>Программы обрабатывающие такие объемы данных стоят недешево.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>>>Если же действительно нгужна большая база (десятки гигов), то и цена БД в цене такого решения будет занимать минимум. T>>>Не понял логики: как связан размер базы со стоимостью решения? G>>Непосредственно. Огромные объемы данных просто так никому не нужны. T>Верно.
G>>Программы обрабатывающие такие объемы данных стоят недешево. T>С чего ты взял?
Наверное с того что разработкой подобных программ занимаюсь.
Здравствуйте, gandjustas, Вы писали:
G>Да уж, на интеловских тестах интеловские процессоры всегда были быстрее всех. G>Здесь аналогичный случай
Потому что у интела и амд был примерно паритет и путем использования более "удобных" тестов можно было добиться преимущества как интела так и амд. С MySQL ситуация аналогична. Я не утверждаю, что MySQL работает быстрее, чем MSSQL (хотя могу написать тест, который будет работать быстрее на мускуле), я лишь утверждаю, что его производительность как минимум сопоставима с остальными ведущими СУБД. Разница незначительна и возможные просады производительности всегда можно выличить стандартными средствами (хинты, индексы, переписывание запроса и пр.). Причем это относится не только к MySQL. Низкая производительность и масштабируемость — это не аргумент против MySQL.
Здравствуйте, ДимДимыч, Вы писали:
ДД>Здравствуйте, kuj, Вы писали:
kuj>>И что умеет mysql, чего не умел бы oracle и mssql?
ДД>Как минимум умеет распространяться бесплатно на законных основаниях.
5-ый вроде как умеет. Стал платным. Могу ошибаться.
Здравствуйте, mrTwister, Вы писали:
T> M>При том, что нельзя говорить, что в MySQL-е есть ACID. Он есть при определенных условиях (например, при выборе только одного storage-engine'а — InnoDB)
T> То, что у тебя есть возможность кроме InnoDB выбрать что-то другое говорит лишь в пользу MySQL. Используй InnoDB и будет тебе счастье, в чем проблема? Тебя же никто не заставляет использовать MyISAM. Это все равно, что сказать, что, например C++ не поддерживает ООП, потому что ты можешь писать на С++ не используя ООП.
Любая аналогия является по умолчанию неверной.
Еще раз. По буквам.
Ни один из storage-engine'ов MySQL не поддерживает все фичи MySQL полностью.
Из-за этого приходится тратить дополнитлеьные усилия на проверку — а подходит ли нам этот движок или нет? А можем ли мы пожертвовать теми или иными фичами ли нет? А где у нас будет просаживание в производитльности, а где нет? А раздует ли добавление нового индекса в таблицу требования к харду в три раза или нет? Если нет, то не просадит ли он производительность в четыре раза? Если нет, то не наложит ли ограничения еще на что-нибудь? И т.п.
T> M>MyISAM — The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
T> Это не имеет значения, так как стандартный инсталлятор меняет конфигурацию и по-умолчанию делает дефолтным InnoDB.
Это имеет значение, когда кто-то безаппеляционно заявляет что-то типа:
T> Еще один стереотип. Уже давно по умолчанию InnoDB
Как оказалось, давно и в обозримом будущем движок по умолчанию — не InnoDB.
Здравствуйте, mrTwister, Вы писали:
T> M>Так вот. Нафига мне эти фичи, если «качество неважно»? Нафига мне эти ичи с вот такущим списком ошибок и багов?
T> Во-первых, бОльшая часть этих багов закрыта.
После выхода 5.1, ага
T> Во-вторых, лучше иметь возможность использовать некоторую фичу с незначительными ограничениями, чем не иметь возможности использовать ее вообще.
Во-вторых, лучше иметь возможность использовать стабильный продукт, чьим лозунго не является «Качество — не важно»
Здравствуйте, mrTwister, Вы писали:
T>Потому что у интела и амд был примерно паритет и путем использования более "удобных" тестов можно было добиться преимущества как интела так и амд. С MySQL ситуация аналогична. Я не утверждаю, что MySQL работает быстрее, чем MSSQL (хотя могу написать тест, который будет работать быстрее на мускуле)
Напиши.
Здравствуйте, mrTwister, Вы писали:
T>Можно, конечно, смеяться, но эта стратегия работает. Так, MySQL по вкусным фичам уже ИМХО обгоняет PostgreeSQL. И классическое утверждение "MySQL для мелких задач, Postgree для крупных" уже перешло в разряд стереотипов, которые имеют мало общего с действительностью.
Что там с check constraints? (Стандартная фича SQL, между прочим.) А живы ли ещё .frm-файлы, которые не журналируются и в итоге легко могут повредиться, и транзакции их не спасут? А что у нас с sequences? Или до сих пор нет ничего, кроме auto_increment, значения которого сбрасываются в select(max(id)) при перезапуске сервера? А что у нас с типом timestamp, первое поле которого ведёт себя как on insert/update set now (или как там), а остальные on update set null?
D>Что там с check constraints? (Стандартная фича SQL, между прочим.)
Внешние ключи есть, check constraints нет. Это не является препятствием для использования в крупных проектах.
D>А живы ли ещё .frm-файлы, которые не журналируются и в итоге легко могут повредиться, и транзакции их не спасут?
Файлы живы, но в случае с InnoDB они никем не модифицируются, могут быть в любой момент восстановлены, а следовательно не нуждаются в журналировании.
D>А что у нас с sequences? Или до сих пор нет ничего, кроме auto_increment,
Что не мешает жить MSSQL'ю
D>значения которого сбрасываются в select(max(id)) при перезапуске сервера?
Нет такого.
D>А что у нас с типом timestamp, первое поле которого ведёт себя как on insert/update set now (или как там), а остальные on update set null?
Здравствуйте, Mamut, Вы писали:
M>Любая аналогия является по умолчанию неверной.
M>Еще раз. По буквам.
M>Ни один из storage-engine'ов MySQL не поддерживает все фичи MySQL полностью.
InnoDB поддерживает достаточно фич, чтобы использовать остальные движки при необходимости в очень редких случаях.
T>> Это не имеет значения, так как стандартный инсталлятор меняет конфигурацию и по-умолчанию делает дефолтным InnoDB.
M>Это имеет значение, когда кто-то безаппеляционно заявляет что-то типа: M>
T>> Еще один стереотип. Уже давно по умолчанию InnoDB
M>Как оказалось, давно и в обозримом будущем движок по умолчанию — не InnoDB.
Это смотря что считать движком по умолчанию. При отсутствии конфигурации движок по умолчанию MyISAM. Возможно, это сделано для совместимости. Но факт то, что инсталлятор прописывает в конфиге по умолчанию InnoDB и именно InnoDB становится движком по умолчанию.
Здравствуйте, mrTwister, Вы писали:
T> M>Любая аналогия является по умолчанию неверной.
T> M>Еще раз. По буквам.
T> M>Ни один из storage-engine'ов MySQL не поддерживает все фичи MySQL полностью.
T> InnoDB поддерживает достаточно фич, чтобы использовать остальные движки при необходимости в очень редких случаях.
Угу, то-то мужики об этом не знают и ждут-не дождутся Flcon, который наконец-то будет компромиссом между InnoDB и MyISAM'ом
И то-то в High Performance MySQL целая глава о выборе storage engine'ов написана. Не говоря уже о постоянных сносках на engine'ы практически во всех главах — от оптимизации запросов до индексов до бэкапов. И каждый раз предупреждение: остороно, здесь потенциальная жопа, если вдруг вы используете MyISAM, а не InnoDB, и наоборот
T> T>> Это не имеет значения, так как стандартный инсталлятор меняет конфигурацию и по-умолчанию делает дефолтным InnoDB.
Не знаю, где и какой инсталлятор так делает, дефолтным движком в MySQL является MyISAM.
T> M>Это имеет значение, когда кто-то безаппеляционно заявляет что-то типа: T> M>
T> T>> Еще один стереотип. Уже давно по умолчанию InnoDB
T> M>
T> M>Как оказалось, давно и в обозримом будущем движок по умолчанию — не InnoDB.
T> Это смотря что считать движком по умолчанию. При отсутствии конфигурации движок по умолчанию MyISAM. Возможно, это сделано для совместимости. Но факт то, что инсталлятор прописывает в конфиге по умолчанию InnoDB и именно InnoDB становится движком по умолчанию.
Блин. «смотря что считать».. Ага. Еще раз:
MyISAM — The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
То, что авторы инсталлятора решили менять конфигурацию, остается на совести авторов инсталлятора. Движком MySQL по умолчанию является MyISAM. Думаю, авторам документации и, скажем, бывшему Manager of High Performace Group at MySQL Inc (одному из авторов High Performance MySQL)известно, что считать движком MySQL по умолчанию. Движком по умолчанию они называют MyISAM.
