> объясните, пожалуйста, на пальцах, что это?

На пальцах - 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, со стандартными таблицами, индексами, хранимыми процедурами, транзакциями - не надо городить костылей. Профит.

Пачка астерисков с единой базой пиров и всяких параметров? Тоже пожалуйста. И так далее.