Почитайте подробнее тот пример, откуда взята эта цитата: «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 я как раз об одном таком процессе рассказывал.
И все отлично работает.
Вот, кстати, еще возможная причина: «Previously, a deadlock in the JDBC driver sometimes occurred when the close() methods of a Connection and a child PreparedStatement were called concurrently. The issue has been resolved.»
Эта проблема исправлена последним сервиспаком.
Да, так и есть. Это довольно просто проверить, киньте такой запрос, когда подозрительный запрос работает:
select * from sessions s join transactions tr on tr.transaction_id =s.transaction_id
У нас, как я говорил, такую ситуацию создавал самый обычный select, сформированный Tableau через неудачно настроенное соединение.
Это не совсем так.
В Вертике не каждая колонка — индекс. А только та (те), которые указаны в сортировке и сегментации. Технически они являются hash индексом.
Возможно создание альтернативного индекса, он называется проекцией, но с совместным использованием разных индексов по одной таблице возможны проблемы.
Добрый день, был раз знакомству на HighLoad++. :)
Очень рад, что еще кто-то активно использует Pattern Match в Вертике. Мы тоже его используем уже несколько месяцев, местами это дает просто фантастические результаты… Хотя есть и некоторые смешные особенности.
На тему скорости — а не могли бы вы привести код, как у вас отсортирована, сегментирована и партиционирована та таблица, events.events?
Нюансов очень много, но я теперь лучше понимаю, на чем лучше сфокусироваться в следующей статье.
Там сделаю примеры таблиц основных сущностей — хаба, сателита и линка (терминологию взял из Data Vault), и напишу про то, как устроены ELT процессы на питоне.
Но будут именно иллюстративные примеры, верхнеуровневые, примеров кода автогенерации не обещаю.
Спасибо :)
Сервис не в проекте, это Авито :)
Про опенсорс… в начале уже писал, что выбор технологии немного за рамками статьи… но, если вкратце:
1. нам нужно было, чтобы система заработала быстро. Не было время на овладение и кастомизацию опенсорс инфраструктуры.
2. на тему HBase — данные нужно было не просто хранить, они все, вся совокупность, должны быть доступны для Ad-hoc аналитики. Посредством BI инструментов (Tableau), или посредством SQL. Сейчас у нас сидит чуть больше полудюжины аналитиков, которые, после однодневного обучения, анализируют все наши десятки ТБ информации посредством SQL запросов.
3. на тему Кассанды — вопрос в стабильности, скорости заливки, и, прежде всего, скорости выполнения ad-hoc SQL запросов. За счет сжатия и in-memory алгоритмов вертика выполняет подобные запросы за секунды или, в худшем случае, минуты.
Там описывается, что такой lock дает операция delete (и, соответственно, update).
insert работает с уровнем блокировки I.
У меня, например, распространена практика, когда в одну единственную таблицу льет от 7 до 30 параллельных транзакций, c read commited изоляцией. На highload я как раз об одном таком процессе рассказывал.
И все отлично работает.
И здесь, в упрощенном варианте: my.vertica.com/docs/7.1.x/HTML/Content/Authoring/ConceptsGuide/Other/Transactions.htm
Если вкратце, lock от READ COMMITED другим транзакциям не мешает. А от Serializable — мешает.
Эта проблема исправлена последним сервиспаком.
select * from sessions s join transactions tr on tr.transaction_id =s.transaction_id
У нас, как я говорил, такую ситуацию создавал самый обычный select, сформированный Tableau через неудачно настроенное соединение.
В Вертике не каждая колонка — индекс. А только та (те), которые указаны в сортировке и сегментации. Технически они являются hash индексом.
Возможно создание альтернативного индекса, он называется проекцией, но с совместным использованием разных индексов по одной таблице возможны проблемы.
Очень рад, что еще кто-то активно использует Pattern Match в Вертике. Мы тоже его используем уже несколько месяцев, местами это дает просто фантастические результаты… Хотя есть и некоторые смешные особенности.
На тему скорости — а не могли бы вы привести код, как у вас отсортирована, сегментирована и партиционирована та таблица, events.events?
Там сделаю примеры таблиц основных сущностей — хаба, сателита и линка (терминологию взял из Data Vault), и напишу про то, как устроены ELT процессы на питоне.
Но будут именно иллюстративные примеры, верхнеуровневые, примеров кода автогенерации не обещаю.
Сервис не в проекте, это Авито :)
Про опенсорс… в начале уже писал, что выбор технологии немного за рамками статьи… но, если вкратце:
1. нам нужно было, чтобы система заработала быстро. Не было время на овладение и кастомизацию опенсорс инфраструктуры.
2. на тему HBase — данные нужно было не просто хранить, они все, вся совокупность, должны быть доступны для Ad-hoc аналитики. Посредством BI инструментов (Tableau), или посредством SQL. Сейчас у нас сидит чуть больше полудюжины аналитиков, которые, после однодневного обучения, анализируют все наши десятки ТБ информации посредством SQL запросов.
3. на тему Кассанды — вопрос в стабильности, скорости заливки, и, прежде всего, скорости выполнения ad-hoc SQL запросов. За счет сжатия и in-memory алгоритмов вертика выполняет подобные запросы за секунды или, в худшем случае, минуты.