Все зависит от человека. У меня знакомый и за пол года сам вкатился в программирование (java). Три из них обучался самостоятельно, три как стажировка/испытательный срок. Между прочим, потом за год серьёзно вырос.

Включены судя по всему только компании с штатом сотрудников выше какого-то кругленького числа

Просто от инженеров там тоже особых знаний и не требуется. Поставь ось, поставь сервер приложений, настрой по инструкции, почисть место на диске, разверни схемку в БД. Примерно так, я полагаю.

Написано «Поклонникам StarCraft и C&C посвящается». Это значит тем, кому нравится эта игра или жанр, скорее всего понравится. Похоже, что так и есть. Никто не говорил, что будет именно StarCraft.

Ничего подобного, я, как игрок в Starcraft, не увидел никакой связи между конкурсом и данной вселенной. С таким же успехом — сапер тоже для поклонников Starcraft. Обычная замануха заголовком.

Вроде уже в декабре обещали

Спасибо за подробный ответ!
По поводу шестого пункта — я имел ввиду, поддерживаются ли XA транзакции?

Спасибо, прочитал. Понял, что все ~100GB хранятся в RAM. Если честно, то очень сомневаюсь в таком подходе. Ну — во всяком случае не понимаю зачем для этого отдельная БД. У всех современных БД есть подсистема кэширования. Я уж не говорю о том, что на серверах приложения так же можно создавать кэши с репликацией. + не понятно что значит что транзакции выполняются в одном потоке… Если сервер приложения создает пул из ~50 тредов и они будут формировать транзакции, то со стороны БД что будет происходить? Они будут в очередь выстраиваться? Т.е. если в обработке сейчас одна транзакция, то вторая будет в ожидании в любом случае? А если это распределенные транзакции?

Не совсем понимаю. Если вы сделали кэш а-ля свою кэширующую БД на 100GB, то какое основное отличие от обычной БД, благодаря которому обращение к данным происходит быстрее? Принцип хранения данных? По итоговой схеме становится понятно, что к MySQL обращения происходят более редко за счет того, что ко всем горячим данным они идут в tarantool. Но ведь т.о. большая часть нагрузки теперь падает на него. Цитирую: «Мы разработали специальную базу данных для горячих данных» — из этого понятно только то, что большая часть обращений будет падать на вашу новую бд, которую также придется маштабировать. Можете как-то уточнить?

пример команды:
yum downgrade java-1.7.0-openjdk.x86_64 java-1.7.0-openjdk-devel.x86_64

Недавно столкнулся с проблемой при очередной установке данного продукта, при соединении к СУБД выползала ошибка про SSL. Откатил Java до версии 1.7.79 и заработало, на 1.7.85 почему-то не хочет. Это так, может кому пригодится.