Здравствуйте, Sinclair, Вы писали:
S>Чем кончилось-то?
замыслы не получилось претворить в жизнь. Могу рассказать что я хотел, но без реального опыта. В реальности же появился "гуру", а дальше как в сказке — "чем дальше тем страшнее"...
Чтобы не быть голословным, рассказывая про сказку. После того как гуру родил дизайн на основе патерна God object, и начал имплементацию методом copy/paste. Он между делом родил свой Razor, основанный на строковых вьюшках в контроллере и массовых реплэйсах... Какой там нахер балансинг... Даже банальные IoC, Unit testing и линк пошли лесом(с мотивацией что без них жили и все было ок).
Здравствуйте, __SPIRIT__, Вы писали:
__S>Т.е. все хранят полную копию базы и все данные(в нашем случае это файлы в несколько десятков теробайт) во всех точках мира? Остановите планету я сойду __S>А если серьезно, как-то это не оптимально.
Представьте Фейсбук. Вася лайкает фотку китайца Чу. В этот момент Джон лайкает эту же фотку Чу.
Вопрос: Увидят ли Вася и Джон лайки друг друга?
Ответ: если и да, то далеко не сразу. А вообще 100% гарантии нет, потому что Вася лайкает копию на российском ноде, а Джон — на штатовском. Чу загрузил фотку неделю назад, поэтому репликация успела пройти по всем нодам.
Бонусный вопрос для самостоятельного разбора: Что увидит Чу?
Сходить с планеты не надо, ибо подобные проблемы испытывает в том числе и маршрутизация всего интернета. Когда где-то происходит изменение конфигурации подсети, остальной интернет узнаёт об этом не сразу, а постепенно, в процессе BGP-обмена. Причём любой BGP-маршрутизатор может держать у себя копию BGP full view, а может и не держать (но знать куда за ним сходить при случае, или просто делегировать всё, что не понял, куда-то "к терапевту").
Здравствуйте, __SPIRIT__, Вы писали:
__S>Я очень сомневаюсь что мордокнига использует РСУБД и как-то ее синхронизирует. Я бы ожидал скорее увидеть шарды + кэш с других шардов. Соответственно будет лаг на обновление кэша.
MD>>Сходить с планеты не надо, ибо подобные проблемы испытывает в том числе и маршрутизация всего интернета. Когда где-то происходит изменение конфигурации подсети, остальной интернет узнаёт об этом не сразу, а постепенно, в процессе BGP-обмена. Причём любой BGP-маршрутизатор может держать у себя копию BGP full view, а может и не держать (но знать куда за ним сходить при случае, или просто делегировать всё, что не понял, куда-то "к терапевту").
__S>Это вариант кэша. А значит не полная копия и даже то что копируется к себе, делается не на всегда.
MD>>Этот мир асинхронен, смиритесь
__S>Все ок пока не появляются общие ресурсы. У нас, например практически все общее. И если одновременно(с разницей в секунду) Куй в Китае, Джон в штатах и Густав в Германии редактируют одну и туже сущность, потом ее смерджить не получится.
[quote]
Как обычно во время полета, представители всех служб космодрома, отряда космонавтов и конструкторов, посменно дежурили, чтобы всегда была возможность организовать консультацию и принять ответственное решение. В нашей смене в тот раз был и Ю. Гагарин. Обычно в два-три часа ночи поступление информации заканчивается, космический аппарат «на той стороне» Земли. Смена, около девяти утра, делать нечего, но спать невозможно, потому что очень сильное напряжение. И начинается треп, всякие байки... Так было и в тот раз. А утром нам из Симферополя, а это первый измерительный пункт, над которым пролетал Быковский, поступает радиограмма. И в конце, после всех параметров кабины: «Имел космический стук».
Переполох страшный! Представляете, что может стучать в космосе?! Что-то оторвалось и стучит? Как звук распространяется? Непонятно. Масса разных предположений. Королева решили не будить, разбудили Каманина, командира отряда космонавтов. Примчался он к нам в радиорубку, туда уже набилась вся смена. А Быковский уже подлетает к нам и вот-вот войдет в связь на коротких волнах. Каманин Гагарину и говорит: -Давай, составляй радиограмму, и как только он войдет в связь, ты ему все открытым текстом и передашь. И диктует: -Космонавту Быковскому. Сообщите характер наблюдавшегося Вами космического стука: шипящий, стучащий, скрежещущий и прочая. Быковский подлетает и, в соответствии с регламентом, начинает с параметров кабины. Обычно связь летающего космонавта с наземным центром, была на уровне дружеской беседы, никакой официальности, по имени, все эти позывные придуманы, я не знаю для кого. А тут Гагарин перебивает Быковского и обращается «на Вы»:
-"Примите радиограмму!" В космосе повисает тишина. Гагарин начинает диктовать, что у него написано.
И вдруг раздается дикий смех: -Какой стук! Стул! Понятно?
На мгновение в радиорубке устанавливается гробовая тишина, а потом...
[/quote]
Задача:
Есть web-приложение B2B, развернуто в штатах на наших серверах. Клиенты используют его по подписке. И есть компании, работающие по всему миру. Нужно им обеспечить быструю работу с намм из Китая, Австралии и Европы.
Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных.
Если схемотично то выглядит так:
1) balancer смотрит на IP и редиректит на ближайший сервер
2) пользователь работает с серваком
3) система на фоне перегонят обновления на другие сервера.
Наверное, уже не актуально, поэтому добавлю для истории пример архитектуры из текущего проекта:
1. Да, региональные узлы. Главная причина, как ни странно, не технологическая, а правовая — законы о персональных данных, требующие в некоторых странах (Россия, Китай) хранить их локально.
2. Микросервисы. Поскольку разные куски функционала отделены друг от друга физически, это хорошо помогает сохранить слабо связанную архитектуру и делать оптимизации в каждом конкретном случае отдельно, по задаче. Клиентские приложения ходят в микросервисы через API GW и балансировщик.
3. Шардинг — для региональных данных, плюс кэширование на ближайших к клиенту узлах, плюс асинхронная обработка ближайшим к клиенту узлом запросов на изменение. Превентивное кэширование пока не используется. Блокировки — оптимистические (специфика системы позволяет).
Здравствуйте, __SPIRIT__, Вы писали:
__S>Задача: __S>Есть web-приложение B2B, развернуто в штатах на наших серверах. Клиенты используют его по подписке. И есть компании, работающие по всему миру. Нужно им обеспечить быструю работу с намм из Китая, Австралии и Европы.
__S>Но все это выглядит тупиковой веткой.
__S>Есть какие-то известные подходы?
Все ровно так и делают, никаких проблем обычно не возникает.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Задача: __S>Есть web-приложение B2B, развернуто в штатах на наших серверах. Клиенты используют его по подписке. И есть компании, работающие по всему миру. Нужно им обеспечить быструю работу с намм из Китая, Австралии и Европы.
__S>Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных.
__S>Если схемотично то выглядит так:
__S>1) balancer смотрит на IP и редиректит на ближайший сервер
Можно ещё попробовать Anycast DNS, тогда балансер не будет единой точкой сбоя (у вас же несколько датацентров, как я понимаю?)
Здравствуйте, __SPIRIT__, Вы писали:
__S>Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных. __S>Есть какие-то известные подходы?
Так и делают обычно. Весь вопрос в том, как правильно нагородить синхронизацию баз данных. Ответ очень зависит от вашей бизнес задачи.
Здравствуйте, Gurney, Вы писали:
__S>>Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных. __S>>Есть какие-то известные подходы? G>Так и делают обычно. Весь вопрос в том, как правильно нагородить синхронизацию баз данных. Ответ очень зависит от вашей бизнес задачи.
Т.е. все хранят полную копию базы и все данные(в нашем случае это файлы в несколько десятков теробайт) во всех точках мира? Остановите планету я сойду
А если серьезно, как-то это не оптимально.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Представьте Фейсбук. Вася лайкает фотку китайца Чу. В этот момент Джон лайкает эту же фотку Чу.
MD>Вопрос: Увидят ли Вася и Джон лайки друг друга? MD>Ответ: если и да, то далеко не сразу. А вообще 100% гарантии нет, потому что Вася лайкает копию на российском ноде, а Джон — на штатовском. Чу загрузил фотку неделю назад, поэтому репликация успела пройти по всем нодам.
MD>Бонусный вопрос для самостоятельного разбора: Что увидит Чу?
Я очень сомневаюсь что мордокнига использует РСУБД и как-то ее синхронизирует. Я бы ожидал скорее увидеть шарды + кэш с других шардов. Соответственно будет лаг на обновление кэша.
MD>Сходить с планеты не надо, ибо подобные проблемы испытывает в том числе и маршрутизация всего интернета. Когда где-то происходит изменение конфигурации подсети, остальной интернет узнаёт об этом не сразу, а постепенно, в процессе BGP-обмена. Причём любой BGP-маршрутизатор может держать у себя копию BGP full view, а может и не держать (но знать куда за ним сходить при случае, или просто делегировать всё, что не понял, куда-то "к терапевту").
Это вариант кэша. А значит не полная копия и даже то что копируется к себе, делается не на всегда.
MD>Этот мир асинхронен, смиритесь
Все ок пока не появляются общие ресурсы. У нас, например практически все общее. И если одновременно(с разницей в секунду) Куй в Китае, Джон в штатах и Густав в Германии редактируют одну и туже сущность, потом ее смерджить не получится.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Есть web-приложение B2B, развернуто в штатах на наших серверах. Клиенты используют его по подписке. И есть компании, работающие по всему миру. Нужно им обеспечить быструю работу с намм из Китая, Австралии и Европы.
__S>Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных.
Клиенты пишут в местные копии базы, или только читают? Нельзя сделать чтение из локальных копий и запись только в центральную?
__S>Но все это выглядит тупиковой веткой.
А почему тупиковой?
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, ins-omnia, Вы писали:
__S>>Есть web-приложение B2B, развернуто в штатах на наших серверах. Клиенты используют его по подписке. И есть компании, работающие по всему миру. Нужно им обеспечить быструю работу с намм из Китая, Австралии и Европы. __S>>Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных. IO>Клиенты пишут в местные копии базы, или только читают? Нельзя сделать чтение из локальных копий и запись только в центральную?
проблемы с записью в первую очередь. Как бы я хотел все видеть, еще не сформулировал(в процессе). Если интересно могу выложить как будет готово.
__S>>Но все это выглядит тупиковой веткой. IO>А почему тупиковой?
Очень сложная конструкция. Большая вероятность ошибок из-за постоянного мержа состояний. Неустранимые проблемы с выходом ноды в офлайн. Самое неприятное, когда авария на магистрали и локальная нода доступна пользователям, а вся система нет.
Не понятно что делать с одновременным изменением одной сущности на разных нодах
Долгий апдейт, если на одну ноду загрузили 100Гигов, другие ноды получат данные очень не скоро.
Очень большой уровень дублирования. Большая часть данных дублируется бессмысленно, они просто не будут использованы. Не оптимально
Это навскидку, уверен проблем будет больше.
Здравствуйте, __SPIRIT__, Вы писали:
__S>проблемы с записью в первую очередь. Как бы я хотел все видеть, еще не сформулировал(в процессе).
Но схема уже реализована в каком-то виде, значит какой-то анализ уже был? Значит известно, что именно необходимо ускорить.
Как я понимаю, там в основном интерактивная работа юзеров с какими-то данными. При таком сценарии веб-приложение в основном читает данные из базы, и только от случая к случаю записывает. Нельзя ли читать данные из местного кеша и просто игнорировать тормоза при записи?
__S>Если интересно могу выложить как будет готово.
Интересно.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
G>>Так и делают обычно. Весь вопрос в том, как правильно нагородить синхронизацию баз данных. Ответ очень зависит от вашей бизнес задачи.
MSSQL peer-to-peer transaction replication
__S>Т.е. все хранят полную копию базы и все данные(в нашем случае это файлы в несколько десятков теробайт) во всех точках мира? Остановите планету я сойду __S>А если серьезно, как-то это не оптимально.
Childish volume. I have such database at home in my basement.
Здравствуйте, Lepsik, Вы писали:
G>>>Так и делают обычно. Весь вопрос в том, как правильно нагородить синхронизацию баз данных. Ответ очень зависит от вашей бизнес задачи.
L>MSSQL peer-to-peer transaction replication
Из штатов в Австралию? Сколько будет идти транзакция? Что будет если одна нода вывалилась и через 2 дня вернулась?
__S>>Т.е. все хранят полную копию базы и все данные(в нашем случае это файлы в несколько десятков теробайт) во всех точках мира? Остановите планету я сойду __S>>А если серьезно, как-то это не оптимально.
L>Childish volume. I have such database at home in my basement.
По русски разучился писать? Или писькомерство на английском идет с коэфициентом?
Ок, у тебя дома десятки терабайт порно, на серверных винтах с рэйдом, раскиданных по всему миру. Плюс запасная копия в каждой точке в соседнем датацентре.
Ок, видимо ты маньяк.
З.Ы.
В следующий раз можешь понтануться перед зеркалом, порадоваться и пройти мимо.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Есть какие-то известные подходы?
А если поглядеть на возможности Azure в этой области?
Плюс еще идея — если клиентам нет необходимости (или даже возможности) видеть данные друг друга, то развернуть независимые приложения. Т.е. как делают иногда для игровых серверов — свой независимый от других "мирок" для отдельных частей реального мира.
Здравствуйте, __SPIRIT__, Вы писали:
SPI> Все ок пока не появляются общие ресурсы. У нас, например практически все общее. И если одновременно(с разницей в секунду) Куй в Китае, Джон в штатах и Густав в Германии редактируют одну и туже сущность, потом ее смерджить не получится.
Может быть, именно в этом ваша проблема. В распределенных системах стараются делать общим кк можно меньше.
__S>Т.е. все хранят полную копию базы и все данные(в нашем случае это файлы в несколько десятков теробайт) во всех точках мира? Остановите планету я сойду __S>А если серьезно, как-то это не оптимально.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Очень сложная конструкция. Большая вероятность ошибок из-за постоянного мержа состояний. Неустранимые проблемы с выходом ноды в офлайн. Самое неприятное, когда авария на магистрали и локальная нода доступна пользователям, а вся система нет.
1. Надо обеспечить HA каждой ноды. Т.е. ситуации, что в локальную ноду загрузили данные, а она умерла, не успев синхронизоваться с остальными, быть не должно. На пальцах: локальная "нода" — трёхмашинный кластер, коммит в который требует кворума 2/3. Вероятностью split brain в локальном кластере можно пренебречь.
2. Надо обеспечить более-менее избыточное подключение региональной ноды к интернету. Штука не очень нужная, т.к. современные магистрали как правило лежат редко, а чинятся — быстро. Найти точку на карте интернета, которая может остаться без связи с большой землёй на 48 часов — это какая-то экзотика в труднодоступных местах. Если вам повезло иметь ноду в таком месте, то купите резервный канал. GPRS через другого провайдера, спутник, что угодно. __S>Не понятно что делать с одновременным изменением одной сущности на разных нодах
Это отдельный большой вопрос. Я знаю три стратегии:
1. Pessimistic locking. Т.е. перед началом изменения мне нужно захватить блокировку на объект, которая получается путём кворума.
2. Разрешение конфликтов.
3. Workflow-based locking. Это разновидность п.1. — когда у документа всегда есть единственный owner, и передача права на редактирование происходит при репликации. При этом забрать право нельзя — можно только отдать. __S>Долгий апдейт, если на одну ноду загрузили 100Гигов, другие ноды получат данные очень не скоро.
С этим придётся смириться. Это интернет, детка (tm). Альтернатива — одеа центральная нода. Те же 100 гигов до неё доедут очень нескоро — по ровно той же причине. Введение региональных нод позволяет хотя бы местным пользователям оперативно насладиться 100 гигами. __S>Очень большой уровень дублирования. Большая часть данных дублируется бессмысленно, они просто не будут использованы. Не оптимально
4. Это решается только семантически. Т.е. вы должны уметь хорошо предсказывать, какие данные будут не нужны локальному пользователю. В общем случае — неразрешимо, т.к. если есть возможность порезать связи данных, то вы сразу получаете набор локальных самодостаточных приложений. Которые могут обмениваться какой-то общей информацией, но только в специальных случаях. Ну, типа локальный офис торгует со своего склада; в тех редких случаях, когда нужного товара на локальном складе нет, мы делаем запросы к коллегам и инициируем дорогостоящий процесс перемещения между складами. Если локальных офисов слишком много, то мы можем завести глобальную базу остатков для ускорения поиска — и все будут реплицироваться в неё. Опять таки, решение построено на доскональном знании не только предметной области, но и относительных частот различных сценариев. Получить обобщённый вариант такого решения не представляется возможным.
__S>Это навскидку, уверен проблем будет больше.
Альтернатив, по большому счёту, нету никаких. Либо 1 центральная нода — страдаем от проблем ширины и надёжности канала к ней. Либо локальные ноды = страдаем от проблем ширины и надёжности канала между ними
Чем кончилось-то?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Очень сложная конструкция. Большая вероятность ошибок из-за постоянного мержа состояний. __S>Не понятно что делать с одновременным изменением одной сущности на разных нодах
Есть так называемая CAP-теорема. Выбирайте тот компромисс, который вам больше подходит.
Ну и еще пару мыслей: если решитесь на шардирование-репликацию по регионам, то тут либо асинхронность, либо тормоза до нескольких минут на каждый синхронный апдейт.
Если нужен мультимастер — то такое умеет кассандра.
Покрутите ивент сорсинг, вполне возможно он несколько облегчит обработку конкурентного апдейта
Ну и надо проектировать систему так, чтобы минимизировать число конкурентных апдейтов. Идеально если получится шардировать и каждый шард привязать к региону.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Задача: __S>Есть web-приложение B2B, развернуто в штатах на наших серверах. Клиенты используют его по подписке. И есть компании, работающие по всему миру. Нужно им обеспечить быструю работу с намм из Китая, Австралии и Европы.
__S>Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных.
peer-to-peer transaction replication. Дальше если нод выпал — коннектимся по списку к ноде слева или справа что ближе
Даже банальные IoC, Unit testing и линк пошли лесом(с мотивацией что без них жили и все было ок). 
