Нередко оказывается, что даже в большом «зоопарке» общедоступных решений нет инструмента, отвечающего всем требованиям. В таком случае команды вынуждены двигаться в сторону разработки своего продукта.
Меня зовут Александр Кленов. Я тимлид разработки Tarantool DB в команде Tarantool. В этой статье я расскажу, почему мы решили добавить в свой продуктовый портфель Tarantool DB и что реализовали в инструменте, а также покажу на примере словарей, почему строить свою СУБД сложно.
В прошлом году Tarantool исполнилось 15 лет. Он прошел долгий путь от обычного кэша до платформы управления данными с десятками разных внутренних продуктов и расширений. Такое обилие инструментов создает множество возможностей — и в этой статье мы расскажем о десяти, о которых многие забывают или попросту не знают.
Масштабирование ИТ-инфраструктуры и переход к высоконагруженным многокомпонентным сервисам дает бизнесу не только преимущества, но и сложности. Одна из основных — необходимость обеспечения для сервисов возможности отказоустойчиво и надежно обмениваться тысячами сообщений без риска их потери или повреждения. И в этих задачах часто не обойтись без реализации очередей сообщений.
Рассказываем об основных сложностях развития высоконагруженных ИТ-систем и способах их преодоления с помощью очередей сообщений на примере Tarantool Queue Enterprise.
Материал подготовлен по мотивам вебинара «Как создавать высокопроизводительные очереди сообщений с различной архитектурой». Вы можете посмотреть его здесь.
Распределённая блокировка — очень удобный инструмент в кластере, который помогает обеспечивать эксклюзивный доступ к некоторому общему ресурсу. Цель такой блокировки — обеспечить доступ к ресурсу лишь одному сервису или запросу в данный момент времени. Так предотвращается гонка за данными и их неконсистентность. Распределённая (или кластерная) блокировка называется так потому, что она обеспечивается несколькими узлами, и выход из строя одного из них не повлияет на приложение. В этой статье я расскажу, как реализовать этот инструмент с помощью Tarantool 3.
С ростом сложности ИТ-систем и задач аналитики изменяются требования и к возможностям инструментов. Для многих сценариев приоритетными становятся решения, которые могут работать как с историческими данными, так и с теми, которые обновляются в реальном времени. То есть аналитикам все чаще нужен инструмент, работающий на стыке возможностей транзакционных и аналитических (OLAP и OLTP) систем.
Меня зовут Николай Карлов. Я директор инновационных проектов в VK Tech. В этой статье я расскажу, что такое HTAP-системы, какие преимущества они предоставляют, и познакомлю с нашей колоночной СУБД Tarantool Column Store, которая реализует HTAP-обработку.
Статья подготовлена по мотивам вебинара «Анализируем данные в Real-time». Его вы можете посмотреть здесь.
С увеличением сложности ИТ-систем все больше становится очевидной ограниченность привычных реализаций с простой архитектурой компонентов. Особенно это заметно в случае систем, которые должны стабильно работать с большими и интенсивными нагрузками.
Чтобы понять это, достаточно рассмотреть механику разворачивания большинства высоконагруженных систем. Например, разобрать построение системы авторизации пользователей для последующей сквозной аналитики авторизации/аутентификации между связанными сервисами компании.
Разбираемся на примере клиентского кейса, как может выглядеть такая система в части хранения данных, почему для таких задач оптимальна комбинация реляционной БД и Tarantool, а также показываем, какие показатели может обеспечить система с Tarantool.
В этой статье я опишу наш путь реализации глобальных индексов в шардированной базе данных. Расскажу обо всех проблемах, с которыми столкнулись, и решениях, которые приняли, чтобы их обойти. Мы поговорим про реализацию на основе базы данных Tarantool, но общий подход применим и к другим шардированным базам данных без встроенной поддержки таких индексов, да и встроенная реализация часто строится по похожим принципам. Эта статья поможет разобраться в деталях, компромиссах и ограничениях работы глобальных индексов.
Если вам когда-нибудь доводилось писать скрипты для Тарантула, то вы наверняка сможете понять мою боль. Тарантул - удивительный инструмент, который позволяет не только хранить относительно большие объёмы данных и обеспечивать поразительно быстрое выполнение операций CRUD над этими данными, но и предоставляет очень широкие возможности для обработки этих данных непосредственно в среде Тарантула. И под обработкой данных я имею ввиду не просто их валидацию и выполнение над ними каких-то математических операций, а почти весь спектр возможностей, предоставляемых языком Lua и ещё целую кучу полезных модулей, входящих в пакет поставки Тарантула или устанавливаемых из сторонних источников.
Для того чтобы написать, например, полноценный HTTP-сервер на Тарантуле (прошу не пинать меня за эту формулировку), нам нужно знать совсем немного - основы синтаксиса языка Lua и API основных модулей самого Тарантула. И вот если с Lua всё совсем просто - изучить этот язык за один вечер, я уверен, мало для кого окажется непосильной задачей - то вот с модулями Тарантула всё немного сложнее. Можно вдоль и поперёк проштудировать всю официальную документацию и уже непосредственно во время написания скрипта столкнуться с одной неприятной проблемой - писать относительно большие вещи для Тарантула жутко неудобно.
Привет, Хабр! Меня зовут Сергей Скубач, я работаю в VK и разрабатываю облачное хранилище WorkDisk. Мы используем Tarantool в своём продукте, так как его разрабатывают и развивают наши коллеги. Я впервые столкнулся с Tarantool именно в VK, и для более глубокого понимания решил попробовать использовать его в своём pet-проекте.
Постараюсь рассказать о сложностях, с которыми столкнулся при внедрении Tarantool-а с позиции разработчика, впервые работающего с этой базой данных.
