ASM — это другое. ASM позволяет работать с ненадёжными дисками, дублируя запись на несколько дисков на уровне самой СУБД. Так-то Oracle всегда ставили на какой-нибудь мощный RAID, а для Exadata сделали ASM. Ну и без экзадаты она доступна.
А работа с сырыми устройствами была сделана задолго до ASM.
OS/400 представляет собой виртуальную машину, в которой выполняется байт-код. В результате аппаратура там давно уже не имеет ничего общего с исходной System/38 (сейчас это процессоры POWER), но код, написанный в те годы, выполняется без перекомпиляции.
чем фреймворк, реализующий распределенные транзакции, лучше распределенной СУБД
Тем, что выход из строя какого-то одного компонента с состоянием (БД одного из шардов или экземпляра оркестратора) никак не влияет на другие компоненты с состоянием. Сбой всегда локализован.
как наши администраторы знают только монолитные базы 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». Было бы смешно, когда бы не было так грустно...
Спасибо!
А можно ссылку на документацию? Я нашёл такое только про Oracle и Db2.
ASM — это другое. ASM позволяет работать с ненадёжными дисками, дублируя запись на несколько дисков на уровне самой СУБД. Так-то Oracle всегда ставили на какой-нибудь мощный RAID, а для Exadata сделали ASM. Ну и без экзадаты она доступна.
А работа с сырыми устройствами была сделана задолго до ASM.
Это не мейнфрейм, а мини-эвм.
OS/400 представляет собой виртуальную машину, в которой выполняется байт-код. В результате аппаратура там давно уже не имеет ничего общего с исходной System/38 (сейчас это процессоры POWER), но код, написанный в те годы, выполняется без перекомпиляции.
Вообще-то еръ и есть твёрдый знак...
Начал было писать ответ, но понял, что потянет уже на отдельный пост. Постараюсь написать на неделе.
Тем, что выход из строя какого-то одного компонента с состоянием (БД одного из шардов или экземпляра оркестратора) никак не влияет на другие компоненты с состоянием. Сбой всегда локализован.
Примерно так и есть, да. И два десятка администраторов сопровождают несколько десятков тысяч экземпляров этих монолитных баз. С распределёнными базами не удаётся достичь такой эффективности работы администратора. Во многом, конечно, это заслуга эксплуатационной зрелости конкретных продуктов, а не распределённости как таковой, но тем не менее.
Не преждевременная. Изначально большинство приложений пишется в расчёте на монолитную БД, и 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». Было бы смешно, когда бы не было так грустно...
А продавец, получающий процент с продаж, — хрен маржовый?