Size: a a a

2020 June 01

ST

Satbek Turganbayev in Tarantool
источник

a

aresit in Tarantool
Добрый день. Ни когда ранее наша компания не работала с in-memory и с тарантулом в частности. Хотим попробовать на новом проекте). И сейчас подбираем оптимальные решения, которые будем тестировать. Есть много общей информации о данном продукте. Есть документация, которой точно более чем достаточно для теста, и это все хорошо. Но хотелось бы где то увидеть советы по железу и по структуре данных от разработчиков продукта, так как подобную информацию нашел только 2 летней давности и то очень поверхностно...
Например у нас есть 3 Тб данных, технически мы можем большую часть из них разнести в разные базы, но при этом получим, что именно одна крупная таблица будет занимать 1 Тб, остальные по можем делить на не связанные пачки по 100 Гб и потом связывать без особой нагрузки на бекенде.
1) Вопрос нужно ли это деление или не имеет особого смысла?
2) Лучше использовать те же докеры или разворачивать кластер на целом сервере, у нас по сути в выборе есть сервера с 1 и 2 процессорами по 18 ядер 36 потоков либо один процессор 6 ядер 12 потоков, но частота первых на ядро ниже, семейство одно lga2011 v3
3) Ограничение по ОЗУ 768 ГБ на сервер, но как помните есть одна таблица на 1 ТБ, и реально ли это разделить шардированием.
По нагрузке она разнообразна, нет подавляющего преобладания select.

Понимаю, вопросы в чем то наивные и дилетантские, так же как и то что нет кучи информации, прошу не судить строго!)
Буду рад ссылке откуда под черпнуть информацию, мне не лень и почитать, но не нашел информации(

Спасибо!
источник

A

Aleksandr baltazor in Tarantool
Шардировать вам в любом случае нужно
источник

A

Aleksandr baltazor in Tarantool
Есть vshard без наворотов, есть cartridge более правильный инструмент
источник

A

Aleksandr baltazor in Tarantool
По железу мое мнение что тарантулу важнее частота ядра за счёт его однопоточности, но опять же нужно тестировать вам ваше приложение
источник

AK

Alexey Kuzin in Tarantool
aresit
Добрый день. Ни когда ранее наша компания не работала с in-memory и с тарантулом в частности. Хотим попробовать на новом проекте). И сейчас подбираем оптимальные решения, которые будем тестировать. Есть много общей информации о данном продукте. Есть документация, которой точно более чем достаточно для теста, и это все хорошо. Но хотелось бы где то увидеть советы по железу и по структуре данных от разработчиков продукта, так как подобную информацию нашел только 2 летней давности и то очень поверхностно...
Например у нас есть 3 Тб данных, технически мы можем большую часть из них разнести в разные базы, но при этом получим, что именно одна крупная таблица будет занимать 1 Тб, остальные по можем делить на не связанные пачки по 100 Гб и потом связывать без особой нагрузки на бекенде.
1) Вопрос нужно ли это деление или не имеет особого смысла?
2) Лучше использовать те же докеры или разворачивать кластер на целом сервере, у нас по сути в выборе есть сервера с 1 и 2 процессорами по 18 ядер 36 потоков либо один процессор 6 ядер 12 потоков, но частота первых на ядро ниже, семейство одно lga2011 v3
3) Ограничение по ОЗУ 768 ГБ на сервер, но как помните есть одна таблица на 1 ТБ, и реально ли это разделить шардированием.
По нагрузке она разнообразна, нет подавляющего преобладания select.

Понимаю, вопросы в чем то наивные и дилетантские, так же как и то что нет кучи информации, прошу не судить строго!)
Буду рад ссылке откуда под черпнуть информацию, мне не лень и почитать, но не нашел информации(

Спасибо!
@azaraysky подскажешь?
источник

a

aresit in Tarantool
Aleksandr baltazor
По железу мое мнение что тарантулу важнее частота ядра за счёт его однопоточности, но опять же нужно тестировать вам ваше приложение
Спасибо, за ответ
источник

AZ

Alexander Zaraysky in Tarantool
aresit
Добрый день. Ни когда ранее наша компания не работала с in-memory и с тарантулом в частности. Хотим попробовать на новом проекте). И сейчас подбираем оптимальные решения, которые будем тестировать. Есть много общей информации о данном продукте. Есть документация, которой точно более чем достаточно для теста, и это все хорошо. Но хотелось бы где то увидеть советы по железу и по структуре данных от разработчиков продукта, так как подобную информацию нашел только 2 летней давности и то очень поверхностно...
Например у нас есть 3 Тб данных, технически мы можем большую часть из них разнести в разные базы, но при этом получим, что именно одна крупная таблица будет занимать 1 Тб, остальные по можем делить на не связанные пачки по 100 Гб и потом связывать без особой нагрузки на бекенде.
1) Вопрос нужно ли это деление или не имеет особого смысла?
2) Лучше использовать те же докеры или разворачивать кластер на целом сервере, у нас по сути в выборе есть сервера с 1 и 2 процессорами по 18 ядер 36 потоков либо один процессор 6 ядер 12 потоков, но частота первых на ядро ниже, семейство одно lga2011 v3
3) Ограничение по ОЗУ 768 ГБ на сервер, но как помните есть одна таблица на 1 ТБ, и реально ли это разделить шардированием.
По нагрузке она разнообразна, нет подавляющего преобладания select.

