>> Криптоакселератор - он в целом как мертвому припарка - хорошо что есть, но нужен весьма и весьма специфических нагрузках.
> Он там довольно универсальный, с акселерацией SHA и zlib например, это много
> где в обычных задачах может всплыть. Понятное дело, это далеко не
> то же самое, что плата акселератора для спец. задач - просто
> специальные инструкции процессора позволяют ускорять определенный код. Не все ж specint
> считать, нужно и реальный код запускать.Когда такое же запихали в Xeon - после тестов оказалось что мертвому припарка. Тот же аппаратный CRC32 проигрывает по скорости вычислению через таблицу. Так и с остальными.
>> Я думал gzip используют что бы уйти от этих самых узких мест
> gzip слишком уж все кладет. lzo дает очень хорошее сжатие и не
> грузит проц, а gzip просто забесплатно сожрет +10 ядер на той
> же нагрузке. А эффективности сжатия и ввода-вывода почти не добавит. Кроме
> того, на практике в HBase можно дизайнить таблицы так, чтобы получать
> эффект от fastdiff (префиксного сжатия), после него дожать что lzo, что
> gzip - одна фигня.
Понятно. lzo не всегда хорошо сжимает.
>[оверквотинг удален]
> В общем виде ему и не нужно, при правильном проектировании он обеспечивает
> локальность данных. А пересылки по сети только чтобы поддерживать распределенные копии
> (т.е. внутренние механизмы) и при изменении места хранений какой-то копии, чтобы
> данные оказались там, где обрабатываются. Хотя это плохой сценарий и такого
> не должно быть много, нужно обработку перемещать туда, где данные, а
> не данные, где обработка. Но даже при перемещении данных для конкретной
> задачи это будет однократно. Т.е. реальная обработка будет идти сразу с
> локальными данными (в идеале) или через некоторое время (при проблемах проектирования),
> и как там загружается сеть и с какими задержками, не имеет
> значения.
насколько я помню архитектуру этого безобразия - там нода обработки и нода хранения в общем случае разные ноды. после чего нужно как-то передавать данные для обработки. Из-за чего даже делали хак в виде hardlinks что бы эмулировать копирование по сети.
>> Подходы у них весьма странные. На счет только такие и работают
> Я не говорил, что только такие и работают. Но у кучи очень
> крупных компаний такой или аналогичный подход и он работает - на
> очень больших кластерах.
Очень большие кластера это сколько дисковой памяти и сколько клиентов и средний размер объекта хранения, требуемая скорость доступа? А то может у вас понятие о больших другие чем у меня? У меня все что относится к TOP10 считается большим. Остальное - так себе.
Попутно всплывают требования по скорости 20-40 GBytes/s для обработки чего нить объемами по 4-10Т в одном объекте, при общем количестве обработчиков - 10-30 тысяч.
>> PS. Когда там Хадуп научится версионности объектов? что бы не требовалось сохранять копию объекта при чтении клиентом
> Не знаю, я не в курсе такой проблемы. В HBase очень мощная
> версионность, что мешает его использовать там, где она нужна?
Вот уж не знаю. В той версии что я копался - выглядело что он не может читать одновременно с модификацией.
