essbase.ruiv_an_ruа вот найти потом узкоспециального покупателя --- тяжело.

VoltDB - возможно есть стнадартное решение , которое позволяет вытаскивать оперативно из VoltDB данные для real-Time DWH

(как компенсирующее решение ? )

Есть готовые переходники для экспортирования в Вертику и Нетиззу.

iv_an_ruVoltDBМне кажется, мы с Вами продолжаем теоретизировать и обсуждать какие-то абсолютно гипотетические проблемы... Разрешите мне повториться и задать Вам тот же самый практический вопрос, который я уже задавал: у Вас есть пример какой-нибудь конкретной OLTP задачи, которая, по Вашему мнению, не вписывается в архитектуру VoltDB?Так вот в том и проблема. Любая конкрентая задача, которая есть у меня под рукой, содержит хоть небольшую, но не нулевую долю аналитики. И хуже того, пролистав ТЗ вы скажете "это невозможно повторить со сравнимым качеством за разумное для экспериментальных целей время" --- и будете 100% правы. Поэтому остаются бенчмарки, которые лично я тихо ненавижу, но лучше которых для исследовательских целей ещё никто ничего не придумал. И тут облом. Новомодная BSBM вам не нравится, старомодная TPC-C тоже. Ну извините, больше популярных "более-менее OLTP" бенчмарок у меня под рукой нет. И пока сравнимых цифр нет, остальное остаётся милыми малополезными разговорами.

-----8<-----

В лохматом 1995 году OpenLink Virtuoso выпускалась как OLTP. Она и сейчас совсем не дурна в этой роли: если не убиваться ради круглой цифры в TPC-C, а просто "обеспечить требуемую пропускную способность и надежность нагрузки, вызванной конкретными запросами продиктованными конкретным бизнес-процесом", то цена лицензии приятно удивит.

Вот только "за время пути собака могла подрасти", и каждый юзер, довольный OLTP производительностью, просил не "ещё больше OLTP", а фенечки для OLAP, виртуальной схемы, 2pc, hosting languages и т.п. И мы соглашались на каждую следующую фенечку. Потому что писать узкоспециальную СУБД легко и просто, а вот найти потом узкоспециального покупателя --- тяжело. Как результат эволюции, последние лет пять Virtuoso стала "OLAP". Несколько внезапно для нас самих. Писали миддлварную СУБД, а юзеры решили, что мы написали OLAP :) Но простите, она же не потеряла ни одной единички в TPC-C? То есть, сидеть на трёхногой табуретке OLTP + миддлварь с виртуальной схемой + OLAP оказывается по всем параметрам лучше, чем на одном пике производительности в TPC-C?
Как-то сумбурно получилось, но тут уж извиняйте. Это жизнь такая сумбурная, а я как акын, что вижу --- то пою.

Как это - "как результат эволюции, последние лет пять Virtuoso стала "OLAP"? То есть, подлежащая архитектура системы затачивалась под OLTP, а используется она как OLAP? Или система с самого начала как гибрид задумывалась?

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


Есть готовые переходники для экспортирования в Вертику и Нетиззу.Real-Time DWH это не "экспортирование"

Справедливо... Переходники обеспечивают периодическую загрузку в Вертику и Нетиззу короткими бэтчами через короткие интервалы времени, то есть назвать это сплошным потоком данных, конечно, нельзя. В качестве примера, некоторые из наших юзеров ставят VoltDB как OLTP front-end систему перед аналитической Вертикой - инжестают рил-тайм данные в VoltDB (запись-за-записью, а не в бэтче), модифицируют, если нужно (всякий там data enrichment), потом сливают мелкими бэтчами (но часто) в Вертику. При этом аналитический клиент может слать читательское запросы через JDBC одновременно в Волт, и Вертику, то есть результат может включать данные из обоих баз

VoltDBПереходники обеспечивают периодическую загрузку в Вертику и Нетиззу короткими бэтчами через короткие интервалы времени, то есть назвать это сплошным потоком данных, конечно, нельзя. В качестве примера, некоторые из наших юзеров ставят VoltDB как OLTP front-end систему перед аналитической Вертикой - инжестают рил-тайм данные в VoltDB (запись-за-записью, а не в бэтче), модифицируют, если нужно (всякий там data enrichment), потом сливают мелкими бэтчами (но часто) в Вертику. При этом аналитический клиент может слать читательское запросы через JDBC одновременно в Волт, и Вертику, то есть результат может включать данные из обоих баз

Да, кстати, забыл сказать, при таком сценарии VoltDB и Vertica могут сидеть на одном и том же кластере (ведь обе архитектуры shared-nothing) - данные VoltDB в памяти, данные Verticа - на диске. То есть, получается система, у которой OLTP имеет строчное хранилище, а аналитика - колоночное; каждая оптимизирована под свою нагрузку. При этом сидят на одном кластере (соответственно, цену делят), а на софтверном уровне - независимы, на ноги друг другу не наступают. Плюс у каждой части свой собственный maintanance plan.