Понимаю, вопросы в чем то наивные и дилетантские, так же как и то что нет кучи информации, прошу не судить строго!)
Буду рад ссылке откуда под черпнуть информацию, мне не лень и почитать, но не нашел информации(

Спасибо!
Шардировать, либо как-то иначе делить, очевидно, придется - в память данные не поместятся.
Посмотрите про шардинг в тарантуле доклад Влада
https://youtu.be/9PW5agbLyQM
По поводу ядер - лучше брать те, где больше потоков. На одном сервере поднимите несколько инстансов тарантула, каждому дадите памяти гигов по 32-64
Если есть возможность запускать без докера - лучше без него, зачем вам оверхед

а вообще - заходите в личку
источник

MM

Max Melentiev in Tarantool
https://github.com/tarantool/tarantool/wiki/Memory-size-calculation
тут можно посчитать, сколько данные и индексы занимать будут в памяти.
еще надо учесть, что резервирование крайне рекомендуется для ХА. для этого памяти нужно х2
источник

a

aresit in Tarantool
Alexander Zaraysky
Шардировать, либо как-то иначе делить, очевидно, придется - в память данные не поместятся.
Посмотрите про шардинг в тарантуле доклад Влада
https://youtu.be/9PW5agbLyQM
По поводу ядер - лучше брать те, где больше потоков. На одном сервере поднимите несколько инстансов тарантула, каждому дадите памяти гигов по 32-64
Если есть возможность запускать без докера - лучше без него, зачем вам оверхед

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

KN

Konstantin Nazarov in Tarantool
Alexander Zaraysky
Шардировать, либо как-то иначе делить, очевидно, придется - в память данные не поместятся.
Посмотрите про шардинг в тарантуле доклад Влада
https://youtu.be/9PW5agbLyQM
По поводу ядер - лучше брать те, где больше потоков. На одном сервере поднимите несколько инстансов тарантула, каждому дадите памяти гигов по 32-64
Если есть возможность запускать без докера - лучше без него, зачем вам оверхед

а вообще - заходите в личку
от докера нет оверхеда
источник

AZ

Alexander Zaraysky in Tarantool
Konstantin Nazarov
от докера нет оверхеда
дискуссионно 🙂
источник

a

aresit in Tarantool
Max Melentiev
https://github.com/tarantool/tarantool/wiki/Memory-size-calculation
тут можно посчитать, сколько данные и индексы занимать будут в памяти.
еще надо учесть, что резервирование крайне рекомендуется для ХА. для этого памяти нужно х2
Спасибо,  статья очень нужная!
источник

KN

Konstantin Nazarov in Tarantool
Alexander Zaraysky
дискуссионно 🙂
пользовательская сессия по-умрочанию работает в «контейнере»
источник

R

R-omk in Tarantool
Alexander Zaraysky
дискуссионно 🙂
любой технический  оверхед   на порядки перекрывается эксплуатационными удобствами
источник

KN

Konstantin Nazarov in Tarantool
с современным линуксом ты не можешь не юзать механизм cgroups итд
источник

AZ

Alexander Zaraysky in Tarantool
всегда есть трейдоф. надо смотреть на реальный кейс
источник

KN

Konstantin Nazarov in Tarantool
нет никакого трейдоффа по перфу у контейнеров, это большой миф
источник

KN

Konstantin Nazarov in Tarantool
по юзабилити - может быть в некоторых кейсах
источник

KN

Konstantin Nazarov in Tarantool
это как сравнивать софт который работает под рутом, по сравнению с софтом, который работает под другим юзером
источник