powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Другие СУБД [игнор отключен] [закрыт для гостей] / Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
18 сообщений из 118, страница 5 из 5
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38534977
Фотография VoltDB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_an_ru...подсчёт голосов за участников телепередачи "алло мы ищем таланты" --- очень тяжёлая, ответственная и критичная к честной ACID-ности задача. Счётчик лейкоцитов с реактивным двигателем.

Да нет, ничего тяжелого в такой задаче нет - это ведь приложение-пример для демонстрации базовых концепций... Своего рода "Hello, world!", только для OLTP СУБД. Согласен, это, конечно, не Virtuoso-вские примеры про Принца Гарри из Уэльса, а скучный подсчёт голосования участников телепередачи, но для целей демонстрации OLTP - задачка вполне подходящая...

PS. Я, кстати, против примеров про принца и его семейство - в хорошом смысле... Понимаю, что онтологию юзеру на пальцах объяснить тяжело - тоже своего рода "Hello, world!" пример нужен.
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38534997
Фотография VoltDB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WarstoneVoltDBОдин нод - в общем, не проблема... Но так как VoltDB полностью в памяти, а у Вас 1.5ТБ данных, нод может понадобиться очень уж большой :)А... То есть для больших задач ее использовать нельзя так как мы ограничены оперативкой. Ясно, спасибо. То есть переход с MyISAM на VoltDB для меня стоит поставить 10-15 серверов... Не, спасибо. Я как-нибудь так.

Ну основную мысль я услышал. Все в памяти. Дальше не интересно. Для меня VoltDB - мертвая технология, так как она требует ОЧЕНЬ больших затрат на железо.

В Вашем случае, задача - не высоко-производительная OLTP, а бэтчевая загрузка и аналитика. Бэтчи по 300-400к записей каждые 15-минут - не должно быть проблемой ни в MyISAM, ни в Virtuoso. VoltDB Вашему приложению не нужен.
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38536176
Фотография VoltDB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VoltDBВопросы который был недавно был получен в одной из предыдущих групп ( http://www.sql.ru/forum/762473-8/voltdb-neskolko-millionov-tranzakciy-v-sekundu)

Как происходит увеличение размера кластера в 2 раза? Если это возможно вообще.

Абсолютно возможно. Так как архитектура кластера shared-nothing, масштабируемость СУБД практически линейна. То есть, при увеличении кластера в 2 раза, общая пропускная способность системы должна увеличиться соответственно.

VoltDBВозможна ли репликация средствами БД в пределах нескольких ДЦ по WAN?

Да, такая функциональность реализована. Хотя из моего личного опыты с большими системами (не VoltDB), в некоторых случаях более эффективно дублировать нагрузку в нескольких ДЦ, чем реплицировать, (т.е приложение пишет в несколько ДЦ в параллели, если позволяет топология). Но это дело вкуса...

VoltDBВ k-safety какое максимально возможное k и какова политика размещения копий?

Максимально теоретически возможное К - это количество нодов в кластере, т.е если все ноды кроме одного одновременно упали, база выживет. Но я про такую конфигурацию в реальных приложениях никогда не слышал :) Обычно, приложения требуют или К+1 (т.е если один нод упал, то база жива и продолжает нормально функционировать на оставшихся нодах), или К+2 (т.е защита на случай, если пока первый упавший нод чинится, второй, не дай бог, падает)

В общем, идея К-защиты в чем-то, в принципе, близка к Reundant Array of Inexpensive Drives (RAID) с той разницей, что вместо дисков в массиве используются ноды в кластере. Как и в RAID, с увеличением уровня защиты, общая производительность системы уменьшается.
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38536217
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VoltDBМаксимально теоретически возможное К - это количество нодов в кластере, т.е если все ноды кроме одного одновременно упали, база выживет.Тут есть ньюанс. Предположим, что у нас есть 4 машины и k=2. Представим себе аварию сети, при которой одна пара машин (A и B) оказывается оторвана от другой (C и D). При отсутствии независимых дополнительных средств диагностики каждая пара решает, что две другие ноды умерли, и спокойно продолжает работать. Но если внешние подключения продолжаются ко всем четырём машинам, то состояние базы на A и B начинает расходиться с состоянием базы на C и D, и восстановление сети станет удивительным и незабываемым событием для админа --- стандартная процедура "взять бэкап и накатить логи" не поможет ничем, потому что два разных комплетка логов --- это так же плохо, как и ноль. Решений проблемы много, самое дешёвое я назвал "закон о ТСЖ": мастер объявляет кластер недееспособным, если в нём осталась ровно половина или меньше половины от общего числа машин. В этом состоянии кластер остаётся до тех пор, пока "половина плюс один" узел кластера не соединятся и не выберут себе нового мастера.

