Winnipuhспасибо, коллеги, проясняется. Т.е. факт в том, что для колоночно-ориентированных баз апдейт (инсерт, делете) не просто делать.
Собственно, это и видно на примере columstore index от SQL Server 2012
В любых BigData операция обновления считается дорогостоящей и применяется редко. Обычно могут изменятся измерения, факты изменяться не должны. А для измерений так же применяется схема проектирования БД, где они хранятся версиями аля SCD (измерения, медленно изменяющиеся во времени). Ну и к тому же для колонко-ориентированных апдейт вообще штука вредная, так как их основная фишка это возможность сильной денормализации данных для ускорения выполнения запросов, а здесь уже поле в справочнике не проапдейтишь, если оно же в фактах продублировано. Здесь выход, только новые версии записей справочников. С версиями тоже не все так просто - если делать дату начала и конца версии или признак активной, то при изменении записи справочника их опять же надо апдейтить. Если в день апдейтится пару тысяч записей измерения, то это еще терпимо. А если пару миллионов, то этот вариант уже плох. Решение зависит впервую очередь от возможностей СУБД.

В Оракле это моими коллегами решается через партиционирование. Я работаю с Vertica, здесь партициями делу не поможешь, так как они предназначены для быстрого удаления данных, но никак не апдейта. Здесь получается мне выгоднее применить гибридную схему хранения больших измерений в виде двух таблиц - актуальной и истории, где с актуальной таблицы записи удаляются DELETE (если их удаляться не сильно много будет за проход джоба) и переносятся в историю. Или же, если обновляется большая часть актуальных записей, легче тогда просто копировать не измененные записи актуальной таблицы во времянку, добавлять туда новые и измененные, очищать актуальную таблицу и вставлять с нее записи с времянки. По скорости выходит на порядки. Ну и на историчной таблице конечно же играет свою роль порядок сортировки таблицы для быстрого доступа к данным по версиям. На выходе пишется представление, сцепляющее актуальную и архивную информацию через UNION ALL и получается достаточно шустро работающая на запросы и обновления схема.

В общем везде по разному. Но в любом случае самый главный момент - это подход к проектированию структуры с учетом особенностей используемой СУБД, с максимальным использованием плюсов и внимательным отношениям к минусам. У нас например, в реалтайме постоянно идет загрузка большого объема сетевых и финансовых данных с различных источников и не смотря на то, что Vertica колонко ориентированный сервер, справляется на ура, одновременно обслуживая до сотни аналитических запросов для BI систем, другого ПО и веб сервисов. Но, чтобы добиться этого, пришлось изрядно походить по граблям при проектировании структур данных, алгоритмов загрузки данных, распределением нагрузок и т.д. Сейчас в большинстве своем приходится бороться не с Vertica, а ораклистами, которые пытаются писать загрузки и запросы в oracle-style, что очень негативно сказывается на работе сервера и приходится постоянно контролировать, чтобы они не запустили какой нибудь SELECT * на таблицу с миллиардами записей или же не попытались грохнуть миллион записей, чтобы вставить точно такой же миллион плюс одну измененную запись.

ApexASCRUSВ любых BigData операция обновления считается дорогостоящей и применяется редко.
Просто для пояснения: не путайте VLDB с Big Data . Разные вещи: ключевое отличие Big Data в сложности и разнообразии формата данных, а не просто наличие большых объемов.
А я вроде так и написал, что именно в BigData операция обновления считается дорогостоящей. В очень большой БД я не вижу проблем с обновлением. Тот же Oracle или Sybase на больших базах спокойно у нас переваривает такие операции при должном тюнинге, а вот Vertica как не тюнингуй, потребует изменение самих подходов алгоритмов хранения и обновления данных.

