Компания Oracle представила (http://permalink.gmane.org/gmane.comp.db.mysql.announce/704) первый выпуск новой ветки пакета для развертывания кластерных конфигураций СУБД MySQL - MySQL Cluster 7.3. Пакет позволяет строить распределенные хранилища и высоконадежные конфигурации, которые могут обеспечить уровень доступности сервиса порядка 99.999% при обеспечении требований ACID к выполнению транзакций (атомарность, согласованность, изолированность,
долговечность).
MySQL Cluster позволяет создать распределённую сеть реплицированных в режиме multi-master серверов, гарантирующих отсутствие единой точки отказа. Система обеспечивает горизонтальное масштабирование - наращивание мощности кластера производится за счёт подключения новых узлов и использования техники автоматического шардинга (распределения набора данных по серверам на основе определенного ключа). Код проекта распространяется под лицензией GPL и доступен (http://dev.mysql.com/downloads/cluster/#downloads) для свободной загрузки.<center><iframe width="640" height="360" src="http://www.youtube.com/embed/DnWItDTZL2c?rel=0" frameborder="0" allowfullscreen></iframe></center>
Ключевые улучшения:
- Поддержка внешних ключей (Foreign Keys) для контроля связности и целостности данных в таблицах, распределённых по разным узлам кластера, в том числе находящихся в разных дата-центрах;
- NoSQL JavaScript коннектор для Node.js;
- Поддержка MySQL 5.6 (http://www.opennet.me/opennews/art.shtml?num=36031), позволяющая комбинировать в рамках единой БД хранилища на базе InnoDB и MySQL Cluster NDB;
- Улучшение масштабируемости нитей обработки соединений: удалось добиться повышения пропускной способности для соединений к каждому узлу кластера до трех раз, позволяя использовать для каждого соединения больше клиентских нитей;
- Автоматический инсталлятор, позволяющий в считанные минуты ввести в строй решение на базе MySQL Cluster и оптимально настроить конфигурацию в зависимости от требуемого типа решаемых кластером задач.URL: http://permalink.gmane.org/gmane.comp.db.mysql.announce/704
Новость: http://www.opennet.me/opennews/art.shtml?num=36721
оно начало работать и не падает на первой десятке гиг?
десятке гиг чего?
ну раньше оно не работало :)
руки?
память!
Вы в курсе, что оно in-memory?
> Система обеспечивает горизонтальное масштабированиеточно горизонтальное?
горизонтальное в том числе и на write-операции?
...и количество одновременно-открытых соеденений/транзакций (к базе данных) можно горизонтально расширить?
Да точно горизонтальное. Точнее так: "не менее горизонтальное, чем у других".
В NDB (MySQL) Cluster поддерживается автоматический прозрачный шардинг. Собственно за счет этого и масштабироваться можно горизонтально.
P.S.
NDB Cluster != MySQL в Master-Master конфигурации.
> горизонтальное в том числе и на write-операции?И на write тоже. С оговоркой: не в одну сущность одновременно. А то можно такую write-операцию придумать, что она любую базу проложит. Независимо от архитектуры.
эт клёво!
ЗЫ. Под сущностью подразумевается блокировочная сущность - в случае NDB это строка. Есть там у транзакций возможность невеселых коллизий в индексах, при которых блокируется весь индекс, но оное происходит только при определенных условиях.
Эх, вырождаются языки программирования.
После C++ - Java, после Java - JPA.
чем JPA не нравится?
русскоязычным звучанием
Интересненько.Кто-нибудь уже попробовал в тестовых инсталляциях? Как оно?
Упс. Это же DMR. Development Milestone Release.
объясните, пожалуйста, на пальцах, что это?
> объясните, пожалуйста, на пальцах, что это?На пальцах - MySQL над хитрой кластерной почти NoSQL. Эдакий кроссовер. Комбинирует в себе как явные плюсы, так и явные минусы миров SQL/NoSQL, на выходе получается нечто усредненное по возможностям и производительности.
Кроссовер и по типу хранения. Вообще - in-memory, хранит все данные в памяти, однако при этом регулярно синхронно сливает транзакции на диск, и при старте взлетает полностью с диска (плюс синхронизируется с живыми нодами для актуализации).
Очень легко горизонтально масштабируется, обеспечивает отказоустойчивость, имеет как привычную обертку SQL, так и собственное NoSQL API для выполнения запросов. Еще вроде бы есть интерфейс а-ля memcached, но не пробовал.
Плюс свои плюшки и ограничения. В силу отказоустойчивости и легкого масштабирования для выполнения многих тысяч TPS очень даже применимо в Telco. Идеально для read-mostly применений, хотя при грамотной организации системы с записью тоже справляется неплохо.
--
Не на пальцах - подробнее:
В силу того, что хранит данные в памяти, и имеет ряд особенностей по выполнению запросов (в частности - более высокую по сравнению с "классическим" MySQL задержку и синхронную запись на ноды) - с трудом применимо для "бытовых" решений.
Т.е. просто вот так взять и пересадить сайтик/аппликуху на NDB - можно, но шанс нарваться на диковинные грабли - почти 100%. Для хорошей производительности вся система должна с самого начала проектироваться с учетом особенностей NDB.
Кроме того - очень много данных в таком кластере хранить достаточно непросто: объем данных ограничен объемом оперативки на нодах. Либо ставить кучу нод, либо хранить только оперативные данные.
Если вам нужен именно синхронный кластер (а не запаздывающая репликация), с привычной и удобной SQL-оберткой, и ваша архитектура не против использования синхронной кластерной in-memory БД по объёму и характеристикам - можно стартовать именно с NDB. Как-то так.
Из положительных нюансов - отсутствие падения транзакций при падении нод, возможность иметь несколько API-нод (серверов MySQL) для доступа к данным кластера, легкая масштабируемость, достаточная надежность. Автоподхват созданных на любых API нодах структур (таблиц, неймспейсов, индексов) всеми API-нодами. Возможность автоматической репликации набора прав (таблиц с правами из БД MySQL) путем изменения их на тип ndbcluster вместо MyISAM - тоже очень вкусно.
Из отрицательных - суровое время старта (зависит от объема данных, в первую очередь) каждой ноды с данными (в наших условиях - нода стартует ~5 минут), и очень высокие требования к объему памяти и производительности дисковой системы. Еще - очень сложная конфигурация, собрать все параметры хорошо и правильно - совершенно непросто.
Поддержка "исключительно" on-disk данных имеется, толк от нее есть, но не большой - все равно расход памяти высок (все индексы все равно в памяти), производительность on-disk достаточно низкая, + опять же увеличивает время взлета ноды.
---
Пример? Есть у вас RADIUS-сервер с пулом адресов, аккаунтингом и прочими фичами, всё хранится в БД.
Репликация в случае RADIUS-сервера будет запаздывать очень серьезно по сравнению с интервалом обращений, и вы не сможете толком использовать традиционную Master-Master конфигурацию - постоянно будете получать конфликты. В случае Write-Master Read-All - будете иметь запаздывающие данные при ответе с данными с Slave-серверов, что для RADIUS недопустимо. Сделать шардинг - задача тоже нетривиальная.
Тут-то и спасает NDB. Кластер синхронный - все серверы кластера автоматически работают с одинаковым набором данных, независимо от источника обновления. Шардинг - тоже автоматический. MySQL API, со стандартными таблицами, индексами, хранимыми процедурами, транзакциями - не надо городить костылей. Профит.
Пачка астерисков с единой базой пиров и всяких параметров? Тоже пожалуйста. И так далее.