|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
essbase.ruiv_an_ruа вот найти потом узкоспециального покупателя --- тяжело. VoltDB - возможно есть стнадартное решение , которое позволяет вытаскивать оперативно из VoltDB данные для real-Time DWH (как компенсирующее решение ? ) Есть готовые переходники для экспортирования в Вертику и Нетиззу. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 19:54 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBessbase.ruпропущено... VoltDB - возможно есть стнадартное решение , которое позволяет вытаскивать оперативно из VoltDB данные для real-Time DWH (как компенсирующее решение ? ) Есть готовые переходники для экспортирования в Вертику и Нетиззу.Real-Time DWH это не "экспортирование" ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 20:02 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ruVoltDBМне кажется, мы с Вами продолжаем теоретизировать и обсуждать какие-то абсолютно гипотетические проблемы... Разрешите мне повториться и задать Вам тот же самый практический вопрос, который я уже задавал: у Вас есть пример какой-нибудь конкретной OLTP задачи, которая, по Вашему мнению, не вписывается в архитектуру VoltDB?Так вот в том и проблема. Любая конкрентая задача, которая есть у меня под рукой, содержит хоть небольшую, но не нулевую долю аналитики. И хуже того, пролистав ТЗ вы скажете "это невозможно повторить со сравнимым качеством за разумное для экспериментальных целей время" --- и будете 100% правы. Поэтому остаются бенчмарки, которые лично я тихо ненавижу, но лучше которых для исследовательских целей ещё никто ничего не придумал. И тут облом. Новомодная BSBM вам не нравится, старомодная TPC-C тоже. Ну извините, больше популярных "более-менее OLTP" бенчмарок у меня под рукой нет. И пока сравнимых цифр нет, остальное остаётся милыми малополезными разговорами. -----8<----- В лохматом 1995 году OpenLink Virtuoso выпускалась как OLTP. Она и сейчас совсем не дурна в этой роли: если не убиваться ради круглой цифры в TPC-C, а просто "обеспечить требуемую пропускную способность и надежность нагрузки, вызванной конкретными запросами продиктованными конкретным бизнес-процесом", то цена лицензии приятно удивит. Особенно если цена будет root@master:/etc/bind# apt-get install virtuoso-opensource Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: virtuoso-opensource-6.1 virtuoso-server virtuoso-vad-conductor virtuoso-vsp-startpage Suggested packages: virtuoso-vad-doc virtuoso-vad-demo virtuoso-vad-tutorial virtuoso-vad-rdfmappers virtuoso-vad-sparqldemo virtuoso-vad-syncml virtuoso-vad-bpel virtuoso-vad-isparql virtuoso-vad-ods The following NEW packages will be installed: virtuoso-opensource virtuoso-opensource-6.1 virtuoso-server virtuoso-vad-conductor virtuoso-vsp-startpage 0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded. Need to get 2,084 kB of archives. After this operation, 9,302 kB of additional disk space will be used. Do you want to continue [Y/n]? Вот только "за время пути собака могла подрасти", и каждый юзер, довольный OLTP производительностью, просил не "ещё больше OLTP", а фенечки для OLAP, виртуальной схемы, 2pc, hosting languages и т.п. И мы соглашались на каждую следующую фенечку. Потому что писать узкоспециальную СУБД легко и просто, а вот найти потом узкоспециального покупателя --- тяжело. Как результат эволюции, последние лет пять Virtuoso стала "OLAP". Несколько внезапно для нас самих. Писали миддлварную СУБД, а юзеры решили, что мы написали OLAP :) Но простите, она же не потеряла ни одной единички в TPC-C? То есть, сидеть на трёхногой табуретке OLTP + миддлварь с виртуальной схемой + OLAP оказывается по всем параметрам лучше, чем на одном пике производительности в TPC-C? Как-то сумбурно получилось, но тут уж извиняйте. Это жизнь такая сумбурная, а я как акын, что вижу --- то пою. Как это - "как результат эволюции, последние лет пять Virtuoso стала "OLAP"? То есть, подлежащая архитектура системы затачивалась под OLTP, а используется она как OLAP? Или система с самого начала как гибрид задумывалась? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 20:09 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
Alexander RyndinVoltDBпропущено... Есть готовые переходники для экспортирования в Вертику и Нетиззу.Real-Time DWH это не "экспортирование" Справедливо... Переходники обеспечивают периодическую загрузку в Вертику и Нетиззу короткими бэтчами через короткие интервалы времени, то есть назвать это сплошным потоком данных, конечно, нельзя. В качестве примера, некоторые из наших юзеров ставят VoltDB как OLTP front-end систему перед аналитической Вертикой - инжестают рил-тайм данные в VoltDB (запись-за-записью, а не в бэтче), модифицируют, если нужно (всякий там data enrichment), потом сливают мелкими бэтчами (но часто) в Вертику. При этом аналитический клиент может слать читательское запросы через JDBC одновременно в Волт, и Вертику, то есть результат может включать данные из обоих баз ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 20:39 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
Вот у меня есть интересная статистическая задачка, которую мы гоняем на MySQL в MyISAM'е на одной ноде с "индексы на SSD, данные на SATA"... Смысл вот в чем: На вход идут специальные логи раз в 15 минут средний лог: Код: sql 1. 2.
То есть 2,5КК строчек и 900Мб распакованного размера. Одна запись имеет где-то 7 уникальных измерений и порядка 5 линейных параметров. Что мы делаем - Мы берем все попавшиеся варианты измерений и складываем. В среднем получается где-то 300-400К записей за 15 минут. Потом они агрегируются в часы, дни и т.д. Дальше мы строим графики по мере необходимости. В среднем нам надо где-то 1 процент от всех данных (99% не будут выбраны никогда). Сейчас база весит 1,5 Тб. Насколько я понимаю - это как-раз ваш юз кейс. В связи с этим вопросы: 1) Как у вас там с ACID'ом? (Я знаю что у MyISAM с ACID'ом проблемы) 2) Как у вас со скоростью работы на одной ноде? (Реплика есть, но она принципиально не пользуется, так как на селектах и так довольно быстро работает). ... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 20:46 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBiv_an_ruпропущено... Так вот в том и проблема. Любая конкрентая задача, которая есть у меня под рукой, содержит хоть небольшую, но не нулевую долю аналитики. И хуже того, пролистав ТЗ вы скажете "это невозможно повторить со сравнимым качеством за разумное для экспериментальных целей время" --- и будете 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? Или система с самого начала как гибрид задумывалась?А что такого может быть в приличном OLTP-сервере, что помешало бы приличному OLAP-серверу? Хорошая работа с дисками? Хорошая работа с сетью? Хорошие диспетчеры блоков памяти? ...больших объёмов виртпамяти? ...нитей/файберов? Хорошие драйверы ODBC/UDBC/IODBC/чего-ещё там? Возможно, это из OLAP в OLTP эволюционировать было бы менее удобно, не знаю :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 20:50 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBПереходники обеспечивают периодическую загрузку в Вертику и Нетиззу короткими бэтчами через короткие интервалы времени, то есть назвать это сплошным потоком данных, конечно, нельзя. В качестве примера, некоторые из наших юзеров ставят VoltDB как OLTP front-end систему перед аналитической Вертикой - инжестают рил-тайм данные в VoltDB (запись-за-записью, а не в бэтче), модифицируют, если нужно (всякий там data enrichment), потом сливают мелкими бэтчами (но часто) в Вертику. При этом аналитический клиент может слать читательское запросы через JDBC одновременно в Волт, и Вертику, то есть результат может включать данные из обоих баз Да, кстати, забыл сказать, при таком сценарии VoltDB и Vertica могут сидеть на одном и том же кластере (ведь обе архитектуры shared-nothing) - данные VoltDB в памяти, данные Verticа - на диске. То есть, получается система, у которой OLTP имеет строчное хранилище, а аналитика - колоночное; каждая оптимизирована под свою нагрузку. При этом сидят на одном кластере (соответственно, цену делят), а на софтверном уровне - независимы, на ноги друг другу не наступают. Плюс у каждой части свой собственный maintanance plan. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 20:52 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
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 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 20:57 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
WarstoneВ среднем получается где-то 300-400К записей за 15 минут. Потом они агрегируются в часы, дни и т.д. Дальше мы строим графики по мере необходимости. В среднем нам надо где-то 1 процент от всех данных (99% не будут выбраны никогда). Сейчас база весит 1,5 Тб. Насколько я понимаю - это как-раз ваш юз кейс.Это и наш юз кейс. Свежие цифры по загрузке TPC-H, точнее RDF-H, на одной машине с четырьмя дисками: TPC-H 100G dataset (600M order lines и т.д.), sustained rate загрузки --- 270К RDF-ных фактов в секунду. У вас 12 колонок вместо четырёх, зато без словарей --- давайте не будем про словари, щедро поделим скорость на три и пусть будет 90К строк в секунду. Логи делать незачем, проще грузить "внаглую" и на некоторое время оставлять исходные файлы. В результате мы максимум за пять секунд закидываем очередную 15-минутную порцию, и потом без помех делаем с данными всё, что душе угодно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 21:09 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBiv_an_ruпропущено... А что такого может быть в приличном 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Ничто не запрещает в одном движке поддерживать и строчное и колоночное хранение. Чесслово. И даже держать индексы разного типа для одной таблицы. И при необходимости компилировать одну хранимку и как скалярную и как векторизованную. И две версии встроенных функций, если они особо критичны по времени, и пусть оптимизатор чешет в затылке, каким образом ему сподручней выполнить операцию, не создавая лишних трудностей разработчику. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 21:16 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBAlexander Ryndinпропущено... Real-Time DWH это не "экспортирование" Справедливо... Переходники обеспечивают периодическую загрузку в Вертику и Нетиззу короткими бэтчами через короткие интервалы времени, то есть назвать это сплошным потоком данных, конечно, нельзя. В качестве примера, некоторые из наших юзеров ставят VoltDB как OLTP front-end систему перед аналитической Вертикой - инжестают рил-тайм данные в VoltDB (запись-за-записью, а не в бэтче), модифицируют, если нужно (всякий там data enrichment), потом сливают мелкими бэтчами (но часто) в Вертику. При этом аналитический клиент может слать читательское запросы через JDBC одновременно в Волт, и Вертику, то есть результат может включать данные из обоих базМикробатчи - это проблема самой вертики, а не VoltDB. Они нужны, потому что Real-Time репликация это OLTP, а Vertica, не смотря на все хитрости, не предназначена для OLTP. Поэтому OLTP-операции объединяют в пачки (батчи) и грузят их раз 10-100-1000 секунд Со стороны VoltDB Вы получите другую проблему. Допустим, прошло 10 минут. За это время на так полюбившихся Вам warehouse изменилось количество 100 товаров из 100 млн. Ну или 1 счетчика из миллиарда. Как вы поймете, какие данные изменились для обновления Vertica? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 21:39 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
WarstoneВот у меня есть интересная статистическая задачка, которую мы гоняем на MySQL в MyISAM'е на одной ноде с "индексы на SSD, данные на SATA"... Смысл вот в чем: На вход идут специальные логи раз в 15 минут средний лог: Код: sql 1. 2.
То есть 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ТБ данных, нод может понадобиться очень уж большой :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 21:42 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
WarstoneОдна запись имеет где-то 7 уникальных измерений и порядка 5 линейных параметров. Что мы делаем - Мы берем все попавшиеся варианты измерений и складываем. В среднем получается где-то 300-400К записей за 15 минут. Потом они агрегируются в часы, дни и т.д. Дальше мы строим графики по мере необходимости. В среднем нам надо где-то 1 процент от всех данных (99% не будут выбраны никогда). Сейчас база весит 1,5 Тб. Насколько я понимаю - это как-раз ваш юз кейс.Это классический пример задачи для Complex Event Processing. Посмотрите, если интересно :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 21:42 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
Alexander RyndinVoltDBпропущено... Справедливо... Переходники обеспечивают периодическую загрузку в Вертику и Нетиззу короткими бэтчами через короткие интервалы времени, то есть назвать это сплошным потоком данных, конечно, нельзя. В качестве примера, некоторые из наших юзеров ставят VoltDB как OLTP front-end систему перед аналитической Вертикой - инжестают рил-тайм данные в VoltDB (запись-за-записью, а не в бэтче), модифицируют, если нужно (всякий там data enrichment), потом сливают мелкими бэтчами (но часто) в Вертику. При этом аналитический клиент может слать читательское запросы через JDBC одновременно в Волт, и Вертику, то есть результат может включать данные из обоих базМикробатчи - это проблема самой вертики, а не VoltDB. Они нужны, потому что Real-Time репликация это OLTP, а Vertica, не смотря на все хитрости, не предназначена для OLTP. Поэтому OLTP-операции объединяют в пачки (батчи) и грузят их раз 10-100-1000 секунд Со стороны VoltDB Вы получите другую проблему. Допустим, прошло 10 минут. За это время на так полюбившихся Вам warehouse изменилось количество 100 товаров из 100 млн. Ну или 1 счетчика из миллиарда. Как вы поймете, какие данные изменились для обновления Vertica?Кстати, а как поживают частичные индексы в VoltDB? Вот хочу я отметку времени последнего изменения на каждом товаре, для закидывания лопатой в аналитическую базу, но не хочу, чтоб у меня был гигантский индекс, хочу держать в нём только свежачок, и подчищать старьё после каждой лопаты. Я могу так? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 21:53 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
[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 субсистему ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 22:02 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
Alexander RyndinWarstoneОдна запись имеет где-то 7 уникальных измерений и порядка 5 линейных параметров. Что мы делаем - Мы берем все попавшиеся варианты измерений и складываем. В среднем получается где-то 300-400К записей за 15 минут. Потом они агрегируются в часы, дни и т.д. Дальше мы строим графики по мере необходимости. В среднем нам надо где-то 1 процент от всех данных (99% не будут выбраны никогда). Сейчас база весит 1,5 Тб. Насколько я понимаю - это как-раз ваш юз кейс.Это классический пример задачи для Complex Event Processing. Посмотрите, если интересно :) Я с СЕР знаком. Отличная вещь для того, для чего он разработан, но есть проблемы: адресуемый горизонт времени для запросов достаточно ограничен. Если объявить окно ивентов в запросе слишком большим, движок должен хранить в памяти слишком много данных. В некоторых случаях, столько памяти просто не доступно на машине, на которой такой движок работает. А ведь СЕР очень тяжело горизонтально масштабировать, те в большинство СЕР движков ограничены размером оперативной памяти на единственной машине. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 22:14 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ruНичто не запрещает в одном движке поддерживать и строчное и колоночное хранение. Чесслово. Да нет - никто не запрещает хранить одну и ту же запись в двух местах - и в строчном хранилище, и в колоночном. И иметь один "универсальный" оптимизатор тоже возможно. Вертика, кстати, так и делает - у них есть WOS и в ROS. Просто они свой строчный WOS под OLTP не затачивали, а сфокусировались на поддержке аналитических нагрузок в колоночном ROS. Но если копнуть поглубже, C-Store и Н-Store ведь очень друг друга дополняют ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 22:38 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDB Но для бэтчевой загрузки в "почти" настоящем времени - VoltDB оборудована отлично. Опечаточка вышла... Но для бэтчевой загрузки в "почти" настоящем времени - Вертика оборудована отлично. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 23:01 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBОдин нод - в общем, не проблема... Но так как VoltDB полностью в памяти, а у Вас 1.5ТБ данных, нод может понадобиться очень уж большой :)А... То есть для больших задач ее использовать нельзя так как мы ограничены оперативкой. Ясно, спасибо. То есть переход с MyISAM на VoltDB для меня стоит поставить 10-15 серверов... Не, спасибо. Я как-нибудь так. Ну основную мысль я услышал. Все в памяти. Дальше не интересно. Для меня VoltDB - мертвая технология, так как она требует ОЧЕНЬ больших затрат на железо. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 15:58 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ru, Надо будет мне Юз кейс сделать наш и погонять на Вертике. Кстати... что у вас с лицензированием?.. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 16:01 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBТак как записи вставляются через вызов сохраненной процедуры написанной в JAVAОй... Вечно тормозящая JAVA... Все, закапывайте. Никогда ее у нас не будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 16:02 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
WarstoneДля меня VoltDB - мертвая технология, так как она требует ОЧЕНЬ больших затрат на железо.Вы не одиноки в этом мнении. И некоторые примеры на блоговом сайте VoltDB добавляют только удивление, но не восторгов. Скажем, подсчёт голосов за участников телепередачи "алло мы ищем таланты" --- очень тяжёлая, ответственная и критичная к честной ACID-ности задача. Счётчик лейкоцитов с реактивным двигателем. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 16:05 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
Warstoneiv_an_ru, Надо будет мне Юз кейс сделать наш и погонять на Вертике. Кстати... что у вас с лицензированием?..Одномашинная виртуоза без виртуальной схемы есть в открытых исходниках, версию с виртуальной схемой и кластерную версию придётся покупать, Есть триальные лицензии, их обычно дают на месяц, но можно договориться и на подольше. В амазоновом облаке есть образы дисков с предустановленной полной версией, не требующей лицензии, инсталлируй бери и гоняй, но та версия скомпилирована только под тот линукс, который живёт в том облаке. С амазоном есть смысл играться, если вы, например, генетик --- люди делают образы дисков с уже готовыми базами Uniprot и т.п., так что вместо начального заполнения базы можно взять готовую, долить немного своих данных, погонять все нужные аналитические запросы, а потом просто грохнуть. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 16:15 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ru, Ну мне для тестов надо, насколько я понял, очень мало... Хост будет 1 (не готовы несколько нод под это дело отдавать), а что есть виртуальная схема? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 18:05 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
Warstoneiv_an_ru, Ну мне для тестов надо, насколько я понял, очень мало... Хост будет 1 (не готовы несколько нод под это дело отдавать), а что есть виртуальная схема?Это возможность выполнить ATTACH TABLE <table_name> FROM <datasource> AS <local_alias>, после чего использовать таблицу с соседнего оракла/mssql/и т.п. в запросах наравне с таблицами, которые хранятся локально. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 18:23 |
|
|
start [/forum/topic.php?fid=56&msg=38533773&tid=2015180]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
150ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 233ms |
total: | 481ms |
0 / 0 |