Comments 17
А почему выбор пал именно на Tarantul? Аналогов много. Чем руководствовались при выборе?
насколько я понял, выбор пал не на Tarantool, а на написание своей системы, которую и назвали Tarantool.
Tarantool уже достаточно широко используется в mail.ru, когда он создавался аналогов (Redis, пожалуй, наиболее близкий) не было. Я инженер, т.е. работаю над самой базой, поэтому вопрос не совсем по адресу.
Если бы еще сайт Tarantool работал :)
Работает, спасибо :)
У автора какая-то нездоровая любовь к запятым в тексте. Они рассыпаны по тексту таким ровным слоем, что текст становится трудночитаем.
Не по содержанию, а по форме замечания. «Релязионными», «персистентное» — это как?
Самый главный вопрос — когда систему можно будет использовать в продакшене ;)
Она уже давно с успехом используется. На мой взгляд разработчика, тарантул — одна из немногих вещей, которые в мейле сделаны действительно качественно, за что отдельное спасибо основному автору системы, Юре Вострикову. По непонятным для меня причинам, компания эту разработку рекламирует как-то лениво, в стиле «мы тут сайт сделали, на конференции немного рассказали, кто не забыл — сам все найдет». А IT-сообществу в общем-то плевать, потому что отношение к компании в нашей среде прямо скажем неоднозначное. На мой взгляд подробный рассказ про тарантула и открытие кода еще пары проектов, за которые не стыдно, могли бы ситуацию переломить, но пока увы.
В mail.ru она уже давно используется в production. За последние 3 месяца был один крэш в production, и тот при не совсем корректно сформированном запросе с клиента. В любом случае, все известные нам баги задокументиророваны на bugs.launchpad.net/tarantool, процесс разработки открыт. Там можно посмотреть, что с priority 'high' и выше есть всего 3 открытых бага. Да и то это всё баги обнаруженные QA, в production их не было. В ближайшую неделю-две мы будем делать релиз, в который будут включены патчи для всех high+ багов, для них для всех есть фиксы в дереве.
На сайте нет упоминания статуса — поэтому и такой вопрос.
Костя спасибо за статью,
все очень интересно, но развернуть тарантул у меня так и не получилось
хотел по эксперементировать в сравнительных целях
в частности сравнить со своим продуктом.
У меня сейчас а альфа тестировании собственная разработка на базе rb-Tree (пока за основу взято дерево из TockyoCabinet. возможно в будущем будет свое) и прикрутил к нему сетевую часть.
По скорости немного обгоняет мемкеш, редис и HandlerSocket + сохраняет все данные на диске
Это не кеш а именно БД, нет механизма вытеснения из кеша.
из до возможностей — выбор по региону ключей, выбор ключей по маске. Правда на имена ключей из-за этого накладываются некоторые ограничения.
Если интересно — есть презенташка, могу скинуть ссылку.
Просто посмотрел, что наши продукты похожи и решил написать
все очень интересно, но развернуть тарантул у меня так и не получилось
хотел по эксперементировать в сравнительных целях
в частности сравнить со своим продуктом.
У меня сейчас а альфа тестировании собственная разработка на базе rb-Tree (пока за основу взято дерево из TockyoCabinet. возможно в будущем будет свое) и прикрутил к нему сетевую часть.
По скорости немного обгоняет мемкеш, редис и HandlerSocket + сохраняет все данные на диске
Это не кеш а именно БД, нет механизма вытеснения из кеша.
из до возможностей — выбор по региону ключей, выбор ключей по маске. Правда на имена ключей из-за этого накладываются некоторые ограничения.
Если интересно — есть презенташка, могу скинуть ссылку.
Просто посмотрел, что наши продукты похожи и решил написать
Почему не удалось развернуть?
Как устроена сетевая часть?
Как проводился бенчмарк? Что-то меня берут сомнения что persistent solution может быть быстрее memcache в принципе.
Tarantool — это framework, у него есть rb-деревья в том числе. То есть на этом framework можно построить сетевой сервес, так же как Tokyo Cabinet, как я понимаю, это просто Dbm и сетевой фронт-енд у него называется Kyoto Cabinet
Давайте спишемся например в ru_nosql в livejournal, чтобы там продолжить обсуждение.
Как устроена сетевая часть?
Как проводился бенчмарк? Что-то меня берут сомнения что persistent solution может быть быстрее memcache в принципе.
Tarantool — это framework, у него есть rb-деревья в том числе. То есть на этом framework можно построить сетевой сервес, так же как Tokyo Cabinet, как я понимаю, это просто Dbm и сетевой фронт-енд у него называется Kyoto Cabinet
Давайте спишемся например в ru_nosql в livejournal, чтобы там продолжить обсуждение.
Sign up to leave a comment.
Использование опыта тестирования реляционной СУБД для технологии NoSQL