Система бронирования кинотеатров - дизайн БД
От: dglaurung  
Дата: 07.07.21 07:08
Оценка:
Допустим нужно сделать систему бронирования кинотеатров, примерная схема такая

Client: кто бронировал
SeatBooking: таблица связывающая место-клиент-сеанс
Seat: места (IS_BOOKED не используется атрибут)
Show: сеанс

Пусть пользователи могут бронировать много мест на много сеансов.

Как лучше всего(производительность) сделать так, чтобы паралелльные транзакции не сделали пересекающиеся бронирования на одно и тоже место в одном и том же сеансе?
Менять схему можно (и нужно).

Заранее спс!
Re: Система бронирования кинотеатров - дизайн БД
От: Maniacal Россия  
Дата: 07.07.21 07:15
Оценка: 3 (1)
Здравствуйте, dglaurung, Вы писали:

D>Как лучше всего(производительность) сделать так, чтобы паралелльные транзакции не сделали пересекающиеся бронирования на одно и тоже место в одном и том же сеансе?

D>Менять схему можно (и нужно).

SELECT FOR UPDATE делать для seats до подтверждения бронирования (UPDATE seats / COMMIT) или отмены (ROLLBACK) бронирования.
Re: Система бронирования кинотеатров - дизайн БД
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.07.21 07:27
Оценка: 8 (1)
Здравствуйте, dglaurung, Вы писали:

D>Как лучше всего(производительность) сделать так, чтобы паралелльные транзакции не сделали пересекающиеся бронирования на одно и тоже место в одном и том же сеансе?

D>Менять схему можно (и нужно).
Уникальный индекс на SeatBooking(место, сеанс)

D>Заранее спс!

Нзчт
Re[2]: Система бронирования кинотеатров - дизайн БД
От: dglaurung  
Дата: 07.07.21 07:29
Оценка:
Здравствуйте, Maniacal, Вы писали:

M>SELECT FOR UPDATE делать для seats до подтверждения бронирования (UPDATE seats / COMMIT) или отмены (ROLLBACK) бронирования.


Что можно сделать, если база данных не поддерживает транзакции?
Re[3]: Система бронирования кинотеатров - дизайн БД
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.07.21 07:34
Оценка:
Здравствуйте, dglaurung, Вы писали:

D>Что можно сделать, если база данных не поддерживает транзакции?

Сделать свой WAL.

То есть append-only таблицу, куда складывать детали транзакции и общий процесс разбора лога и записи данных в таблицу Bookings.
Клиенты буут писать в лог и ожидать ответа от процесса разбора. Если процесс разбора выяснит что такая запись уже была добавлена ранее, то она ставит флаг что транзакцию необходимо откатить.

Но лучше конечно взять СУБД поддерживающую транзакции.
Отредактировано 07.07.2021 7:34 gandjustas . Предыдущая версия .
Re[3]: Система бронирования кинотеатров - дизайн БД
От: BlackEric http://black-eric.lj.ru
Дата: 07.07.21 15:57
Оценка:
Здравствуйте, dglaurung, Вы писали:

D>Здравствуйте, Maniacal, Вы писали:


M>>SELECT FOR UPDATE делать для seats до подтверждения бронирования (UPDATE seats / COMMIT) или отмены (ROLLBACK) бронирования.


D>Что можно сделать, если база данных не поддерживает транзакции?


Заменить бд. Ну или написать свой DAL с реализацией транзакций.
https://github.com/BlackEric001
Re[3]: Система бронирования кинотеатров - дизайн БД
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 08.07.21 15:20
Оценка: +2
Здравствуйте, dglaurung, Вы писали:
D>Что можно сделать, если база данных не поддерживает транзакции?
Для начала — выкинуть её в помойку и поставить СУБД, которая транзакции поддерживает.
Объём данных, о которых идёт речь — семечки. С ним справится настольная версия любой СУБД из большой четвёрки при работе на позапрошлогоднем ноуте от батарейки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re: Система бронирования кинотеатров - дизайн БД
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 08.07.21 16:01
Оценка: 59 (3) +1
Здравствуйте, dglaurung, Вы писали:

D>Как лучше всего(производительность) сделать так, чтобы паралелльные транзакции не сделали пересекающиеся бронирования на одно и тоже место в одном и том же сеансе?

D>Менять схему можно (и нужно).
Для комфортной работы потребуется двух- трёх-фазная блокировка:
— вначале, когда пользователь выбирает место, мы его "мягко" бронируем на короткий промежуток времени.
— далее, если пользователь забронировал, мы его бронируем с фиксированным временем отмены — например, за 30 минут до начала сеанса
— далее, если пользователь оплатил бронирование, мы его уже не отменяем вплоть до возврата билета.

