Comments 27
Жирный минус тарантулу в сравнении в редисом — в удобстве структуры документации. В редисе есть команды и типы и с этим всё понятно. А чем и как правильно оперировать в тарантуле — огромный вопрос.
Жена ногу обводить не дала, но дал Stackoverflow:
Ну да, они свое пиарят. В тексте вообще много маркетинга, решили меряться по latency, которая из бенчмарков настолько не настоящая, что никакой роли не играет на реальных нагрузках. А реальная tail latency из реальной жизни, которая заставляет юзеров ждать, у таких решений все равно проблемная, сеть и ОС и много чего еще ее угробят. И достижение каких-то реальных гарантий по tail latency — это уже совсем о другом уровне, где медленный, но распределенный Riak с этим справится, потому что учитывает возможные проблемы на сети и нодах, а тарантулы с редисами — нет.
Это ведь может означать, что с редисом проблем больше, а с тарантулом все сами разобрались.
Т.е. latency для вас будет очень большим, но throughput у этого магазина маленький.
У Ашана большой throughput (ск. всего неверно транскрибировали презентацию).
Напишу личное мнение, о том, почему я прохожу мимо Tarantool:
Интуитивно БД вопринимается по аналогии так: был memcached, его допилили и он стал memcachedb.
Не пользовался ни тем, ни другим, но и желания особого не возникает именно потому, что это все воспринимается как поделка.
Был redis, его допилили, он стал Tarantool. Почему redis? — Из-за Lua и начальных статей про БД.
В самом начале, кто-то из ваших сотрудников, как раз, проводил параллели с Redis и создал впечатление, что вы адаптировали его под ваши нужны.
Т.е проблема не в Tarantool, а в его восприятии другими. Может быть, дело даже в Mail.ru.
Т.е сейчас продукт не воспринимается как что-то целое и автономное, а вопринимается так, как будто это не самостоятельная надстройка над Redis. Нужно попытаться попытаться изменить это, наверное, более хардкорными новостями о кодовой базе, о этапах разработки и.т.п.
Интуитивно БД вопринимается по аналогии так: был memcached, его допилили и он стал memcachedb.
Не пользовался ни тем, ни другим, но и желания особого не возникает именно потому, что это все воспринимается как поделка.
Был redis, его допилили, он стал Tarantool. Почему redis? — Из-за Lua и начальных статей про БД.
В самом начале, кто-то из ваших сотрудников, как раз, проводил параллели с Redis и создал впечатление, что вы адаптировали его под ваши нужны.
Т.е проблема не в Tarantool, а в его восприятии другими. Может быть, дело даже в Mail.ru.
Т.е сейчас продукт не воспринимается как что-то целое и автономное, а вопринимается так, как будто это не самостоятельная надстройка над Redis. Нужно попытаться попытаться изменить это, наверное, более хардкорными новостями о кодовой базе, о этапах разработки и.т.п.
В примере с магазином Ашан, наверное, имеется опечатка:
throughput (пропускная способность) у него большая, т.к. много касс.
Т.е. latency для вас будет очень большим, но throughput у этого магазина маленький.
throughput (пропускная способность) у него большая, т.к. много касс.
Смотрел даже несколько видео с Костей Осиповым, он популярно объясняет чем они круче Redis-а, (с маркетинговой точки зрения зря вообще затеяли такое сравнение, ибо получается что всегда гонитесь его опередить, хотя имеете и другие преимущества), например LuaJit + фулл луа поддержка выглядит в tarantool вкуснее. Но есть какое-то наплевательское отношение к созданию своего сообщества:
1) Нет билда под win, год-полтора назад спрашивали в гугл группах, ответ где-то в видео 2014-2015 года типа там затрат на пару месяцев, никто не будет этим заниматься
2) Насколько помню нет клиента для .net
Ребят, я за продвижение тарантула, вещь реально интересно выглядит, но вы игнорируете windows системы, наплевательски относитесь к формированию сообщества.В Gitter последнее сообщение
апр. 21 2016 г. Тухло с сообществом потому что в основной массе это люди-пользователи, а не не хотят сами писать порт на вин, они хотят скачать бинарники и пользоваться. (Redis берет как раз сообществом + приличной скоростью, мне например чтобы начать что-то на win достаточно скачать пару бинарников, на проде развернуть уже использовать линь если требуется, с тарантулом мне нужно создать виртуалку, удобства разработки значительно меньше)
1) Нет билда под win, год-полтора назад спрашивали в гугл группах, ответ где-то в видео 2014-2015 года типа там затрат на пару месяцев, никто не будет этим заниматься
2) Насколько помню нет клиента для .net
Ребят, я за продвижение тарантула, вещь реально интересно выглядит, но вы игнорируете windows системы, наплевательски относитесь к формированию сообщества.В Gitter последнее сообщение
апр. 21 2016 г. Тухло с сообществом потому что в основной массе это люди-пользователи, а не не хотят сами писать порт на вин, они хотят скачать бинарники и пользоваться. (Redis берет как раз сообществом + приличной скоростью, мне например чтобы начать что-то на win достаточно скачать пару бинарников, на проде развернуть уже использовать линь если требуется, с тарантулом мне нужно создать виртуалку, удобства разработки значительно меньше)
У редиса порт на винду официально не поддерживается, но есть чьи-то потуги его сделать. Не совсем понятно, какой в этом смысл: на проде эксплуатировать редис или тарантул на винде бессмысленно. Даже stackexchange, имея целиком виндовую инфраструктуру, держит редисовые серверы на линуксе.
Для стендов разработчиков у многих и так вагрант или девелоперские виртуалки в облаке. Редису и тарантулу на винде просто нет применения.
Для стендов разработчиков у многих и так вагрант или девелоперские виртуалки в облаке. Редису и тарантулу на винде просто нет применения.
В плане создания сообщества, мне кажется, появление документации на русском перевешивает версию для windows (https://tarantool.org/doc/ru/index.html)
Всё таки для винды можно просто докер образ развернуть без установок виртуалки, докер на 10 винде нативно работает
https://docs.docker.com/docker-for-windows/
https://hub.docker.com/r/tarantool/tarantool/
Всё таки для винды можно просто докер образ развернуть без установок виртуалки, докер на 10 винде нативно работает
https://docs.docker.com/docker-for-windows/
https://hub.docker.com/r/tarantool/tarantool/
Документации на английском достаточно, например Sphinx, имеет только английскую версию документации и все хорошо. Кстати и билдится очень легко. Конечно русская версия документации это плюс, но я все же за win порт двумя руками, кажется даже есть fork их менеджера памяти small, где энтузиаст портанул её (ну или пытался, я не проверял).
p.s. иногда бывают требования заказчика — винда, закрытая сеть, все дела, это тоже не стоит забывать
p.s. иногда бывают требования заказчика — винда, закрытая сеть, все дела, это тоже не стоит забывать
Так все сообщество давно переехало с Gitter в Telegram, есть англо говорящая группа в телеграмм https://telegram.me/tarantool, есть так же русско говорящая группа, но по инвайту, просто напишите в англо говорящий чат и вам вышлют инвайт. А уже в группе телеграмма вам помогут, и ответят на все вопросы по поводу Lua и тарантула, и ответят ответить могут сами разработчики тарантула.
В самостоятельном тестировании различных систем профит не только в изучении их поведения на собственных нагрузках и задачах, но и в том, что в процессе обрастаешь опытом и новыми знаниями: утилиты тестирования, поднятие и настройка хранилищ данных и т.п.
Извините за пятничный P.S., но судя по почерку и цвету на слайдах, жена помогла не только отпечатком ноги :)
Извините за пятничный P.S., но судя по почерку и цвету на слайдах, жена помогла не только отпечатком ноги :)
О каких потоках идёт речь? Это количество потоков из которых тестер шлёт запросы к БД? Добавьте плиз пояснение в текст, а то не очень понятно с первого взгляда.
Забавно читать, что автор говорит вы инженеры и выбирать по совету друга это плохо, а инструмент тестирования выбирает вот так: «Во-первых, она является отраслевым стандартом, ему все доверяют, т.е. ею, вообще, тестируют NoSQL базы данных» :))
Как понять, что тестируемая БД настроена лучшим образом для прохождения нагрузочного тестирования, если к тестированию не привлечены разработчики этой БД?
Есть великое множество сравнений более традиционных RDBMS противоречивых по результатам. И ожидаемо лучше оказывается та БД, которую автор тестирования лучше знает, и может в нужных местах подкрутить.
Нельзя качественно протестировать некоторую систему, находясь внутри этой системы. Сравнение нескольких баз данных, разработчиком одной из которых ты являешься — изначально не может быть корректным. Это как каждый первый браузер рассказывает о себе, что он быстрее остальных, или энергоеффективнее.
Заказали бы независимое тестирование кому-нибудь авторитетному, не связанному напрямую с разработкой БД — можно было бы читать.
Заказали бы независимое тестирование кому-нибудь авторитетному, не связанному напрямую с разработкой БД — можно было бы читать.
Когда наконец появится поддержка SQL запросов?
Такая огромная статья по выбору БД и ни одного слова об уровне обеспечиваемой консистентности. По-моему это позор.
Если верить Gil Tene, ycsv страдает от coordinate omission. Это очень заметно при скачках в latency. Хорошее видео от него https://youtu.be/ElbYf2uiPmQ
Какая странная буква «Д» у вас
как-то раз работал в конторе использующей eXtremeDB для обмена данными от датчиков в реальном времени, мне понравилась ее производительность, почему ее не включили в тест…
На одном Ашане следовало бы объяснять. Весьма грубо термин throughput в Ашане означает, что в магазине работают не все кассы, а, если все, то некоторые кассиры за кассами спят. Грубо throughput текущее количество обслуженных покупателей на кассах. Когда работают все кассы и кассиры работают с полной отдачей в одном и другом магазинах — это bandwich.
Достаточно странные результаты получились для Redis.
20K-30K запросов в секунду характерны для синхронной работы с Redis расположенном на той же машине.
В асинхронном режиме (pipeline) на встроенном бенчмарке Redis показывал у нас более миллиона запросов в секунду даже в случае разнесенных по разным машинам клиента-сервера.
20K-30K запросов в секунду характерны для синхронной работы с Redis расположенном на той же машине.
В асинхронном режиме (pipeline) на встроенном бенчмарке Redis показывал у нас более миллиона запросов в секунду даже в случае разнесенных по разным машинам клиента-сервера.
Sign up to leave a comment.
Как выбрать In-memory NoSQL базу данных с умом. Тестируем производительность