|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ru...подсчёт голосов за участников телепередачи "алло мы ищем таланты" --- очень тяжёлая, ответственная и критичная к честной ACID-ности задача. Счётчик лейкоцитов с реактивным двигателем. Да нет, ничего тяжелого в такой задаче нет - это ведь приложение-пример для демонстрации базовых концепций... Своего рода "Hello, world!", только для OLTP СУБД. Согласен, это, конечно, не Virtuoso-вские примеры про Принца Гарри из Уэльса, а скучный подсчёт голосования участников телепередачи, но для целей демонстрации OLTP - задачка вполне подходящая... PS. Я, кстати, против примеров про принца и его семейство - в хорошом смысле... Понимаю, что онтологию юзеру на пальцах объяснить тяжело - тоже своего рода "Hello, world!" пример нужен. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 22:39 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
WarstoneVoltDBОдин нод - в общем, не проблема... Но так как VoltDB полностью в памяти, а у Вас 1.5ТБ данных, нод может понадобиться очень уж большой :)А... То есть для больших задач ее использовать нельзя так как мы ограничены оперативкой. Ясно, спасибо. То есть переход с MyISAM на VoltDB для меня стоит поставить 10-15 серверов... Не, спасибо. Я как-нибудь так. Ну основную мысль я услышал. Все в памяти. Дальше не интересно. Для меня VoltDB - мертвая технология, так как она требует ОЧЕНЬ больших затрат на железо. В Вашем случае, задача - не высоко-производительная OLTP, а бэтчевая загрузка и аналитика. Бэтчи по 300-400к записей каждые 15-минут - не должно быть проблемой ни в MyISAM, ни в Virtuoso. VoltDB Вашему приложению не нужен. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 23:07 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
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, с увеличением уровня защиты, общая производительность системы уменьшается. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2014, 23:42 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBМаксимально теоретически возможное К - это количество нодов в кластере, т.е если все ноды кроме одного одновременно упали, база выживет.Тут есть ньюанс. Предположим, что у нас есть 4 машины и k=2. Представим себе аварию сети, при которой одна пара машин (A и B) оказывается оторвана от другой (C и D). При отсутствии независимых дополнительных средств диагностики каждая пара решает, что две другие ноды умерли, и спокойно продолжает работать. Но если внешние подключения продолжаются ко всем четырём машинам, то состояние базы на A и B начинает расходиться с состоянием базы на C и D, и восстановление сети станет удивительным и незабываемым событием для админа --- стандартная процедура "взять бэкап и накатить логи" не поможет ничем, потому что два разных комплетка логов --- это так же плохо, как и ноль. Решений проблемы много, самое дешёвое я назвал "закон о ТСЖ": мастер объявляет кластер недееспособным, если в нём осталась ровно половина или меньше половины от общего числа машин. В этом состоянии кластер остаётся до тех пор, пока "половина плюс один" узел кластера не соединятся и не выберут себе нового мастера. Если вам кажется, что таких аварий не бывает, то учтите, что большинство свитчей на 16 или 24 портов состоят из 8+1-портовых матриц, соединённых эдаким "внутренним свитчем". И если использование 4xGigE на раздельных свитчах такую угрозу снимает, то инфинибанд представлен как правило только одним портом на ящик. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2014, 01:22 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ruVoltDBМаксимально теоретически возможное К - это количество нодов в кластере, т.е если все ноды кроме одного одновременно упали, база выживет.Тут есть ньюанс. Предположим, что у нас есть 4 машины и k=2. Представим себе аварию сети, при которой одна пара машин (A и B) оказывается оторвана от другой (C и D). При отсутствии независимых дополнительных средств диагностики каждая пара решает, что две другие ноды умерли, и спокойно продолжает работать. Но если внешние подключения продолжаются ко всем четырём машинам, то состояние базы на A и B начинает расходиться с состоянием базы на C и D, и восстановление сети станет удивительным и незабываемым событием для админа --- стандартная процедура "взять бэкап и накатить логи" не поможет ничем, потому что два разных комплетка логов --- это так же плохо, как и ноль. Решений проблемы много, самое дешёвое я назвал "закон о ТСЖ": мастер объявляет кластер недееспособным, если в нём осталась ровно половина или меньше половины от общего числа машин. В этом состоянии кластер остаётся до тех пор, пока "половина плюс один" узел кластера не соединятся и не выберут себе нового мастера. Если вам кажется, что таких аварий не бывает, то учтите, что большинство свитчей на 16 или 24 портов состоят из 8+1-портовых матриц, соединённых эдаким "внутренним свитчем". И если использование 4xGigE на раздельных свитчах такую угрозу снимает, то инфинибанд представлен как правило только одним портом на ящик. К-кластера имеют нечетное количество нодов. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2014, 02:04 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBiv_an_ruпропущено... Тут есть ньюанс. Предположим, что у нас есть 4 машины и k=2. Представим себе аварию сети, при которой одна пара машин (A и B) оказывается оторвана от другой (C и D). При отсутствии независимых дополнительных средств диагностики каждая пара решает, что две другие ноды умерли, и спокойно продолжает работать. Но если внешние подключения продолжаются ко всем четырём машинам, то состояние базы на A и B начинает расходиться с состоянием базы на C и D, и восстановление сети станет удивительным и незабываемым событием для админа --- стандартная процедура "взять бэкап и накатить логи" не поможет ничем, потому что два разных комплетка логов --- это так же плохо, как и ноль. Решений проблемы много, самое дешёвое я назвал "закон о ТСЖ": мастер объявляет кластер недееспособным, если в нём осталась ровно половина или меньше половины от общего числа машин. В этом состоянии кластер остаётся до тех пор, пока "половина плюс один" узел кластера не соединятся и не выберут себе нового мастера. Если вам кажется, что таких аварий не бывает, то учтите, что большинство свитчей на 16 или 24 портов состоят из 8+1-портовых матриц, соединённых эдаким "внутренним свитчем". И если использование 4xGigE на раздельных свитчах такую угрозу снимает, то инфинибанд представлен как правило только одним портом на ящик. К-кластера имеют нечетное количество нодов.Душевненько. Я вот сейчас пытаюсь вспомнить хоть одного нашего клиента, у которого в кластере было бы нечетное число нод больше единицы --- и не могу. На что только не посмотри --- оптовые скидки на оборудование идут по чётным числам; чётные ёмкости свичей, чётные вместимости корзин под вертикальные и тем более под горизонтальные блейды и т.п. И тут нате вам. Хотя, в чём-то идея здравая: хоть таким издевательским методом, а появляется шанс заначить ящик в холодный резерв. Купили 20 --- подняли 19 :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2014, 02:12 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ruVoltDBпропущено... К-кластера имеют нечетное количество нодов.Душевненько. Я вот сейчас пытаюсь вспомнить хоть одного нашего клиента, у которого в кластере было бы нечетное число нод больше единицы --- и не могу. На что только не посмотри --- оптовые скидки на оборудование идут по чётным числам; чётные ёмкости свичей, чётные вместимости корзин под вертикальные и тем более под горизонтальные блейды и т.п. И тут нате вам. Хотя, в чём-то идея здравая: хоть таким издевательским методом, а появляется шанс заначить ящик в холодный резерв. Купили 20 --- подняли 19 :) Я не зная насчет скидок итд но могу Вам точно сказать, что К-кластера не мы придумали ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2014, 02:25 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
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 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2014, 02:50 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
iv_an_ruВот вам k=2 на вполне себе чётном N=8. Или k=3 N=8: Вообще-то, Вы правы - четное количество нодов в К-кластере возможно. Например, Вертика их поддерживает. Но у нас - нечетное количество нодов. Теоретически, любая конфигурация кластера уязвима и всегда можно придумать сценарий аварии, при котором есть вероятность остановки кластера - например, единственный свич на кластере упал, или дата центр потерял электропитание, а тех нескольких минут, которые система работает на аварийном питании не хватило, что бы дизельный генератор запустить, или вообще весь ДЦ затопило вместе с дизелями итд. Причем, это относится к любому кластеру, даже к дуплицированному. Если предохранять систему от таких сценариев важно, то нужен запасной ДЦ, и не только для СУБД, а для всего приложения. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2014, 03:58 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDB О тенденции разделения универсальных СУБД на специализированные Таким образом, возникает противоречие: если система должна быть гибридной OLTP/OLAP, оптимизировать ее нужно было бы методами хранения данных, противоречащими друг другу. Но если разделить OLTP и OLAP, тогда каждая из-задач может быть оптимизирована отдельно и без последствий для другой задачи: OLTP с построчным хранилищем и OLAP с колоночным. Своего рода, случай когда 1+1>2 ну да. А в субд Greenplum тупо можно одни таблицы делать с поколоночным хранением, другие с построчным. Мало того, партиции внутри одной таблицы можно делать разными. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2014, 16:04 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
Ivan DurakVoltDB О тенденции разделения универсальных СУБД на специализированные Таким образом, возникает противоречие: если система должна быть гибридной OLTP/OLAP, оптимизировать ее нужно было бы методами хранения данных, противоречащими друг другу. Но если разделить OLTP и OLAP, тогда каждая из-задач может быть оптимизирована отдельно и без последствий для другой задачи: OLTP с построчным хранилищем и OLAP с колоночным. Своего рода, случай когда 1+1>2 ну да. А в субд Greenplum тупо можно одни таблицы делать с поколоночным хранением, другие с построчным. Мало того, партиции внутри одной таблицы можно делать разными. Может быть - я Greenplum сам не гонял, хотя и слышал хорошие отзывы. Если я не ошибаюсь, они все-таки разработаны как аналитическая система, а не гибрид. Если у Вас есть опыт OLTP приложения на Greenplum, поделитесь - было бы очень интересно узнать по-подробнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2014, 19:37 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBIvan Durakпропущено... ну да. А в субд Greenplum тупо можно одни таблицы делать с поколоночным хранением, другие с построчным. Мало того, партиции внутри одной таблицы можно делать разными. Может быть - я Greenplum сам не гонял, хотя и слышал хорошие отзывы. Если я не ошибаюсь, они все-таки разработаны как аналитическая система, а не гибрид. Если у Вас есть опыт OLTP приложения на Greenplum, поделитесь - было бы очень интересно узнать по-подробнее. Там все тривиально, классическое POSTGRE строчное хранилище + append only колоночное, из названия понятно все уже... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2014, 22:36 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VoltDBiv_an_ruВот вам k=2 на вполне себе чётном N=8. Или k=3 N=8: Вообще-то, Вы правы - четное количество нодов в К-кластере возможно. Например, Вертика их поддерживает. У Вертики или 1 или 2, больше вариантов нет, насколько мне известно ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2014, 22:37 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
VovakaVoltDBпропущено... Вообще-то, Вы правы - четное количество нодов в К-кластере возможно. Например, Вертика их поддерживает. У Вертики или 1 или 2, больше вариантов нет, насколько мне известноТам нет других вариантов для k, а N может быть любым бОольшим, чем 2k. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2014, 23:22 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
Отличная, на мой взгляд, статья в "Открытые Системы" Будущее транзакционных систем Простота и дешевизна построения неограниченно горизонтально масштабируемых кластеров систем вызвали резкую активизацию исследований и разработок соответствующих архитектур СУБД. http://www.osp.ru/os/2011/04/13008790/ ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2014, 22:37 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
Новая версия 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 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2014, 22:56 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
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 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2014, 00:01 |
|
Open Source OLTP СУБД VoltDB - Вопросы архитектуры, разработки, внедрения и эксплуатации
|
|||
---|---|---|---|
#18+
Есть вопрос касающийся выполнения 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? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2014, 13:12 |
|
|
start [/forum/topic.php?fid=56&msg=38537482&tid=2015180]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
128ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 241ms |
0 / 0 |