All streams
Search
Write a publication
Pull to refresh
22
0
Роман Цисык @rtsisyk

User

Send message
За любыми серьезными open-source проектами в большинстве своем стоит какая-то организация, а то и не одна.
Все указанные проекты в том или ином виде поддерживаются Mail.Ru, как именно — это уже малоинтересные юридические тонкости.

Некоторые вещи были куплены за квазиллиарды денег и выложены в открытый доступ (Maps.Me), некоторые — написаны полностью внутри компании (tarantool.org).
Надо понимать, что у Mail.Ru Group и Mozilla Foundation все же немного разный бизнес.

Основной продукт Mozilla — open source браузер Firefox — разрабатывается по полностью открытой модели разработки. Все утилиты, скрипты, документация, исходники сайта и прочее находятся в hg репозиториях на mozilla.org. А с учетом того, что проект реально очень (ОЧЕНЬ) большой, количество репозиториев просто зашкаливает по естественным причинам.

В Mail.Ru по аналогичной модели разрабатывается Tarantool. У нас точно также доступно всё до последнего байта, включая внутренние тулзлы, скрипты сборки и планы развития. И мы не занимаемся «выкладыванием» каких-то непонятных исходников. На GitHub ведется реальная разработка, в открытом режиме. Можно вот даже план на следующий релиз почитать: github.com/tarantool/tarantool/issues/1209.

Теперь ради интереса сравните количество сотрудников в Mozilla Corporation/Foundation и в Тарантуле. В одной только Mozilla Corporation более 1000 человек (см. википедию), тогда как в Tarantool можно по пальцам пересчитать. Да и бюджет не сотни лямов $$, как у Mozilla.
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
Мы подобную статью тоже написали articles.rvncerr.org/how-to-chose-an-in-memory-nosql-solution-performance-measuring
Продвигать будем в том числе и на западный рынок, но наши ресурсы не безграничны.
Вчера в комментариях просили рассказать о реальных use-case использования Tarantool.
Вот и один из реальных примеров, правда еще на предыдущей версии Тарантула. Сервис в проде (cloud.mail.ru).

В какой-то мере согласен с Вами. Пока что статей от early adopters Tarantool 1.6, прошедших семь кругов ада с управлением зависимостями, CI, deploy, тестированием, мониторингом и прочим, не так много, как хотелось бы. На конференциях были хорошие доклады, но надо постараться донести свой опыт и в виде статей. Также на митапе постараемся рассмотреть больше реальных use cases.
articles.rvncerr.org/how-to-chose-an-in-memory-nosql-solution-performance-measuring вот здесь есть статья по мотивам доклада.
Если задача состоит в том, что надо получить данные с устройства, немного их обработать и сразу же сохранить в БД, то какой смысл здесь городить целый стек tomcat + play + postgresql, если один тарантул с http на борту сделает тоже самое?
Про модуль для nginx писали тоже не так давно: habrahabr.ru/company/mailru/blog/272141
возможно, он там и не нужен был.
Расскажите как use-case у Вас…
Вы говорите сейчас о так называемой «фрагментации памяти». Естественно, что решить NP-полную задачу выделения памяти идеально для всех случаев невозможно, но можно свести фрагментацию к минимуму для ваших конкретных данных. Именно поэтому Tarantool использует аж целое семейство специализированных аллокаторов под разные задачи, а также дает различные ручки для их настройки. На HighLoad++ в этом году аж целый доклад был про особенности в СУБД для данных в оперативной памяти (видео пока организаторы не дают).

У нас же не монгаWebScale, нет никакого пустого места ни в каких файлах в принципе.
В случае in-memory мы пишем append only write-ahead-log (binary log) и периодически делаем снапшоты на диск. Индексы вообще хранятся полностью в памяти.

На Хайлоаде был знатный доклад тех. дира почты (почты Mail.Ru, Карл) про сэкономленный миллион долларов на Тарантуле.
Как раздобуду презентацию — постараюсь выложить.
Фидбек всегда ждем, поскольку на его основе мы планируем новые фичи.

row-based на запросы к самой базе.
Кстати вызовы хранимок на слейвы тоже не проигрываем, как некоторые, передаем лишь сделанные изменения в базе.

В плане базы данных у нас все честно. ACID самый что ни на есть настоящий.
Мастер-Мастер есть уже более года, с каждым релизом делаем всё проще и удобнее.

Немного поправлю, 32-40 с одним индексом (сервер->файлы) и примерно 48-56 с двумя (файл->сервер + сервер->файлы).
Над утилизацией памяти мы активно работаем, есть чем похвастаться. Остальные перечисленные фишки (persistency, fault tolerance, master-master replication) также есть из коробки.

Смешались в кучу кони, люди :) Я не очень понимаю как можно сравнивать play framework и bdb, ведь это совершенно разные инструменты для разных задач.

Для телеметрии от датчиков и прочего IoT сервис можно поднять сервис напрямую на тарантуле, хоть по HTTP, хоть MQTT какой-нибудь на луа. В таком раскладе tomcat c play может оказаться вам просто не нужен. Собственно в этом и есть соль статьи.

Кстати, с графиками у нас есть няшный пример — bench.farm.tarantool.org

box.schema.space.create('in_memory', { engine = 'memtx' }) — храним в памяти
box.schema.space.create('on_disk', { engine = 'sophia' }) — храним на диске
При том что мы используем общий binlog для всех движков, репликация и прочие фишки будут работать одинаково.
Сравнение разумно проводить в разрезе с какими-то другими конкретными решениями, но в целом это тема для отдельной докторской диссертации статьи :) Расскажите о своей задаче и мы скажем насколько Tarantool для неё подходит.
Само приложение лучше делать отдельно в виде модуля и помещать в /usr/share/tarantool/myapp.
В etc лучше оставить только конфигурацию. Изменение настроек на лету можно делать через админку, правда не все опции пока меняются.
Я думаю мы еще напишем об этом.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity