LINUX.ORG.RU

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 ()

Мысле о скалярной природе данных и невозможности натянуть ее на ОО модель категорически отказанно в парковке в головах программистов. Отсюда и NoSQL с JSON-нами. Потом, внезапно как всегда, выясняется, что без кластеризации и in-memory вот это вот все объектно-ориентированное наслоение работать не может. И как вишенка: ради того чтобы не использовать SQL + RDBMS переизобретается что? Правильно! Поддержка SQL и всех сущствующих фич RDBMS.

anonymous ()

У меня картинка в глазах отпечаталась! Как убрать, теперь обои окно и даже моё пузо с этим логотипом, боюсь в зеркало смотреть!

А так, прикольна, документация очень хорошая (глянул по диагонали). Жаль что сходу докер лезет, лучшеб без него доку, как взять, скомпилять, поставить и дальше уже по доке.

LINUX-ORG-RU ★★ ()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от Vit

Даже странно что его популярность не очень.

Видать, потому что его возможности на практике «не очень»))

Шучу. Это потому, что, чтобы пользоваться такими вещами эффективно, нужно иметь весьма высокую техническую квалификацию и теоретическую подготовку, а в этой области уже и так сильная конкуренция. И она весьма консервативна и суеверна. Специалисты не будут перескакивать на новую модную вундервафлю с проверенных их собственным временем решений.

Российский программист традиционно «смотрит на Запад». А «на Западе», чтобы что-то в этой нише продвигать, нужны большие рекламные бюджеты. Вот когда Tarantool будет мне мелькать в рекламе так же, как мелькает Neo4J, вот тогда её популярность начнет резко расти.

aist1 ★★ ()
Последнее исправление: aist1 (всего исправлений: 1)
Ответ на: комментарий от aist1

Так и скажи, что это никому не нужно и без него люди мутят делишки. А когда проект выше всех на голову ему и реклама особо не нужна, расхватают как горячие пирожки.

Щас этих nosql поделий как на собаке блох и каждое из них очередное ненужно. Тренд за newsql, впрочем и там если у тебя не копрорация, то опять же ненужно. О малом и среднем бизнесе копроразрабы не думают и не заморачиваются.

foror ★★★★ ()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от anonymous

Дело не в самой системе типов сверху хранилища. Систему типов можно сделать динамической и многовариантной. Т.е. создавать те же объектные представления данных «на лету» для того кода, который работает с данными в объектной семантике.

Дело в нижележащем K/V-движке, который заточен под точечные запросы, но не заточен под эффективное сканирование диапазонов. Именно поэтому «нахлобучивание SQL сверху» на K/V дает, в лучшем случае, сомнительный результат. Cassandra, например, тупо отваливается по таймауту, если сканирование по любой причине получается слишком долгим. Полагаться на эту операцию в C* нельзя вообще.

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

Ты всё верно говоришь. Просто в NoSQL сделать что-то «выше всех на голову» сейчас будет очень сложно. Оно и так уже предельно вылизано. А, как я сказал в посте выше, нахлобучивать сложные системы типов поверх K/V — так себе занятие.

Вот и получается, что NoSQL очень хороши в каких-то узких классах задач и неэффективны во всем остальном. И будут не интересны всем, у кого нет этого узкого класса задач.

aist1 ★★ ()

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

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

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

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

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

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

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

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

Как раз таки в базе. Точнее в том, что тем, кто будет вот это всё использовать, придется делать базу данных самим. Та же ловушка, в которую попадают микросервисники, когда выбирают модель «одна база на каждый сервис». Выбирают, а потом ломают голову, как обеспечивать целостность распределенных данных. «Сервер приложений» тут, сам по себе, не поможет ничем.

Сервер приложений решает проблему доставки вычислений к данным. Обычный же noSQL — это доставка данных к вычислениями. Просто файловая система без лишних сущностей и возможностей.

Я потому и сказал, что оно требует высокой квалификации для работы. По сути, придется писать свой движок БД над такой штукой. Слишком уж она низкоуровневая, несмотря на всю свою систему типов.

aist1 ★★ ()
Ответ на: комментарий от 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 ★★ ()
Ответ на: комментарий от LINUX-ORG-RU

Жаль что сходу докер лезет, лучшеб без него доку, как взять, скомпилять, поставить и дальше уже по доке.

Докерфайл по сути это и есть та самая дока, как взять и поставить.

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

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

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

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

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

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

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

нужны большие рекламные бюджеты. Вот когда Tarantool будет мне мелькать в рекламе так же, как мелькает Neo4J, вот тогда её популярность начнет резко расти.

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

crypt ★★★★★ ()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от crypt

Идея о том, что «нормальный продукт люди сами найдут» предполагает два условия:

1. Есть всё же некий дефицит на рынке, который бы заставлял людей искать.

2. Ищущий способен сам сделать рациональный выбор, не оглядываясь на толпу и авторитеты.

По обоим условиям в области БД полный жесткач. Без агрессивной рекламы ты просто не существуешь. Область консервативная, и чтобы реально попробовать что-то новое, нужно именно убеждать людей. Причем массы людей, которые рациональные аргументы вряд ли поймут правильно.

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

make sense

p.s.

другое дело, что выступления на конференциях - это способ лучше, чем просто реклама. никто ведь не страдает от того, что продукт mail.ru не стал популярен. кому надо, услышали на конфах. кому не надо, не услышали. я за ограничение информирования в специальных, тематических рубриках.

crypt ★★★★★ ()
Последнее исправление: crypt (всего исправлений: 5)
Ответ на: комментарий от crypt

