> объясните, пожалуйста, на пальцах, что это?На пальцах - 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, со стандартными таблицами, индексами, хранимыми процедурами, транзакциями - не надо городить костылей. Профит.
Пачка астерисков с единой базой пиров и всяких параметров? Тоже пожалуйста. И так далее.
Вариант для распечатки
on 18-Апр-13, 00:20 