iv_an_ruVoltDBпропущено...


Как это - "как результат эволюции, последние лет пять Virtuoso стала "OLAP"? То есть, подлежащая архитектура системы затачивалась под OLTP, а используется она как OLAP? Или система с самого начала как гибрид задумывалась?А что такого может быть в приличном OLTP-сервере, что помешало бы приличному OLAP-серверу? Хорошая работа с дисками? Хорошая работа с сетью? Хорошие диспетчеры блоков памяти? ...больших объёмов виртпамяти? ...нитей/файберов? Хорошие драйверы ODBC/UDBC/IODBC/чего-ещё там? Возможно, это из OLAP в OLTP эволюционировать было бы менее удобно, не знаю :)

Не то что бы "помешало", но OLTP и OLAP оптимизируются по-разному

О тенденции разделения гибридных OLTP/OLAP систем на специализированные


Как результат такой тенденции, существует специализированная OLAP Vertica, разработанная для эффективных аналитических нагрузок и бэтч-загрузок, а также, специализированная OLTP VoltDB, разработанная для эффективной поддержки транзакционной нагрузки в режиме реального времени. Дело в том, что идеальные архитектуры OLTP и OLAP имеют очень разные задачи.

Классическая OLAP нагрузка подразумевает большое количество агрегатных запросов (SUM, AVG, COUNT итд) и, как результат, требует сканнированния всей (или большой части) таблицы, что, в свою очередь, подразумевает большое количество чтений с диска. Причем, большинству аналитических запросов полная строка данных не нужна. Колоночное хранилище, позволяет запросу читать отдельные колонки данных. Кроме того, данные, читаемые по-колоночно, отлично компрессируются. По этим причинам, колоночное хранилище прекрасно подходит для оптимизации решения OLAP задач.

OLTP, в свою очередь, отличается большим количеством точечных запросов, находящих в таблице запись (строку) данных, обязательно включающую каждую колонку. Соответственно, колоночное хранилище уступает построчному для оптимизации OLTP нагрузки.

Таким образом, возникает противоречие: если система должна быть гибридной OLTP/OLAP, оптимизировать ее нужно было бы методами хранения данных, противоречащими друг другу. Но если разделить OLTP и OLAP, тогда каждая из-задач может быть оптимизирована отдельно и без последствий для другой задачи: OLTP с построчным хранилищем и OLAP с колоночным. Своего рода, случай когда 1+1>2

WarstoneВот у меня есть интересная статистическая задачка, которую мы гоняем на MySQL в MyISAM'е на одной ноде с "индексы на SSD, данные на SATA"... Смысл вот в чем:
На вход идут специальные логи раз в 15 минут средний лог:
То есть 2,5КК строчек и 900Мб распакованного размера.

Мы же OLTP СУБД, т.е у нас данные приходят по-одной (запись за записью), а не в бэтче. Вам пришлось бы построчно читать из Вашего файла и вставлять каждую запись в базу. Если это возможно, то тогда есть смысл продолжить разговор...

WarstoneОдна запись имеет где-то 7 уникальных измерений и порядка 5 линейных параметров. Что мы делаем - Мы берем все попавшиеся варианты измерений и складываем. В среднем получается где-то 300-400К записей за 15 минут.

Я не совсем понял... Вы имеете ввиду, что из каждой строчки Вы достаете около 12 атрибутов (7+5) и так как у вас 2.5К строк в бэтче, всего получается около 300-400К элементов данных, каждый из них должен быть записан в таблицу базу как отдельная запись?

WarstoneПотом они агрегируются в часы, дни и т.д. Дальше мы строим графики по мере необходимости. В среднем нам надо где-то 1 процент от всех данных (99% не будут выбраны никогда). Сейчас база весит 1,5 Тб.

Так как записи вставляются через вызов сохраненной процедуры написанной в JAVA, внутри такой процедуры Вы можете делать дополнительные трансформации. Например, Вы передаете в процедуру вашу запись из лог-файла, внутри процедуры в JAVA-коде не только делаете INSERT самой записи в ее таблицу, но и вытаскиваете из этой записи все необходимые атрибуты и разбрасываете их по разным таблицам, и может быть даже UPDATE какую нибудь другую таблицу с бегущими суммами или там счетчиками разными. Вся описанная сохраненная процедура содержащие несколько таких INSERT и UPDATE - это одна ACID транзакция и, соответственно, комитается или откатывается целиком.

WarstoneНасколько я понимаю - это как-раз ваш юз кейс.

Может быть... Я бы хотел по-лучше понять задачу - пока я не совсем понимаю зачем нужна OLTP, если данные приходят в бэтчах и при этом записи в каждом бэтче статические, т.е не изменяются... Не проще ли написать какой-нибудь загрузчик, который читает из свежего куска лог-файла, достает нужные данные, строит другой бэтч и затем вставляет его в аналитическую базу?