Да, я тоже согласен. Я к тому, что mindshare тоже необходим, и одними только конференциями его не создать. Нужно «А, так вот тут рассказывают про тот самый Тарантул. Пойду послушаю.» Эффект «знакомого слова». Так наше потребительской общество работает, и программисты — такие же потребители, как и все остальные.

На меня постоянно выходят всякие «продавцы технологий», чтобы рассказать про свои продукты. Причем я — совсем не ЛПР у нас. И несмотря на это, они готовы тратить свое время на презентации конкретно мне. Потому что это mindshare. И если мне продукт понравится, то я буду его предлагать использовать внутри компании. Этакое «жжж снизу».

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

понятно. правда, на лоре это работает наоборот. приходит альфа из федоры (редхата) и буквально называет пользователей закрытого центоса халявщиками. в итоге начинаешь относится хуже к редхату вообще=) я как раз ей пытался объяснить, что поддержка продукта со стороны специалистов очень важна.

crypt ★★★★★ ()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от crypt

Чела того, кстати, можно было изящно ткнуть носом в тот факт, что для RH CentOS был именно способом завоевания mindshare и рекламным проектом. В конце-концов проект решили свернуть, но сделали это как-то совсем некрасиво. Фу быть такими.

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

А можно в двух словах студенту второкуру пояснить, в чем отличие в областях применения sql и nosql? Где он будет лучше и выгоднее чем традиционный sql? Ну на примере хотя бы вот этого тарантула?

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

Чувак, ты неправильно ставишь вопрос. Тебе нужно понимать, как эти вещи работают «под капотом», и тогда вопрос отпадет сам собой. Не просто отпадет, а ты будешь знать, какая БД для каких нагрузок подходит лучше.

Вот, например, тот Tarantool в варианте дискового хранилища использует модный LSM-tree, у которого есть некоторые важные свойства, определяющие зону применимости этой структуры данных и БД, над ней построенных. LSM могут очень быстро принимать данные (на запись), но ограниченное время. Они хороши для всякого рода веб-магазинов, для которых есть проблема внезапного 100х-наплыва пользователей. Нахватал за час заявок — и потом неделю обрабатываешь.

По той же причине LSM-tree себя очень хорошо показывают в микробенчмарках, где время записи ограничено. Но из-за деградации структуры дерева и необходимости фоновой сборки мусора LSM-tree не могут держать высокую интенсивность записи долго. А еще для них надо резервировать как минимум 2х место на диске, для слияния сегментов. Но там, где нужно держать очень высокую пиковую нагрузку на запись — они незаменимы.

И вот если ты будешь понимать, как различные БД внутри хранят и обрабатывают данные, а это не rocket science, то ты поймешь, где, что и как использовать. Причем экспертом (в узком смысле) по БД для этого становиться не обязательно.

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

это alter ego. изображение с надгробья (crypt). на нем скорее всего херувим в рафаэльской традиции. в других традициях есть изображения ангелов с шестью крыльями, отсюда твоя ассоциация со звездой. советская символика не оригинальна, она заимствовала то, что уже было. однако, тему ты поднял не в токсах. поэтому, если ты захочешь еще что-то спросить, либо переносить ее туда, либо в личную почту.

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

А не могли бы вы порекомендовать литературу, желательно более-менее качественную, чтобы понимать как под капотом работает хотя бы sql, хотелось бы на русском (да, я знаю что без английского никуда, я именно на него сейчас и трачу больше всего времени, три часа в день, у меня была хорошая физ-мат школа с просто отвратительным преподаванием английского - провинция), но если нет на русском - можно и на английском. У нас препод сишник хороший, сам работал и работает, а вот sql объясняют женщины которые при превосходном знании математики, в реальном программировании - ни в зуб ногой…

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

Книги, тем более «на русском», тебе не сильно-то помогут и на твоем месте я бы не тратил на них драгоценное время. Что я могу рекомендовать — это поковыряться в трех движках — LMDB (Copy-on-write B-tree), SQLite (B-tree + WAL) и RocksDB (LSM-tree). На мой взгляд, наиболее вкусная и перспективная из них — LMDB, но у неё код отвратительный. Можно брать BoltDB на Go — там получше.

Вот эти три движка тебе дадут в сумме 90% необходимых представлений о том, как работают дисковые БД. Хакай на здоровье, присоединяйся к проектам, присылай патчи, и всё такое)

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

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

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

А документация у кого лучше? И еще, хоть где нибудь математический аппарат описан? С матаном (в самом общем смысле) проблем нет - разберусь во всем, просто не пойму куда смотреть?

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

Начинать лучше всего с LMDB. Несмотря на, как я сказал, отвратительный код, идея (и её реализация) у этой БД самые простые. Ищи любую инфу по Copy-on-Write BTree. Для начала пойдет даже статья про персистентные структуры данных на Вики. А дальше попробуй такую структуру данных поднять просто в памяти, на любом удобном языке. Фишка CoW b-tree в том, что там данные никогда не перезаписываются поверх старых, поэтому она может надежно работать в транзакционном режиме над mmap.

CoW b-tree умеют атомарно сбрасывать состояние из RAM на диск, не требуя для этого WAL. Автоматом получишь актуальные представления о том, на каком принципе работают ZFS и BTRFS.

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

Тарантул интересный. Даже странно что его популярность не очень.

Как высказался мой батя о ГКЧП: «Идея неплохая, но исполнители…».
Видимо подспудно ожидается, что вместе с тарантулом в систему проползет Amigo.

TI_Eugene ★★ ()