Какое решение для базы данных вы предложите для конкурентной продажи билетов онлайн - PullRequest
4 голосов
/ 01 марта 2011

Можете ли вы дать мне предложение дизайна базы данных?

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

  • если у меня есть счетчик оставленных билетов на каждое событие, в этом поле будет больше обновлений (блокировка), но я легко найду, сколько осталось билетов
  • если я сгенерирую билеты на каждое мероприятие заранее, будет сложно узнать, сколько осталось билетов

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

Может быть, резервирование также должно выполняться в асинхронном режиме?

Нужно ли использовать базу данных отношений (MySQL, Postgres) или базу данных отношений (MongoDB)?

Я планирую использовать серверы AWS EC2, чтобы я мог запускать больше серверов, если они мне нужны.

Я слышал, что "реляционные базы данных не масштабируются", но я думаю, что они мне нужны, потому что они имеют транзакции и согласованность данных, которые мне понадобятся при работе с определенным количеством заявок, я прав или нет?

Знаете ли вы какие-нибудь ресурсы в интернете для подобных тем?

Ответы [ 4 ]

5 голосов
/ 01 марта 2011

Если вы продаете 100 000 билетов за 5 минут, вам нужна база данных, которая может обрабатывать не менее 333 транзакций в секунду.Почти любая СУБД на новейшем оборудовании может обрабатывать такой объем трафика.

Если у вас не столь оптимальная схема базы данных и / или SQL, но это еще одна проблема.

3 голосов
/ 01 марта 2011

Перво-наперво: когда дело доходит до продажи товаров (электронной коммерции), вам действительно нужна поддержка транзакций. Это в основном исключает любой тип NoSQL-решений, таких как MongoDB или Cassandra.

Таким образом, вы должны использовать базу данных, которая поддерживает транзакции. MySQL делает, но не в каждом механизме хранения. Убедитесь, что вы используете InnoDB, а не MyISAM.

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

Почему транзакции? Потому что вам нужно выполнить кучу обновлений базы данных, и вы должны быть уверены, что все они выполнены успешно как одна атомарная операция. Например: 1) убедитесь, что билет доступен. 2) Уменьшить количество доступных билетов на один 3) обработать кредитную карту, получить одобрение 4) записать детали покупки в базу данных

Если какая-либо из операций не удалась, вы должны откатить предыдущие обновления. Например, если кредитная карта отклонена, необходимо откатить уменьшение доступного билета.

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

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

3 голосов
/ 01 марта 2011

Проверьте этот вопрос о выпуске инвентаря .

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

2 голосов
/ 01 марта 2011

Ваш вопрос кажется шире, чем дизайн базы данных.

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

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

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

...