MySQL созрела

проблемы с юникодом в четвертке мои интимные(при извлечении данных орет на нераспознаваемые символы если в сторке заглавные русские буквы) ? и испрвлены ли они в пятой версии ?

в статье нет ни одного вхождения "oracle" или "ibm".

далее имхо: пока они не сделают хотя бы архивлоги или какую-то разумную им замену - ни о какой конкуренции в enterprise-окружении даже речи быть не может.

про аналоги flashback, real application cluster, а также поставляющихся в комплекте инструментов для работы с OLAP и близких DSS-инструментов я даже и вспоминать не буду.

MySQL дозреет через полтора-два года, когда все то, что сейчас понапихали в пятую ветку окончательно отладят и вычистят. Пока же оно не только в продакшн не годится, но даже для тестов: ХП на встроенном языке ведут себя крайне нестабильно, нет кластеризации (то, что там есть - не кластер), кривая репликация, слетающие под нагрузкой индексы и т.д. Хотя да, есть хорошая тенденция к переходу от коротких штанишек к более-менее серьезному продукту.

> есть хорошая тенденция к переходу от коротких штанишек к более-менее серьезному продукту.

тенденция - есть, это хорошо. но до полноценной конкуренции - пилить и пилить, путь ещё только начат.

>проблемы с юникодом в четвертке мои интимные(при извлечении данных орет на нераспознаваемые символы если в сторке заглавные русские буквы) ? и испрвлены ли они в пятой версии ?

Боюсь, что твои интимные :) Не имел проблем с юникодом с самых первых 4.1.2alpha, сперва на RH7.3, потом на Gentoo :)

Отвёртка собралась составить конкуренцию отбойному молотку? Оригинально-с.

Бредовая новость, точнее бредовый анонс оной... Вообще - не анонс, а классическая провокация флейма... Кто подтвердил? Аааа! Ну понятно - ктож еще... :)

Как в старом анекдоте: когда напильником обработают и нормальный ARCHIVE_LOG с работающими транзакциями сделают, MyOracle получиЦЦо 8) Про OLAP я уже и не говорю...

что под оффтопиком, что под гентой с юникодной локалью (собственно локаль совершенно непричем должна быть) один и тот же код ошибки, т.е. оно нормально вроде забивает стоки как в TEXT так и в VARCHAR а вот когда потом пытаешься делать выборку даже в переменную данные не присваиваются, я уже не знаю на питона(или конкретно на sqlobject) ли грешить или на мускуль или на руки, гуглил, в каком то из мейл листов заметил предположение одного из троллей, что у мускуля не все шоколадно с юникодом, вот подумал может сталкивался кто уже ..

мдя, попробовал воспроизвести ошибку, не получилось, видимо она решила вылезти чуть позже, когда показывать программу буду:-/

Так попробуйте подключиться к серверу напрямую текстовым клиентом (mysql) и оттуда проверить Ваши SELECTы. Только не забудьте set names перед запросами сделать.

"а девочка созрела"? by Zemfira

Аффтар, "причины по которым эта СУБД составит серьёзную конкуренцию Oracle и IBM" в студию!

> Аффтар, "причины по которым эта СУБД составит серьёзную конкуренцию Oracle и IBM" в студию!

Собственно почему составит? Уже состовляет! И гланая тому причина - скорость. Вернее отсутствие таковой и всяких оракулов и прочей монструозной проприетарщины.

Анонимус, не позорься!

>Отвёртка собралась составить конкуренцию отбойному молотку? Оригинально-с

маразматик быдложабопрограмер слез с пальмы и собрался составить конкуренцию homo sapiens? оригинально

гм а причем тут слоны ? ( Postgresql ) ?

>Собственно почему составит? Уже состовляет!

Конкуренцию Ораклу? Хорошо. Не затруднит ли Вас рассказать, как, при наличии 10G базы и 2G RAM, сделать кластер из.... ну, к примеру, пяти машин?

>И гланая тому причина - скорость. Вернее отсутствие таковой и всяких оракулов и прочей монструозной проприетарщины.

Простите, если Вам так нужна скорость, почему Вы не используете SQLite или просто файлы?

Блин во народ прозрел. Пару лет назад здесь такая ругань стояла
по поводу нах транзакции, сохраненные процедуру и тп.

> Пару лет назад здесь такая ругань стояла по поводу нах транзакции, сохраненные процедуру и тп.

можно ссылочку? =)

> И гланая тому причина - скорость. Вернее отсутствие таковой

