Это хорошая практика - хранить сеанс аутентификации в базе данных?

Question

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

Как и в случае с мобильными телефонами, я хочу, чтобы пользователь находился в системе до тех пор, пока он не выберет выход , Я не использовал аутентификацию для сеансов в PHP.

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

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

Меня беспокоит, не станет ли это слишком медленным для системы, которая может иметь от 900 миллионов до 1,5 миллиардов пользователей, поскольку база данных будет иметь гораздо больше запросов и проверочных запросов в дополнение к обычному запросу, запрошенному пользователем. .

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

MysqlDatabase

Answer 1

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

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

 login_token   PK
 key           PK
 value

session_id - это значение сеанса login_token cook ie, большого трудно угадываемого случайного значения, которое ваше веб-приложение отправляет каждому вошедшему в систему пользователю. браузер. Например, если бы мой идентификатор пользователя был 100054, таблица сеанса могла бы содержать эти строки для меня.

 2EwZzPJdigVlrwtkFC5qoe97YE0EBddJ user_id    10054
 2EwZzPJdigVlrwtkFC5qoe97YE0EBddJ user_name  ojones

Зачем использовать этот дизайн ключа / значения? Он легко переносится на высокопроизводительную систему хранения ключей / значений, такую ​​как Redis. Это просто. И, чтобы выйти из системы и прервать мой сеанс, все, что вам нужно, это

     DELETE FROM session WHERE login_token = '2EwZzPJdigVlrwtkFC5qoe97YE0EBddJ'

(вы запросили отзыв о дизайне вашей таблицы. Вот мой: используйте значения INT или BIGINT для первичных ключей в таблицах, которые вы ожидаете становятся большими. Значения VARCHAR - плохой выбор для первичных ключей, поскольку поиск по индексу и вставка строк значительно медленнее. Значения CHAR (n) - немного лучший выбор, но все же медленнее, чем целые числа. Таблица session охватывает только пользователей, которые в настоящее время вошли в систему .)

И, повторю свой комментарий. Не тратьте слишком много времени сегодня на разработку новой системы, чтобы она могла работать в масштабе Twitter или Facebook (~ 10 ** 9 пользователей). На этом этапе вашего проекта вы не можете знать, где ваши узкие места в производительности будут ie, когда вы работаете в таком масштабе. И вам понадобится как минимум десять лет, чтобы получить такое количество пользователей. К тому времени над вашей системой будут работать сотни разработчиков. Если нанять их с умом, большинство из них будут умнее вас.

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