Каждый, кто работал с большими кластерами, знает: данные все время растут. Рано или поздно перед разработчиками распределенных систем встает задача масштабирования. Сейчас найти место для хранения данных не проблема, но как быть с доработкой и настройкой приложений? Доработки можно избежать, если заранее заложить в систему возможность масштабирования. Можно разделить узлы приложения по типу выполняемой функциональности и развёртывать только то, что необходимо. 

Меня зовут Игорь, я работаю в команде Tarantool. У нас большой опыт разработки высоконагруженных продуктов, например, систем хранения данных для крупных ритейлеров или операторов сотовой связи. Сегодня я расскажу о принципах масштабирования наших кластеров и покажу типовой пример. Будет интересно всем, кто работает с большими данными и задумывается о масштабировании.

Привет, меня зовут Игорь и я работаю в команде Tarantool. При разработке мне часто требуется быстрое прототипирование приложений с базой данных, например, для тестирования кода или для создания MVP. Конечно же хочется, чтобы такой прототип требовал минимальных усилий по доработке, если вдруг будет решено пустить его в работу.

Мне не нравится тратить время на настройку SQL базы данных, думать, как управлять шардированием данных, тратить много времени на изучение интерфейсов коннекторов. Хочется просто написать несколько строчек кода и запустить его, чтобы все работало из коробки. В быстрой разработке распределенных приложений мне помогает Cartridge — фреймворк для управления кластерными приложениями на основе NoSQL базы данных Tarantool.

Сегодня я хочу рассказать о том, как можно быстро написать приложение на Cartridge, покрыть его тестами и запустить. Статья будет интересна всем, кто устал тратить много времени на прототипирование приложений, а также людям, которые хотят попробовать новую NoSQL технологию.

Привет, меня зовут Игорь, и я разработчик решений на Tarantool в Mail.ru Group. Я работаю над витринами маркетинга в реальном времени для Мегафона. При мониторинге часто требуется использовать перцентили. Они позволяют понять, как система работает бóльшую часть времени, в отличие от усреднения значений, которое сильно подвержено влиянию выбросов. Если 9 из 10 запросов выполняются за 1 секунду, а один за 10 секунд, то среднее будет 1,9 секунды, а 50-перцентиль — 1 секунда. Это лишь один пример того, что среднее значение не подходит для мониторинга. Возникает необходимость считать перцентили, для этого мы добавили в tarantool/metrics Summary-коллектор.