Всем привет. Как использовать uuid в качестве primary индексов в tarantool/sql? В nonsql есть отдельный тип индекса uuid. Как быть в sql версии? Ставлю тип поля string + primary key по данному полю?

От скорее бы. Очень хорошее решение.

Н2О рулит.

Tarantool - OSS, PR's приветствуются!

Так я за. Дайте кусочек работы.
Чтоб не переделывать. Как вы это видите. Я подключусь.

Если есть генеральный замысел, то помогу, как могу. Можно конечно сделать так, как я сам это вижу.... Потом переделывать нужно будет. Лучше ставьте задачу)))

Мне кажется, сейчас это пока не параллелится. Через месяц думаем показать MVP, можно будет на него набежать с хотелками и патчами.

Привет всем
Наверное уже много раз спрашивал, но я рискну повториться:
А у нас для tarantool 2.2.2 есть ли встроенный модуль для мониторинга? (может как lua, напимер)

Для метрик есть вот это: https://github.com/tarantool/metrics
Можно ещё сюда заглянуть: https://habr.com/ru/company/mailru/blog/534826/

Спасибо, пошел изучать!

Добрый день, коллеги! Всех с началом рабочей недели!)
Разворачиваю картридж через оператор, делаю по инструкции с хабра.
Возникает такая ошибка, при попытке запаковать тестовое приложение:
Может быть кто-то сталкивался?

Эмм он человечьим языком пишет нет tarantool

Сам тарантул стоит?

сейчас проверю…

да, действительно, с тарантулом проблемы, спасибо)

Дано: 20 csv таблиц с разными языками (RU, EN, DE. и тд) в каждой таблице 200К строк итого 4 млн строк, необходимо за один запрос выбирать по 3 случайных слова (строки) для определенного языка, как лучше хранить дабы увеличить RPS? Каждый язык (200К строк) в отдельном спейсе или все толкать в один спейс?

Чтобы решить, хранить в одном спейсе или в нескольких, нужны ещё кейсы. Например, будут ли выборки сразу по двум языкам или поиск соответствий между языками?

Сразу по двум не будет, только по одному языку, поиск соответствий не будет

Всем привет! С прошедшими праздниками.


Нужна платная консультация и настройка тарантул.

Суть:

Есть тестовый мемкеш и тарантул, в оба сложены одни и те же данные.На одном и том же сервере.

Вот тесты одновременного чтения данных:

время                                                          тарантул                  мемкеш

минимальное время                                  3.05                           0.50

максимальное время                                4.75                           0.72

среднее время                                             3.86                           0.58


Как видно, скорость отличается в 6-7 раз. Нужно добиться максимального приближения скорость заборы данных из тарантула к показателям мемкеша.
Специфика-используется перловый коннектор.

рпс будет зависеть от количества записей в спейсе и правильности выбора индексов. Выборка одной записи по праймари индексу — самая быстрая операция.