В общем выдалось тут плотно покрутить эту штуку в разных конфигурациях (2-4-8 нод) и на разных нагрузках. С краш-тестами и т.д. Впечатления двоякие остались.. Основная идея в том, что данные разбиты (партиционированы) по узлам кластера + по сайтам на каждом узле (зависит от кол-ва ядер). Для взаимодействия с данными (select, insert, update, delete) необходимо писать процедуры, которые в идеале д.б. партиционированы по тому же ключу, что и данные (single-partitioned - SP). (Необходимо отметить, что процедура атомарна, она либо выполняется вся, либо откатываются все транзакции внутри процедуры). Тогда в каждой партиции есть данные и есть свой процессинг, это все обслуживается одним ядром в один момент времени, таким образом никаких блокировок нет, обработка данных в одной партиции серилизована. Это конечно здорово. Второй плюс, что вся база in-memory, поэтому никаких кешей и все, что связано с этим. Опять же плюс в производительности. Ну и в силу своей архитектуры k-safe, когда данные одного узла зеркалируются на соседей, записи снапшотов каждой ноды на диск каждые несколько минут и ведения между снапшотами логов, достигается отказоустойчивость кластера к различного рода инцидентам и обеспечивается целостность данных. Пока все замечательно. А теперь чуть отвлечемся - представим себе болид F1, мчящийся по трассе, быстрый мощный, надежный (в последнее время). Это вот Воль в своей стихии. А что будет если на этом болиде выехать в город? Уже не так быстро.. А поехать на дачу? А это совсем уже никак.. вот и Вольт такой же.. на первой же задаче возникла необходимость обеспечения атомарности нескольких последовательных транзакций, которые не могут быть партиционированы по одному ключу (в терминах Вольта multi-partitioned - MP), и в этом случае такие процедуры выполняются одновременно на всех ядрах кластера параллельно, что в силу архитектуры ставит весь кластер на паузу. Если эту же процедуру разложить на последовательность SP процедур то разница в производительности получается 100-1000Х!!! В наших тестах мы получили 2M+ TPS на SP процедурах и 20K на МР процедурах. Такая разница подтверждена инженерами Вольта. (сейчас в роадмапе есть наработки, чтобы ускорить не SP процедуры, будем подождать, но пока не понятно когда). Далее, есть некий "стандартный SQL", но выполнение из консоли или откуда еще непосредственно SQL команд приводит к тому, что все это выполняется в МР режиме, т.е. подключиться консолькой к БД и сделать что-то а-ля select top N равносильно нажать на паузу, это справедливо абсолютно для любой SQL команды. Но справедливости ради даже аналитические запросы работают очень быстро, джойны тоже, но не дай бог выйти за постулат SP, как только вы уходите в MP - это полный треш, непартиционированные джойны и другие запросы МР просто вешают кластер, а точнее ставят его на паузу. В общем резюме - штука прикольная, очень резвая, но пока не разберутся с транзакционной целостностью на произвольной последовательности операций, а вернее с производительностью такой схемы, говорить о чем-то серьезном пока еще рано. Очень узкий рынок есть, но не более того.