Компания Oracle представила (http://permalink.gmane.org/gmane.comp.db.mysql.announce/646) стабильный релиз MySQL Cluster 7.2, пакета для развертывания кластерных конфигураций СУБД MySQL, позволяющих построить распределенные хранилища и высоконадежные конфигурации, которые могут обеспечить уровень доступности сервиса порядка 99.999% при обеспечении требований ACID к выполнению транзакций (атомарность, согласованность, изолированность,
долговечность). MySQL Cluster позволяет создать распределённую сеть реплицированных в режиме multi-master серверов, гарантирующих отсутствие единой точки отказа. Система обеспечивает горизонтальное масштабирование - наращивание мощности кластера производится за счёт подключения новых узлов и использования техники автоматического шардинга (распределения набора данных по серверам на основе определенного ключа). Код проекта распространяется под лицензией GPL и доступен (http://www.mysql.com/downloads/cluster/7.2.html) для свободной загрузки.
По тестам ...URL: http://permalink.gmane.org/gmane.comp.db.mysql.announce/646
Новость: http://www.opennet.me/opennews/art.shtml?num=33116
Ого, впечатляет. Если не накосячили и ровно реализовали - моё почтение.
> Ого, впечатляет. Если не накосячили и ровно реализовали - моё почтение.multimaster работает очень ровно. Бенчи конечно всерьез воспринимать не стоит - будет зависеть от конкретной инсталляции. Но для своих задач движок очень вменяемый.
Ну и кто там говорил, что оракл купил мускул исключительно с целью "закaпать"?
Первая задача Дьявола убедить всех в том что он не существует, а далее по обстоятельствам :)
> Первая задача Дьявола убедить всех в том что он не существует, а далее по обстоятельствам :)А обстоятельство таковы, что при таких суммах сделки закапывать купленное - самый сложный и геморройный способ закопать себя.
> Первая задача Дьявола убедить всех в том что он не существует, а далее по обстоятельствам :)Какой хитрый план: сделать из мускуля стабильный и фичастый проект, после чего, очевидно, тот сдохнет сам.
Оракл просто наугад кидает кости. Может, попадет. У него этих коробок, с купленным ненужным софтом - а купленным просто ради выкосить конкурентов или подобия конкурентов - как дерьма в коровнике.
Ну на самом деле это ещё смотреть нужно на реальных инсталяциях на сколько все это работает и соответствует действительности. А то вон partitioning как бэ сделали но вот с внешними ключами он как бэ не работает -> пользы от него ноль без палочки.Но вообще звучит конечно привлекательно факт.
ну да - 1.8 млн апдейтов на сферических бенчах - внушительно. По механике у них зачет. В реальности всё немного по-другому.
> ну да - 1.8 млн апдейтов на сферических бенчах - внушительно. По
> механике у них зачет. В реальности всё немного по-другому.Не держите в себе экспертные знания, поделитесь с другими. Тут не госдума лохов по телевизору разводить. Имеете информацию - делитесь. Не хотите делиться - молчите. За умного сойдёте.
Ваш ОК.
а чего тут расписывать очевидные вещи? Да быстро вставляет. Первые секунды/минуты/часы (зависит от структуры). В какой-то момент, зависит от положения звёзд, скорость падает на порядки. Это беда не только "кластер эдишн". Это раз. Гораздо чаще, перед вставкой/обновлением необходимо произвести 10-20, бывает и 50, проверок. Вот тут всё упирается в невозможности нормально распараллелить выборки. Т.е. остаётся только менять архитектуру приложения. Второй гвоздь.
> а чего тут расписывать очевидные вещи? Да быстро вставляет. Первые секунды/минуты/часы
> (зависит от структуры). В какой-то момент, зависит от положения звёзд, скорость
> падает на порядки. Это беда не только "кластер эдишн". Это раз.От структуры тут мало что зависит, это in-memory database.
>> а чего тут расписывать очевидные вещи? Да быстро вставляет. Первые секунды/минуты/часы
>> (зависит от структуры). В какой-то момент, зависит от положения звёзд, скорость
>> падает на порядки. Это беда не только "кластер эдишн". Это раз.
> От структуры тут мало что зависит, это in-memory database.Быстро вставляет любая реляционная таблично-ориентированная БД, чувак. Это так, для твоей инфы. В самом Оракле вставка - тоже самая быстрая операция. Скорость вставки лимитируется лишь скоростью синхронизации кэша на диски, если что. Блокировки там не нужны, сам понимаешь. Монитор транзакций не участвует.
> Ну и кто там говорил, что оракл купил мускул исключительно с целью
> "закaпать"?Кто? Поясните, подтвердите, приведите примеры, ссылки. Обоснуйте, короче говоря.
>> Ну и кто там говорил, что оракл купил мускул исключительно с целью
>> "закaпать"?
> Кто? Поясните, подтвердите, приведите примеры, ссылки. Обоснуйте, короче говоря.Поди в маркетинговом отделе Оракла вопросы позадавай. Тебе там, может быть, что-то прояснят.
Ты серьезно считаешь, что тебе кто-то должен что-то объяснять и доказывать? Оракл - владелец. Что хочет - то и сделает. И объяснять первому встречному тупо ничего не обязан.
> Ну и кто там говорил, что оракл купил мускул исключительно с целью
> "закaпать"?Вы путаете MySQL и NDB. NDB - это совершенно отдельный движок БД, NoSQL, кстати. MySQL к нему - всего лишь надстройка для реализации SQL.
кластерный греп, охлол :D
а знает кто нить хорошее хауту по внедрению?)
> а знает кто нить хорошее хауту по внедрению?)Достаточно манов. Два года назад легко внедрили 7.0 по манам, после перепрыгнули на 7.1 и сейчас - на 7.2. Живёт отлично.
А с авторизация и разграничение прав у них поддерживается, или как memcached?
> А с авторизация и разграничение прав у них поддерживается, или как memcached?Почти все стандартные функции MySQL с движком NDB работают. В 7.2 реализовали дистрибуцию таблиц привилегий, что радует несказанно - раньше приходилось на каждой SQL-ноде привилегии заводить.
а мне вот интересно, как посчитали «99.999». а почему не 99.998? или 98.999? или любое другое число, собственно.
>а мне вот интересно, как посчитали «99.999». а почему не 99.998? или 98.999? или любое другое число, собственно.Я думаю это предложение следует понимать как нашу жаргонную фразу "пять девяток", которую употребляют спецы по надежности. Т.е. просто обозначается порядок, а не точная вероятность безотказной работы.
да я понял, что это маркетолух в релиз вписал. мне интересно увидеть методику подсчёта. в конце концов, это серьёзная корпорация, а не «вася-петя-инкорпорейтед».
> да я понял, что это маркетолух в релиз вписал. мне интересно увидеть
> методику подсчёта. в конце концов, это серьёзная корпорация, а не «вася-петя-инкорпорейтед».Ну это так, для красивого словца. В реальности на big-daba-base никто, конечно, этого не тестировал. С другой стороны, программист рад и счастлив, если формальные тесты пройдены - можно заниматься другой не менее полезной задачей, что бы потом с упоением вернуться взад.
Ваш ОК.
> Ну это так, для красивого словца. В реальности на big-daba-base никто, конечно,
> этого не тестировал. С другой стороны, программист рад и счастлив, если
> формальные тесты пройдены - можно заниматься другой не менее полезной
> задачей, что бы потом с упоением вернуться взад.Плохой вы КО. NDB Cluster никогда не предназначался для "big database" - это именно среда, которая имеет несколько направлений масштабирования, но хранить в ней терабайты никто не будет - она предназначена для "быстрых" данных. Терабайты проще хранить в архивных БД.
>> Ну это так, для красивого словца. В реальности на big-daba-base никто, конечно,
>> этого не тестировал. С другой стороны, программист рад и счастлив, если
>> формальные тесты пройдены - можно заниматься другой не менее полезной
>> задачей, что бы потом с упоением вернуться взад.
> Плохой вы КО. NDB Cluster никогда не предназначался для "big database" -
> это именно среда, которая имеет несколько направлений масштабирования, но хранить в
> ней терабайты никто не будет - она предназначена для "быстрых" данных.
> Терабайты проще хранить в архивных БД.Ну валяй, попытайся терабайт положить в мускуль. А мы все посмеемся вместе.
ну терабайт не терабайт
а полтерабайта - полет нормальный
Нельзя же быть таким безграмотным!
http://www.opennet.me/openforum/vsluhforumID3/83061.html#14
Это все не нужно если есть мемкеш.
Миллиард в секунду! а не заврались ли?
Сеть тоже это дело долнжа протащись.
А вот репликацию таблицы или вьюшки не мешало бы, потому что sql это похоже все больше удел управления (т.е. админок), а реальное highload and highavailability это удел inmemory и прочих key-value.По моему реляционные базы сейчас на грани. На коньке во многом благодаря большому количеству инженеров с ними знакомых.
з.ы.
С учетом кеширования в мемкеш, редис и тд, по быстродействию к sql базам претензий вообще нет, есть претензии к надежности и функциональности репликаций!!!
Дорогой друг. Пора уже прочитать учебник по истории и понять, что кровавый социализм кончился и начался прекрасный капитализм, при котором каждый кому не лень пишет "до миллиарда запросов в минуту". Ключевое слово "до". Например, адекватная скорость при данной формулировке - это 0.000001 запроса в секунду. Такая скорость тоже будет удовлетворять условию "до". Поэтому не надо слёз и соплей - парни героически сделали что обещали.И ещё. По-моему на грани не SQL, а ты. Берись за учебу, она полезней чем бессмысленная писана сюда.
Твой ОК.
> это похоже все больше удел управления (т.е. админок), а реальное highload
> and highavailability это удел inmemory и прочих key-value.WTF? NDB - это inmemory NoSQL.
Я это Г в бете юзал. В 7.2 обещали джойны ускорить, по факту оказалось что ускорили только один их тип. Оптимизатор планы строит как звезды сложатся. Посмотрите их форум. там тоже прикреплены статьи про 100500 tps, а ниже - топики с вопросами "почему это медленее чем InnoDB"
Специально для таких случаев есть подзапрос, который усе чинит, неасилил не кричи
> Специально для таких случаев есть подзапрос, который усе чинит, неасилил не кричиПример подзапроса с бенчмарками или не считается!
Паптча 96668 намекает, что ты не ответишь..
>Пример подзапроса с бенчмарками или не считается!
>Паптча 96668 намекает, что ты не ответишь..Почему это не отвечу,
Вот тут мой вопрос, и ответ разработчиков на него. Можете изучить.http://www.clusterdb.com/mysql/dramatically-increased-mysql-...
> Я это Г в бете юзал. В 7.2 обещали джойны ускорить, по
> факту оказалось что ускорили только один их тип. Оптимизатор планы строит
> как звезды сложатся. Посмотрите их форум. там тоже прикреплены статьи про
> 100500 tps, а ниже - топики с вопросами "почему
> это медленее чем InnoDB"Потому что непрофессионалам не понять, что у InnoDB и NDB совершенно разные области применения. Пытаться тащить базу с InnoDB в NDB и наоборот - удел новичка, соответственно и жалобы. Вы же не пытаетесь отверткой гвозди забивать?
И в итоге постгрес с прогретым кешем запрос по плоской таблице быстрее выполняет чем этот кластер из 6 нод, притом у кластера все данные лежали исключительно в раме. То есть как sql база, оно сливает просто жутко. А как key-value вообще не ясно чем оно лучше других.
Да-да, для многих программистов загадка, почему дисковый кеш быстрее помещенных ими в рамдиск через одно место данных. А про key-value претензия не по адресу, это скорее nosql.
> Да-да, для многих программистов загадка, почему дисковый кеш быстрее помещенных ими в
> рамдиск через одно место данных. А про key-value претензия не по
> адресу, это скорее nosql.По определению, ёпта. Потому что есть такая хрень, как архитектура железа. Сперва данные надо через хост-адаптер протащить в южный мост, оттуда бриджом кинуть в северный, а оттуда контроллером РАМ раздать по банкам памяти. Туда и обратно.
А диск во многих случаях позволяет алгоритмически не переть данные на северный мост, и пробросить их диск-ту-диск по южному. И это, сцуко, быстрее.
Что вам, остолопам, непонятно?
> И в итоге постгрес с прогретым кешем запрос по плоской таблице быстрее
> выполняет чем этот кластер из 6 нод, притом у кластера все
> данные лежали исключительно в раме. То есть как sql база, оно
> сливает просто жутко. А как key-value вообще не ясно чем оно
> лучше других.А как у вашего постгреса с HA и одновременной записью на десятке нод?
>> И в итоге постгрес с прогретым кешем запрос по плоской таблице быстрее
>> выполняет чем этот кластер из 6 нод, притом у кластера все
>> данные лежали исключительно в раме. То есть как sql база, оно
>> сливает просто жутко. А как key-value вообще не ясно чем оно
>> лучше других.
> А как у вашего постгреса с HA и одновременной записью на десятке
> нод?Базовики-затейники, мля! Какой HA может быть на кластерной ФС с ОДНОЙ точкой отказа на ОДНОМ массиве?
>>> И в итоге постгрес с прогретым кешем запрос по плоской таблице быстрее
>>> выполняет чем этот кластер из 6 нод, притом у кластера все
>>> данные лежали исключительно в раме. То есть как sql база, оно
>>> сливает просто жутко. А как key-value вообще не ясно чем оно
>>> лучше других.
>> А как у вашего постгреса с HA и одновременной записью на десятке
>> нод?
> Базовики-затейники, мля! Какой HA может быть на кластерной ФС с ОДНОЙ точкой
> отказа на ОДНОМ массиве?У нас вообще-то хранилище, по fc подключенно, там не один массив, не один контроллер, не один fc линк. Вы про какую единую точку отказа?
> Базовики-затейники, мля! Какой HA может быть на кластерной ФС с ОДНОЙ точкой
> отказа на ОДНОМ массиве?А при чем тут кластерная фс?
да да, select .. from t1 left joint (select * from t2) ON .. выполняется в 10 раз быстрее чем select .. from t1 left join t2 ON .. Удивительно но факт. Только в постгресе такой запрос выполняется еще в сто раз быстрее.
У вас видимо разогретые базы данных - попробуйте на холодных.
> У вас видимо разогретые базы данных - попробуйте на холодных.А давайте мягкое с теплым не сравнивать? Этот запрос по-разному будет даже в разных инсталляциях Оракла выполняться. Ничо, что говорить о перфомансе запросов вне точного контекста "железо-данные-план выполнения" тупо бессмысленно?
>> У вас видимо разогретые базы данных - попробуйте на холодных.
> А давайте мягкое с теплым не сравнивать? Этот запрос по-разному будет даже
> в разных инсталляциях Оракла выполняться. Ничо, что говорить о перфомансе запросов
> вне точного контекста "железо-данные-план выполнения" тупо бессмысленно?И что мне греть/охлаждать в NDB? Там база в раме целиком лежит. Я совсем не против чтобы план запроса менялся в зависимости от условий. Только вот почему то когда используется ndb движек, то оптимизатор статистику использовать не может. Вы это тоже можете на форуме почитать. Потому если вы делаете запрос который выбирает данные очень селективно, а потом их сортирует, то используются те же индексы что и в случае когда селективность низкая, и нужно было бы делать фулл скан, или использовать индекс по сортируемому полю(для ускорения сортировки).
PS:
У меня на постгресе да, одновременная запись на несколько нод, огранизованная средствами софта с двухфазными транзакциями. Расскажите пожалуйста какие по вашему профессионалы вообще ndb используют? Вы вообще на sql.ru видели советы по его использованию?
>> У вас видимо разогретые базы данных - попробуйте на холодных.
> А давайте мягкое с теплым не сравнивать? Этот запрос по-разному будет даже
> в разных инсталляциях Оракла выполняться. Ничо, что говорить о перфомансе запросов
> вне точного контекста "железо-данные-план выполнения" тупо бессмысленно?http://www.clusterdb.com/mysql/dramatically-increased-mysql-...
Тут планы. И ответ разработчиков.
Что кстати скажут профессионалы, про merge и hash join? Которые бы кстати неплохо можно было бы распараллелить на несколько нод, только вот в mysql таких фич совсем нету?
Осторожно, в 7.2.4 фатальная бага - не работают LIKE в pushed down condition. Правится легко, патч есть на багтрекере, либо отключением condition pushdown, но если опыта мало - лучше подождите 7.2.5.