https://www.opennet.ru/openforum/vsluhforumID3/83061.html Компания Oracle представила (http://permalink.gmane.org/gmane.comp.db.mysql.announce/646) стабильный релиз MySQL Cluster 7.2, пакета для развертывания кластерных конфигураций СУБД MySQL, позволяющих построить распределенные хранилища и высоконадежные конфигурации, которые могут обеспечить уровень доступности сервиса порядка 99.999% при обеспечении требований ACID к выполнению транзакций (атомарность, согласованность, изолированность,<br>долговечность). MySQL Cluster позволяет создать распределённую сеть реплицированных в режиме multi-master серверов, гарантирующих отсутствие единой точки отказа. Система обеспечивает горизонтальное масштабирование - наращивание мощности кластера производится за счёт подключения новых узлов и использования техники автоматического шардинга (распределения набора данных по серверам на основе определенного ключа). Код проекта распространяется под лицензией GPL и доступен (http://www.mysql.com/downloads/cluster/7.2.html) для свободной загрузки.<br><br><br>По тестам ...<br><br>URL: http://permali https://www.opennet.ru/openforum/vsluhforumID3/83061.html#52 Mon, 12 Mar 2012 13:00:51 GMT ну терабайт не терабайт<br>а полтерабайта - полет нормальный<br> https://www.opennet.ru/openforum/vsluhforumID3/83061.html#51 Sun, 19 Feb 2012 08:58:29 GMT &gt; Базовики-затейники, мля! Какой HA может быть на кластерной ФС с ОДНОЙ точкой <br>&gt; отказа на ОДНОМ массиве?<br><br>А при чем тут кластерная фс?<br> https://www.opennet.ru/openforum/vsluhforumID3/83061.html#50 Sat, 18 Feb 2012 13:38:37 GMT &gt;&gt; У вас видимо разогретые базы данных - попробуйте на холодных.<br>&gt; А давайте мягкое с теплым не сравнивать? Этот запрос по-разному будет даже <br>&gt; в разных инсталляциях Оракла выполняться. Ничо, что говорить о перфомансе запросов <br>&gt; вне точного контекста "железо-данные-план выполнения" тупо бессмысленно?<br><br>http://www.clusterdb.com/mysql/dramatically-increased-mysql-cluster-join-performance-with-adaptive-query-localization/comment-page-1/#comment-60598<br><br>Тут планы. И ответ разработчиков.<br><br>Что кстати скажут профессионалы, про merge и hash join? Которые бы кстати неплохо можно было бы распараллелить на несколько нод, только вот в mysql таких фич совсем нету?<br> https://www.opennet.ru/openforum/vsluhforumID3/83061.html#49 Sat, 18 Feb 2012 13:34:51 GMT &gt;&gt;&gt; И в итоге постгрес с прогретым кешем запрос по плоской таблице быстрее <br>&gt;&gt;&gt; выполняет чем этот кластер из 6 нод, притом у кластера все <br>&gt;&gt;&gt; данные лежали исключительно в раме. То есть как sql база, оно <br>&gt;&gt;&gt; сливает просто жутко. А как key-value вообще не ясно чем оно <br>&gt;&gt;&gt; лучше других.<br>&gt;&gt; А как у вашего постгреса с HA и одновременной записью на десятке <br>&gt;&gt; нод?<br>&gt; Базовики-затейники, мля! Какой HA может быть на кластерной ФС с ОДНОЙ точкой <br>&gt; отказа на ОДНОМ массиве?<br><br>У нас вообще-то хранилище, по fc подключенно, там не один массив, не один контроллер, не один fc линк. Вы про какую единую точку отказа?<br> https://www.opennet.ru/openforum/vsluhforumID3/83061.html#48 Sat, 18 Feb 2012 13:31:35 GMT &gt;&gt; У вас видимо разогретые базы данных - попробуйте на холодных.<br>&gt; А давайте мягкое с теплым не сравнивать? Этот запрос по-разному будет даже <br>&gt; в разных инсталляциях Оракла выполняться. Ничо, что говорить о перфомансе запросов <br>&gt; вне точного контекста "железо-данные-план выполнения" тупо бессмысленно?<br><br>И что мне греть/охлаждать в NDB? Там база в раме целиком лежит. Я совсем не против чтобы план запроса менялся в зависимости от условий. Только вот почему то когда используется ndb движек, то оптимизатор статистику использовать не может. Вы это тоже можете на форуме почитать. Потому если вы делаете запрос который выбирает данные очень селективно, а потом их сортирует, то используются те же индексы что и в случае когда селективность низкая, и нужно было бы делать фулл скан, или использовать индекс по сортируемому полю(для ускорения сортировки).<br><br>PS:<br>У меня на постгресе да, одновременная запись на несколько нод, огранизованная средствами софта с двухфазными транзакциями. Расскажите пожалуйста какие по ваше https://www.opennet.ru/openforum/vsluhforumID3/83061.html#47 Sat, 18 Feb 2012 13:22:43 GMT &gt;Пример подзапроса с бенчмарками или не считается!<br>&gt;Паптча 96668 намекает, что ты не ответишь..<br><br>Почему это не отвечу,<br>Вот тут мой вопрос, и ответ разработчиков на него. Можете изучить.<br><br>http://www.clusterdb.com/mysql/dramatically-increased-mysql-cluster-join-performance-with-adaptive-query-localization/comment-page-1/#comment-60598<br> https://www.opennet.ru/openforum/vsluhforumID3/83061.html#46 Sat, 18 Feb 2012 10:29:29 GMT &gt; У вас видимо разогретые базы данных - попробуйте на холодных.<br><br>А давайте мягкое с теплым не сравнивать? Этот запрос по-разному будет даже в разных инсталляциях Оракла выполняться. Ничо, что говорить о перфомансе запросов вне точного контекста "железо-данные-план выполнения" тупо бессмысленно?<br> https://www.opennet.ru/openforum/vsluhforumID3/83061.html#45 Sat, 18 Feb 2012 10:28:23 GMT &gt;&gt; И в итоге постгрес с прогретым кешем запрос по плоской таблице быстрее <br>&gt;&gt; выполняет чем этот кластер из 6 нод, притом у кластера все <br>&gt;&gt; данные лежали исключительно в раме. То есть как sql база, оно <br>&gt;&gt; сливает просто жутко. А как key-value вообще не ясно чем оно <br>&gt;&gt; лучше других.<br>&gt; А как у вашего постгреса с HA и одновременной записью на десятке <br>&gt; нод?<br><br>Базовики-затейники, мля! Какой HA может быть на кластерной ФС с ОДНОЙ точкой отказа на ОДНОМ массиве?<br><br> https://www.opennet.ru/openforum/vsluhforumID3/83061.html#44 Sat, 18 Feb 2012 10:27:42 GMT &gt; Да-да, для многих программистов загадка, почему дисковый кеш быстрее помещенных ими в <br>&gt; рамдиск через одно место данных. А про key-value претензия не по <br>&gt; адресу, это скорее nosql.<br><br>По определению, ёпта. Потому что есть такая хрень, как архитектура железа. Сперва данные надо через хост-адаптер протащить в южный мост, оттуда бриджом кинуть в северный, а оттуда контроллером РАМ раздать по банкам памяти. Туда и обратно.<br><br>А диск во многих случаях позволяет алгоритмически не переть данные на северный мост, и пробросить их диск-ту-диск по южному. И это, сцуко, быстрее.<br><br>Что вам, остолопам, непонятно?<br>