чем фреймворк, реализующий распределенные транзакции, лучше распределенной СУБД
Тем, что выход из строя какого-то одного компонента с состоянием (БД одного из шардов или экземпляра оркестратора) никак не влияет на другие компоненты с состоянием. Сбой всегда локализован.
как наши администраторы знают только монолитные базы X и Z
Примерно так и есть, да. И два десятка администраторов сопровождают несколько десятков тысяч экземпляров этих монолитных баз. С распределёнными базами не удаётся достичь такой эффективности работы администратора. Во многом, конечно, это заслуга эксплуатационной зрелости конкретных продуктов, а не распределённости как таковой, но тем не менее.
преждевременная оптимизация
Не преждевременная. Изначально большинство приложений пишется в расчёте на монолитную БД, и 95% за её пределы никогда и не вылезают. Работа с шардами начинается не раньше, чем будет очевидно, что в одну базу вся нагрузка не помещается.
не надо разработчиков бизнес-логики заставлять писать части СУБД
Не надо. Но всю распределённую логику можно оформить в виде фреймворка. Тут же дело в том, что это всё потом сопровождать, и когда падает монолитная база, понятно, что делать. А с распределённой базой возможны варианты.
по моим ощущениям у нас очень много тех, кто использует YDB, как монолитную базу, и у них все хорошо.
Наши администраторы наотрез отказываются брать на сопровождение распределённую БД как единое целое. Где-то есть MongoDB, Cassandra и Hadoop, но всё это не поднимается выше класса вспомогательного программного обеспечения, данные которого можно и потерять, если рагнарёк.
пользователь ничего не знает о шардировании
Вот как раз когда пользователь знает, получается более эффективные приложения. Естественно, всё распределение автоматизировано. Но пишет, например, программист погашение долга по кредитке — это гарантированно локальная транзакция, и можно полагаться на гарантии СУБД. А вот пишет он p2p перевод — тут уже должна быть сага, потому что клиенты могут быть в разных шардах. И программист неизбежно задумается — а как бы сделать поменьше шагов?
Учебник выглядит интересно. С удовольствием посмотрю :)
Идеально за пивом/кофе/чаем на закрытии конференции
Ну приходите на PGConf через пару недель, например :)
На мой взгляд, разработчики приложений должны писать приложения
Видите ли, практика показывает, что если прикладной программист начинает использовать распределённую БД как «монолитную, только большую», это приводит к разного рода проблемам. Код операций, затрагивающих несколько узлов, должен принципиально отличаться от кода операций, выполняемых на одном узле — это залог успеха. Говорят, в Яндексе очень строгий отбор программистов, и те, кто прошёл этот отбор, такие вещи понимают. Но большинство программистов, особенно тех, которые автоматизируют бизнес, а не занимаются инфраструктурными проектами, — нет.
Является ли наш бекап консистентным
А тут философский вопрос — а что такое вообще «точка во времени» в распределённой системе? Если ответ на этот вопрос есть (как, например, в Foundation DB или в классическом Calvin), то сделать согласованную резервную копию — чисто техническая задача. А вот если нет...
А что если между списанием и зачислением сущность, выполняющая операцию, упадет?
Ну саги ведь тоже не вчера появились, они гораздо старше, чем Calvin. И бороться с такими инцидентами давно научились. Полагаю, вы тему знаете не хуже меня, а если чего-то не знаете, легко нагуглите :)
Я тоже за KISS, просто понятия о простоте у нас с вами разные. Как-то я столкнулся с неожиданным поведением распределённых систем, стал разбираться, почему они ведут себя так, и в итоге написал вузовский учебник по базам данных. А заодно стал идейным противником распределённых СУБД, если только это не аналитическая платформа типа Greenplum, Presto, Vertica и т. п. :))
Если требуются распределенные транзакции (и распределенный/глобальный снепшот), то особых альтернатив распределенным СУБД нет.
А много ли в жизни таких задач? Большинство реальных задач эффективно решаются сагами. Если какое-то непродолжительное время суммарный остаток на счетах будет меньше нужного (у дающего уже списали, а берущему ещё не зачислили), ничего страшного не случится. Возможно, при моделировании каких-то сложных систем в научных экспериментах этот самый «глобальный снапшот» и нужен, но для автоматизации бизнеса — в 99.99% случаев нет.
Спорное утверждение, если посмотреть на цитаты, которые я специально привел в посте.
Я не увидел ни одной цитаты типа «мы ориентируемся на результаты теста XXX при выборе YYY». А разработчики СУБД, конечно, любят щеголять высокими результатами в подобных тестах. Чем иногда создают серьёзные проблемы клиенту.
наконец рассказать, почему YDB больше, чем просто Calvin.
С удовольствием бы почитал. С точки зрения функциональности — очевидно, оригинальный Calvin оперирует моделью «ключ—значение», там нет реляционных механизмов. А вот с точки зрения производительности — пока понимаю только, почему она хуже оригинального кальвина :))
YDB просто по построению будет нормально работать только в том случае, если нет «узких мест», за которые конкурирует множество транзакций. Если вы попробуете, например, построить расчётную систему, где стопиццот транзакций в секунду идут через малое количество ЛОРО и НОСТРО счетов, никакого горизонтального масштабирования не будет. Кальвин — штука такая.
А если транзакции плюс-минус равномерно размазываются по данным, то гораздо лучше будет работать схема Facebook со множеством независимых шардов, каждый из которых обслуживается монолитной базой (MySQL или PostgreSQL). В этой схеме проще всё — и обновление прикладного софта, и локализация сбоев.
P. S. Да, и ещё добавлю. TPC-C — это именно такой тест, где конкуренция между транзакциями достаточно низкая. Сам консорциум TPC давно уже придумал новый тест TPC-E, но только на их сайте опубликовано не более сотни результатов. Так-то индустрия давно наигралась в синтетические тесты и перестала им верить.
Э-э... то есть по-вашему «указатели» равносильны «динамическому выделению памяти»? Это мягко говоря не так. Под словом «указатели» я понимаю именно указатели, а если вам в этом слове очевидно что-то другое, то тут я бессилен.
На ваше зачем есть контраргумент: а зачем на других, если можно на плюсах? )))
Ну в принципе да, аргумент принимается. Но знаете... я когда-то давно писал на плюсах, а вот на Java не написал ни строчки. Но когда я вижу какие-то примеры на современной версии C++ и на Java, то Java намного понятнее. Поэтому выбор C++ и кажется мне странным. Хотя Java тоже, мягко говоря, не идеальна.
Вы как-то очень странно читаете текст. Я разве где-то писал, что на C++ невозможно писать, не используя указатели? Наверное, можно, верю вам на слово. Но зачем? Без указателей можно и на других языках писать.
Вот вы зря смеётесь. Как-то мои коллеги по большому секрету поведали мне, что сделали такую штуку в самом начале разработки прошивки. А когда через год выяснилось, что очередная версия прошивки на 200 байт длиннее, чем объём ПЗУ, они уменьшили размер массива и стали героями дня.
Вы напомнили анекдот, которому лет уж точно больше, чем нам с вами.
Приходит Рабинович устраиваться на работу в советское учреждение. Начальник мнётся, мычит, в общем — видно, что не хочет брать (борьба с космополитизмом в разгаре), но и отказать неудобно.
— Да вы не переживайте так, я же русский на самом деле!
— У-у, ну тогда ступайте себе. С такой фамилией я уж лучше еврея возьму.
Если уж начинать новый безопасный проект, то зачем брать C++?
Но вообще, конечно, отличная статья, спасибо. Не слушайте комментарии про «дурацкие картинки»: если автор способен объяснить такую сложную технологию, почти магию, буквально на пальцах, значит, он очень хорошо понимает, что там происходит :)
Ага. Сертифицированный Oracle DBA не может объяснить, что делает команда «alter database begin backup». Было бы смешно, когда бы не было так грустно...
Статья по ссылке интересная. Но первое и главное, что сделал автор решения, — отвязал все компоненты от облака. «Умный дом» в формате «гик сделал себе хитрые штучки, управляемые с локального сервера» вполне имеет право на существование. В формате «кто-то где-то удалённо управляет системами жизнеобеспечения моего дома» — нет. По крайней мере, с моей точки зрения.
в подавляющем большинстве случаев, Вас лично даже и не видели и не знают.
Вы не читали «Гарри Поттера и методы рационального мышления»? Цитата оттуда: «Антоним любви — не ненависть, а равнодушие». Пока всё нормально, всё нормально. Но как только что-то пошло не так, исправить что-то невозможно. Именно потому, что на тебя всем плевать. Вот я уже год якобы должен компании несколько десятков тысяч рублей. Написано два десятка заявок и несколько заказных писем в дирекцию, сколько ругани по телефону — вообще не счесть. Но только воз и ныне там. А так бы какой-нибудь бездушный исполнитель просто нажал на кнопку.
не космический аппарат на луну
Верно. Когда проектировали космический аппарат, всё отлаживали до того, как его запустить. Сейчас всё сначала выпускается, потом отлаживается.
со стороны человека с ограниченными возможностями
Тут вы, безусловно, правы. Бывают протезы, коляски, слуховые аппараты и прочие приспособления, позволяющие как-то пережить последствия травм и других бед, случившихся с человеком. Но не надо принудительно делать инвалидами всех, заставляя пользоваться костылями.
видение умного дома только с Вашей личной позиции.
Ну да, какая позиция есть, с такой и вижу.
Кто-то эти дома конструирует, кто-то покупает, кто-то потом ругается «зачем я в это влез», кто-то наоборот радуется... Никто не запретит людям этого делать, но и мне удивляться тоже никто не запретит :)
управляющие компании все у всех прекрасно отключают за неуплату или при аварийной ситуации
Только теоретически. Неуёмное человеконенавистничество компаний уравновешивается скоростью прохождения управляющего сигнала от головы до Петровича, непосредственно поворачивающего вентиль.
Умный дом при отключении электроэнергии становится обычным домом.
Это если все ручки продублированы. При отключении электроэнергии обычно выясняется, что продублировано всё, кроме того, что нужно.
,включающая свет в прихожей когда я открываю входную дверь.
голосовым ассистентом
Бесит неимоверно. Если мне надо поговорить, я поговорю с людьми. Железки пусть сами с собой разговаривают.
Не будьте луддитом
Почитайте, кто такие луддиты. Я ничего не ломаю и не призываю ломать. Я только не хочу, чтобы это лезло в мою жизнь. И искренне удивляюсь, глядя на людей, которые не просто пускают, но ещё и согласны платить за это деньги.
Прочтите рассказ Рэя Бредбери «Будет ласковый дождь» из «Марсианских хроник».
Да вот первым же комментарием — «управляющие компании смогут отключать свет/газ/воду». Учитывая опыт общения с разными управляющими компаниями, для меня такая возможность — однозначный маркер, что покупать такую квартиру не надо.
Кроме того, электрическое управление ненадёжно — как минимум из-за того, что электричество могут отключить. А аккумуляторы в квартиру тащить — так себе идея.
Ну и самое элементарное — механическая кнопка всегда удобнее любого приложения. Покатайтесь на Яндекс-драйве по магазинам и сравните ощущение от управления машиной с брелка и из приложения. И ещё многих людей (меня, например) раздражает, когда «умная электроника» пытается предугадать мои желания — обычно у неё получается плохо.
Тем, что выход из строя какого-то одного компонента с состоянием (БД одного из шардов или экземпляра оркестратора) никак не влияет на другие компоненты с состоянием. Сбой всегда локализован.
Примерно так и есть, да. И два десятка администраторов сопровождают несколько десятков тысяч экземпляров этих монолитных баз. С распределёнными базами не удаётся достичь такой эффективности работы администратора. Во многом, конечно, это заслуга эксплуатационной зрелости конкретных продуктов, а не распределённости как таковой, но тем не менее.
Не преждевременная. Изначально большинство приложений пишется в расчёте на монолитную БД, и 95% за её пределы никогда и не вылезают. Работа с шардами начинается не раньше, чем будет очевидно, что в одну базу вся нагрузка не помещается.
Не надо. Но всю распределённую логику можно оформить в виде фреймворка. Тут же дело в том, что это всё потом сопровождать, и когда падает монолитная база, понятно, что делать. А с распределённой базой возможны варианты.
Наши администраторы наотрез отказываются брать на сопровождение распределённую БД как единое целое. Где-то есть MongoDB, Cassandra и Hadoop, но всё это не поднимается выше класса вспомогательного программного обеспечения, данные которого можно и потерять, если рагнарёк.
Вот как раз когда пользователь знает, получается более эффективные приложения. Естественно, всё распределение автоматизировано. Но пишет, например, программист погашение долга по кредитке — это гарантированно локальная транзакция, и можно полагаться на гарантии СУБД. А вот пишет он p2p перевод — тут уже должна быть сага, потому что клиенты могут быть в разных шардах. И программист неизбежно задумается — а как бы сделать поменьше шагов?
Посмотрите.
Вот тут в электронном виде без регистрации и СМС: https://postgrespro.ru/education/books/dbguide
А вот тут на бумаге, но уже за деньги: https://dmkpress.com/catalog/computer/databases/978-5-93700-287-7/
Если понравится, буду благодарен за любой PR кроме некролога :)
Ну приходите на PGConf через пару недель, например :)
Видите ли, практика показывает, что если прикладной программист начинает использовать распределённую БД как «монолитную, только большую», это приводит к разного рода проблемам. Код операций, затрагивающих несколько узлов, должен принципиально отличаться от кода операций, выполняемых на одном узле — это залог успеха. Говорят, в Яндексе очень строгий отбор программистов, и те, кто прошёл этот отбор, такие вещи понимают. Но большинство программистов, особенно тех, которые автоматизируют бизнес, а не занимаются инфраструктурными проектами, — нет.
А тут философский вопрос — а что такое вообще «точка во времени» в распределённой системе? Если ответ на этот вопрос есть (как, например, в Foundation DB или в классическом Calvin), то сделать согласованную резервную копию — чисто техническая задача. А вот если нет...
Ну саги ведь тоже не вчера появились, они гораздо старше, чем Calvin. И бороться с такими инцидентами давно научились. Полагаю, вы тему знаете не хуже меня, а если чего-то не знаете, легко нагуглите :)
Я тоже за KISS, просто понятия о простоте у нас с вами разные. Как-то я столкнулся с неожиданным поведением распределённых систем, стал разбираться, почему они ведут себя так, и в итоге написал вузовский учебник по базам данных. А заодно стал идейным противником распределённых СУБД, если только это не аналитическая платформа типа Greenplum, Presto, Vertica и т. п. :))
А много ли в жизни таких задач? Большинство реальных задач эффективно решаются сагами. Если какое-то непродолжительное время суммарный остаток на счетах будет меньше нужного (у дающего уже списали, а берущему ещё не зачислили), ничего страшного не случится. Возможно, при моделировании каких-то сложных систем в научных экспериментах этот самый «глобальный снапшот» и нужен, но для автоматизации бизнеса — в 99.99% случаев нет.
Я не увидел ни одной цитаты типа «мы ориентируемся на результаты теста XXX при выборе YYY». А разработчики СУБД, конечно, любят щеголять высокими результатами в подобных тестах. Чем иногда создают серьёзные проблемы клиенту.
С удовольствием бы почитал. С точки зрения функциональности — очевидно, оригинальный Calvin оперирует моделью «ключ—значение», там нет реляционных механизмов. А вот с точки зрения производительности — пока понимаю только, почему она хуже оригинального кальвина :))
Классика же. Выливаем воду из чайника, далее действуем в соответствии с п. 1
YDB просто по построению будет нормально работать только в том случае, если нет «узких мест», за которые конкурирует множество транзакций. Если вы попробуете, например, построить расчётную систему, где стопиццот транзакций в секунду идут через малое количество ЛОРО и НОСТРО счетов, никакого горизонтального масштабирования не будет. Кальвин — штука такая.
А если транзакции плюс-минус равномерно размазываются по данным, то гораздо лучше будет работать схема Facebook со множеством независимых шардов, каждый из которых обслуживается монолитной базой (MySQL или PostgreSQL). В этой схеме проще всё — и обновление прикладного софта, и локализация сбоев.
P. S. Да, и ещё добавлю. TPC-C — это именно такой тест, где конкуренция между транзакциями достаточно низкая. Сам консорциум TPC давно уже придумал новый тест TPC-E, но только на их сайте опубликовано не более сотни результатов. Так-то индустрия давно наигралась в синтетические тесты и перестала им верить.
Э-э... то есть по-вашему «указатели» равносильны «динамическому выделению памяти»? Это мягко говоря не так. Под словом «указатели» я понимаю именно указатели, а если вам в этом слове очевидно что-то другое, то тут я бессилен.
Ну в принципе да, аргумент принимается. Но знаете... я когда-то давно писал на плюсах, а вот на Java не написал ни строчки. Но когда я вижу какие-то примеры на современной версии C++ и на Java, то Java намного понятнее. Поэтому выбор C++ и кажется мне странным. Хотя Java тоже, мягко говоря, не идеальна.
Вы как-то очень странно читаете текст. Я разве где-то писал, что на C++ невозможно писать, не используя указатели? Наверное, можно, верю вам на слово. Но зачем? Без указателей можно и на других языках писать.
Вот вы зря смеётесь. Как-то мои коллеги по большому секрету поведали мне, что сделали такую штуку в самом начале разработки прошивки. А когда через год выяснилось, что очередная версия прошивки на 200 байт длиннее, чем объём ПЗУ, они уменьшили размер массива и стали героями дня.
Я бы спросил, что вы знаете о моём подходе к выбору языков программирования и откуда...
Если указатели не нужны, то зачем нужен C++?
Вы напомнили анекдот, которому лет уж точно больше, чем нам с вами.
Приходит Рабинович устраиваться на работу в советское учреждение. Начальник мнётся, мычит, в общем — видно, что не хочет брать (борьба с космополитизмом в разгаре), но и отказать неудобно.
— Да вы не переживайте так, я же русский на самом деле!
— У-у, ну тогда ступайте себе. С такой фамилией я уж лучше еврея возьму.
Если уж начинать новый безопасный проект, то зачем брать C++?
ШМЯК!!!
Но вообще, конечно, отличная статья, спасибо. Не слушайте комментарии про «дурацкие картинки»: если автор способен объяснить такую сложную технологию, почти магию, буквально на пальцах, значит, он очень хорошо понимает, что там происходит :)
Ага. Сертифицированный Oracle DBA не может объяснить, что делает команда «alter database begin backup». Было бы смешно, когда бы не было так грустно...
А продавец, получающий процент с продаж, — хрен маржовый?
Статья по ссылке интересная. Но первое и главное, что сделал автор решения, — отвязал все компоненты от облака. «Умный дом» в формате «гик сделал себе хитрые штучки, управляемые с локального сервера» вполне имеет право на существование. В формате «кто-то где-то удалённо управляет системами жизнеобеспечения моего дома» — нет. По крайней мере, с моей точки зрения.
Вы не читали «Гарри Поттера и методы рационального мышления»? Цитата оттуда: «Антоним любви — не ненависть, а равнодушие». Пока всё нормально, всё нормально. Но как только что-то пошло не так, исправить что-то невозможно. Именно потому, что на тебя всем плевать. Вот я уже год якобы должен компании несколько десятков тысяч рублей. Написано два десятка заявок и несколько заказных писем в дирекцию, сколько ругани по телефону — вообще не счесть. Но только воз и ныне там. А так бы какой-нибудь бездушный исполнитель просто нажал на кнопку.
Верно. Когда проектировали космический аппарат, всё отлаживали до того, как его запустить. Сейчас всё сначала выпускается, потом отлаживается.
Тут вы, безусловно, правы. Бывают протезы, коляски, слуховые аппараты и прочие приспособления, позволяющие как-то пережить последствия травм и других бед, случившихся с человеком. Но не надо принудительно делать инвалидами всех, заставляя пользоваться костылями.
Ну да, какая позиция есть, с такой и вижу.
Кто-то эти дома конструирует, кто-то покупает, кто-то потом ругается «зачем я в это влез», кто-то наоборот радуется... Никто не запретит людям этого делать, но и мне удивляться тоже никто не запретит :)
Только теоретически. Неуёмное человеконенавистничество компаний уравновешивается скоростью прохождения управляющего сигнала от головы до Петровича, непосредственно поворачивающего вентиль.
Это если все ручки продублированы. При отключении электроэнергии обычно выясняется, что продублировано всё, кроме того, что нужно.
Бесит неимоверно. Если мне надо поговорить, я поговорю с людьми. Железки пусть сами с собой разговаривают.
Почитайте, кто такие луддиты. Я ничего не ломаю и не призываю ломать. Я только не хочу, чтобы это лезло в мою жизнь. И искренне удивляюсь, глядя на людей, которые не просто пускают, но ещё и согласны платить за это деньги.
Прочтите рассказ Рэя Бредбери «Будет ласковый дождь» из «Марсианских хроник».
Да вот первым же комментарием — «управляющие компании смогут отключать свет/газ/воду». Учитывая опыт общения с разными управляющими компаниями, для меня такая возможность — однозначный маркер, что покупать такую квартиру не надо.
Кроме того, электрическое управление ненадёжно — как минимум из-за того, что электричество могут отключить. А аккумуляторы в квартиру тащить — так себе идея.
Ну и самое элементарное — механическая кнопка всегда удобнее любого приложения. Покатайтесь на Яндекс-драйве по магазинам и сравните ощущение от управления машиной с брелка и из приложения. И ещё многих людей (меня, например) раздражает, когда «умная электроника» пытается предугадать мои желания — обычно у неё получается плохо.
Удивляет, что до сих пор находятся люди, которые считают все эти «умняшки» преимуществом, а не критическим недостатком дома.
Ну зря вы так. Есть сервисы, которые уже лет пять как автоматически верстают альбомы. Только «нейросетями» это не называют.
И да, может дизайнер Вася сделать, но это оговаривается отдельно и, в отличие от автоматической вёрстки, стоит денег.