ACID-гарантии дают монолитные базы, т. е. базы, работающие на одном сервере. Проблемы с целостностью начинаются на распределённых платформах. Но вообще говоря из распределённости непосредственно не следует нереляционность.
Почему MongoDB, Cassandra и стопиццот других платформ не реляционные? Потому, что реализовать SQL на распределённой системе сложно. То есть неполноценный интерфейс – это плата за распределённость.
Тем не менее, есть и реляционные распределённые СУБД – например, Cockroach. Он вроде как декларирует ACID, но ценой производительности.
Есть в природе и нереляционные монолитные СУБД. Например, GT.M. Зачем их использовать – загадка, потому что SQL реально удобен.
Есть, конечно, и распределённые реляционные СУБД с полноценным ACID – Greenplum, Teradata, Microsoft PDW... Но тут мы уходим вбок по третьей оси – OLTP/OLAP :)
Здесь ошибка. Эта команда ищет файлы *.cpp и любые объекты *.txt (ваше счастье, что у вас нет таких каталогов). Условия с OR надо заключать в скобки. А поскольку у bash свой взгляд на скобки, их надо ещё и экранировать:
Удивительно, что никто до сих пор не вспомнил, что п~ц на английский переводится как «multidimensional state of reality possibly bearing heavy negative connotation».
У соответствующего русского термина совсем не обязательно должен быть тот же корень. Можно, например, использовать слово «перерасход». Но увы, вряд ли этот термин будет принят профессиональным сообществом – ведь «оверпровижынинг» уже утвердился :(
С одной стороны, вы правы. Родной язык надо любить и беречь.
С другой – например, компания РдТЕХ сделала отличный перевод фирменной документации Oracle, где session – сеанс, partition – секция и т. д. Но уже много раз приходилось участвовать в таком диалоге:
– Вы знаете, что такое секционирование?
– Нет.
– Ну, когда одна таблица делится на несколько сегментов.
Вы же помните анекдот, как у курортника кончились деньги, и осталось только на телеграмму из адреса и единственного слова? Он и написал жене: «Пятидесятирублируй».
Идея интересная, мне она приходила в голову ровно 19 лет назад :)
Сначала я не понял, что это звонит телефон. Мелодия была знакомая, и, если бы была такая возможность, я бы обязательно поставил её в качестве звонка. Но такой мелодии у меня никогда не было. Когда люди вокруг уже стали оглядываться, я достал трубку и посмотрел на экран. Точно.
Matsushita! Oh, Matsushita! Matsushita, oh!
— подумал я вслед за легендарным Басё, добавив в хокку несколько слов неяпонского происхождения.
АОН сработал. На экране светилось 7-903-PARADIS. Не успев удивиться, я нажал кнопку:
— Алло!
— Здравствуй, брат! Это я, твой ангел-хранитель.
Не знаю почему, но я сразу ему поверил. Что-то необычное было в его голосе, какая-то неземная сила.
— Здравствуй! — ответил я. Не поверите, но не было во мне ни страха, ни удивления, ни простого любопытства. Как будто каждый день вот так запросто мне звонят ангелы…
— Прости, брат, последнюю неделю было не до тебя. У нас тут вводят электронный документооборот. Все в запарке. Сонмы ангелов скармливают Оракулу терабайты информации, но всё равно еле-еле добрались до Пятой Скрижали Книги Судеб…
— Интересно, а где же вы возьмёте столько дисков, чтобы хранить Вечность?
С кем только я не обсуждал свои профессиональные проблемы! Теперь вот и с ангелом. Можно получить бесценный опыт. Правда, в резюме его не отразишь: «настройка Оракула для Небесной канцелярии» — говорит скорее о шизофрении, чем об опыте работы. Не резюме получается, а диагноз.
— Да это-то как раз не проблема! — ответил Он. — Архангел Михаил с месяц назад приспособил для переработки данных Чёртову мельницу. Идеология, конечно, пострадала, да ничего страшного. Ещё двоих чертей взяли администраторами. Нормальные ребята оказались. Правда, серой от них разит… Я тебе, собственно, чего звоню? Мне вот судьбу твою надо посмотреть хотя бы дня на три, а рабочих мест пока на всех не хватает. Поставили всего сотню терминалов, да и то к ним не протолкнуться. Ты мне подскажи, что там нажимать, а то я, сам понимаешь, к ветрам и молниям больше привык, чем к клавиатуре…
Я задумался. В мечтах я уже сидел за этим терминалом, жадно вчитывался в ярко-зелёные буквы, набирал команды и вершил судьбы. Хотя… security там, наверно, не в пример круче… Надо хотя бы помочь брату:
— Ну, это просто. Набираешь select * from destiny where soul_id=2364523405 and eventdate between sysdate and sysdate+3 order by eventdate и смотришь. Всё очень просто. Если видишь какую-нибудь неприятность, запомни число в самой левой колонке, а потом набери delete from destiny where event_id= и это число. Очень удобно — никаких тебе громов, молний и прочей средневековой атрибутики…
— Селект… чего? Как это пишется?
— Sierra, Echo, Lima, Echo, Charlie, Tango, — начал диктовать я по буквам…
— Подожди… что это за язык такой дурацкий? Они что, не могли на иврите написать? Ну, в крайнем случае, по-русски — я пока с тобой носился, его выучил.
Мне стало стыдно за человечество. В самом деле, неужели нельзя было придумать что-нибудь попроще? Это мне понятно, а Ему там, на Небесах, совершенно незачем забивать голову подобной чепухой.
— Ладно, разберёмся как-нибудь… давай ещё раз помедленнее, я запишу. У-у-у, бюрократы…
Я диктовал SQL-команды по буквам и слышал, как на той стороне скрипит резец по изумрудной скрижали.
— Спасибо, брат! Упдате, говоришь? Ну ладно, попробую… давай, счастливо. Буду за тобой приглядывать.
Трубка замолчала. Я медленно приходил в себя, а потом вдруг вспомнил, что не сказал самого главного: после update обязательно должен следовать commit, иначе все усилия моего Хранителя пропадут даром. Я вызвал на экран список последних принятых звонков, нашёл нужный и нажал кнопку набора.
— Sorry, the subscriber is not available, — ответил ангельский голос на том конце…
не может себе позволить потратить пару миллионов на разработку софта
Да может и тратит. Но за эти деньги решаются другие задачи.
сложность реализации глобально атомарных операций в распределенных системах
Зачем «глобальная атомарность»? Что это за фетиш такой?
В научных экспериментах это нужно, в финансовых сервисах – нет.
грамотная реализация саг по прежнему является крайне сложной задачей
Даже не знаю, как это комментировать.
Эта тема столько раз разжёвана и переварена, что – – –
Лидер -- он на то и лидер, чтобы быть единственным.
В Zookeeper, которому мы тут полощем кости, лидер может меняться. В каждый конкретный момент он один, но если вдруг с лидером что-то случится, то Zookeeper сам принимает решение, кто станет новым лидером (собственно, весь zab/raft/paxos – об этом). А Oracle/PostgreSQL/etc сам такое решение принять не может – у него должен быть внешний переключатель, который для принятия решения использует что-то из перечисленного софта.
Я так понимаю, что его .. разработали в гугле.
Нет, это RedHat в рамках проекта CoreOS
Oracle Observer сам по себе не является отказоустойчивым
Я не понимаю, что вы вкладываете в понятие «отказоустойчивость» в данном случае. Он обеспечивает корректный выбор лидера в случае сбоя в HA-кластере Oracle – и этого достаточно. У Microsoft, IBM и Veritas есть аналогичные решения.
помойка, ржавая и загнившая с концами, с зависшими банкоматами,
Чувствуется, у вас что-то глубоко личное с корнями, уходящими в далёкое детство. В разных банках всё очень по-разному.
нет никакого оправдания для того, чтобы транзакция проходила дольше секунды
Сразу видно человека с богатым практическим опытом. Вот объясните – а зачем быстрее? Ответить человеку «ваша транзакция выполнена» надо быстро, тут SLA обычно полсекунды. Пока он звонит или пишет другу «отправил, лови», деньги дойдут до адресата. Можно вывернуться мехом внутрь и сделать быстрее, но зачем? Банк – это про зарабатывание денег, а не про компаративную фаллометрию.
что при отказе транзакция зависает в лимбо
Не зависает. Прочтите ещё раз, как работает сага.
Как в этой системе обновлять сервера без остановки обработки транзакций?
Смотря что вы понимаете под «обновлять сервера». Если обновление ОС и минорные патчи на СУБД, то спасает физическая репликация на уровне БД (DataGuard, AlwaysOn и т. п.) Если регламентные работы на БД, включая мажорные обновления, и накат новых версий ПО, подразумевающих изменение модели данных, то тут – логическая репликация. С одним, заметьте, лидером.
из публичных софтин ни одно решение не смогло показать отказоустойчивость. Да, реализации рафта и multi-paxos есть -- только они не работают.
Расскажите это разработчикам Oracle Observer и etcd.
Читайте внимательно – маленький raft не для хранения данных, а для автоматизации переключения.
Как человек, последние 15 лет работающий в банковском секторе, а до этого 6 лет в телекоме, я несколько удивлён приведёнными примерами. Достаточно поместить все счета клиента на один монолитный сервер – и никакого воя не будет. А то, что Вася деньги отправил, а Маша получила их только через 5 секунд вообще никого никогда не парило.
Пример с документами тем более непонятен.
Ещё раз подчеркну, я не «против распределённых систем», а против «распределённых БД». Фейсбук – система распределённая, но все БД там монолитные.
нужна строгая согласованность между репликами шарда. Никакими MySQL и сагами этого не сделать.
MySQL – не сделать, хотя вроде Алибаба и к MySQL прикрутила физическую репликацию. А вот любая другая монолитная БД – MS SQL, Oracle, PostgreSQL, DB2 – вполне. Ну и да, над ними маленький raft для автоматизации переключения :)
согласованности данных не будет даже при полном отсутствии отказов.
А это сильно зависит от требований к согласованности.
особенно если есть производственная потребность иметь таковую
Не могу придумать «производственную потребность» под распределённую базу (ещё раз подчеркну, речь не об аналитической СУБД). Не поделитесь?
Лепить из чего попало?
Я не это имел в виду. Facebook состоит из множества шардов, данные каждого из которых хранятся в MySQL. При необходимости межшардовых транзакций организуется сага. На мой взгляд, такой подход намного более отказоустойчивый и масштабируемый, чем единая распределённая БД.
Я вообще противник любых распределённых БД, поскольку убеждённость в том, что «распределённая БД ничем не отличается от монолитной, кроме размера» – крайне опасное заблуждение. Разработчики всё равно будут писать код как для обычной монолитной базы, и на «домашних» нагрузках это даже будет работать. А вот на реальных нагрузках всегда будут неожиданные трудноуловимые спецэффекты. И ещё раз повторю – это относится не только к Кальвину, а вообще ко всем распределённым БД (за исключением аналитических).
Если хочется строить большую распределённую систему, за образец надо брать Facebook.
Apex :)
Всё так, но вы немного путаете тёплое с мягким.
ACID-гарантии дают монолитные базы, т. е. базы, работающие на одном сервере. Проблемы с целостностью начинаются на распределённых платформах. Но вообще говоря из распределённости непосредственно не следует нереляционность.
Почему MongoDB, Cassandra и стопиццот других платформ не реляционные? Потому, что реализовать SQL на распределённой системе сложно. То есть неполноценный интерфейс – это плата за распределённость.
Тем не менее, есть и реляционные распределённые СУБД – например, Cockroach. Он вроде как декларирует ACID, но ценой производительности.
Есть в природе и нереляционные монолитные СУБД. Например, GT.M. Зачем их использовать – загадка, потому что SQL реально удобен.
Есть, конечно, и распределённые реляционные СУБД с полноценным ACID – Greenplum, Teradata, Microsoft PDW... Но тут мы уходим вбок по третьей оси – OLTP/OLAP :)
find . -type f -name "*.cpp" -o -name "*.txt"Здесь ошибка. Эта команда ищет файлы *.cpp и любые объекты *.txt (ваше счастье, что у вас нет таких каталогов). Условия с OR надо заключать в скобки. А поскольку у bash свой взгляд на скобки, их надо ещё и экранировать:
find . -type f \( -name "*.cpp" -o -name "*.txt" \)Удивительно, что никто до сих пор не вспомнил, что п~ц на английский переводится как «multidimensional state of reality possibly bearing heavy negative connotation».
У соответствующего русского термина совсем не обязательно должен быть тот же корень. Можно, например, использовать слово «перерасход». Но увы, вряд ли этот термин будет принят профессиональным сообществом – ведь «оверпровижынинг» уже утвердился :(
С одной стороны, вы правы. Родной язык надо любить и беречь.
С другой – например, компания РдТЕХ сделала отличный перевод фирменной документации Oracle, где session – сеанс, partition – секция и т. д. Но уже много раз приходилось участвовать в таком диалоге:
– Вы знаете, что такое секционирование?
– Нет.
– Ну, когда одна таблица делится на несколько сегментов.
– А-а, партиционирование!
P. S. А provisioning – не «предоставление»?
А ещё ёжика, который hedgehog, Шекспир придумал называть hedgepig!
«Макбет», акт 4, сцена 1, строка 2
Давно пора было.
Удачи вам!
Вы же помните анекдот, как у курортника кончились деньги, и осталось только на телеграмму из адреса и единственного слова? Он и написал жене: «Пятидесятирублируй».
Так что ничто не ново :)
Идея интересная, мне она приходила в голову ровно 19 лет назад :)
Сначала я не понял, что это звонит телефон. Мелодия была знакомая, и, если бы была такая возможность, я бы обязательно поставил её в качестве звонка. Но такой мелодии у меня никогда не было. Когда люди вокруг уже стали оглядываться, я достал трубку и посмотрел на экран. Точно.
— подумал я вслед за легендарным Басё, добавив в хокку несколько слов неяпонского происхождения.
АОН сработал. На экране светилось 7-903-PARADIS. Не успев удивиться, я нажал кнопку:
— Алло!
— Здравствуй, брат! Это я, твой ангел-хранитель.
Не знаю почему, но я сразу ему поверил. Что-то необычное было в его голосе, какая-то неземная сила.
— Здравствуй! — ответил я. Не поверите, но не было во мне ни страха, ни удивления, ни простого любопытства. Как будто каждый день вот так запросто мне звонят ангелы…
— Прости, брат, последнюю неделю было не до тебя. У нас тут вводят электронный документооборот. Все в запарке. Сонмы ангелов скармливают Оракулу терабайты информации, но всё равно еле-еле добрались до Пятой Скрижали Книги Судеб…
— Интересно, а где же вы возьмёте столько дисков, чтобы хранить Вечность?
С кем только я не обсуждал свои профессиональные проблемы! Теперь вот и с ангелом. Можно получить бесценный опыт. Правда, в резюме его не отразишь: «настройка Оракула для Небесной канцелярии» — говорит скорее о шизофрении, чем об опыте работы. Не резюме получается, а диагноз.
— Да это-то как раз не проблема! — ответил Он. — Архангел Михаил с месяц назад приспособил для переработки данных Чёртову мельницу. Идеология, конечно, пострадала, да ничего страшного. Ещё двоих чертей взяли администраторами. Нормальные ребята оказались. Правда, серой от них разит… Я тебе, собственно, чего звоню? Мне вот судьбу твою надо посмотреть хотя бы дня на три, а рабочих мест пока на всех не хватает. Поставили всего сотню терминалов, да и то к ним не протолкнуться. Ты мне подскажи, что там нажимать, а то я, сам понимаешь, к ветрам и молниям больше привык, чем к клавиатуре…
Я задумался. В мечтах я уже сидел за этим терминалом, жадно вчитывался в ярко-зелёные буквы, набирал команды и вершил судьбы. Хотя… security там, наверно, не в пример круче… Надо хотя бы помочь брату:
— Ну, это просто. Набираешь
select * from destiny where soul_id=2364523405 and eventdate between sysdate and sysdate+3 order by eventdateи смотришь. Всё очень просто. Если видишь какую-нибудь неприятность, запомни число в самой левой колонке, а потом набериdelete from destiny where event_id=и это число. Очень удобно — никаких тебе громов, молний и прочей средневековой атрибутики…— Селект… чего? Как это пишется?
— Sierra, Echo, Lima, Echo, Charlie, Tango, — начал диктовать я по буквам…
— Подожди… что это за язык такой дурацкий? Они что, не могли на иврите написать? Ну, в крайнем случае, по-русски — я пока с тобой носился, его выучил.
Мне стало стыдно за человечество. В самом деле, неужели нельзя было придумать что-нибудь попроще? Это мне понятно, а Ему там, на Небесах, совершенно незачем забивать голову подобной чепухой.
— Ладно, разберёмся как-нибудь… давай ещё раз помедленнее, я запишу. У-у-у, бюрократы…
Я диктовал SQL-команды по буквам и слышал, как на той стороне скрипит резец по изумрудной скрижали.
— Спасибо, брат! Упдате, говоришь? Ну ладно, попробую… давай, счастливо. Буду за тобой приглядывать.
Трубка замолчала. Я медленно приходил в себя, а потом вдруг вспомнил, что не сказал самого главного: после
updateобязательно должен следоватьcommit, иначе все усилия моего Хранителя пропадут даром. Я вызвал на экран список последних принятых звонков, нашёл нужный и нажал кнопку набора.— Sorry, the subscriber is not available, — ответил ангельский голос на том конце…
Если в английский приходит мем из русского – это хороший знак. Можно было бы ещё как-нибудь ХХП связать с Hewlett-Packard :)
На всей тебе, Русь-матушка,
Как клейма на преступнике,
Как на коне тавро,
Два слова нацарапано:
«Навынос» и «распивочно»
«Всё кончилось так, как должно было быть, у сказок счастливый конец: Дракон умирает, убитый копьём, принцесса идёт под венец» ©
Ждём продолжения!
Из того, что я знаю, – Сбер и Тинькофф.
Да может и тратит. Но за эти деньги решаются другие задачи.
Зачем «глобальная атомарность»? Что это за фетиш такой?
В научных экспериментах это нужно, в финансовых сервисах – нет.
Даже не знаю, как это комментировать.
Эта тема столько раз разжёвана и переварена, что – – –
В Zookeeper, которому мы тут полощем кости, лидер может меняться. В каждый конкретный момент он один, но если вдруг с лидером что-то случится, то Zookeeper сам принимает решение, кто станет новым лидером (собственно, весь zab/raft/paxos – об этом). А Oracle/PostgreSQL/etc сам такое решение принять не может – у него должен быть внешний переключатель, который для принятия решения использует что-то из перечисленного софта.
Нет, это RedHat в рамках проекта CoreOS
Я не понимаю, что вы вкладываете в понятие «отказоустойчивость» в данном случае. Он обеспечивает корректный выбор лидера в случае сбоя в HA-кластере Oracle – и этого достаточно. У Microsoft, IBM и Veritas есть аналогичные решения.
Чувствуется, у вас что-то глубоко личное с корнями, уходящими в далёкое детство. В разных банках всё очень по-разному.
Сразу видно человека с богатым практическим опытом. Вот объясните – а зачем быстрее? Ответить человеку «ваша транзакция выполнена» надо быстро, тут SLA обычно полсекунды. Пока он звонит или пишет другу «отправил, лови», деньги дойдут до адресата. Можно вывернуться мехом внутрь и сделать быстрее, но зачем? Банк – это про зарабатывание денег, а не про компаративную фаллометрию.
Не зависает. Прочтите ещё раз, как работает сага.
Смотря что вы понимаете под «обновлять сервера». Если обновление ОС и минорные патчи на СУБД, то спасает физическая репликация на уровне БД (DataGuard, AlwaysOn и т. п.) Если регламентные работы на БД, включая мажорные обновления, и накат новых версий ПО, подразумевающих изменение модели данных, то тут – логическая репликация. С одним, заметьте, лидером.
Расскажите это разработчикам Oracle Observer и etcd.
Читайте внимательно – маленький raft не для хранения данных, а для автоматизации переключения.
Как человек, последние 15 лет работающий в банковском секторе, а до этого 6 лет в телекоме, я несколько удивлён приведёнными примерами. Достаточно поместить все счета клиента на один монолитный сервер – и никакого воя не будет. А то, что Вася деньги отправил, а Маша получила их только через 5 секунд вообще никого никогда не парило.
Пример с документами тем более непонятен.
Ещё раз подчеркну, я не «против распределённых систем», а против «распределённых БД». Фейсбук – система распределённая, но все БД там монолитные.
MySQL – не сделать, хотя вроде Алибаба и к MySQL прикрутила физическую репликацию. А вот любая другая монолитная БД – MS SQL, Oracle, PostgreSQL, DB2 – вполне. Ну и да, над ними маленький raft для автоматизации переключения :)
А это сильно зависит от требований к согласованности.
С*ки, когда ж вы уймётесь.
«Это там свинья я, а тут – Поросёнок!»
Не могу придумать «производственную потребность» под распределённую базу (ещё раз подчеркну, речь не об аналитической СУБД). Не поделитесь?
Я не это имел в виду. Facebook состоит из множества шардов, данные каждого из которых хранятся в MySQL. При необходимости межшардовых транзакций организуется сага. На мой взгляд, такой подход намного более отказоустойчивый и масштабируемый, чем единая распределённая БД.
Вот тут соглашусь на 100%.
Я вообще противник любых распределённых БД, поскольку убеждённость в том, что «распределённая БД ничем не отличается от монолитной, кроме размера» – крайне опасное заблуждение. Разработчики всё равно будут писать код как для обычной монолитной базы, и на «домашних» нагрузках это даже будет работать. А вот на реальных нагрузках всегда будут неожиданные трудноуловимые спецэффекты. И ещё раз повторю – это относится не только к Кальвину, а вообще ко всем распределённым БД (за исключением аналитических).
Если хочется строить большую распределённую систему, за образец надо брать Facebook.