AT
Ну и поскольку современные Веб-приложения — это по факту сильно разнесённые в пространстве распределённые приложения, в которых ряд нод вообще постоянно "мигает" — всё становится очень интересно в плане моделей консистентности. 😉
Size: a a a
2021 February 09
AT
когда полтора человека в день редактируют сайт? Можно так-то и состояние держать и вебсокеты использовать. Или это еще сложнее и больнее?
Состояние держать — где?
Если пользователь открыл чего-то на редактирование, пошол пить чай на пол-часа и в процессе у него Интернет отвалился — тогда что? Что и как в это время могут редактировать остальные?
Если пользователь открыл чего-то на редактирование, пошол пить чай на пол-часа и в процессе у него Интернет отвалился — тогда что? Что и как в это время могут редактировать остальные?
AT
СУРБД тут вообще в последнюю очередь играет какую-то роль.
MK
В памяти приложения держать открытую транзакцию, состояние держать в транзакции в БД.
Можно редактировать черновики и их коммитить, а потом накатывать разом.
Можно редактировать черновики и их коммитить, а потом накатывать разом.
MK
можно вести журнал и писать туда то, что планируется закоммитить, и этот журнал пишется в другом соединении и коммитится. В случае чего накатываетс заново.
MK
Я не призываю так делать, я вот в самом деле не понимаю.
AT
можно вести журнал и писать туда то, что планируется закоммитить, и этот журнал пишется в другом соединении и коммитится. В случае чего накатываетс заново.
Application-level WAL? 👏
Может, проще взять Kafka? Или СУРБД? 😉
Может, проще взять Kafka? Или СУРБД? 😉
AT
В памяти приложения держать открытую транзакцию, состояние держать в транзакции в БД.
Можно редактировать черновики и их коммитить, а потом накатывать разом.
Можно редактировать черновики и их коммитить, а потом накатывать разом.
Вы, видимо, не понимаете, что "транзакции" — это часть "бизнес-логики", а не БД. 😊
MK
Ну так и я спраишваю про СУРБД.
WAL вести в той же БД. Просто каждое изменение коммитить.
А состояние держать в открытой транзакции.
Если транзакция закроется, останется журнал, котороый можно накатить.
транзакции бд и бизнес транзакции вообще разные вещи
WAL вести в той же БД. Просто каждое изменение коммитить.
А состояние держать в открытой транзакции.
Если транзакция закроется, останется журнал, котороый можно накатить.
транзакции бд и бизнес транзакции вообще разные вещи
AT
В памяти приложения держать открытую транзакцию, состояние держать в транзакции в БД.
Можно редактировать черновики и их коммитить, а потом накатывать разом.
Можно редактировать черновики и их коммитить, а потом накатывать разом.
Ну и где находится "память приложения", составленного хотя бы по традиционной трёхзвенной архитектуре мне всё ещё не понятно. 🤷♀️
MK
Ну и где находится "память приложения", составленного хотя бы по традиционной трёхзвенной архитектуре мне всё ещё не понятно. 🤷♀️
в микросхеме RAM, я не знаю как еще это объяснить
MK
Websocket, а не http - конечно же
AT
Ну так и я спраишваю про СУРБД.
WAL вести в той же БД. Просто каждое изменение коммитить.
А состояние держать в открытой транзакции.
Если транзакция закроется, останется журнал, котороый можно накатить.
транзакции бд и бизнес транзакции вообще разные вещи
WAL вести в той же БД. Просто каждое изменение коммитить.
А состояние держать в открытой транзакции.
Если транзакция закроется, останется журнал, котороый можно накатить.
транзакции бд и бизнес транзакции вообще разные вещи
Пропустим ерунду и перейдём к сути
> транзакции бд и бизнес транзакции вообще разные вещи
А Вы хотите использовать первые чтобы реализовать вторые. Поэтому ничего и не получается — это разные явления, которые реализуют разную логику работы, имеют разный контекст и scope.
> транзакции бд и бизнес транзакции вообще разные вещи
А Вы хотите использовать первые чтобы реализовать вторые. Поэтому ничего и не получается — это разные явления, которые реализуют разную логику работы, имеют разный контекст и scope.
AT
Websocket, а не http - конечно же
Как только оборвался Websocket, так всё — сели голой жопой в лужу? 😊
JS
может быть, реляционная алгебра не очень хорошая модель для хранения данных приложения? она работает, но не оптимально
AT
может быть, реляционная алгебра не очень хорошая модель для хранения данных приложения? она работает, но не оптимально
Больше похоже на то, что проблемы как раз начинаются в той части SQL, которая не является реляционной алгеброй. 😉
AT
Впрочем временнОго измерения явно не хватает.
2021 February 10
A
Привет, я Миша и я не знаю как использовать SQL базы.
Я хорошо знаком с ними наверное лет 10. Писал сложные запросы, оптимизировал их, оптимизировал хранение, чтобы туда влезало полтерабайта данных.
Я понимаю паттерны вроде Unit of work и Identity map.
Но блин, я не понимаю как правильно работать с БД. Такое ощущение, что мы как-то противоестественно их используем. Не так, как расчитывали их создатели.
Зачем мне в памяти держать копию данных, менять их и героически синхронизировать с состоянием транзакции.
Почему просто не сделать БД единственным источником правды?
Да, много запросов рождают задержки, но настолько ли это серьезно?
Почему, когда контент-менеджер заполняет форму, нельзя отрыть транзакцию и постепенно записывать данные, получать идентификаторы создаваемых вложенных сущностей?
Может быть кто-нибудь видел книжку или доклад?
Я хорошо знаком с ними наверное лет 10. Писал сложные запросы, оптимизировал их, оптимизировал хранение, чтобы туда влезало полтерабайта данных.
Я понимаю паттерны вроде Unit of work и Identity map.
Но блин, я не понимаю как правильно работать с БД. Такое ощущение, что мы как-то противоестественно их используем. Не так, как расчитывали их создатели.
Зачем мне в памяти держать копию данных, менять их и героически синхронизировать с состоянием транзакции.
Почему просто не сделать БД единственным источником правды?
Да, много запросов рождают задержки, но настолько ли это серьезно?
Почему, когда контент-менеджер заполняет форму, нельзя отрыть транзакцию и постепенно записывать данные, получать идентификаторы создаваемых вложенных сущностей?
Может быть кто-нибудь видел книжку или доклад?
Firebase, Rethink не то?
MK
Firebase, Rethink не то?
спасибо посмотрю
но тут же вопрос в sql, например postgres.
например, к elasticsearch или redis у меня нет таких вопросов
но тут же вопрос в sql, например postgres.
например, к elasticsearch или redis у меня нет таких вопросов
AS
спасибо посмотрю
но тут же вопрос в sql, например postgres.
например, к elasticsearch или redis у меня нет таких вопросов
но тут же вопрос в sql, например postgres.
например, к elasticsearch или redis у меня нет таких вопросов
Мне в свое время как-то изучение пролога помогло