Size: a a a

2020 November 23

Д

Дмитрий in Tarantool
И ещё вопрос такой. Если в спейсе хранятся таплы, допустим тех же Машин. В атрибутах есть такие вещи, как Аксессуары, Шины. Соответственно последние являются массивами типа map. Искать в них не планируется. Разработчики будут затягивать эти таплы в Lua, и дальше их как-то обрабатывать. Вот в таком случае эти вот Аксессуары есть смысл выносить в отдельные спейсы или лучше оставить в виде массивов прям в тех таплах? Если аксессуар меняется, то обновлять его в уже сохраненном тапле не обязательно.
источник

MA

Mons Anderson in Tarantool
Дмитрий
"1-* реализутся через указание pk в связанной таблице", если RPS будет высокая, то есть смысл денормализации (как писали выше) или в целом прирост от этого будет не большим? Скажем при 100 тыс. RPS.
В принципе все приёмы оптимизации производительности применимы так-же.
(Магии не бывает, тут те же самые индексы, просто всё в памяти)
Самым лучшим ответом будет: проверяйте на целевой нагрузке.
Для одного сценария будет лучше денормалировать, для другого нормализовать
источник

MA

Mons Anderson in Tarantool
Дмитрий
И ещё вопрос такой. Если в спейсе хранятся таплы, допустим тех же Машин. В атрибутах есть такие вещи, как Аксессуары, Шины. Соответственно последние являются массивами типа map. Искать в них не планируется. Разработчики будут затягивать эти таплы в Lua, и дальше их как-то обрабатывать. Вот в таком случае эти вот Аксессуары есть смысл выносить в отдельные спейсы или лучше оставить в виде массивов прям в тех таплах? Если аксессуар меняется, то обновлять его в уже сохраненном тапле не обязательно.
Если аксессуары связываются с машиной "навсегда", не используется индексация и не нужно "обновлять все разом", то вполне удобно хранить их как вложенный map
источник

Д

Дмитрий in Tarantool
Mons Anderson
В принципе все приёмы оптимизации производительности применимы так-же.
(Магии не бывает, тут те же самые индексы, просто всё в памяти)
Самым лучшим ответом будет: проверяйте на целевой нагрузке.
Для одного сценария будет лучше денормалировать, для другого нормализовать
Про то, что надо проверять - полностью согласен. Пока пытаюсь выработать методики в целом, перед началом проектирования первого варианта.
источник

DS

Dmitry Sharonov in Tarantool
если вы часто вытягиваете все целиком, то сделать 1 гет из 1го большого спейса или 1 гет машины и 5 гетов аксессуаров - разница по рпс заметная
источник

DS

Dmitry Sharonov in Tarantool
а если аксессуары обычно не нужны - то наоборот, удобнее нормализация
источник

MA

Mons Anderson in Tarantool
Я обычно начинаю с нормализованной схемы (как более удобной и красивой с точки зрения работы с данными)
При этом имеет смысл руководствоваться логической связанностью данных (как сказал выше Дмитрий)
источник

Д

Дмитрий in Tarantool
Принято 👍🏻
источник

BG

Bit Gorbovsky in Tarantool
Всем добрый день!
Скажите пожалуйста, а вот коннектор к PostgreSQL https://github.com/tarantool/pg внутри себя создает пул соединений или об этом надо заботиться самостоятельно?
источник

BG

Bit Gorbovsky in Tarantool
Или это вовсе не нужно? :)
источник

BG

Bit Gorbovsky in Tarantool
А, все, нашел.. pool_create
источник

BG

Bit Gorbovsky in Tarantool
Извините, глаза устали ((
источник

AS

Arthur Salimkhanov in Tarantool
подскажите плиз, как сделать так чтобы при запуске тестов не стартовал модуль task ?
источник

AS

Arthur Salimkhanov in Tarantool
это тот случай когда создаем кластер через catridge.test-helpers
источник
2020 November 24

RP

Roman Proskin in Tarantool
Arthur Salimkhanov
подскажите плиз, как сделать так чтобы при запуске тестов не стартовал модуль task ?
Можно сделать для тестов свой init.lua, в котором не указывать ролей для task
источник

RP

Roman Proskin in Tarantool
Хотя просто отсутствие включенных ролей в кластере тот же эффект должно иметь. То есть когда кластер настраиваете в тестах, то не включайте эти роли
источник

AS

Arthur Salimkhanov in Tarantool
Подскажите пож-та куда копать, в админке один из репликасетов хелсчек все ок, но горит желтым и пропали инфа о бакетах и занятом пространтсве, в логах ток куча из "Exception during calling 'vshard.storage.buckets_discovery'" и "Error during discovery 938e1c67-1f05-41b7-bff8-970ce3dc2ce7, retry will be done"  после записи сначала было все ок, потом ничего с ним не делал а зашел через пару часов а он вот такой)
источник

AK

Alexey Kuzin in Tarantool
Посмотрите на процессы в топе
источник

AK

Alexey Kuzin in Tarantool
Может он занят там чем-то
источник

AS

Arthur Salimkhanov in Tarantool
ничем не был занят, ща ребутнул, посмотрю мб что то разовое было
источник