|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBiv_an_ruС запозданием до меня дошло, что если транзакции выполняются строго одна за одной, то на боевой системе нельзя использовать отладчик. Не то что бы нельзя...Если останов одной транзакции останавливает всю работу вообще (транзакции исполняются строго последовательно), то без всяких "не то что бы". С другой стороны, это не так важно, поскольку здесь ничего особо сложного в хранимках лучше не писать, чтобы не похоронить производительность. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 07:02 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBПартиционирование происходит не только для данных, но и для хранимых процедур. Таким образом, процедура выполняется на том же ноде, где размещена соответствующая партиция данных, Программный код и данные которыми он оперирует не совсем одно и тоже . Я знаю только одну концепцию, которая работает в описанном Вами режиме - это программирования для BigData - Map:Reduce. Означает ли что для VoltDB нужно писать хранимки в таком же стиле ? з.ы. IMHO хранимка это не только "догонка" транзакций "связанными" данными (ключами или справочниками) . Обычно это еще и пакетная обработка всех данных (за год, или день). ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 10:13 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBessbase.ru2) Можно ли || код. Если Вы имеете ввиду sqlcmd, то да Я имею ввиду , что бы в коде сделать опреацию "выполнить процедуру в три четыре потока , дождаться завершения всех потоков , получить консолидированный результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 10:15 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBХранимые процедуры пишутся в JAVA, соответственно, все JAVA IPC методы доступны жесть. по идее я не должен знать на какой ноде выполняется конкретный вызов процедуры. При предложенном подходе , мне придется придумывать собственную шину данных для всего кластера. Чем мне может помочь в этом VoltDB ? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 10:17 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBЯ думаю, производительность Java приложений в большей степени зависит от индивидульного стиля разработки такого приложения, чем от GC. Получается что весь код хранимок выполняется в других процессах и службах ? Т.е. по сути нет совмещения данных и программного кода как это есть в других RDB ? (где можно написать бизнес слой на PL-SQL(TSQL) и получить дополнительный выйгрыш за счет того, что данные "далеко" не пробрасываются ? ) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 10:20 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBНет. Но у разработчика есть доступ к таблице из Java, так что... Концепция табличный функций - это не только доступ к таблицам. Если программист знает вкус стиля программирования с ТФ, перейти к временным таблицам - это все равно что с Java перейти на ASM. ER ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 10:23 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
essbase.ruVoltDBХранимые процедуры пишутся в JAVA, соответственно, все JAVA IPC методы доступны жесть. по идее я не должен знать на какой ноде выполняется конкретный вызов процедуры. При предложенном подходе , мне придется придумывать собственную шину данных для всего кластера. Чем мне может помочь в этом VoltDB ?Дока говорит, что любая хранимка обязана гарантировать, что результат её работы не зависит от ноды. На этом фоне IPC выглядит "полулегальным", потому что вы не можете защититься от сбоев транпорта. Если ноды A и B выполняют одну и ту же хранимку, которая обращается к X вне кластера, но X почему-то отвечает только ноде B, то формально гарантия нарушена (а точного описания "кары" за нарушение я быстро не нашёл). (У нас проще. Хранимка может звать любой код на любом hosted language, но этот код будет исполняться на той машине кластера, к которой прицепился клиент, даже если разные части самой хранимки выполняются на разных машинах кластера. Технически никто не запрещает на разных машинах кластера держать вообще разные версии рантаймов perl/php/java и т.п., чтобы дать возможность каждому клиенту юзать его любимую версию и не греть голову совместимостью тех версий.) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 11:29 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
essbase.ruVoltDBПартиционирование происходит не только для данных, но и для хранимых процедур. Таким образом, процедура выполняется на том же ноде, где размещена соответствующая партиция данных, Программный код и данные которыми он оперирует не совсем одно и тоже . Я знаю только одну концепцию, которая работает в описанном Вами режиме - это программирования для BigData - Map:Reduce. Означает ли что для VoltDB нужно писать хранимки в таком же стиле ? з.ы. IMHO хранимка это не только "догонка" транзакций "связанными" данными (ключами или справочниками) . Обычно это еще и пакетная обработка всех данных (за год, или день). Извините, но я не уловил связи... MapReduce - механизм генерализации параллельной обработки больших объемов данных на распределенном НРС кластере. VoltDB - OLTP СУБД. MapReduce разработан под аналитический бэтч-процесс, VoltDB - под большое количество коротких SQL запросов (транзакций) в реальном времени. MapReduce не предполагает логического партицирования данных (файловай система просто разбивает файл на чанки, при этом никакой логической связи между данными в индивидуальном чанке нет), а VoltDB группирует строки таблицы по значению в определенной колонке (т.о все данные в партиции имеют общий аттрибут). В MapReduce код исполняется параллельно на каждом ноде, в VoltDB - на ноде, на котором размещена соответствующая партиция данных (например, запрос SELECT Col1, Col2, Col3 FROM Invoices WHERE CustomerID = XYZ будет исполнен ядром которое обслуживает партицию содержащую инвойсы заказчика XYZ). ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 20:49 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
essbase.ruVoltDBпропущено... Если Вы имеете ввиду sqlcmd, то да Я имею ввиду , что бы в коде сделать опреацию "выполнить процедуру в три четыре потока , дождаться завершения всех потоков , получить консолидированный результат. Опять-таки, мне кажется это пример аналитического запроса. В контексте OLTP задача звучала бы так: Клиент: "СУБД, выполни сохраненную процедуру, которая называется МойКод, при этом передай в процедуру аргумент CustomerID=XYZ." СУБД: "Ага, процедура МойКод ищет иновойсы заказчика XYZ... Я знаю, что все инвойсы этого заказчика сгруппированы вместе и находятся в оперативной памяти, локально приписанной к ядру номер 2 на ноде номер 3. Поручаю дальнейшую работу именно этому ядру. Готова к следующему заданию..." ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 21:19 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
essbase.ruVoltDBЯ думаю, производительность Java приложений в большей степени зависит от индивидульного стиля разработки такого приложения, чем от GC. Получается что весь код хранимок выполняется в других процессах и службах ? Т.е. по сути нет совмещения данных и программного кода как это есть в других RDB ? (где можно написать бизнес слой на PL-SQL(TSQL) и получить дополнительный выйгрыш за счет того, что данные "далеко" не пробрасываются ? ) Я говорил о том, что главная причина плохой производительности кода, во многих случаях не GC, а как такой код написан. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 21:29 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
essbase.ruЧем мне может помочь в этом VoltDB ? Я не уверен я понимаю какую проблему Вы пытаетесь решить... Вы не могли бы описать задачу? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 21:44 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBessbase.ruпропущено... Я имею ввиду , что бы в коде сделать опреацию "выполнить процедуру в три четыре потока , дождаться завершения всех потоков , получить консолидированный результат. Опять-таки, мне кажется это пример аналитического запроса. В контексте OLTP задача звучала бы так: Клиент: "СУБД, выполни сохраненную процедуру, которая называется МойКод, при этом передай в процедуру аргумент CustomerID=XYZ." СУБД: "Ага, процедура МойКод ищет иновойсы заказчика XYZ... Я знаю, что все инвойсы этого заказчика сгруппированы вместе и находятся в оперативной памяти, локально приписанной к ядру номер 2 на ноде номер 3. Поручаю дальнейшую работу именно этому ядру. Готова к следующему заданию..."Щасс... готова она. Вы же строго последовательно прогоняете транзакции, так что к времени работы транзакции запросто прибавляются два времени IPC и связанные с ними противные мьютексы на читателях и писателях. Чем дольше я думаю над вашей моделью обработки данных, тем более узкоспециальной она мне кажется. чуть шаг в сторону от простейшего OLTP с "точечными" выборками и изменениями, тем менее корректна исходная "рекламная" картинка. Вспомним кадры с первых презентаций идеи: локи стоят X% времени, буферизация Y% времени, ... собственно транзакция 1%, а теперь мы жестом фокусника выкидываем лишние X,Y,Z... Слайд красивый, конечно. Но некорректность, IMHO, в мало обоснованном предположении, что выкидывание всех X,Y,Z со всеми их мьютексами не изменит статистики ожиданий на мьютексах в оставшемся коде. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 21:53 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ruVoltDBпропущено... Опять-таки, мне кажется это пример аналитического запроса. В контексте OLTP задача звучала бы так: Клиент: "СУБД, выполни сохраненную процедуру, которая называется МойКод, при этом передай в процедуру аргумент CustomerID=XYZ." СУБД: "Ага, процедура МойКод ищет иновойсы заказчика XYZ... Я знаю, что все инвойсы этого заказчика сгруппированы вместе и находятся в оперативной памяти, локально приписанной к ядру номер 2 на ноде номер 3. Поручаю дальнейшую работу именно этому ядру. Готова к следующему заданию..." Щасс... готова она. Вы же строго последовательно прогоняете транзакции, Ну да - именно готова к следующему заданию... Выполнение процедур сериализуется на уровне ядра, а не всей системы. То есть, если в кластере, например, 24 ядра, то это значит, что 24 процедуры могут выполняться одновременно, остальные ждут своей очереди. Система асинхронно "разбрасывает" запросы по очередям ядер - после того как запрос направлен определенному ядру для выполнения, система готова принимать следующее задание от клиента iv_an_ruтак что к времени работы транзакции запросто прибавляются два времени IPC и связанные с ними противные мьютексы на читателях и писателях. Я, честно говоря, не понимаю зачем коммуникация между процедурами вообще нужна. В общем случае, приходят одновременно два независимых запроса с двух независимых клиентов и конкурируют за доступ к данным - лок-менеджер умеет таким доступом управлять... Вы можете привести пример двух SQL запросов, потребовавшего от разработчика этих запросов кодирования мютекса? iv_an_ruЧем дольше я думаю над вашей моделью обработки данных, тем более узкоспециальной она мне кажется. У Вас есть конкретный пример OLTP задачи, с которой Вы считаете VoltDB не может справиться по причине своей "узкоспециализированности"? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 22:39 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBУ Вас есть конкретный пример OLTP задачи, с которой Вы считаете VoltDB не может справиться по причине своей "узкоспециализированности"?Я подозреваю, хотя ещё не было времени проверить, что если сделать шаг в сторону от "самой удобной" OLTP, то производительность окажется хорошей, но не выдающейся. Интересно было бы посмотреть, скажем, на SQL-версию BSBM Explore and Update ( http://wifo5-03.informatik.uni-mannheim.de/bizer/berlinsparqlbenchmark/spec/index.html#usecase_explore_and_update ) . Там запросы и довольно правдоподобные, и простые, и составляющие на удивление пакостную смесь --- кто слишком хорошо выигрывает на update части, тот норовит завалиться на explore, и наоборот. Хотя на первый взгляд проблемам взяться неоткуда. "Ничто не предвещало беды в то теплое летнее утро: ни огромная кружка парного молока, только что из под коровы, ни свежесобранные пупырчатые огурцы с грядки..." ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 23:04 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ru Но некорректность, IMHO, в мало обоснованном предположении, что выкидывание всех X,Y,Z со всеми их мьютексами не изменит статистики ожиданий на мьютексах в оставшемся коде. Давайте попробуем сначала... Представьте что у Вас есть ящик с 2 процами, каждый по 4 ядра. На этом ящике всего 128ГБ памяти. Давайте представим, что мы поделили всю эту память между всеми ядрами - каждое ядро имеет свой собственный регион в 16ГБ. Теперь давайте возьмем таблицу инвойсов и разделим ее на несколько частей по имени заказчиков. Предположим, у нас всего 85 заказчиков, т.е, соответственно, таблица инвойсов разделена на 85 частей и каждая часть приписана к какому нибудь ядру; 5 ядер имеют по 11 "кусков" данных, 3 ядра - по 10. На наш ящик начинают приходить запросы - каждый требует доступа к инвойсу определенного заказчика, т.е доступ к только к определенной части данных, которая, соответственно, приписана к определенному ядру. Так как у нас всего 8 ядер, только 8 запросов исполняются одновременно, причем каждое из них работает только со своими собственными данными. Остальные запросы сидят в очередях - каждый в очереди на том ядре, которое имеет часть данных, необходимую запросу. В этом случае, никакого конкурентного доступа просто не существует. В каких то случаях, запросу могут понадобиться данные для более чем одного заказчика, т.е существуют ситуации когда работу нескольких ядер нужно координировать. Если система OLTP, то большая часть запросов в такой системе являются "точечными", то есть, как правило, каждый запрос делает транзакцию с очень небольшим количеством записей (в нашем примере, ищет инвойс определенного заказчика, или, например, резервирует авиабилет, или вставляет запись с определенного датчика, или осуществляет покупку на вэб-сайте, или обрабатывает запись телефонный звонок итд). Если система по сути своей аналитическая (то есть, запросам нужны сравнительно большие регионы данных, например для нахождения инвойсов для многих заказчиков и суммирований квартальных продаж), то, соответственно, OLAP-оптимизированная систему более подходящий выбор. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2014, 23:59 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDB, Вероятно, нет необходимости начинать сначала, потому что чайников тут нет. Чего не хватает для предметного разговора, так это результатов общеупотребительных пузомерок индустриального качества. Когда в блоге voltdb-benchmarks обнаруживается пример "счётчик голосов зрителей на телеконкурсе каких-то там талантов", но не гуглится ни TPC-чего-нибудь, ни BSBM, ни ещё каких-то бенчмарок, по которым наработаны массивы данных для сравнения, восьмидесятое место voltDB в http://db-engines.com/en/ranking становится вполне объяснимым. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 00:32 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ruVoltDBУ Вас есть конкретный пример OLTP задачи, с которой Вы считаете VoltDB не может справиться по причине своей "узкоспециализированности"?Я подозреваю, хотя ещё не было времени проверить, что если сделать шаг в сторону от "самой удобной" OLTP, то производительность окажется хорошей, но не выдающейся. Интересно было бы посмотреть, скажем, на SQL-версию BSBM Explore and Update ( http://wifo5-03.informatik.uni-mannheim.de/bizer/berlinsparqlbenchmark/spec/index.html#usecase_explore_and_update ) . Там запросы и довольно правдоподобные, и простые, и составляющие на удивление пакостную смесь --- кто слишком хорошо выигрывает на update части, тот норовит завалиться на explore, и наоборот. Хотя на первый взгляд проблемам взяться неоткуда. "Ничто не предвещало беды в то теплое летнее утро: ни огромная кружка парного молока, только что из под коровы, ни свежесобранные пупырчатые огурцы с грядки..." VoltDB - СУБД реляционная, не граф-СУБД. Соответственно, наш интерес - не SPARQL, а SQL. Более традиционные тесты для SQL нагрузки основаны на спецификациях TPC (Transaction Processing Counsel), в частности, TPC-C. Вкратце, суть теста сводится к эмулированию широко-используемых бизнес-транзакций (введение заказа, проверки статуса заказа и доставки, проверка наличия в складе и.т.д) и замерению пропускгой способности СУБД для соответствующих запросов. Детальную ТРС-С спецификацию Вы можете найти здесь: http://www.tpc.org/tpcc/spec/tpcc_current.pdf Исходный код для одного из наших тестовых стендов можно найти здесь: https://github.com/apavlo/h-store/tree/master/src/benchmarks/org/voltdb/benchmark/tpcc/ ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 00:41 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBИсходный код для одного из наших тестовых стендов можно найти здесь: https://github.com/apavlo/h-store/tree/master/src/benchmarks/org/voltdb/benchmark/tpcc/ The TPC-C example runs a modified TPC-C benchmark.Я даже не буду разбираться после этого, что именно там "modified", потому что для сравнения с другими СУБД я должен сделать... что? Для каждой СУБД подкрутить бенчмарку в удобную для неё сторону? Или сделать что-то менее разрушительное? Я в растерянности. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 00:46 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBVoltDB - СУБД реляционная, не граф-СУБД. Соответственно, наш интерес - не SPARQL, а SQL.Кстати говоря, ни одна граф-СУБД ни одну серьёзную SPARQL-овую бенчмарку не выигрывала и в обозримом будущем не выиграет. Это просто потому, что создание движка соотвествующего качества требует таких инвестиций, которых не может обеспечить весь мировой рынок для всех граф-СУБД вместе взятых. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 00:50 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ruVoltDB, ...восьмидесятое место voltDB в http://db-engines.com/en/ranking становится вполне объяснимым. Это ж надо - рейтингов стало больше чем продуктов:) Даже не слышал о такой организации... Кстати, а какой рейтинг у их рейтинга? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 01:08 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ruVoltDBИсходный код для одного из наших тестовых стендов можно найти здесь: https://github.com/apavlo/h-store/tree/master/src/benchmarks/org/voltdb/benchmark/tpcc/ The TPC-C example runs a modified TPC-C benchmark.Я даже не буду разбираться после этого, что именно там "modified", потому что для сравнения с другими СУБД я должен сделать... что? Для каждой СУБД подкрутить бенчмарку в удобную для неё сторону? Или сделать что-то менее разрушительное? Я в растерянности. Там дальше в тексте есть детали... В официальном тесте есть бизнес-транзакции, которые представляют заказ посланный на один склад, а выполненный на другом. Мы посчитали, что в век интернета (оригинальная ТРС-С спецификация вышла в 1988 году), сразу посылать заказ на "правильный" склад особого труда не составит (например, в вэб-сервере) и модифицировали эту часть теста таким образом, что заказ выполняется на том складе, на который он поступил. Кстати, в соответствии со ТРС-С спецификацией, это 10% всех транзакций. Но так как тест модифицирован, официальным он быть не может (с чем мы полностью согласны) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 01:21 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBiv_an_ruпропущено... пропущено... Я даже не буду разбираться после этого, что именно там "modified", потому что для сравнения с другими СУБД я должен сделать... что? Для каждой СУБД подкрутить бенчмарку в удобную для неё сторону? Или сделать что-то менее разрушительное? Я в растерянности. Там дальше в тексте есть детали... В официальном тесте есть бизнес-транзакции, которые представляют заказ посланный на один склад, а выполненный на другом. Мы посчитали, что в век интернета (оригинальная ТРС-С спецификация вышла в 1988 году), сразу посылать заказ на "правильный" склад особого труда не составит (например, в вэб-сервере) и модифицировали эту часть теста таким образом, что заказ выполняется на том складе, на который он поступил. Кстати, в соответствии со ТРС-С спецификацией, это 10% всех транзакций. Но так как тест модифицирован, официальным он быть не может (с чем мы полностью согласны)Правильно ли я понимаю, что такая тривиальная вещь, как выполнение заказа, полученного на другом складе, продемонстрировала достаточно большую проблему, чтобы было решено пустить под нож репрезентативность результатов? Это не первый подобный случай, в той же BSBM полно отчётов, в которых даны отдельно цифры полного прогона и отдельно прогонов за вычетом такого-то запроса (и отчётов, в которых написано, что такие-то BI-запросы вообще отправили сервер в нирвану). Тем не менее, по каждому запросу каждого query mix-а доступны цифры, которые можно сравнивать для разных вендоров, для разных объёмов данных и т.п., и эти цифры были сняты либо с систем, доступных для аудита, либо вообще независимыми тестерами. Имееон эта верифицируемость воспроизводимых экспериментов и отличает индустриальные бенчмарки от поделок для внутреннего употребления. Кстати, у меня по этому продукту вопрос за вопросом так или иначе одним ребром упирается в IPC. Сходу вспоминаются распределённые транзакции, точная настройка партиционирования, тормоза на восстановлении после сбоя, поддержка нескольких маршрутов между двумя машинами кластера, латентности на IPC перед и после "неудобных" транзакций. И тут из стандартной бенчмарки вырезается как раз IPC-шный кусочек. Обидно, понимаешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 02:04 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ruVoltDBпропущено... Там дальше в тексте есть детали... В официальном тесте есть бизнес-транзакции, которые представляют заказ посланный на один склад, а выполненный на другом. Мы посчитали, что в век интернета (оригинальная ТРС-С спецификация вышла в 1988 году), сразу посылать заказ на "правильный" склад особого труда не составит (например, в вэб-сервере) и модифицировали эту часть теста таким образом, что заказ выполняется на том складе, на который он поступил. Кстати, в соответствии со ТРС-С спецификацией, это 10% всех транзакций. Но так как тест модифицирован, официальным он быть не может (с чем мы полностью согласны) Правильно ли я понимаю, что такая тривиальная вещь, как выполнение заказа, полученного на другом складе, продемонстрировала достаточно большую проблему, чтобы было решено пустить под нож репрезентативность результатов? Я точных деталей уж и не упомню - все-таки 5 лет прошло с того теста... Но могу сказать, что даже на тот момент мы чувствовали, что некоторые бизнес-транзакции, как их описывала спецификация 20-летней давности, устарели. Некоторые вещи из того, что включено в ТРС-С спецификацию, сегодня лучше делаются за пределами СУБД. В том, что внесение изменение в некоторые транзакции в тест сработало в пользу H-Store архитектуры - так это, по моему мнению, только подтверждает что такая архитектура лучше приспособлена к современным реалиям в бизнес-транзакциям. Да и, по-большому счету, какая разница кто быстрее на определенном "синтетическом" бэнчмарке? Ведь более важный вопрос - может ли система обеспечить требуемую пропускную способность и надежность нагрузки, вызванной конкретными запросами продиктованными конкретным бизнес-процесом и сколько такое решение стоит . Для каких-то задач VoltDB - решение, а для каких-то - нет. Как говорится, на вкус и цвет - карандаши разные... :) iv_an_ruКстати, у меня по этому продукту вопрос за вопросом так или иначе одним ребром упирается в IPC. Сходу вспоминаются распределённые транзакции, точная настройка партиционирования, тормоза на восстановлении после сбоя, поддержка нескольких маршрутов между двумя машинами кластера, латентности на IPC перед и после "неудобных" транзакций. И тут из стандартной бенчмарки вырезается как раз IPC-шный кусочек. Обидно, понимаешь. Мне кажется, мы с Вами продолжаем теоретизировать и обсуждать какие-то абсолютно гипотетические проблемы... Разрешите мне повториться и задать Вам тот же самый практический вопрос, который я уже задавал: у Вас есть пример какой-нибудь конкретной OLTP задачи, которая, по Вашему мнению, не вписывается в архитектуру VoltDB? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 03:01 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBМне кажется, мы с Вами продолжаем теоретизировать и обсуждать какие-то абсолютно гипотетические проблемы... Разрешите мне повториться и задать Вам тот же самый практический вопрос, который я уже задавал: у Вас есть пример какой-нибудь конкретной 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? Как-то сумбурно получилось, но тут уж извиняйте. Это жизнь такая сумбурная, а я как акын, что вижу --- то пою. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 10:14 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ruа вот найти потом узкоспециального покупателя --- тяжело. VoltDB - возможно есть стнадартное решение , которое позволяет вытаскивать оперативно из VoltDB данные для real-Time DWH (как компенсирующее решение ? ) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 10:45 |
|
|
start [/forum/topic.php?fid=56&msg=38531431&tid=2015180]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
316ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 434ms |
0 / 0 |