Почему не удалось развернуть?
Как устроена сетевая часть?
Как проводился бенчмарк? Что-то меня берут сомнения что persistent solution может быть быстрее memcache в принципе.
Tarantool — это framework, у него есть rb-деревья в том числе. То есть на этом framework можно построить сетевой сервес, так же как Tokyo Cabinet, как я понимаю, это просто Dbm и сетевой фронт-енд у него называется Kyoto Cabinet
Давайте спишемся например в ru_nosql в livejournal, чтобы там продолжить обсуждение.
В mail.ru она уже давно используется в production. За последние 3 месяца был один крэш в production, и тот при не совсем корректно сформированном запросе с клиента. В любом случае, все известные нам баги задокументиророваны на bugs.launchpad.net/tarantool, процесс разработки открыт. Там можно посмотреть, что с priority 'high' и выше есть всего 3 открытых бага. Да и то это всё баги обнаруженные QA, в production их не было. В ближайшую неделю-две мы будем делать релиз, в который будут включены патчи для всех high+ багов, для них для всех есть фиксы в дереве.
Tarantool уже достаточно широко используется в mail.ru, когда он создавался аналогов (Redis, пожалуй, наиболее близкий) не было. Я инженер, т.е. работаю над самой базой, поэтому вопрос не совсем по адресу.
Как устроена сетевая часть?
Как проводился бенчмарк? Что-то меня берут сомнения что persistent solution может быть быстрее memcache в принципе.
Tarantool — это framework, у него есть rb-деревья в том числе. То есть на этом framework можно построить сетевой сервес, так же как Tokyo Cabinet, как я понимаю, это просто Dbm и сетевой фронт-енд у него называется Kyoto Cabinet
Давайте спишемся например в ru_nosql в livejournal, чтобы там продолжить обсуждение.