Для этого потребуется несколько доработать схему.
Вместо Client_id нужно иметь поле Booking_id, которое показывает в табличку Booking — потому, что люди, как правило, покупают билеты пачкой, а не по одному.
В Booking добавляем поле Expiration, и имеем отдельный процесс, который делает Delete from SeatBooking where Expiration < Now() ежеминутно (или чаще, если нагрузка высокая).
Чтобы не нарушить инвариант "в одном бронировании могут быть места только на один сеанс", делаем композитный FK (booking_id, show_id) references Booking(id, show_id) on delete cascade
Готовим наши запросы:
1. Смотрим на схему заполнения зала: select seat_id from SeatBooking where show_id = @show_id
2.1. Пользователь начинает выбор мест: Insert into Booking(Show_id, Expiration, Status) values(@show_id, DateAdd(Second, 300, Now()), 'temporary') returning booking_id
2.2. Пользователь выбрал место:
  insert into SeatBooking(seat_id, booking_id) values (@seat_id, @booking_id)
  update Booking set expiration = DateAdd(Second, 300, Now()) where id = @booking_id

2.3. Пользователь отменил выбор места:
  delete from SeatBooking where seat_id = @seat_id and booking_id = @booking_id
  update Booking set expiration = DateAdd(Second, 300, Now()) where id = @booking_id

2.4. Пользователь подтвердил бронирование:
  update Booking set expiration = DateAdd(Minute, -30, @show_start), client=@client_id, status = 'confirmed' where id = @booking_id

2.5. Пользователь оплатил бронирование:
  update Booking set expiration = null, client=@client_id, status = 'paid' where id = @booking_id


Индексы нужны по:
SeatBooking(show_id, seat_id) — PK
SeatBooking(booking_id, show_id) — для удаления по FK


Booking(id) — для unique constraint
Booking(id, show_id) — PK
Booking(Expiration) — для удаления истекающих броней
Booking(client_id) — для истории бронирования клиента
Booking(show_id) — для поиска бронирований на конкретный сеанс
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Отредактировано 09.07.2021 4:42 Sinclair . Предыдущая версия . Еще …
Отредактировано 09.07.2021 4:42 Sinclair . Предыдущая версия .
Отредактировано 09.07.2021 4:42 Sinclair . Предыдущая версия .
Отредактировано 09.07.2021 4:41 Sinclair . Предыдущая версия .
Отредактировано 09.07.2021 4:41 Sinclair . Предыдущая версия .
Re: Система бронирования кинотеатров - дизайн БД
От: Qulac Россия  
Дата: 08.07.21 16:18
Оценка: :)
Здравствуйте, dglaurung, Вы писали:

D>Допустим нужно сделать систему бронирования кинотеатров, примерная схема такая


D>Client: кто бронировал

D>SeatBooking: таблица связывающая место-клиент-сеанс
D>Seat: места (IS_BOOKED не используется атрибут)
D>Show: сеанс

D>Пусть пользователи могут бронировать много мест на много сеансов.


D>Как лучше всего(производительность) сделать так, чтобы паралелльные транзакции не сделали пересекающиеся бронирования на одно и тоже место в одном и том же сеансе?

D>Менять схему можно (и нужно).

D>Заранее спс!


1. Свой менеджер блокировок. Преимущество — просто, но необходимо решить как хранить блокировки и есть вероятность по ошибке словить дедлок,так как блокировки придётся накладывать в ручную при обращении к бд. Тут предпочтительно использовать блокировки с низкой степенью детализации.
2. Свой менеджер транзакций. Сложно, поэтому отпадает.
3. Бд это не только поддержка транзакций но и возможность восстановления после сбоя в согласованном состоянии. Что бы обеспечить в самодельной бд такое поведение нужно кучу чего написать, хотя есть более простой способ: бд лежит в памяти, а лог пишутся все транзакции, при включении это транзакции(зафиксированные) прогоняются заново для заполнения бд.
Программа – это мысли спрессованные в код
Отредактировано 08.07.2021 16:21 Qulac . Предыдущая версия .
Re[2]: Система бронирования кинотеатров - дизайн БД
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 09.07.21 04:48
Оценка:
Здравствуйте, Qulac, Вы писали:

Q>1. Свой менеджер блокировок. Преимущество — просто, но необходимо решить как хранить блокировки и есть вероятность по ошибке словить дедлок,так как блокировки придётся накладывать в ручную при обращении к бд. Тут предпочтительно использовать блокировки с низкой степенью детализации.

