Общение между слоями

Обсуждаем, как правильно строить приложения
Bio man
Сообщения: 609
Зарегистрирован: 2013.07.22, 10:40

Re: Общение между слоями

Сообщение Bio man » 2018.01.23, 18:58

Не хочу создавать отдельную тему, спрошу тут.

йишные миграции это инфраструктура?

Аватара пользователя
ElisDN
Сообщения: 4831
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Общение между слоями

Сообщение ElisDN » 2018.01.23, 19:55

Bio man писал(а):
2018.01.23, 18:58
йишные миграции это инфраструктура?
Да.

sda
Сообщения: 330
Зарегистрирован: 2013.12.19, 09:29

Re: Общение между слоями

Сообщение sda » 2018.02.01, 23:55

anton_z, ну транзакции в рсубд же тоже не магическим образом работают. Нельзя атомарно изменить данные в двух разных файлах, так как это 2 операции, в то время как ядро процессора атомарно может выполнить только 1 операцию. Рсубд эти транзакции пишут в лог, а уже потом накатывают изменения на данные которые физически могут располагаться в разных файлах. База по этому логу восстанавливает консистентность данных после сбоя.

Примерно тоже самое можно сделать и с дедупликацией на монге. Просто придется загрязнять сущность знаниями о том, какие сообщения она уже обрабатывала и какие сообщения она сгенерировала в процессе своей жизнедеятельности. Потом из сущности перекладывать обработанные сообщения в отдельную коллекцию, сгенерированные сообщения в очередь и затем удалять эти данные из сущности, чтобы они не раздували документ.

То есть сохранение сущности теперь будет в несколько шагов:

1. Конвертировать сущность в документ
2. Сохранить документ
3. Сохранить обработанное сообщение в отдельную коллекцию
4. Отправить сгенерированное сообщение в очередь.
5. Удалить обработанное/сгенерированное сообщения из документа.

На любом этапе у нас есть информация по сообщениям. Их можно найти в документе, отдельной коллекции или очереди. Нужно еще продумать как при сбоях вычищать мусор из документа (пункт 5). Так как сохранение сущности может сломаться на шаге 3, 4 и 5.

Это всё грязно, плохо, криво. Но возвращаться на рсубд с объектно-реляционным несоответствием, с гигантскими ORM, с ручным шардингом и как следствие отказ от транзакций, джойнов, контроля целостности и всего остального за что любят рсубд то в итоге не будет никаких преимуществ перед nosql. Останутся только минусы.

sda
Сообщения: 330
Зарегистрирован: 2013.12.19, 09:29

Re: Общение между слоями

Сообщение sda » 2018.02.02, 00:12

anton_z, и ещё я по кассандре немного не понял. Там есть транзакции построенные на алгоритме paxos кажется. Но я так понял там не работает подход Read-Modify-Update по которому работает слой приложения в многоуровневых приложениях. Так как нет блокировок то соответственно при стандартном подходе read-modify-update будут теряться обновления. Я так понял, cassandra будет работать только либо для event sourcing подхода либо для transaction script, но это снова шаг назад в процедурное программирование.

Кто разбирается в cassandra скажите, я верно понимаю?

anton_z
Сообщения: 283
Зарегистрирован: 2017.01.15, 15:01

Re: Общение между слоями

Сообщение anton_z » 2018.02.03, 04:47

sda писал(а):
2018.02.01, 23:55
Это всё грязно, плохо, криво. Но возвращаться на рсубд с объектно-реляционным несоответствием, с гигантскими ORM, с ручным шардингом и как следствие отказ от транзакций, джойнов, контроля целостности и всего остального за что любят рсубд то в итоге не будет никаких преимуществ перед nosql. Останутся только минусы.
Все решения хороши только в определенных условиях. РСУБД для большинства задач хватает, если вы не работаете в Facebook, Badoo или других больших проектах с миллионами пользователей. Для большинства сайтов, даже немаленьких, производительности РСУБД и возможностей одного физического сервера БД хватит намного, также есть кеширование, которое может серьезно снизить нагрузку. На чтение можно масштабироваться горизонтально и с РСУБД если приемлема консистентность в конечном счете. Также можно реплицироваться в другие БД на чтение - tarantool, ElasticSearch и пр.

Еще слышал про NDB и масштабирование на аппаратном уровне, но никогда не трогал руками.

Монструозные ORM типа Doctrine использовать необязательно, есть AR, gateway, DAO. Под задачу можно подобрать то или иное решение - подход "везде используем DDD и DataMapper" ложный. Я в основном AR пользуюсь и мне очень удобно, Doctrine тоже пользовался, но мне не понравилось, на самопис время не хочу тратить - как ни крути получается дольше чем готовое, да и другим разработчикам дольше разбираться.

