Как я сказал выше - индекс подсказывает направление движение для того, чтобы сказать разработчику, какой из многих сотен кластерных джобов работает наиболее неэффективно. Вы ручками ходить по консолям спарка через день окажетесь, и правильно сделаете.
Это надо компании, чтобы в итоге сэкономить деньги, и заплатить годовой бонус разработчику. У которого вообще никаких проблем нет, кроме эмпатии.
⚡ Kotobotov ⚡, там есть числовая метрика равномерности использования слейвов, правда?
Или вы предлагаете мне метрики со спарка взять и с ними работать? Так метрики - не проблема абсолютно, хоть с прометея, хоть с spark UI, хоть с ганглии - забрать - это вопрос техники. Проблема - аналитический механизм превращения графиков с разных нод в скалярное число, индекс равномерности.
Я ищу такую библиотеку или продукт, чтобы самому не писать. Как и написал в вопросе.
После разработки и запуска задачи, естественно, специалист смотрит производительность и тюнит алгоритм. Но, запуская этот же код на данных другого клиента, или на данных этого же клиента в другое время, можно обнаружить, что из-за data skewness или чего-то подобного - кластер впустую тратит деньги.
Таким образом, у нас сотни запусков N алгоритмов на M клиентах в разное время T. Как в этом случае понять, куда должен идти копать наш специалист со всеми своими инструментами?
Чтобы решить этот вопрос, я предположил, что в распределенных вычислениях можно определить запуски, которые "пахнут", способом в вопросе. Теперь ищу такую библиотечку, чтобы скормить ей метрики машин, и получить на выходе индекс.
// Вообще, задача вообще не про спарк, а про все распределенные вычисления, указал спарк в тегах для большего охвата аудитории. Не очень понимаю, как без таких инструментов серьезно подходить к распределенным вычислениям.
Я имел ввиду ускорение скорости серфинга в сети, из-за того, что каждый сайт десятки запросов для каждой картинки делает не по отдельности со всеми хендшейками, а по уже установленному каналу до дата центра, который точно быстрее меня, сидящего в дырке мира.
P747, Делаем буквально абсолютно все на Java.
Из очевидных фактов - на любом языке общего пользования можно решить любую задачу. В том числе на старом языке написав новый язык - под задачу :)
Ну а касательно "серверной транзакции".. У меня нет слов. В стеке JavaEE нативно есть такие вещи, которые для программистов с других стеков - просто какое-то откровение. К примеру - работа с распределенными транзакциями :) Когда надо увязать несколько баз и очередей вместе - в одной транзакции, и надежно.
P747, руби занял нишу из-за того, что очень удобный для своего времени был RoR. Сам по себе Руби - очередной язык. Тренд использования RoR также нисходящий, так как на более мейнстримных языках появились похожие фреймворки.
2TB SSD GP2, 64GB RAM 8 CPU
Упираемся в IOPS - 6К IOPS.
С вашими 5к в секунду это 20М в час. Но данные проще - это time series, т.е. элементы индекса (он же по времени, верно?) лежат очень рядом - и запись происходит в блоки кучно - и индекса и данных.
У меня customerId это довольно рандомное число, значит по индексу будем бегать и писать очень фрагментарно. Возможно случаются еще какие-то блокировки на индекс при записи конкурентно, это непросто расследовать..
Я даже отсортировал по customerId ASC, и индекс сделал не по конкретному customerId, а по префиксу, типа записи 11111185 и 11111186 будут попадать в один бакет "111111", а далее работать как hashmap, но даже так не выжимается более 1-2М записей в час.
Спасибо!
DynamoDB билл считает по запросам, 20М запросов это 25 баксов. Короче, очень дорого выходит :)
Может быть, другие варианты KV стораджей приходят в голову?
Но даже если кластер шарится между джобами - находить места проблем не руками - это важно и нужно.