Q>2. Свой менеджер транзакций. Сложно, поэтому отпадает.
Q>3. Бд это не только поддержка транзакций но и возможность восстановления после сбоя в согласованном состоянии. Что бы обеспечить в самодельной бд такое поведение нужно кучу чего написать, хотя есть более простой способ: бд лежит в памяти, а лог пишутся все транзакции, при включении это транзакции(зафиксированные) прогоняются заново для заполнения бд.
При всём уважении, коллега — вы описываете способ потратить много времени и сил на велосипедостроение.
Свой менеджер блокировок с поведением лучше, чем у промышленной RDBMS, будет весьма нетривиально реализовать.
Свою система Undo/Redo журналирования — тоже.
Это кажется простым, но на деле реализовать всё без багов не так просто, как кажется.
При этом мы говорим о базе данных с объёмами в жалкие десятки миллионов строк — тут вообще нет повода вылезать из стандартных решений. Я бы понял, если бы надо было уметь поддерживать 10k запросов в секунду на миллиарде комбинаций сеанс/место, и при этом иметь SLA в 300мс на любой запрос.
А описанная задачка — это ж лабораторная по курсу "Базы данных" для непрофильного факультета. У меня ровно это (ну, со скидками при приёме заданий) делали детишки на потоке "бизнес-информатика" экономфака НГУ.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[3]: Система бронирования кинотеатров - дизайн БД
От: Qulac Россия  
Дата: 09.07.21 09:16
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Qulac, Вы писали:


Q>>1. Свой менеджер блокировок. Преимущество — просто, но необходимо решить как хранить блокировки и есть вероятность по ошибке словить дедлок,так как блокировки придётся накладывать в ручную при обращении к бд. Тут предпочтительно использовать блокировки с низкой степенью детализации.

Q>>2. Свой менеджер транзакций. Сложно, поэтому отпадает.
Q>>3. Бд это не только поддержка транзакций но и возможность восстановления после сбоя в согласованном состоянии. Что бы обеспечить в самодельной бд такое поведение нужно кучу чего написать, хотя есть более простой способ: бд лежит в памяти, а лог пишутся все транзакции, при включении это транзакции(зафиксированные) прогоняются заново для заполнения бд.
S>При всём уважении, коллега — вы описываете способ потратить много времени и сил на велосипедостроение.
S>Свой менеджер блокировок с поведением лучше, чем у промышленной RDBMS, будет весьма нетривиально реализовать.
S>Свою система Undo/Redo журналирования — тоже.
S>Это кажется простым, но на деле реализовать всё без багов не так просто, как кажется.
S>При этом мы говорим о базе данных с объёмами в жалкие десятки миллионов строк — тут вообще нет повода вылезать из стандартных решений. Я бы понял, если бы надо было уметь поддерживать 10k запросов в секунду на миллиарде комбинаций сеанс/место, и при этом иметь SLA в 300мс на любой запрос.
S>А описанная задачка — это ж лабораторная по курсу "Базы данных" для непрофильного факультета. У меня ровно это (ну, со скидками при приёме заданий) делали детишки на потоке "бизнес-информатика" экономфака НГУ.

Коллега, это был ответ на вопрос: Что можно сделать, если база данных не поддерживает транзакции? Или за использование другой бд увольняют, расстреливают и т.д. но сделать все равно надо.
Программа – это мысли спрессованные в код
Re[4]: Система бронирования кинотеатров - дизайн БД
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.07.21 09:47
Оценка:
Здравствуйте, Qulac, Вы писали:

Q>Коллега, это был ответ на вопрос: Что можно сделать, если база данных не поддерживает транзакции? Или за использование другой бд увольняют, расстреливают и т.д. но сделать все равно надо.


А кто сказал что увольняют и расстрливают?
Мы работаем в бизнес-среде, где рулят сроки и затраты. Если у вас база не поддерживает транзакции, то реализацию бронирования дешевле и быстрее сделать если взять базу, поддерживующую транзакции.
Re[4]: Система бронирования кинотеатров - дизайн БД
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 09.07.21 13:24
Оценка:
Здравствуйте, Qulac, Вы писали:
Q>Коллега, это был ответ на вопрос: Что можно сделать, если база данных не поддерживает транзакции? Или за использование другой бд увольняют, расстреливают и т.д. но сделать все равно надо.
Ну, в таком виде — да, согласен. Нужно брать учебник по разработке БД, и документацию по предполагаемой платформе. См. тж. https://danluu.com/file-consistency/
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.