Преимущества РСУБД - скорость разработки. Не зря же связка MySQL + PHP завоевала такую популярность - выходит быстрее и дешевле.
Конечно, можно все проекты делать на nosql и закладывать хороший фундамент на масштабирование, замену хранилища, бесконечную гибкость, но это слишком дорого, редко кто вообще так делает - все решают проблемы по мере поступления. Сотрим за нагрузкой - если быстро растет - покупаем сервер помощнее, нанимаем еще людей, переписываем.

У вас терабайты данных, что партицирование потребовалось? Или "на вырост" закладываете? Если данные старые и не требуются, их можно и чистить.

По cassandra ничего сказать не могу, никогда не пробовал.

sda
Сообщения: 330
Зарегистрирован: 2013.12.19, 09:29

Re: Общение между слоями

Сообщение sda » 2018.02.08, 08:45

anton_z, а у вас транзакции фейлятся? Чем больше агрегатов сохраняется в одной транзакции, тем ведь выше шанс что она законфликтится с другими транзакциями.

anton_z
Сообщения: 283
Зарегистрирован: 2017.01.15, 15:01

Re: Общение между слоями

Сообщение anton_z » 2018.02.08, 09:26

sda писал(а):
2018.02.08, 08:45
anton_z, а у вас транзакции фейлятся? Чем больше агрегатов сохраняется в одной транзакции, тем ведь выше шанс что она законфликтится с другими транзакциями.
А фейлы какой природы интересуют?

Если речь идет про фейлы из-за размеров то транзакции большими не делаю (наборот, чем меньше, тем лучше - насколько позволяют требования к атомарности), поэтому не разу не наблюдал фейлов из-за размера.

Если про дедлоки - то они ниоткуда не берутся. Всегда есть причина - что-то не так задумано/запрограммировано. Если случается дедлок ищем, логгируем, переписываем

sda
Сообщения: 330
Зарегистрирован: 2013.12.19, 09:29

Re: Общение между слоями

Сообщение sda » 2018.02.08, 10:41

anton_z, да из-за размеров. У вас же наверняка есть реализация optimistic concurrency и когда одна транзакция меняет скажем сразу 3 агрегата, то кто-то другой уже мог тоже изменить любой из этих трех агрегатов. Тогда текущая транзакция не сможет выполниться. И чем толще транзакция, тем выше шанс таких конфликтов.

anton_z
Сообщения: 283
Зарегистрирован: 2017.01.15, 15:01

Re: Общение между слоями

Сообщение anton_z » 2018.02.08, 10:56

sda писал(а):
2018.02.08, 10:41
anton_z, да из-за размеров. У вас же наверняка есть реализация optimistic concurrency и когда одна транзакция меняет скажем сразу 3 агрегата, то кто-то другой уже мог тоже изменить любой из этих трех агрегатов. Тогда текущая транзакция не сможет выполниться. И чем толще транзакция, тем выше шанс таких конфликтов.
А, вы больше не про фейлы а про откаты транзакций в случае срабатывания блокировки. Я стараюсь больше одного агрегата в транзакции не менять и UI и служебные утилиты (консоль по крону, демоны) проектирую соответсвующим образом. Для основных форм помимо optimistic lock иногда (если вероятность одновременного изменения высокая) использую еще pessimistic lock (на основе ajax), так что вообще редко транзакции откатываются.

sda
Сообщения: 330
Зарегистрирован: 2013.12.19, 09:29

Re: Общение между слоями

Сообщение sda » 2018.02.08, 11:18

anton_z писал(а):
2018.02.08, 10:56
Я стараюсь больше одного агрегата в транзакции не менять
А как вы обрабатываете тогда ситуации когда изменения в агрегате влияют на другой агрегат ?

anton_z
Сообщения: 283
Зарегистрирован: 2017.01.15, 15:01

Re: Общение между слоями

Сообщение anton_z » 2018.02.08, 13:09

sda писал(а):
2018.02.08, 11:18
anton_z писал(а):
2018.02.08, 10:56
Я стараюсь больше одного агрегата в транзакции не менять
А как вы обрабатываете тогда ситуации когда изменения в агрегате влияют на другой агрегат ?
Я стараюсь больше одного не менять, но это в некоторых случаях недостижимо, так как продиктовано требованиями. Если нужна атомарность и мгновенность изменений, тогда конечно общая транзакция. Если получается, что слишком много агрегатов надо менять - ищу возможность сделать массовый update, часто этому препятствует необходимость генерирования событий для каждого агрегата. Если на active record и запросах делать, без изоляции домена от базы, то все получается довольно быстро и просто (имхо). А вообще исходя из задачи надо смотреть и проектировать, универсальных решений нет.

Ответить