Если вам кажется, что таких аварий не бывает, то учтите, что большинство свитчей на 16 или 24 портов состоят из 8+1-портовых матриц, соединённых эдаким "внутренним свитчем". И если использование 4xGigE на раздельных свитчах такую угрозу снимает, то инфинибанд представлен как правило только одним портом на ящик.
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38536223
Фотография VoltDB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_an_ruVoltDBМаксимально теоретически возможное К - это количество нодов в кластере, т.е если все ноды кроме одного одновременно упали, база выживет.Тут есть ньюанс. Предположим, что у нас есть 4 машины и k=2. Представим себе аварию сети, при которой одна пара машин (A и B) оказывается оторвана от другой (C и D). При отсутствии независимых дополнительных средств диагностики каждая пара решает, что две другие ноды умерли, и спокойно продолжает работать. Но если внешние подключения продолжаются ко всем четырём машинам, то состояние базы на A и B начинает расходиться с состоянием базы на C и D, и восстановление сети станет удивительным и незабываемым событием для админа --- стандартная процедура "взять бэкап и накатить логи" не поможет ничем, потому что два разных комплетка логов --- это так же плохо, как и ноль. Решений проблемы много, самое дешёвое я назвал "закон о ТСЖ": мастер объявляет кластер недееспособным, если в нём осталась ровно половина или меньше половины от общего числа машин. В этом состоянии кластер остаётся до тех пор, пока "половина плюс один" узел кластера не соединятся и не выберут себе нового мастера.

Если вам кажется, что таких аварий не бывает, то учтите, что большинство свитчей на 16 или 24 портов состоят из 8+1-портовых матриц, соединённых эдаким "внутренним свитчем". И если использование 4xGigE на раздельных свитчах такую угрозу снимает, то инфинибанд представлен как правило только одним портом на ящик.

К-кластера имеют нечетное количество нодов.
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38536226
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VoltDBiv_an_ruпропущено...
Тут есть ньюанс. Предположим, что у нас есть 4 машины и k=2. Представим себе аварию сети, при которой одна пара машин (A и B) оказывается оторвана от другой (C и D). При отсутствии независимых дополнительных средств диагностики каждая пара решает, что две другие ноды умерли, и спокойно продолжает работать. Но если внешние подключения продолжаются ко всем четырём машинам, то состояние базы на A и B начинает расходиться с состоянием базы на C и D, и восстановление сети станет удивительным и незабываемым событием для админа --- стандартная процедура "взять бэкап и накатить логи" не поможет ничем, потому что два разных комплетка логов --- это так же плохо, как и ноль. Решений проблемы много, самое дешёвое я назвал "закон о ТСЖ": мастер объявляет кластер недееспособным, если в нём осталась ровно половина или меньше половины от общего числа машин. В этом состоянии кластер остаётся до тех пор, пока "половина плюс один" узел кластера не соединятся и не выберут себе нового мастера.

Если вам кажется, что таких аварий не бывает, то учтите, что большинство свитчей на 16 или 24 портов состоят из 8+1-портовых матриц, соединённых эдаким "внутренним свитчем". И если использование 4xGigE на раздельных свитчах такую угрозу снимает, то инфинибанд представлен как правило только одним портом на ящик.

К-кластера имеют нечетное количество нодов.Душевненько. Я вот сейчас пытаюсь вспомнить хоть одного нашего клиента, у которого в кластере было бы нечетное число нод больше единицы --- и не могу. На что только не посмотри --- оптовые скидки на оборудование идут по чётным числам; чётные ёмкости свичей, чётные вместимости корзин под вертикальные и тем более под горизонтальные блейды и т.п. И тут нате вам.

Хотя, в чём-то идея здравая: хоть таким издевательским методом, а появляется шанс заначить ящик в холодный резерв. Купили 20 --- подняли 19 :)
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38536231
Фотография VoltDB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_an_ruVoltDBпропущено...


К-кластера имеют нечетное количество нодов.Душевненько. Я вот сейчас пытаюсь вспомнить хоть одного нашего клиента, у которого в кластере было бы нечетное число нод больше единицы --- и не могу. На что только не посмотри --- оптовые скидки на оборудование идут по чётным числам; чётные ёмкости свичей, чётные вместимости корзин под вертикальные и тем более под горизонтальные блейды и т.п. И тут нате вам.