Зачет, пиши ещё! =)

ну во-первых как я уже заметил ошибка проявляется "раз на раз", а во вторых phpmyadmin такого не городил и нормально показывает записи в базе, ладно попоробую разработчиков sqlobject поданимать, что-то мне подсказывает, что проблема в каком нить ихнем валидаторе данных

Когда я еще учился (года 2-3 назад) MySQL смешно было даже СУБД назвать. Это была система обработки таблиц, так как в ней небыло даже таких базовых для СУБД вещей как вложенные запросы и ссылочная целостность.

Интересно сейчас добавили?

>можно ссылочку? =)
мона
http://www.linux.org.ru/view-message.jsp?msgid=201140&back=

>Когда я еще учился (года 2-3 назад) MySQL смешно было даже СУБД назвать. Это была система обработки таблиц, так как в ней небыло даже таких базовых для СУБД вещей как вложенные запросы и ссылочная целостность.

Транзакции и FOREIGN KEYS есть при использовании специального типа таблиц На сегодняшний момент в продакшн-релизе нету: - языка ХП - триггеров - CHECKS / CONSTRAINTS - VIEWS В пятой версии все это должно появиться. В общем-то, формально оно там есть. Но - не работает или работает нестабильно или работает катастрофически медленно. Года через полтора-два, скорее всего, пятую ветку доведут до ума и она станет программных продуктом, который можно куда-либо поставить. Сейчас в пятой ветке куча вещей попросту не работает. Поэтому говорить о какой-либо конкуренции с серьезными СУБД попросту невозможно.

экспериментальным путем установлено, что проблема возникает только на руссокой не заглавной буковке "с". Я худею, дорогая редакция (С) Ну теперь хоть можно поставить костыль-валидатор

> В общем-то, формально оно там есть. Но - не работает или работает нестабильно или работает катастрофически медленно

Конкретный пример в студию! Что именно работает катастрофически медленно ?

2Synco: RTFM по поводу своих русских символов. А именно - SET NAMES

> Конкуренцию Ораклу? Хорошо. Не затруднит ли Вас рассказать, как, при наличии 10G базы и 2G RAM, сделать кластер из.... ну, к примеру, пяти машин?

Очень просто, ставишь 5 машин х86, бесплатный мыскль-кластер на бесплатный линукс, лоад-балансер.
И получаешь мощное решение в 10 раз дешевле аналогичного от оракла.

Я уже не говорю на сколько дешевле ДБА обойдется.

>экспериментальным путем установлено, что проблема возникает только на руссокой не заглавной буковке "с". Я худею, дорогая редакция (С) Ну теперь хоть можно поставить костыль-валидатор

На 4.1 висит форум с ~1Гб базой, поисковый энжин с ~7Гб базой, CMS с ~500Мб и несколько мелких форумов. Число запросов на пике достигает 200 в секунду.

За последние 2 суток: Трафик MySQL - 30Мб/час Соединений - 15123 в час SELECT - 52882 в час INSERT - 8164 тыс. в час UPDATE - 19766 в час.

И при всём этом зоопарке ни единого сбоя :D

Так что буква "С" тут явно не при чём :)

нет я конечно покурю, но что-то удивительно, что в ORM нужно что-то подобное делать, кроме того что задан класс с юникодным типом колонок, с томуже почему только на букве с ?

Что-то с математикой не сходится. 30 mb/час маловато для всего что ты написал (select,insert.update), 200 req/sec.

Вы хоть пробовали подобное делать? У неё же фс на корбе. И блокировки нифига не работают. Бред. Будут потери в производительности ~ 80%

MySQL созрела... упала с дерева и сгнила :)

не поймите превратно :)

форумы и сайты - только мускль,

а mission critical c транзакциями пока только постгрес

вот обкатают все что накрутили и наобещали, а там посмотрим %)

>Очень просто, ставишь 5 машин х86, бесплатный мыскль-кластер на бесплатный линукс, лоад-балансер. И получаешь мощное решение в 10 раз дешевле аналогичного от оракла.

>Я уже не говорю на сколько дешевле ДБА обойдется.

а давайте дальше пойдем? %)))

видел своими глазами - написан сервер на клиппере "типа центральная база/хранилище" с базой в DBF, и конектятся к нему клиенты сливают инфу из локальных баз и подгружают справочники(небольшие), делают запросы(основные данные у клиентов не пересекаются)

не знаю сколько была база на "сервере" - врать не буду :) но клиентские DBF-ки порядка 100М :)))))

