LINUX.ORG.RU

Tarantool 2.8

 , , ,

Tarantool 2.8

1

1

Вышла новая версия персистентной in-memory NoSQL СУБД Tarantool. Проект написан на языке C и позволяет программировать хранимые процедуры на Lua (движок LuaJIT).

Главные изменения:

  • Стабилизировано MVCC (Многоверсионное управление конкурентным доступом) в in-memory движке memtx.
  • Добавлена поддержка транзакционности в бинарном протоколе IPROTO. Раньше для транзакции необходимо было написать хранимую процедуру на языке Lua.
  • Добавлена синхронная репликация, работающая потаблично (per-table).
  • Реализован механизм автоматического переключения мастера (failover) на базе протокола RAFT. В Tarantool уже реализована асинхронная WAL-based репликация, теперь можно не следить за мастером вручную.
  • Автоматическое переключение мастера также доступно в случае топологии с шардированием данных (библиотека vshard). Vshard — это библиотека, распределяющая данные по серверам с помощью виртуальных корзин (bucket).
  • Tarantool Cartridge теперь он лучше держит нагрузку при работе в виртуальных средах. Tarantool Cartridge — это фреймворк для построения кластерных приложений.
  • Ускорена работа Ansible-роли для развертывания кластера в 15-20 раз. Работа с большими кластерами стала проще. Появился инструмент для упрощенной миграции со старых версий >1.6 и < 1.10, который доступен с помощью дополнительной опции при старте без необходимости развёртывания промежуточной версии 1.10.
  • Оптимизировано хранения кортежей небольшого размера.
  • Добавлена поддержка UUID в SQL, улучшено преобразование типов.

Стоит отметить, что с версии 2.10 будет осуществлен переход на новую политику релизов.

>>> Русскоязычное сообщество в Telegram

>>> Подробности



Проверено: hobbit ()
Последнее исправление: sudopacman (всего исправлений: 5)

Немного странно в этой теме то, что оно однопоточное и при этом требует дикое кол-во памяти. Сервера это обычно много ядер с низкой частотой, а тут нужно совсем мало ядер с высокой частотой. Смахивает на десктопное железо, но много памяти это не про десктопы. Да и что это за «сервера» без ECC.

d9d9 ★★★★
()
Ответ на: комментарий от d9d9

Потому что многопоточность - это синхронизация, а синхронизация - это долго.

anonymous
()
Ответ на: комментарий от d9d9

Оно не «однопоточное» в узком смысле. Внутренняя архитектура Тарантула очень хорошо шардируется. «Поток на шард» — это нормально для операционных БД, в которых преобладают точечные запросы. Логика простая: если worker thread занят на 100%, то пора делать новый shard. Так удастся лучше утилизировать CPU по сравнению с тем, если бы использовались разделяемые данные и блокировки.

Тут архитекторам системы нужно отдать должное. В рамках выбранной ниши архитектура системы хорошо продумана (акторы, файберы и всё такое). Главное — не ждать от этой архитектуры чудес за пределами её зоны эффективности (линеаризуемые транзакции, single writer, single reader).

aist1 ★★★
()
Ответ на: комментарий от aist1

Оно не «однопоточное» в узком смысле. Внутренняя архитектура Тарантула очень хорошо шардируется.

Тут проблема в непропорциональности нужного количества памяти и количества ядер в современных процессорах. Судя из их описания два инстанса на одном сервере выжирают 250ГБ памяти на одном сервере. А типичный современный сервер нынче это порядка 16 ядер и больше. И где столько памяти брать? Ядра это дешевое горизонтальное масштабирование, к которому пришли эволюционным путём. А масштабировать новыми серверами это приблизительно как менять авто когда пепельница заполнилась.

d9d9 ★★★★
()
Ответ на: комментарий от d9d9

Обычно остальные ядра обрабатывают данные, которые из базы получены.

Хотя я наверное больше про бд типа level db/dbm/lmdb думаю - то есть те, которые как либа подключаются и по сути представляют гигантский хэш (или ordered map). Поэтому немного удивляет, зачем нужны хранимые процедуры.

anonymous
()
Ответ на: комментарий от d9d9

Это уже другой вопрос. У нас обычно или аналитика (много ядер молотят большие разделяемые статичные данные), либо OLTP (мало ядер насилуют небольшой объем разделяемых динамических данных). Либо какой-то гибрид, но тут все сильно сложнее. Так как базовых структур данных, которые были бы хороши и для аналитики, и для OLTP — нет. Есть персистентные структуры данных, как в LMDB, дающие single writer/multiple reader с взаимно неблокирующими писателями и читателем, но там будет оверхед CoW-деревьев. Зато полный параллелизм на чтение.

Т.е. вот в Тарантуле выбрали модель шардированных хэшмапов в RAM + WAL + акторная модель сериализации транзакций. Это хорошо для точечных транзакций. Но не хорошо для аналитики, которая хочет читать много статичных данных. Для второго случая нужен LMDB. Он тоже быстр на запись, но транзакции на запись должны быть короткими: «update table set F1 = X where F2 = Y» уже не прокатит. Т.е. прокатит, но все остальные писатели будут ждать. Серебряной пули нет.

aist1 ★★★
()
Ответ на: комментарий от aist1

Единственное, чего я в Тарантуле не понимаю, так это зачем там файберы для in-memory сценария. Файберы нужны, чтобы амортизировать задержки дисковой и/или сетевой подсистемы (выполняется тот файбер, для которого уже пришли данные).

aist1 ★★★
()
Ответ на: комментарий от anonymous

Поэтому немного удивляет, зачем нужны хранимые процедуры.

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

d9d9 ★★★★
()
Ответ на: комментарий от d9d9

Именно. Те бд я, которые я привел и есть «на стороне бд». Только там не что-то вставляется в бд, а бд сама вставляется в приложение и даёт интерфейс (api) обычной хэш мапы (почти) - хочешь, получай по ключу, хочешь - итерируйся.

Вот когда надо по сети ходить, тогда да. Хотя в простейшем случае можно сделать ключи упорядоченные и получать по диапазону, как, например, в etcd сделано.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.