Комментарии 59
Что-то вас понесло конечно) Я когда-то рассматривал тарантул в качестве бд, но ещё на этапе бд она уже была разнобокая — хранение на диске и в памяти было реализовано по-разному, в итоге прихоодилось выбирать либо только то, либо только это. А теперь, когда ваш тарантул превратился и в веб-сервер-клиент-api-parser и т.д. уже совсем непонятно, в какой реальной задаче требуется это всё?
Это все инструменты, не обязательно их все использовать, к примеру, можно использовать только in-memory или только storage.
Кстати, многие проекты которые начинались как БД обросли не меньше.
Кстати, многие проекты которые начинались как БД обросли не меньше.
У меня вообще обрабатывает звонки из телефонии. Можно делать что хочешь, и как хочешь.
box.schema.space.create('in_memory', { engine = 'memtx' }) — храним в памяти
box.schema.space.create('on_disk', { engine = 'sophia' }) — храним на диске
При том что мы используем общий binlog для всех движков, репликация и прочие фишки будут работать одинаково.
box.schema.space.create('on_disk', { engine = 'sophia' }) — храним на диске
При том что мы используем общий binlog для всех движков, репликация и прочие фишки будут работать одинаково.
Что-то я на Highload поспрашивал используется ли оно хоть где-то в production, и не получил положительных ответов.
Как я понял, Mail.ru это делает чисто для поиграться, и ищет желающих подопытных все-таки попробовать это в работе…
Т.е. по сути очистка кармы перед OSS сообществом и информационный повод.
Как я понял, Mail.ru это делает чисто для поиграться, и ищет желающих подопытных все-таки попробовать это в работе…
Т.е. по сути очистка кармы перед OSS сообществом и информационный повод.
Всё Mail.Ru на Tarantool. Серьезно.
Это странное утверждение. На стенде рассказывали что оно используется в Badoo, Avito, Wallarm, да и во всём Мейл.Ру.
Не особо понятно о каком «Mail.ru это делает чисто для поиграться» идёт речь.
Не особо понятно о каком «Mail.ru это делает чисто для поиграться» идёт речь.
На стенде говорили что его пробуют много где.
Пробовать — не значит использовать в проде.
На прямой вопрос о том в каких кейсах Mail.Ru использует Tarantool мне фактически не ответили, съехали с разговора.
На всех докладах говорилось что они ждут фидбек от тех кто использует в проде.
Как я понял своего фидбека нет…
Пробовать — не значит использовать в проде.
На прямой вопрос о том в каких кейсах Mail.Ru использует Tarantool мне фактически не ответили, съехали с разговора.
На всех докладах говорилось что они ждут фидбек от тех кто использует в проде.
Как я понял своего фидбека нет…
На Хайлоаде был знатный доклад тех. дира почты (почты Mail.Ru, Карл) про сэкономленный миллион долларов на Тарантуле.
Как раздобуду презентацию — постараюсь выложить.
Фидбек всегда ждем, поскольку на его основе мы планируем новые фичи.
Как раздобуду презентацию — постараюсь выложить.
Фидбек всегда ждем, поскольку на его основе мы планируем новые фичи.
Так вот же он it.mail.ru/video/253
Вот ещё про использование Tarantool в «Облаке@Mail.Ru»
+ Badoo, Avito, Wallarm, чуток в Сбербанке, и др.
Я использую в продакшене: 4 сервера в кластере с 96Gb, суммарно 320Gb памяти под тарантулы.
Хранятся порядка 5 млрд записей, в среднем по 40 байт. Uptime 2 года без без каких либо вмешательств и обновлений.
Никакая база так эффективно не может хранить столько мелких данных так эффективно в оперативке.
Бизнес логика зашита в lua процедурах, и запросы идут в batch режиме.
Если бы не было lua процедур, batch режим был бы не доступен, т.к. изменение данных зависят от других данных в базе: пара селектов и один апдейт. Это было бы 3 раунд-трипа на одну операцию изменения, а тут удается упаковать 50 операций в один раунд-трип.
Хранятся порядка 5 млрд записей, в среднем по 40 байт. Uptime 2 года без без каких либо вмешательств и обновлений.
Никакая база так эффективно не может хранить столько мелких данных так эффективно в оперативке.
Бизнес логика зашита в lua процедурах, и запросы идут в batch режиме.
Если бы не было lua процедур, batch режим был бы не доступен, т.к. изменение данных зависят от других данных в базе: пара селектов и один апдейт. Это было бы 3 раунд-трипа на одну операцию изменения, а тут удается упаковать 50 операций в один раунд-трип.
2 года без обновлений? Смело.
4 сервера в кластере, у вас Master->3xSlave?
Просто Master-Master появился в Tarantool чуть больше месяца назад и использовать подобное решение для боевых данных без проверки временем рисковано.
Раудтрипы убираются в любой БД встроенными процедурами.
Почему взяли Tarantool?
4 сервера в кластере, у вас Master->3xSlave?
Просто Master-Master появился в Tarantool чуть больше месяца назад и использовать подобное решение для боевых данных без проверки временем рисковано.
Раудтрипы убираются в любой БД встроенными процедурами.
Почему взяли Tarantool?
Не ясно откуда утверждение про эффективность хранения.
В Tarantool не шардинга, только поделка на коленке от инженеров Mail.Ru без понимания принципа ACID.
Очевидно что либо Tarantool не хранит все данные в ОЗУ, либо у вас свой наколеночный шардинг.
И опять таки, почему не использовать взрослые решения и с чем вы сравнивали?
И сравнивали ли вы вообще…
В Tarantool не шардинга, только поделка на коленке от инженеров Mail.Ru без понимания принципа ACID.
Очевидно что либо Tarantool не хранит все данные в ОЗУ, либо у вас свой наколеночный шардинг.
И опять таки, почему не использовать взрослые решения и с чем вы сравнивали?
И сравнивали ли вы вообще…
В плане базы данных у нас все честно. ACID самый что ни на есть настоящий.
Мастер-Мастер есть уже более года, с каждым релизом делаем всё проще и удобнее.
Мастер-Мастер есть уже более года, с каждым релизом делаем всё проще и удобнее.
Сравнивал (мемкеш, монго, мускуль, редис, токио кабинет), но расписывать все не хочу, могу ответить по конкретным конкурентам, про которые вы хотели бы знать.
На HighLoad был доклад от Дмитрия Калугина-Балашова о выборе базы данных.
articles.rvncerr.org/how-to-chose-an-in-memory-nosql-solution-performance-measuring вот здесь есть статья по мотивам доклада.
Вы просили — мы сделали. habrahabr.ru/company/mailru/blog/272769
У нас в плюсофоне используется.
Отлично, кто-то живой с опытом production use.
Ответьте пожалуйста на вопросы, думаю всем будет интересно:
Под какие структуры данных?
Какой стор используете?
Масштабируете?
Почему именно Tarantool?
Ответьте пожалуйста на вопросы, думаю всем будет интересно:
Под какие структуры данных?
Какой стор используете?
Масштабируете?
Почему именно Tarantool?
1. Разные данные, есть где пары звонков с индексами по несколько ключам, есть просто куча данных которые по кругу через очередь ротируются.
2. У меня memtx и почти все режиме temporary=true.
3. Стоит http встроенный, и nginx балансирует нагрузку. На сокетах протоколы (AGI & AMI) из АТС (Asterisk).
4. Очень удобно программировать на Lua (нет лишних знаков препинания), и сразу есть куча ништяков. У меня не только Tarantool есть. Есть redis/riak которые пойдут под нож в будущем.
2. У меня memtx и почти все режиме temporary=true.
3. Стоит http встроенный, и nginx балансирует нагрузку. На сокетах протоколы (AGI & AMI) из АТС (Asterisk).
4. Очень удобно программировать на Lua (нет лишних знаков препинания), и сразу есть куча ништяков. У меня не только Tarantool есть. Есть redis/riak которые пойдут под нож в будущем.
Переносим скриптец в /etc/tarantool/instances.enabled/myapp.lua и запускаем уже через готовые утилиты для init (tarantoolctl start myapp или даже service tarantool restart). Работает! Просто?
Все хорошо, но тогда приложение БД и http сервер нужно описывать в одном файле, иначе при рестарте http приложение заворачивается в event loop и на этом все! Я подозреваю, что server:start() должен вызываться вконце всего и вся.
И отсюда проблемы с перезапуском, service tarantool restart на большой БД (около 180кк туплов ) занимает порядка 15минут!!! А тебе всего лишь нужно было добавить новый route и handler.
Использовать «tarantoolctl eval \<app\>» , по хорошему. Никакого перезапуска, только перезагрузка файла конфигурации.
ну, плюсы обозначены. а какие минусы в сравнении с другими архитектурами? сравнивали?
какие шишки успели набить? где стелить солому?
Всё Mail.Ru на Tarantool. Серьезно.
какие шишки успели набить? где стелить солому?
Сравнение разумно проводить в разрезе с какими-то другими конкретными решениями, но в целом это тема для отдельной докторской диссертации статьи :) Расскажите о своей задаче и мы скажем насколько Tarantool для неё подходит.
Я и надеялся, что такие сравнения проводились.
Вот, например возьмем кейс, который мне интересен: веб-сервис, принимающий на вход потоки маленьких сущностей, например телеметрию от тысяч датчиков, которые куда-то сложить и потом сравнительно быстро показать график или выбрать данные за последний час для любого из них.
Задача наглядная, и частично покрыта Асинхронная работа с Tarantool на Python. Но если взять вместо tarantool что-то из набора: tomcat, play2, mina, go, mysql, postgresql, berkleydb — где станет хуже/лучше?
ps. то что будет солянка их технологий — меня не пугает. от неё все равно не уйти. интересует только какие проблемы добавит tarantool.
Вот, например возьмем кейс, который мне интересен: веб-сервис, принимающий на вход потоки маленьких сущностей, например телеметрию от тысяч датчиков, которые куда-то сложить и потом сравнительно быстро показать график или выбрать данные за последний час для любого из них.
Задача наглядная, и частично покрыта Асинхронная работа с Tarantool на Python. Но если взять вместо tarantool что-то из набора: tomcat, play2, mina, go, mysql, postgresql, berkleydb — где станет хуже/лучше?
ps. то что будет солянка их технологий — меня не пугает. от неё все равно не уйти. интересует только какие проблемы добавит tarantool.
Смешались в кучу кони, люди :) Я не очень понимаю как можно сравнивать play framework и bdb, ведь это совершенно разные инструменты для разных задач.
Для телеметрии от датчиков и прочего IoT сервис можно поднять сервис напрямую на тарантуле, хоть по HTTP, хоть MQTT какой-нибудь на луа. В таком раскладе tomcat c play может оказаться вам просто не нужен. Собственно в этом и есть соль статьи.
Кстати, с графиками у нас есть няшный пример — bench.farm.tarantool.org
Для телеметрии от датчиков и прочего IoT сервис можно поднять сервис напрямую на тарантуле, хоть по HTTP, хоть MQTT какой-нибудь на луа. В таком раскладе tomcat c play может оказаться вам просто не нужен. Собственно в этом и есть соль статьи.
Кстати, с графиками у нас есть няшный пример — bench.farm.tarantool.org
Смешались в кучу кони, люди :) Я не очень понимаю как можно сравнивать play framework и bdb
не надо сравнивать одно с другим. вопрос был про Tarantool vs others. Потому что статья называется «Tarantool как сервер приложений», да и сам тарантул вроде как база чуть-чуть. поэтому и сравнивать можно/надо со стеком, в котором компонентами может быть как play, так и bdb.
как можно сделать телеметрию с тарантулом — придумать можно. но пока не попробуешь — плюсы не очевидны, а грабли — не видны
Если задача состоит в том, что надо получить данные с устройства, немного их обработать и сразу же сохранить в БД, то какой смысл здесь городить целый стек tomcat + play + postgresql, если один тарантул с http на борту сделает тоже самое?
Про модуль для nginx писали тоже не так давно: habrahabr.ru/company/mailru/blog/272141
Про модуль для nginx писали тоже не так давно: habrahabr.ru/company/mailru/blog/272141
Технический вопрос.
Стоит задача эффективно хранить сотню (или больше) миллионов записей вида (idA, idB) — т.е. отношение many-to-many. Например, что такой-то файл есть на таком-то сервере (файлов много и серверов много, один и тот же файл на разных серверах и соотв на одном сервере разные файлы). Как с этим справится тарантул? Сколько байт будет в среднем потребляться на одну запись (положим, айдишники по 32 бита)? Нужны persistency, fault tolerance, master-master replication, индексированный доступ по обоим полям (т.е. эффективно получить список серверов для файла и список файлов на сервере).
Стоит задача эффективно хранить сотню (или больше) миллионов записей вида (idA, idB) — т.е. отношение many-to-many. Например, что такой-то файл есть на таком-то сервере (файлов много и серверов много, один и тот же файл на разных серверах и соотв на одном сервере разные файлы). Как с этим справится тарантул? Сколько байт будет в среднем потребляться на одну запись (положим, айдишники по 32 бита)? Нужны persistency, fault tolerance, master-master replication, индексированный доступ по обоим полям (т.е. эффективно получить список серверов для файла и список файлов на сервере).
32-40 байт на запись, с учётом памяти под данные и индексы.
Есть ли у тарантула проблема с index bloating? Если индексы ещё можно пересоздать на ходу (можно ж на ходу создать индекс?) то как обстоит с фрагментацией в файлах данных? Сколько будет занимать пустое место (от удаленных записей) в файлах базы под активной нагрузкой?
У нас же не монгаWebScale, нет никакого пустого места ни в каких файлах в принципе.
В случае in-memory мы пишем append only write-ahead-log (binary log) и периодически делаем снапшоты на диск. Индексы вообще хранятся полностью в памяти.
В случае in-memory мы пишем append only write-ahead-log (binary log) и периодически делаем снапшоты на диск. Индексы вообще хранятся полностью в памяти.
Индексы вообще хранятся полностью в памяти.То что они хранятся в памяти ещё не означает что нет проблемы с раздуванием. Например, тарантул запустился, загрузил 100М записей, проиндексировал их и это заняло 5ГБ памяти. Потом пошла работа — какие-то данные удалились, какие-то добавились, в итоге их осталось те же 100М, но уже других. В ходе работы потребление памяти будет расти. Например, при записях нефиксированной длины будут оставаться дырки, когда на место большой записи будет добавлена маленькая, а оставшееся место уже не сможет уместить ни одну запись. Обновление индексов тоже влечет за собой постоянное перемещение указателей для сохранения балансировки дерева — в итоге часть нод будет заполнена совсем не так плотно, как могла бы.
Если в процессе работы будет заменено в случайном порядке 200% записей (т.е. 200М обновлений для 100М записей) — во сколько раз вырастет потребление памяти? Для постгреса, например, размер индекса легко вырастает в несколько раз при активной нагрузке.
Вы говорите сейчас о так называемой «фрагментации памяти». Естественно, что решить NP-полную задачу выделения памяти идеально для всех случаев невозможно, но можно свести фрагментацию к минимуму для ваших конкретных данных. Именно поэтому Tarantool использует аж целое семейство специализированных аллокаторов под разные задачи, а также дает различные ручки для их настройки. На HighLoad++ в этом году аж целый доклад был про особенности в СУБД для данных в оперативной памяти (видео пока организаторы не дают).
У посгри есть вакуум. Советую вам попробовать, если вам подходит решение такого класса как Tarantool, если будут не понимание в использование у нас открытое комьюнити обращайтесь — поможем.
А решать задачи абстрактно, гипотетически немного не благодарное занятие.
А решать задачи абстрактно, гипотетически немного не благодарное занятие.
Lua это хорошо, это вам не q/kdb.
Ребята. Вы странно пиарите продукт. Будь он сто раз крут, я не возьму его пока не увижу use cases. Потом связка lua application server является диковиной, никто не представляет как это готовить.
Предлагаю вам написать приложение. Идеально если это будет не веб чатик, а что то полезное у вас в компании. Выложите все это в open source. Расскажите с нуля что как делали. Как код структурировали, базу проектировали, управляли зависимостями, CI, deploy, мониторинг и тд.
Предлагаю вам написать приложение. Идеально если это будет не веб чатик, а что то полезное у вас в компании. Выложите все это в open source. Расскажите с нуля что как делали. Как код структурировали, базу проектировали, управляли зависимостями, CI, deploy, мониторинг и тд.
В какой-то мере согласен с Вами. Пока что статей от early adopters Tarantool 1.6, прошедших семь кругов ада с управлением зависимостями, CI, deploy, тестированием, мониторингом и прочим, не так много, как хотелось бы. На конференциях были хорошие доклады, но надо постараться донести свой опыт и в виде статей. Также на митапе постараемся рассмотреть больше реальных use cases.
Мне кажется вы немного не туда смотрите. Не надо доносить что-то в статьях и встречах. Надо на сайте написать пачку железобетонных use cases в которых tarantool максимально подходит. Можно сравнить с какой нить базой, например Redis.
Гляньте для примера kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
А популяризация Tarantool происходит только в русской часте сети?
Гляньте для примера kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
А популяризация Tarantool происходит только в русской часте сети?
Статьи и сравнения (например, на tarantool.org) есть. Use cases не хватает, тоже пришли к такому мнению, будет исправляться, но не все сразу.
А популяризация Tarantool происходит только в русской часте сети?
Не только в русской части сети.
А популяризация Tarantool происходит только в русской часте сети?
Не только в русской части сети.
Мы подобную статью тоже написали articles.rvncerr.org/how-to-chose-an-in-memory-nosql-solution-performance-measuring
Продвигать будем в том числе и на западный рынок, но наши ресурсы не безграничны.
Продвигать будем в том числе и на западный рынок, но наши ресурсы не безграничны.
А нет никакого инструментария для управления зависимостями там и тп? Ранние адаптеры не выкладывают своих решений?
luarocks [1], если поиграться на коленках (типа как pip, gem, npm и прочее).
Если в боевую, то deb/rpm пакеты. Можно использовать нашу инфраструктуру [2][3] для сборки своих аппликух под нужные платформы.
[1]: rocks.tarantool.org
[2]: github.com/tarantool/modulekit
[3]: github.com/tarantool/http/blob/master/.travis.yml
Если в боевую, то deb/rpm пакеты. Можно использовать нашу инфраструктуру [2][3] для сборки своих аппликух под нужные платформы.
[1]: rocks.tarantool.org
[2]: github.com/tarantool/modulekit
[3]: github.com/tarantool/http/blob/master/.travis.yml
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Tarantool как сервер приложений