Не очень уловаливаю суть заявлений :) И тем более не понимаю, почему BigData должна быть Hadoop, NoSQL или уж тем более In-Memory. Та же Vertica прекрасно вписывается под определение BigData без этих трех волшебных слов, причем является MPP, колонкоориентированной, 100% ANSI SQL совместимым сервером. И кстати прекрасно демонстрирующим массовый параллелизм, реалтайм загрузку массивов данных и способный проводить обработку и анализ разнообразных видов информации без использования модных слов ;) Однако в любом случае мне становится интересным, моя фраза
В любых BigData операция обновления считается дорогостоящей и применяется редко.
имеет по Вашему мнению какие то противоречия с Вашим пониманием "BigData" ? :)

Alexander RyndinASCRUSНе очень уловаливаю суть заявлений :) И тем более не понимаю, почему BigData должна быть Hadoop, NoSQL или уж тем более In-Memory. Та же Vertica прекрасно вписывается под определение BigData без этих трех волшебных слов, причем является MPP, колонкоориентированной, 100% ANSI SQL совместимым сервером. И кстати прекрасно демонстрирующим массовый параллелизм, реалтайм загрузку массивов данных и способный проводить обработку и анализ разнообразных видов информации без использования модных слов ;) Однако в любом случае мне становится интересным, моя фраза
пропущено...

имеет по Вашему мнению какие то противоречия с Вашим пониманием "BigData" ? :)Почему BigData должна быть Hadoop - почитайте документы, написанные в Vertica .
Почему In-Memory, потому что Vertica тоже частично In-Memory, чтобы обеспечить высокую скорость записи. Я про WOS говорю.

Короче, Vertica может без извращений только Volume, Velocity с извращениями (я не знаю ни одного промышленного инструмента, который поддерживал доставку изменений в Vertica), Variety вообще никак, иначе в HP тупые менеджеры, которые зря заплатили 10 млрд.$ за Autonomy
Извините, но WOS и in-memory это разные вещи под разные цели. Vertica заточена под большие объемы структурированных данных, Hadoop под не структуированные. А вообще BigData сильно расплывчатый термин, чтобы под него равнять продукты и технологии. Тот же Hadoop на фоне Вертики при работе со структурированными данными будет отставать по скорости выполнения запросов на порядки, но это не означает, что его нельзя причислить к BigData.

Alexander RyndinASCRUSТот же Hadoop на фоне Вертики при работе со структурированными данными будет отставать по скорости выполнения запросов на порядки...Хехе, это вы из расчета на 1 Mhz, или на 1$?
Повторюсь, Vertica может быть причислена к Big Data, но только по одной из трех V.
Из любого расчета. И в любой конфигурации. Лицензирование не ограничивает размеры и параметры кластера, так что она не зря на Амазоне в облаках крутиться.

Alexander RyndinASCRUSпропущено...

Из любого расчета. И в любой конфигурации. Лицензирование не ограничивает размеры и параметры кластера, так что она не зря на Амазоне в облаках крутиться.О, да! :) Стоимость 100.000$/TB это отличная цена. Особенно такая цена актуальна для BigData, где объемы считаются на 10-ки ТБ.
Решение на Hadoop от Oracle стоит 2.500$/TB и это вместе с железом. Что называется, почувствуй разницу.
У нас сейчас 2 лицензии - одна на 30 тб , вторая анлим (идет в составе купленного штатовского софта под автоматизацию телекома). Ни о каких миллионах там речи нету. На нашу лицензию, расчетный прирост данных при полной нагрузке в итоге выйдет порядка 10 тб в год, где большая часть исходной информации будет храниться 3 года, агрегаты будут хранится еще дольше. Естественно мы будем докупать сервера и лицензию, сервера в следующем году, лицензию видимо через годик, если конечно не появятся новые не запланированные источники данных. Чем выше объем лицензии, тем ниже ее стоимость. Так что на выходе в итоге получается Вертика подороже Гринплама или Нетизы, но дешевле, чем Терадата.

P.S. Я понимаю, что Вы умеете пользоваться Гуглом, но приводить ссылки на статьи с устаревшей информацией 2009 года без приведения планки и публикования российских цен не очень корректно. Ну и по теме топика хотелось бы от Вас хоть что то услышать по Vertical DBMS vs NoSQL. Обсуждение кто-что BigData или не BigData немного не в теме топика:)