даеш кластер на DBF-ках!!! не страшно ??? ;)

А вот почему эта база больше НЕ составит серьёзную конкуренцию Ораклу: http://www.oracle.com/innodb/index.html

Оракл купил Innobase, разработчиков движка InnoDB для мыскля.

>А вот почему эта база больше НЕ составит серьёзную конкуренцию Ораклу: http://www.oracle.com/innodb/index.html

Особенно мне понравилось что в следующем году заканчивается котракт Innobase и MySQL. Как вовремя Oracle сделал покупку :))) раньше что-то Innobase их не интересовал ;)

Да. Как представлю, сколько теперь будет стоить коммерческая лицензия на InnoDB для MySQL, так вздрогну. ;)

Интересно, Oracle на $1k на одно процессорное ядро остановится или будет тянуть повыше? ;)

И при этом, самое интересное, на каждом углу можно будет кричать о поддержке Open Source -- для OS разработок-то денежку платить не надо будет.

>MySQL созрела

Угу, и теперь она упадет с ветки и ее начнут есть черви...

>Года через полтора-два, скорее всего, пятую ветку доведут до ума и она станет программных продуктом, который можно куда-либо поставить. Сейчас в пятой ветке куча вещей попросту не работает. Поэтому говорить о какой-либо конкуренции с серьезными СУБД попросту невозможно.

Для конкуренции с ораклом ещё надо уметь хотя бы иерархические запросы, вложенные транзакции, нормальную репликацию и кластеризацию. С этим у даже постгреса не всё в порядке (hier_pg разве что в виде патча есть, да slony/pgspool до какого-то момента могут устраивать). Плюс на высокой нагрузке тормозить начинает. Куда там mysql попал.

>Очень просто, ставишь 5 машин х86, бесплатный мыскль-кластер на бесплатный линукс, лоад-балансер. И получаешь мощное решение в 10 раз дешевле аналогичного от оракла.

Мощное - это по энергопотреблению? А что твой "кластер" кроме пожирания ваттов и постоянных тормозов на реплицировании будет делать?

>Блин во народ прозрел. Пару лет назад здесь такая ругань стояла по поводу нах транзакции, сохраненные процедуру и тп.

можем повторить - мнение не изменилось. нужны хранимые процедуры - юзайте монстров. мы же обойдёмся быстрой базой MySQL (4.0.24)

>не поймите превратно :)

>форумы и сайты - только мускль,

>а mission critical c транзакциями пока только постгрес

а кто спорит? или Oracle/DB2 кто хотел под чат?

>Число запросов на пике достигает 200 в секунду.

всего то?

>Когда я еще учился (года 2-3 назад) MySQL смешно было даже СУБД назвать. Это была система обработки таблиц, так как в ней небыло даже таких базовых для СУБД вещей как вложенные запросы и ссылочная целостность.

>Интересно сейчас добавили?

этого никогда не будет. спите дальше.

>> И гланая тому причина - скорость. Вернее отсутствие таковой

>Зачет, пиши ещё! =)

всё же интересно что он имел ввиду! погоди хаха

Да что там IBM и Oracle... был тут на AMD RoadShow проводившемся совместно с HP, так там несколько раз прозвучали фразы типа: "Настоящие базы данных SQL, не какой-нибудь там ORacle" имелось ввиду конечно MS SQL. Так что SQL это только микрософт... :) и даже не ИБМ и ОРакле... что уж говорить про наши постгресы...

> Оракл купил Innobase, разработчиков движка InnoDB для мыскля.

Ну, тогда об чём дискуссия? Если Оракел покупает технологии Mysql,
значит mysql точно созрела!

>Что-то с математикой не сходится. 30 mb/час маловато для всего что ты написал (select,insert.update), 200 req/sec.

Ты читать научись. ~200 - это пиковая загрузка. Чем пиковая от среднесуточной отличается тоже рассказывать нужно?

Кстати, под 200 - это только селектов. Всего же запросов у меня по текущей статистике 61 в секунду в среднем за сутки.

Сейчас средний трафик - 22.7Мб/час. При 220.7 тыс. запросов в час это, в среднем, 105кБ на запрос. Разве мало? Если пересчитать на одни 48.7тыс селектов в час, то выйдет 477кБ/запрос.

>всего то?

А я где-то писал, что много? Я просто говорю, что при такой нагрузке сбоев в БД нету. А что, у массовых Web-серверов нагрузка обычно больше?