К написанию сей заметки меня сподвигло то, что я устал делать развёрнутые замечания на эту тему в комментариях к статьям, где в качестве части инструкции по сборке и настройке чего-либо для конкретного дистра предлагают выполнить make install.

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

Но ведь авторы программ в руководствах по установке пишут, что нужно использовать эту команду, возможно, скажете вы. Да, пишут. Но это лишь означает, что они не знают, какой у вас дистрибутив, и дистрибутив ли это вообще, может, вы вступили в секту и обкурилисьчитались LFS и теперь решили под свою хтоническую систему скомпилять их творение. А make install является универсальным, хоть и зачастую неправильным способом это сделать.

UPD: Продолжение статьи по ссылке — habrahabr.ru/company/avito/blog/322510

О чем статья

Незаметно пролетел год, как начались работы по разработке и внедрению хранилища данных на платформе Вертика.
На хабре уже есть статьи про саму СУБД Вертика, особенно рекомендую эту: HP Vertica, первый запущенный проект в РФ, ведь ее автор очень помог нам на начальном этапе. Алексей, спасибо еще раз.
Хотелось бы рассказать о том, какая методология применялась для проектирования физической структуры хранилища, чтобы наиболее полно использовать возможности HP Vertica.
Эту статью хотел бы посветить обоснованию оптимальности выбранной методологии, а в следующей — рассказать о том, какие техники позволяют анализировать данные, содержащие десятки млрд.

Постановка задачи

Рассмотрим высоконагруженный сайт крупной российской интернет-компании (теперь можно — это Авито ;)).
Деятельность компании описывается следующими цифрами: ~ 10 млн. активных пользователей, ~100 млн. просмотров страниц в день, около 1 тыс. новых объектов, размещенных пользователями на сайте в течение 1 минуты, ~10 тыс. поисковых запросов пользователей в минуту.
Грубая оценка количества действий, подлежащих сохранению в хранилище, составляет 100 млн. новых записей в сутки (~100 GB новых данных в сутки).
Т.е. при построении классического хранилища данных с отказом от стирания поступивших ранее данных, объем хранилища через 3 месяца эксплуатации составит 10TB сырых данных. Big Data как она есть.
Нужно построить хранилище, которое хранило бы не меньше 6 месяцев данных, позволяло их анализировать, визуализировать, и отставало бы от реальной жизни настолько мало, насколько это возможно (в худшем случае — отставало бы на день, в лучшем — на минуты).
Вынося сразу за скобки вопрос выбора платформы — хранилище должно работать на HP Vertica, MPP базе колоночного хранения, см. вводную статью в заголовке.