> Когда такое же запихали в Xeon - после тестов оказалось что мертвому припарка. Тот же аппаратный CRC32 проигрывает по скорости вычислению через таблицу. Так и с остальными.

Ну у Xeon свои особенности, там общая ПСП о-го-го и кэша до фига. Тут, думаю, есть смысл, иначе бы не стали делать.

> Понятно. lzo не всегда хорошо сжимает.

На практике вместо поблочного сжатия в HBase иногда лучше сжимать/разжимать некоторые данные при обработке, если критично именно сжатие и куски достаточно большие (тогда хоть lzma используй). Иногда получается даже эффективнее, т.к. при встроенном сжатии в кэше данные хранятся несжатыми. Но для всех остальных случаев lzo - самое то.

> насколько я помню архитектуру этого безобразия - там нода обработки и нода хранения в общем случае разные ноды. после чего нужно как-то передавать данные для обработки. Из-за чего даже делали хак в виде hardlinks что бы эмулировать копирование по сети.

В общем случае - да, но это неправильное использование и не должно происходить. Данные из HDFS должны читаться HBase'ом локально - если регион переедет на другую ноду, где нет копии данных, будет временно читаться по сети, но Hadoop тут же начнет перемещение данных туда для обеспечения локальности. Обработка типа map также должна запускаться на нодах с данными.

> Очень большие кластера это сколько дисковой памяти и сколько клиентов и средний размер объекта хранения, требуемая скорость доступа

Обычно для косвенных задач запускают небольшие кластеры в десятки и сотни нодов http://wiki.apache.org/hadoop/Hbase/PoweredBy
А у крупных игроков типа Yahoo, Facebook порядка тысячи (самый крупный, вроде, у Fluffy - два кластера по 1200 нодов). Еще есть Google (у которого не HBase, но Bigtable, на основе которого проектировался HBase) с кластером на несколько тысяч нод по похожей технологии.

Типичные оптимальные ноды - 32-64 Гб памяти (128 тоже замечательно, но не всегда требуется) и 4-8 SATA-дисков. Объекты от нескольких байт до нескольких мегабайт в HBase хранить оптимально, для более крупных, видимо, уже стоит напрямую работать с HDFS, записывая туда файлы.

Общая скорость обработки масштабируется линейно с количеством нод. Т.е. сколько требуется, столько и нод.

> Вот уж не знаю. В той версии что я копался - выглядело что он не может читать одновременно с модификацией.

Если мы говорим про HBase, там сильная консистентность - читай и пиши одновременно, всегда будет корректный результат. При чтении обычно берется последняя версия, но можно все или по диапазону (ограничивая количество или их timestamp'ы). Пока вставка не завершилась, ее (частичную) не видно, когда завершилась, сразу все видят.