Приходил хьюлет паккард, нахваливал, говорит, что залетает по моим задачам (сейчас это олап кубы по продажам)
wiki:Vertica

всю ветку не читал. КГ/АМ уже было?

АМ

sda553 Приходил хьюлет паккард, нахваливал...

К тебе приходил принтер и разговаривал с тобой?

на русском http://habrahabr.ru/post/95181/

К комуто чёртики приходят, а к кому хьюлиты с паккардами

(0) Есть таблица сравнения с теплым ламповым SQL?

(6) это то же с языком sql. Ну мне показали запрос сумму продаж по месяцам-кварталам за пять лет. На моем оракле считалось 20 минут. У них минуты 2

У колоночных СУБД есть и недостатки — они медленно работают на запись, не подходят для транзакционных систем.

Как жэ без транзакций то жить?

но они хороши для bulk работы, что у меня как то как раз надо.
Есть вот такая картинка с одного из ИТ форумов
http://vertica-forums.com/download/file.php?id=8&sid=5593e02d6b48d599ebf46e3cca3a3b07

(10) Ну так то красиво. А не проще ли SSD PCI Express прикупить?

sda553 (6) это то же с языком sql. Ну мне показали запрос сумму продаж по месяцам-кварталам за пять лет. На моем оракле считалось 20 минут. У них минуты 2

А что значит считалось 20 мин. ? А у них 2 мин. ? Можно как-то подробнее развернуть может у них просто какие-то дополнительные агрегирующие таблицы ?
Я к чему вопрос, можно в Оракле добавить пару таблиц и сделать агрегацию данных тем самым повысив скорость получения результата, да чуток избыточности в структуре, но так ли избыточна она если дает прирост ?

тут прям все спецы по вертике
и работаем на британские тнк

(0) купите себе хану в облаке - и будет вам счастье (не денежное правда)

Вообщемя прикинул расчеты и увидел следующее:
Классические построчные СУБД имеют следующий недостаток: Много записей - надо индексировать, чтобы ворочалась. Будешь индексировать - будут еле ворочаться инсерты в таблицу. Разработчику приходится лавировать где то в середине между тем, замедлить ли инсерт или замедлить селект? Если инсертять одну две записи за транзакцию, то жить можно. Если грузят пару миллионов записей за одну транзакцию в индексированную таблицу с миллиардом записей - тут классические СУБД бессильны. Есть конечно SSIS, но это уже другая тема с особым применением. Вот в эту дыру функционала и можно затыкать вертикой.
Т.е. применение вертики, это где до хрена записей уже есть и где в одной транзакции обычно до хрена записей инсертят, делетят.

мне бы ваши объёмы

OLAP там ведь пох на инсерты ? В том смысле что они делаются регламентно и т.д.
разве OLAP и OLTP не на одной и той же СУБД ?

(17) олап имеет другие недостатки, это не оперативность. Ну т.е. добавил пару миллионов записей, на следующий день (смотря когда там олап процессит регламентно) увидел, что получилось.
Плюс, олап он ведь только показывает то, что в него разработчик заложил. если вдруг мне в голову прийдет хитрый запрос с хитрыми соединениями, то посмотреть его я не смогу оперативно

(18) Хотим сидеть на двух стульях ?

(19) как обычно