Комментарии 48
Спасибо за статью!
Да, было бы неплохо узнать, как это все администрировать и мониторить ;)
Да, было бы неплохо узнать, как это все администрировать и мониторить ;)
Через Vertica Management Console или adminTools
Извините конечно что не в тему, но вместо всей этой безумной аналитики лучше бы на ivi.ru добавили возможность посмотреть семпл для оценки качества картинки до оплаты и перестали жадничать с параметрами кодирования так называемого вашего «HD» (на каком-нибудь рутрекере за видео такого качества не только бы удалили раздачу, но и забанили бы пожизненно).
По-моему без этих двух пунктов аналитика навсегда останется сферическим конем в вакууме.
По-моему без этих двух пунктов аналитика навсегда останется сферическим конем в вакууме.
«Vertica блокирует таблицу во время записи;»
вы, что данные INSERT вставляете?
вы, что данные INSERT вставляете?
«После всех манипуляций, предыдущий запрос превратился в простой» и что такое проекции вы не читали?
Строить на все возможные варианты запросов проекции сложно, а у вертики есть ограничение по количеству.
А что, join на таблицы фактов как-то может быть оптимизирован проекцией?
Я даже теоретически не знаю как это сделать (только если ценой очень медленной вставки).
Я даже теоретически не знаю как это сделать (только если ценой очень медленной вставки).
Мне почему кажется, что да, если у вас есть постоянные запросы с не меняющейся функцией агрегации, то наверно есть смысл превратить его pre-join projection, и это проекция будет пересчитываться, про обновление таблицы фактов
vertica.tips/2014/03/05/pre-join-projections-overview/
vertica.tips/2014/03/05/pre-join-projections-overview/
Это можно сделать, если таблицы фактов identically segmented. В таком случае будет merge join, это очень быстро.
И да, и нет. Мы используем драйвер JDBC для вертики, который при batchInsert делает COPY с транзакцией
Мы сначала через rsync заливаем csv.gz файл на ноду вертики, затем выполняем запрос типа
Вертика отлично обрабатывает gzip и файл в 25млн строк заливается за ~30 сек
COPY 'table' FROM 'file' GZIP DELIMITER ',' NULL '\N' ENCLOSED BY '''' DIRECT;
Вертика отлично обрабатывает gzip и файл в 25млн строк заливается за ~30 сек
да, так можно быстро заливать, но у нас чуть-чуть другой кейс. в другом кластере заливка так и происходит
Я вот тоже не понял где у них LOCK то возникает, если у них это COPY то по дефолту он в WOS загружает. И не должно быть никакого лока.
А у вас 25 млн строк это в мегах сколько?
А все увидел у вас метод DIRECT, да он сразу в ROS грузит, и рекомендуется при загрузке файлов более 100 мегов.
А у вас 25 млн строк это в мегах сколько?
А все увидел у вас метод DIRECT, да он сразу в ROS грузит, и рекомендуется при загрузке файлов более 100 мегов.
Да, вертика — это все-таки OLAP а не OLTP, и частые мелкие инсерты вызывают внутренние процессы по перестройке ROS контейнеров, что может сказаться на производительности всего кластера.
Поэтому лучше где-то буферизировать и пачкой записывать сразу в ROS.
Ну и делать UPDATE и DELETE тоже лучше не стоит.
Поэтому лучше где-то буферизировать и пачкой записывать сразу в ROS.
Ну и делать UPDATE и DELETE тоже лучше не стоит.
Скажите, а почему HP Vertica?
Очень хорошая скорость на больших объемах данных. Postgesql уже не справлялся.
Спрашиваю не из разряда «я самый умный, mongo is webscale».
Быстрая в чем? Запись, чтение и особенно аналитика?
Рассматривали ли вы еще какие-то базы данных?
В чем выигрыш с точки зрения бизнеса? Что-то вроде…
— Лучше (дешевле) дать менеджерам OLAP чем возиться каждый раз с Hadoop?
— Проще было поставить HP потому что дружите с HP или потому что к примеру Cassandra не подходила под задачу.
Быстрая в чем? Запись, чтение и особенно аналитика?
Рассматривали ли вы еще какие-то базы данных?
В чем выигрыш с точки зрения бизнеса? Что-то вроде…
— Лучше (дешевле) дать менеджерам OLAP чем возиться каждый раз с Hadoop?
— Проще было поставить HP потому что дружите с HP или потому что к примеру Cassandra не подходила под задачу.
>Быстрая в чем? Запись, чтение и особенно аналитика?
Все вместе, сложные запросы выполняются очень быстро. Запись, если например через CSV файл происходит тоже быстро, даже очень. По сути HP Vertica это postgres на стероидах, заточенная для аналитики.
>Рассматривали ли вы еще какие-то базы данных?
Раньше использовали postgres, на больших и сложных отчетах постгря умирала или выполняла запрос несколько часов. Пробовали еще iccube, но что-то у нас не срослось.
Решения типа cassandra не рассматривали сразу, так как не было опыта и аналитикам сложнее отчеты строить. + сервера, поддержка и прочее. Сейчас есть мысль старые данные убирать куда-то, но думаем про amazon redshift.
Аналитикам всегда проще дать возможность писать запросы на SQL, так как они его хорошо знают и умеют работать. Обучать писать на scalding и на других обертках — дорого.
>Проще было поставить HP потому что дружите с HP
с HP вроде не дружим
Все вместе, сложные запросы выполняются очень быстро. Запись, если например через CSV файл происходит тоже быстро, даже очень. По сути HP Vertica это postgres на стероидах, заточенная для аналитики.
>Рассматривали ли вы еще какие-то базы данных?
Раньше использовали postgres, на больших и сложных отчетах постгря умирала или выполняла запрос несколько часов. Пробовали еще iccube, но что-то у нас не срослось.
Решения типа cassandra не рассматривали сразу, так как не было опыта и аналитикам сложнее отчеты строить. + сервера, поддержка и прочее. Сейчас есть мысль старые данные убирать куда-то, но думаем про amazon redshift.
Аналитикам всегда проще дать возможность писать запросы на SQL, так как они его хорошо знают и умеют работать. Обучать писать на scalding и на других обертках — дорого.
>Проще было поставить HP потому что дружите с HP
с HP вроде не дружим
Спасибо, ответ понял.
>с HP вроде не дружим
Дружим, дружим :) И они с нами
Дружим, дружим :) И они с нами
Извините, могу ошибаться, но общего между PostgreSQLи HP Vertica только то что они реализуют ACID.
Постгрес типичный реляционный версионник. Таблицы храняться строками, работает с индексами.
Vertica — колоночная система, индексы не нужны — колонка уже индекс. Со всеми вытекающими и втекающими.
Запросы по принципу «посчитай кучу данных и выдай пару сотен строк аггрегата по ним это быстро.
А вот запрос поищи мне данные и дай тесколько тысяч строк из таблицы с десятком — другим колонок будет медленно.
Грубо — сама операция найди ключи от записей — быстрая операция, но собери теперь по этим ключам всю строку может быть сильно медленее.
Постгрес типичный реляционный версионник. Таблицы храняться строками, работает с индексами.
Vertica — колоночная система, индексы не нужны — колонка уже индекс. Со всеми вытекающими и втекающими.
Запросы по принципу «посчитай кучу данных и выдай пару сотен строк аггрегата по ним это быстро.
А вот запрос поищи мне данные и дай тесколько тысяч строк из таблицы с десятком — другим колонок будет медленно.
Грубо — сама операция найди ключи от записей — быстрая операция, но собери теперь по этим ключам всю строку может быть сильно медленее.
Это не совсем так.
В Вертике не каждая колонка — индекс. А только та (те), которые указаны в сортировке и сегментации. Технически они являются hash индексом.
Возможно создание альтернативного индекса, он называется проекцией, но с совместным использованием разных индексов по одной таблице возможны проблемы.
В Вертике не каждая колонка — индекс. А только та (те), которые указаны в сортировке и сегментации. Технически они являются hash индексом.
Возможно создание альтернативного индекса, он называется проекцией, но с совместным использованием разных индексов по одной таблице возможны проблемы.
А вы не пробовали такую систему, как Splunk? Она позиционируется как раз как система для анализа больших данных. У меня в базе 1,6 млрд. записей (события из логов Windows), и пока нормально справляется. Плюс из коробки есть возможность кластеризации.
Сейчас есть мысль старые данные убирать куда-то, но думаем про amazon redshift
Работаете на бесплатном комьюните терабайте? :)
Не пробовали voltdb.com?
Мне прям кажется это под ваши задачи.
Мне прям кажется это под ваши задачи.
еще нет, но посмотрим :)
Тогда будем ждать статью ;)
Вы мне весь мир DWH сломали со своим локом.
Был на highload, Николай Голов из Avito. И я спросил, откуда у вам могли взяться локи таблиц, и он сказал, что нужно смотреть в сторону Transaction Isolation Level потому, что есть глюк у JDBC драйвера выставлять не READ COMMITED
Надеюсь ничего не переврал. :)
Был на highload, Николай Голов из Avito. И я спросил, откуда у вам могли взяться локи таблиц, и он сказал, что нужно смотреть в сторону Transaction Isolation Level потому, что есть глюк у JDBC драйвера выставлять не READ COMMITED
Надеюсь ничего не переврал. :)
спасибо, меня на самом деле тоже смущает данная ситуация, так как сейчас пишется через 1 bolt, а хочется в несколько.
в среду постараюсь разобраться, напишу тут результаты.
в среду постараюсь разобраться, напишу тут результаты.
И вы так делаете Loading Batches Directly into ROS?
Да, так и есть. Это довольно просто проверить, киньте такой запрос, когда подозрительный запрос работает:
select * from sessions s join transactions tr on tr.transaction_id =s.transaction_id
У нас, как я говорил, такую ситуацию создавал самый обычный select, сформированный Tableau через неудачно настроенное соединение.
select * from sessions s join transactions tr on tr.transaction_id =s.transaction_id
У нас, как я говорил, такую ситуацию создавал самый обычный select, сформированный Tableau через неудачно настроенное соединение.
А я вот вас не понял. Локи таблиц в вертике повсюду, в том числе с READ COMMITED.
my.vertica.com/docs/7.1.x/HTML/index.htm#Authoring/ConceptsGuide/Other/READCOMMITTEDIsolation.htm
my.vertica.com/docs/7.1.x/HTML/index.htm#Authoring/ConceptsGuide/Other/READCOMMITTEDIsolation.htm
READ COMMITTED isolation uses exclusive (X) write locks that are maintained until the end of the transaction.
Локи разного уровня. Вот здесь хорошая табличка на эту тему есть: my.vertica.com/docs/7.1.x/HTML/index.htm#Authoring/SQLReferenceManual/SystemTables/MONITOR/LOCKS.htm?Highlight=lock type
И здесь, в упрощенном варианте: my.vertica.com/docs/7.1.x/HTML/Content/Authoring/ConceptsGuide/Other/Transactions.htm
Если вкратце, lock от READ COMMITED другим транзакциям не мешает. А от Serializable — мешает.
И здесь, в упрощенном варианте: my.vertica.com/docs/7.1.x/HTML/Content/Authoring/ConceptsGuide/Other/Transactions.htm
Если вкратце, lock от READ COMMITED другим транзакциям не мешает. А от Serializable — мешает.
Почитайте подробнее тот пример, откуда взята эта цитата: «READ COMMITTED isolation uses exclusive (X) write locks that are maintained until the end of the transaction.»
Там описывается, что такой lock дает операция delete (и, соответственно, update).
insert работает с уровнем блокировки I.
У меня, например, распространена практика, когда в одну единственную таблицу льет от 7 до 30 параллельных транзакций, c read commited изоляцией. На highload я как раз об одном таком процессе рассказывал.
И все отлично работает.
Там описывается, что такой lock дает операция delete (и, соответственно, update).
insert работает с уровнем блокировки I.
У меня, например, распространена практика, когда в одну единственную таблицу льет от 7 до 30 параллельных транзакций, c read commited изоляцией. На highload я как раз об одном таком процессе рассказывал.
И все отлично работает.
Ооок, спасибо! Очевидно, я что-то как-то упустил, я разнес вставку в разные таблицы по разным потокам (что, вообще-то не до фига хорошо, на сколько я понимаю, pre join projections мне с такой техникой не видать из-за нарушения порядка вставки). Впрочем, у меня во многие таблички делаются еще и апдейты в приличном количестве, которые я в итоге все сделал через оптимизированный-мерж. Думаю, эксклюзивные локи при мерже и сформировали у меня мнение, что вертика лочит все.
select * from locks
если что
Ещё мучали Sybase IQ. Но тот не потянул. Я даже где-то расстроился.
Добрый день, был раз знакомству на HighLoad++. :)
Очень рад, что еще кто-то активно использует Pattern Match в Вертике. Мы тоже его используем уже несколько месяцев, местами это дает просто фантастические результаты… Хотя есть и некоторые смешные особенности.
На тему скорости — а не могли бы вы привести код, как у вас отсортирована, сегментирована и партиционирована та таблица, events.events?
Очень рад, что еще кто-то активно использует Pattern Match в Вертике. Мы тоже его используем уже несколько месяцев, местами это дает просто фантастические результаты… Хотя есть и некоторые смешные особенности.
На тему скорости — а не могли бы вы привести код, как у вас отсортирована, сегментирована и партиционирована та таблица, events.events?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
I am Groot. Делаем свою аналитику на событиях