| |
| 2.38, AlexAT (ok), 12:29, 18/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Ого, впечатляет. Если не накосячили и ровно реализовали - моё почтение.
multimaster работает очень ровно. Бенчи конечно всерьез воспринимать не стоит - будет зависеть от конкретной инсталляции. Но для своих задач движок очень вменяемый.
| | |
|
| 1.2, Аноним (-), 14:25, 17/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну и кто там говорил, что оракл купил мускул исключительно с целью "закaпать"?
| | |
| |
| 2.3, Анонимо (?), 14:29, 17/02/2012 [^] [^^] [^^^] [ответить]
| +3 +/– |
Первая задача Дьявола убедить всех в том что он не существует, а далее по обстоятельствам :)
| | |
| |
| 3.4, Клыкастый (ok), 14:36, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Первая задача Дьявола убедить всех в том что он не существует, а далее по обстоятельствам :)
А обстоятельство таковы, что при таких суммах сделки закапывать купленное - самый сложный и геморройный способ закопать себя.
| | |
| 3.13, Аноним (-), 18:43, 17/02/2012 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Первая задача Дьявола убедить всех в том что он не существует, а далее по обстоятельствам :)
Какой хитрый план: сделать из мускуля стабильный и фичастый проект, после чего, очевидно, тот сдохнет сам.
| | |
| |
| 4.40, Аноним (-), 14:22, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Оракл просто наугад кидает кости. Может, попадет. У него этих коробок, с купленным ненужным софтом - а купленным просто ради выкосить конкурентов или подобия конкурентов - как дерьма в коровнике.
| | |
|
|
| 2.5, klalafuda (?), 14:58, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Ну на самом деле это ещё смотреть нужно на реальных инсталяциях на сколько все это работает и соответствует действительности. А то вон partitioning как бэ сделали но вот с внешними ключами он как бэ не работает -> пользы от него ноль без палочки.
Но вообще звучит конечно привлекательно факт.
| | |
| |
| 3.6, pro100master (ok), 15:26, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
 ну да - 1.8 млн апдейтов на сферических бенчах - внушительно. По механике у них зачет. В реальности всё немного по-другому.
