Спасибо, прочитал. Понял, что все ~100GB хранятся в RAM. Если честно, то очень сомневаюсь в таком подходе. Ну — во всяком случае не понимаю зачем для этого отдельная БД. У всех современных БД есть подсистема кэширования. Я уж не говорю о том, что на серверах приложения так же можно создавать кэши с репликацией. + не понятно что значит что транзакции выполняются в одном потоке… Если сервер приложения создает пул из ~50 тредов и они будут формировать транзакции, то со стороны БД что будет происходить? Они будут в очередь выстраиваться? Т.е. если в обработке сейчас одна транзакция, то вторая будет в ожидании в любом случае? А если это распределенные транзакции?
Не совсем понимаю. Если вы сделали кэш а-ля свою кэширующую БД на 100GB, то какое основное отличие от обычной БД, благодаря которому обращение к данным происходит быстрее? Принцип хранения данных? По итоговой схеме становится понятно, что к MySQL обращения происходят более редко за счет того, что ко всем горячим данным они идут в tarantool. Но ведь т.о. большая часть нагрузки теперь падает на него. Цитирую: «Мы разработали специальную базу данных для горячих данных» — из этого понятно только то, что большая часть обращений будет падать на вашу новую бд, которую также придется маштабировать. Можете как-то уточнить?
Недавно столкнулся с проблемой при очередной установке данного продукта, при соединении к СУБД выползала ошибка про SSL. Откатил Java до версии 1.7.79 и заработало, на 1.7.85 почему-то не хочет. Это так, может кому пригодится.
yum downgrade java-1.7.0-openjdk.x86_64 java-1.7.0-openjdk-devel.x86_64