WarstoneВ связи с этим вопросы:
1) Как у вас там с ACID'ом? (Я знаю что у MyISAM с ACID'ом проблемы)

Поддерживаем

Warstone2) Как у вас со скоростью работы на одной ноде? (Реплика есть, но она принципиально не пользуется, так как на селектах и так довольно быстро работает) ...

Один нод - в общем, не проблема... Но так как VoltDB полностью в памяти, а у Вас 1.5ТБ данных, нод может понадобиться очень уж большой :)

[quot Alexander Ryndin]VoltDBпропущено...


Справедливо... Переходники обеспечивают периодическую загрузку в Вертику и Нетиззу короткими бэтчами через короткие интервалы времени, то есть назвать это сплошным потоком данных, конечно, нельзя. В качестве примера, некоторые из наших юзеров ставят VoltDB как OLTP front-end систему перед аналитической Вертикой - инжестают рил-тайм данные в VoltDB (запись-за-записью, а не в бэтче), модифицируют, если нужно (всякий там data enrichment), потом сливают мелкими бэтчами (но часто) в Вертику. При этом аналитический клиент может слать читательское запросы через JDBC одновременно в Волт, и Вертику, то есть результат может включать данные из обоих баз

Alexander RyndinМикробатчи - это проблема самой вертики, а не VoltDB. Они нужны, потому что Real-Time репликация это OLTP, а Vertica, не смотря на все хитрости, не предназначена для OLTP. Поэтому OLTP-операции объединяют в пачки (батчи) и грузят их раз 10-100-1000 секунд

Абсолютно правильно - Vertica разработана как аналитическая система, а не OLTP. Она поддерживает trickle-loading. Причем, такой бэтч сидит в WOS в строчном формате до тех пор пока его tuple-mover в колоночный формат не переведет и в ROS не бросит; таким образом если у tuple-mover периодичность небольшая, данные в WOS накапливаются и запросы, у которых уровень изоляции требует доступа к данным и в WOS и в ROS, могут быть сравнительно медленными. Но для бэтчевой загрузки в "почти" настоящем времени - VoltDB оборудована отлично.

Alexander RyndinСо стороны VoltDB Вы получите другую проблему. Допустим, прошло 10 минут. За это время на так полюбившихся Вам warehouse изменилось количество 100 товаров из 100 млн. Ну или 1 счетчика из миллиарда. Как вы поймете, какие данные изменились для обновления Vertica?

У них философия другая - пока запись может быть каким-то образом модифицирована, они эту запись в OLTP держат, как только запись становится статической - они ее в Vertica переводят. Например, ордер посылается на рынок - какое то время он может модифицироваться, но как только он выполнен или отменен, дальнейших модификаций быть не может, т.е он переводится в OLAP субсистему

Alexander RyndinWarstoneОдна запись имеет где-то 7 уникальных измерений и порядка 5 линейных параметров. Что мы делаем - Мы берем все попавшиеся варианты измерений и складываем. В среднем получается где-то 300-400К записей за 15 минут. Потом они агрегируются в часы, дни и т.д. Дальше мы строим графики по мере необходимости. В среднем нам надо где-то 1 процент от всех данных (99% не будут выбраны никогда). Сейчас база весит 1,5 Тб.

Насколько я понимаю - это как-раз ваш юз кейс.Это классический пример задачи для Complex Event Processing. Посмотрите, если интересно :)

Я с СЕР знаком. Отличная вещь для того, для чего он разработан, но есть проблемы: адресуемый горизонт времени для запросов достаточно ограничен. Если объявить окно ивентов в запросе слишком большим, движок должен хранить в памяти слишком много данных. В некоторых случаях, столько памяти просто не доступно на машине, на которой такой движок работает. А ведь СЕР очень тяжело горизонтально масштабировать, те в большинство СЕР движков ограничены размером оперативной памяти на единственной машине.

iv_an_ruНичто не запрещает в одном движке поддерживать и строчное и колоночное хранение. Чесслово.

Да нет - никто не запрещает хранить одну и ту же запись в двух местах - и в строчном хранилище, и в колоночном. И иметь один "универсальный" оптимизатор тоже возможно. Вертика, кстати, так и делает - у них есть WOS и в ROS. Просто они свой строчный WOS под OLTP не затачивали, а сфокусировались на поддержке аналитических нагрузок в колоночном ROS. Но если копнуть поглубже, C-Store и Н-Store ведь очень друг друга дополняют

VoltDB Но для бэтчевой загрузки в "почти" настоящем времени - VoltDB оборудована отлично.

Опечаточка вышла... Но для бэтчевой загрузки в "почти" настоящем времени - Вертика оборудована отлично.