| | |
| |
| 4.26, Аноним (-), 06:06, 18/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> ну да - 1.8 млн апдейтов на сферических бенчах - внушительно. По
> механике у них зачет. В реальности всё немного по-другому.
Не держите в себе экспертные знания, поделитесь с другими. Тут не госдума лохов по телевизору разводить. Имеете информацию - делитесь. Не хотите делиться - молчите. За умного сойдёте.
Ваш ОК.
| | |
| |
| 5.30, pro100master (ok), 12:15, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
а чего тут расписывать очевидные вещи? Да быстро вставляет. Первые секунды/минуты/часы (зависит от структуры). В какой-то момент, зависит от положения звёзд, скорость падает на порядки. Это беда не только "кластер эдишн". Это раз. Гораздо чаще, перед вставкой/обновлением необходимо произвести 10-20, бывает и 50, проверок. Вот тут всё упирается в невозможности нормально распараллелить выборки. Т.е. остаётся только менять архитектуру приложения. Второй гвоздь.
| | |
| |
| 6.31, AlexAT (ok), 12:20, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> а чего тут расписывать очевидные вещи? Да быстро вставляет. Первые секунды/минуты/часы
> (зависит от структуры). В какой-то момент, зависит от положения звёзд, скорость
> падает на порядки. Это беда не только "кластер эдишн". Это раз.
От структуры тут мало что зависит, это in-memory database.
| | |
| |
| 7.41, Аноним (-), 14:23, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> а чего тут расписывать очевидные вещи? Да быстро вставляет. Первые секунды/минуты/часы
>> (зависит от структуры). В какой-то момент, зависит от положения звёзд, скорость
>> падает на порядки. Это беда не только "кластер эдишн". Это раз.
> От структуры тут мало что зависит, это in-memory database.
Быстро вставляет любая реляционная таблично-ориентированная БД, чувак. Это так, для твоей инфы. В самом Оракле вставка - тоже самая быстрая операция. Скорость вставки лимитируется лишь скоростью синхронизации кэша на диски, если что. Блокировки там не нужны, сам понимаешь. Монитор транзакций не участвует.
| | |
|
|
|
|
|
| 2.25, Аноним (-), 06:04, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Ну и кто там говорил, что оракл купил мускул исключительно с целью
> "закaпать"?
Кто? Поясните, подтвердите, приведите примеры, ссылки. Обоснуйте, короче говоря.
| | |
| |
| 3.42, Аноним (-), 14:24, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Ну и кто там говорил, что оракл купил мускул исключительно с целью
>> "закaпать"?
> Кто? Поясните, подтвердите, приведите примеры, ссылки. Обоснуйте, короче говоря.
Поди в маркетинговом отделе Оракла вопросы позадавай. Тебе там, может быть, что-то прояснят.
Ты серьезно считаешь, что тебе кто-то должен что-то объяснять и доказывать? Оракл - владелец. Что хочет - то и сделает. И объяснять первому встречному тупо ничего не обязан.
| | |
|
| 2.32, AlexAT (ok), 12:21, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Ну и кто там говорил, что оракл купил мускул исключительно с целью
> "закaпать"?
Вы путаете MySQL и NDB. NDB - это совершенно отдельный движок БД, NoSQL, кстати. MySQL к нему - всего лишь надстройка для реализации SQL.
| | |
|
| |
| 2.33, AlexAT (ok), 12:22, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> а знает кто нить хорошее хауту по внедрению?)
Достаточно манов. Два года назад легко внедрили 7.0 по манам, после перепрыгнули на 7.1 и сейчас - на 7.2. Живёт отлично.
| | |
|
| 1.9, Аноним (-), 16:39, 17/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А с авторизация и разграничение прав у них поддерживается, или как memcached?
| | |
| |
| 2.39, AlexAT (ok), 12:30, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> А с авторизация и разграничение прав у них поддерживается, или как memcached?
Почти все стандартные функции MySQL с движком NDB работают. В 7.2 реализовали дистрибуцию таблиц привилегий, что радует несказанно - раньше приходилось на каждой SQL-ноде привилегии заводить.
| | |
|
| 1.10, arisu (ok), 17:44, 17/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 а мне вот интересно, как посчитали «99.999». а почему не 99.998? или 98.999? или любое другое число, собственно.
| | |
| |
| 2.11, gaga (ok), 17:59, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
 >а мне вот интересно, как посчитали «99.999». а почему не 99.998? или 98.999? или любое другое число, собственно.