Хотя, в чём-то идея здравая: хоть таким издевательским методом, а появляется шанс заначить ящик в холодный резерв. Купили 20 --- подняли 19 :)

Я не зная насчет скидок итд но могу Вам точно сказать, что К-кластера не мы придумали
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38536232
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VoltDBiv_an_ruпропущено...
Душевненько. Я вот сейчас пытаюсь вспомнить хоть одного нашего клиента, у которого в кластере было бы нечетное число нод больше единицы --- и не могу. На что только не посмотри --- оптовые скидки на оборудование идут по чётным числам; чётные ёмкости свичей, чётные вместимости корзин под вертикальные и тем более под горизонтальные блейды и т.п. И тут нате вам.

Хотя, в чём-то идея здравая: хоть таким издевательским методом, а появляется шанс заначить ящик в холодный резерв. Купили 20 --- подняли 19 :)

Я не зная насчет скидок итд но могу Вам точно сказать, что К-кластера не мы придумалиПусть
нода 1 является бадди для 5 и 3
нода 2 является бадди для 6 и 4
нода 3 является бадди для 7 и 1
нода 4 является бадди для 8 и 2
нода 5 является бадди для 1 и 7
нода 6 является бадди для 2 и 8
нода 7 является бадди для 3 и 5
нода 8 является бадди для 4 и 6

Вот вам k=2 на вполне себе чётном N=8. Или k=3 N=8:

нода 1 является бадди для 5 и 3 и 2
нода 2 является бадди для 6 и 4 и 1
нода 3 является бадди для 7 и 1 и 4
нода 4 является бадди для 8 и 2 и 3
нода 5 является бадди для 1 и 7 и 6
нода 6 является бадди для 2 и 8 и 5
нода 7 является бадди для 3 и 5 и 8
нода 8 является бадди для 4 и 6 и 7
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38536238
Фотография VoltDB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_an_ruВот вам k=2 на вполне себе чётном N=8. Или k=3 N=8:

Вообще-то, Вы правы - четное количество нодов в К-кластере возможно. Например, Вертика их поддерживает. Но у нас - нечетное количество нодов. Теоретически, любая конфигурация кластера уязвима и всегда можно придумать сценарий аварии, при котором есть вероятность остановки кластера - например, единственный свич на кластере упал, или дата центр потерял электропитание, а тех нескольких минут, которые система работает на аварийном питании не хватило, что бы дизельный генератор запустить, или вообще весь ДЦ затопило вместе с дизелями итд. Причем, это относится к любому кластеру, даже к дуплицированному. Если предохранять систему от таких сценариев важно, то нужен запасной ДЦ, и не только для СУБД, а для всего приложения.
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38537087
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VoltDB О тенденции разделения универсальных СУБД на специализированные


Таким образом, возникает противоречие: если система должна быть гибридной OLTP/OLAP, оптимизировать ее нужно было бы методами хранения данных, противоречащими друг другу. Но если разделить OLTP и OLAP, тогда каждая из-задач может быть оптимизирована отдельно и без последствий для другой задачи: OLTP с построчным хранилищем и OLAP с колоночным. Своего рода, случай когда 1+1>2
ну да. А в субд Greenplum тупо можно одни таблицы делать с поколоночным хранением, другие с построчным. Мало того, партиции внутри одной таблицы можно делать разными.
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38537376
Фотография VoltDB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan DurakVoltDB О тенденции разделения универсальных СУБД на специализированные


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

Может быть - я Greenplum сам не гонял, хотя и слышал хорошие отзывы. Если я не ошибаюсь, они все-таки разработаны как аналитическая система, а не гибрид. Если у Вас есть опыт OLTP приложения на Greenplum, поделитесь - было бы очень интересно узнать по-подробнее.
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38537469
Фотография Vovaka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VoltDBIvan Durakпропущено...

ну да. А в субд Greenplum тупо можно одни таблицы делать с поколоночным хранением, другие с построчным. Мало того, партиции внутри одной таблицы можно делать разными.

Может быть - я Greenplum сам не гонял, хотя и слышал хорошие отзывы. Если я не ошибаюсь, они все-таки разработаны как аналитическая система, а не гибрид. Если у Вас есть опыт OLTP приложения на Greenplum, поделитесь - было бы очень интересно узнать по-подробнее.


Там все тривиально, классическое POSTGRE строчное хранилище + append only колоночное, из названия понятно все уже...
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38537470
Фотография Vovaka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VoltDBiv_an_ruВот вам k=2 на вполне себе чётном N=8. Или k=3 N=8:

Вообще-то, Вы правы - четное количество нодов в К-кластере возможно. Например, Вертика их поддерживает.

У Вертики или 1 или 2, больше вариантов нет, насколько мне известно
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38537482
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VovakaVoltDBпропущено...


Вообще-то, Вы правы - четное количество нодов в К-кластере возможно. Например, Вертика их поддерживает.

У Вертики или 1 или 2, больше вариантов нет, насколько мне известноТам нет других вариантов для k, а N может быть любым бОольшим, чем 2k.
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38539745
Фотография VoltDB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Отличная, на мой взгляд, статья в "Открытые Системы"


Будущее транзакционных систем
Простота и дешевизна построения неограниченно горизонтально масштабируемых кластеров систем вызвали резкую активизацию исследований и разработок соответствующих архитектур СУБД.


http://www.osp.ru/os/2011/04/13008790/
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38539753
Фотография VoltDB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Новая версия VoltDB 4.0

Хотел бы еще раз напомнить, что интерактивный вэбкаст с демонстрацией новой функциональности и Q&A сессией состоится в среду 29-го января, 2014 в 23:00 МСК.

Зарегистрироваться можно здесь: https://voltdb.webex.com/mw0401l/mywebex/default.do?nomenu=true&siteurl=voltdb&service=6&rnd=0.699249563374278&main_url=https://voltdb.webex.com/ec0701l/eventcenter/event/eventAction.do?theAction=detail&confViewID=1004752450&&&&siteurl=voltdb&utm_source=hs_email&utm_medium=email&utm_content=11602540&_hsenc=p2ANqtz-_BBBU6bkwv5zrx3pyQac0xUVHSsDS57ypeaNTqOPKj2jTt3wq-i905po16L1UN3p9arR-3akTqffRoQtJtsWH60BWSXw&_hsmi=11602540
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38539798
Фотография VoltDB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VoltDB Новая версия VoltDB 4.0

Хотел бы еще раз напомнить, что интерактивный вэбкаст с демонстрацией новой функциональности и Q&A сессией состоится в среду 29-го января, 2014 в 23:00 МСК.

Зарегистрироваться можно здесь: https://voltdb.webex.com/mw0401l/mywebex/default.do?nomenu=true&siteurl=voltdb&service=6&rnd=0.699249563374278&main_url=https://voltdb.webex.com/ec0701l/eventcenter/event/eventAction.do?theAction=detail&confViewID=1004752450&&&&siteurl=voltdb&utm_source=hs_email&utm_medium=email&utm_content=11602540&_hsenc=p2ANqtz-_BBBU6bkwv5zrx3pyQac0xUVHSsDS57ypeaNTqOPKj2jTt3wq-i905po16L1UN3p9arR-3akTqffRoQtJtsWH60BWSXw&_hsmi=11602540

Если указанный линк не работает, то можно воспользоваться регистрацией здесь: https://voltdb.webex.com/mw0401l/mywebex/default.do?siteurl=voltdb
...
Рейтинг: 0 / 0
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
    #38719272
fathersson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть вопрос касающийся выполнения MP транзакций в кластере. В блоге Run Everywhere есть следующий текст.
авторVoltDB supports single-partition transactions, which as the name implies, run on only
one partition. VoltDB can run as many single partition transactions in parallel as
there are unique partitions. This enables high transaction throughput as well as
high transaction concurrency execution.

VoltDB also supports multi-partition transactions, which are transactions that involve
all unique partitions within the database. When a multi-partition transaction is
executing, it is the only transaction running in the database at that point in time.
Thus, you can run fewer multi-part transactions as compared to single-part transactions

Я знаю, что у каждой партиции есть свой Процессор, который обрабатывает запросы, касающиеся этой партиции. И есть всего один Процессор на весь кластер для MP транзакций (его работа сводиться к тому, чтобы распределить запрос по SP процессорам и затем агрегировать результат). И здесь возникает двоякое толкование.
С одной стороны я читаю текст так, что есть независимая обработка SP и MP транзакций: когда SP транзакций может быть много, MP транзакция может быть всего одна (в конце концов они стоят в очереди и есть всего один MP процессор).
С другой стороны можно понимать эти два абзаца, что когда работает MP процессор все SP транзакции приостанавливаются до тех пор, пока одна MP транзакция не будет выполнена.

Объясните, пожалуйста, как это работает в VoltDB?
...
Рейтинг: 0 / 0
18 сообщений из 118, страница 5 из 5
Форумы / Другие СУБД [игнор отключен] [закрыт для гостей] / Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]