Я думаю это предложение следует понимать как нашу жаргонную фразу "пять девяток", которую употребляют спецы по надежности. Т.е. просто обозначается порядок, а не точная вероятность безотказной работы.
| | |
| |
| 3.14, arisu (ok), 19:13, 17/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
да я понял, что это маркетолух в релиз вписал. мне интересно увидеть методику подсчёта. в конце концов, это серьёзная корпорация, а не «вася-петя-инкорпорейтед».
| | |
| |
| 4.24, Аноним (-), 06:01, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> да я понял, что это маркетолух в релиз вписал. мне интересно увидеть
> методику подсчёта. в конце концов, это серьёзная корпорация, а не «вася-петя-инкорпорейтед».
Ну это так, для красивого словца. В реальности на big-daba-base никто, конечно, этого не тестировал. С другой стороны, программист рад и счастлив, если формальные тесты пройдены - можно заниматься другой не менее полезной задачей, что бы потом с упоением вернуться взад.
Ваш ОК.
| | |
| |
| 5.34, AlexAT (ok), 12:24, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Ну это так, для красивого словца. В реальности на big-daba-base никто, конечно,
> этого не тестировал. С другой стороны, программист рад и счастлив, если
> формальные тесты пройдены - можно заниматься другой не менее полезной
> задачей, что бы потом с упоением вернуться взад.
Плохой вы КО. NDB Cluster никогда не предназначался для "big database" - это именно среда, которая имеет несколько направлений масштабирования, но хранить в ней терабайты никто не будет - она предназначена для "быстрых" данных. Терабайты проще хранить в архивных БД.
| | |
| |
| 6.43, Аноним (-), 14:25, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Ну это так, для красивого словца. В реальности на big-daba-base никто, конечно,
>> этого не тестировал. С другой стороны, программист рад и счастлив, если
>> формальные тесты пройдены - можно заниматься другой не менее полезной
>> задачей, что бы потом с упоением вернуться взад.
> Плохой вы КО. NDB Cluster никогда не предназначался для "big database" -
> это именно среда, которая имеет несколько направлений масштабирования, но хранить в
> ней терабайты никто не будет - она предназначена для "быстрых" данных.
> Терабайты проще хранить в архивных БД.
Ну валяй, попытайся терабайт положить в мускуль. А мы все посмеемся вместе.
| | |
|
|
|
|
|
| 1.16, o (?), 21:44, 17/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Это все не нужно если есть мемкеш.
Миллиард в секунду! а не заврались ли?
Сеть тоже это дело долнжа протащись.
А вот репликацию таблицы или вьюшки не мешало бы, потому что sql это похоже все больше удел управления (т.е. админок), а реальное highload and highavailability это удел inmemory и прочих key-value.
По моему реляционные базы сейчас на грани. На коньке во многом благодаря большому количеству инженеров с ними знакомых.
з.ы.
С учетом кеширования в мемкеш, редис и тд, по быстродействию к sql базам претензий вообще нет, есть претензии к надежности и функциональности репликаций!!!
| | |
| |
| 2.22, Аноним (-), 05:51, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Дорогой друг. Пора уже прочитать учебник по истории и понять, что кровавый социализм кончился и начался прекрасный капитализм, при котором каждый кому не лень пишет "до миллиарда запросов в минуту". Ключевое слово "до". Например, адекватная скорость при данной формулировке - это 0.000001 запроса в секунду. Такая скорость тоже будет удовлетворять условию "до". Поэтому не надо слёз и соплей - парни героически сделали что обещали.
И ещё. По-моему на грани не SQL, а ты. Берись за учебу, она полезней чем бессмысленная писана сюда.
Твой ОК.
| | |
| 2.35, AlexAT (ok), 12:24, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> это похоже все больше удел управления (т.е. админок), а реальное highload
> and highavailability это удел inmemory и прочих key-value.
WTF? NDB - это inmemory NoSQL.
| | |
|
| 1.18, Аноним (-), 00:40, 18/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я это Г в бете юзал. В 7.2 обещали джойны ускорить, по факту оказалось что ускорили только один их тип. Оптимизатор планы строит как звезды сложатся. Посмотрите их форум. там тоже прикреплены статьи про 100500 tps, а ниже - топики с вопросами "почему это медленее чем InnoDB"
| | |
| |
| 2.20, Аноним (-), 01:07, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Специально для таких случаев есть подзапрос, который усе чинит, неасилил не кричи
| | |
| |
| 3.23, Аноним (-), 05:53, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Специально для таких случаев есть подзапрос, который усе чинит, неасилил не кричи
Пример подзапроса с бенчмарками или не считается!
Паптча 96668 намекает, что ты не ответишь..
| | |
|
| 2.36, AlexAT (ok), 12:26, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Я это Г в бете юзал. В 7.2 обещали джойны ускорить, по
> факту оказалось что ускорили только один их тип. Оптимизатор планы строит
> как звезды сложатся. Посмотрите их форум. там тоже прикреплены статьи про
> 100500 tps, а ниже - топики с вопросами "почему
> это медленее чем InnoDB"
Потому что непрофессионалам не понять, что у InnoDB и NDB совершенно разные области применения. Пытаться тащить базу с InnoDB в NDB и наоборот - удел новичка, соответственно и жалобы. Вы же не пытаетесь отверткой гвозди забивать?
| | |
|
| 1.19, Аноним (-), 00:45, 18/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
И в итоге постгрес с прогретым кешем запрос по плоской таблице быстрее выполняет чем этот кластер из 6 нод, притом у кластера все данные лежали исключительно в раме. То есть как sql база, оно сливает просто жутко. А как key-value вообще не ясно чем оно лучше других.
| | |
| |
| 2.27, Аноним (-), 06:13, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Да-да, для многих программистов загадка, почему дисковый кеш быстрее помещенных ими в рамдиск через одно место данных. А про key-value претензия не по адресу, это скорее nosql.
| | |
| |
| 3.44, Аноним (-), 14:27, 18/02/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Да-да, для многих программистов загадка, почему дисковый кеш быстрее помещенных ими в
> рамдиск через одно место данных. А про key-value претензия не по
> адресу, это скорее nosql.
По определению, ёпта. Потому что есть такая хрень, как архитектура железа. Сперва данные надо через хост-адаптер протащить в южный мост, оттуда бриджом кинуть в северный, а оттуда контроллером РАМ раздать по банкам памяти. Туда и обратно.
А диск во многих случаях позволяет алгоритмически не переть данные на северный мост, и пробросить их диск-ту-диск по южному. И это, сцуко, быстрее.
Что вам, остолопам, непонятно?
| | |
|
| 2.37, AlexAT (ok), 12:26, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> И в итоге постгрес с прогретым кешем запрос по плоской таблице быстрее
> выполняет чем этот кластер из 6 нод, притом у кластера все
> данные лежали исключительно в раме. То есть как sql база, оно
> сливает просто жутко. А как key-value вообще не ясно чем оно
> лучше других.
А как у вашего постгреса с HA и одновременной записью на десятке нод?
| | |
| |
| 3.45, Аноним (-), 14:28, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> И в итоге постгрес с прогретым кешем запрос по плоской таблице быстрее
>> выполняет чем этот кластер из 6 нод, притом у кластера все
>> данные лежали исключительно в раме. То есть как sql база, оно
>> сливает просто жутко. А как key-value вообще не ясно чем оно
>> лучше других.
> А как у вашего постгреса с HA и одновременной записью на десятке
> нод?
Базовики-затейники, мля! Какой HA может быть на кластерной ФС с ОДНОЙ точкой отказа на ОДНОМ массиве?
| | |
| |
| 4.49, Аноним (-), 17:34, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>> И в итоге постгрес с прогретым кешем запрос по плоской таблице быстрее
>>> выполняет чем этот кластер из 6 нод, притом у кластера все
>>> данные лежали исключительно в раме. То есть как sql база, оно
>>> сливает просто жутко. А как key-value вообще не ясно чем оно
>>> лучше других.
>> А как у вашего постгреса с HA и одновременной записью на десятке
>> нод?
> Базовики-затейники, мля! Какой HA может быть на кластерной ФС с ОДНОЙ точкой
> отказа на ОДНОМ массиве?
У нас вообще-то хранилище, по fc подключенно, там не один массив, не один контроллер, не один fc линк. Вы про какую единую точку отказа?
| | |
| 4.51, AlexAT (ok), 12:58, 19/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Базовики-затейники, мля! Какой HA может быть на кластерной ФС с ОДНОЙ точкой
> отказа на ОДНОМ массиве?
А при чем тут кластерная фс?
| | |
|
|
|
| 1.21, Аноним (-), 01:11, 18/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
да да, select .. from t1 left joint (select * from t2) ON .. выполняется в 10 раз быстрее чем select .. from t1 left join t2 ON .. Удивительно но факт. Только в постгресе такой запрос выполняется еще в сто раз быстрее.
| | |
| |
| |
| 3.46, Аноним (-), 14:29, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> У вас видимо разогретые базы данных - попробуйте на холодных.
А давайте мягкое с теплым не сравнивать? Этот запрос по-разному будет даже в разных инсталляциях Оракла выполняться. Ничо, что говорить о перфомансе запросов вне точного контекста "железо-данные-план выполнения" тупо бессмысленно?
| | |
| |
| 4.48, Аноним (-), 17:31, 18/02/2012 [^] [^^] [^^^] [ответить] | +/– | И что мне греть охлаждать в NDB Там база в раме целиком лежит Я совсем не прот... большой текст свёрнут, показать | | |
| 4.50, Аноним (-), 17:38, 18/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> У вас видимо разогретые базы данных - попробуйте на холодных.
> А давайте мягкое с теплым не сравнивать? Этот запрос по-разному будет даже
> в разных инсталляциях Оракла выполняться. Ничо, что говорить о перфомансе запросов
> вне точного контекста "железо-данные-план выполнения" тупо бессмысленно?
http://www.clusterdb.com/mysql/dramatically-increased-mysql-cluster-join-perf
Тут планы. И ответ разработчиков.
Что кстати скажут профессионалы, про merge и hash join? Которые бы кстати неплохо можно было бы распараллелить на несколько нод, только вот в mysql таких фич совсем нету?
| | |
|
|
|
| 1.29, AlexAT (ok), 11:24, 18/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Осторожно, в 7.2.4 фатальная бага - не работают LIKE в pushed down condition. Правится легко, патч есть на багтрекере, либо отключением condition pushdown, но если опыта мало - лучше подождите 7.2.5.
| | |
|
