[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Алгоритм работы авторизации на сайте
Страницы: 1, 2
ak167
Пишу свою систему доступа к сайту с помощью логина и пароля.
И я вот о чем подумал:

Предположим пользователь ввел логин и пароль, далее идет поиск этого логина в базе данных MySQL. В самой базе есть таблица "users" а в ней три ячейки: ID, login и pass.
sql-запрос осуществляется таким образом:
SELECT ID, login, pass FROM users WHERE login=$_POST['login']
Т.е. мы просто отбираем запись из БД, если логин в базе совпадает с логином, введенным пользователем.
Затем идет сравнение пароля с тем, которым в ячейке "pass" и с тем, который ввел пользователь. Если они совпадают, то вход осуществляется. Если нет - то не осуществляется.

По идее все должно работать. Однако, меня интересует СКОРОСТЬ работы такого скрипта! Что если в базе МИЛЛИОН пользователей? Будет ли он быстро работать?
Неужели это единственный алгоритм, по которому можно осуществить вход пользователя? Может есть какой-нибудь более быстрый способ и оптимальный способ, который будет работать эффективнее чем оператор WHERE login=$_POST['login'] ???????????????
sergeiss
Фига се, спросил... Другой способ ему подавай smile.gif wink.gif biggrin.gif А этот чем не нравится?

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

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
ak167
sergeiss, этот способ нравиться, но при большом числе юзеров, будут большие задержки, поэтому ищю другой способ.
А вот про индексы пожалуйста по-подробнее можешь рассказать? cool.gif
sergeiss
Цитата (ak167 @ 31.01.2010 - 15:49)
А вот про индексы пожалуйста по-подробнее можешь рассказать?


10 GO TO HELP
20 IF NOT CLEAR GO TO 10

А я тебе уже рассказал о них, вроде бы? Вот тут вот:
Цитата (sergeiss @ 31.01.2010 - 15:44)
На самом деле, для ускорения выборки используется такая хрень, как индексы. Которые позволяют очень быстро сделать такую выборку даже из миллионов записей.

Как их создать (синтаксис и всё остальное) - читай хэлп по своему типу БД.


_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
ak167
sergeiss, спасибо! Поищу хэлп по MySQL.
sergeiss
Гугл, яндекс... Поиск информации занимает несколько секунд, которые затрачиваются на ввод ключевых слов.
Например, как в этой ссылке

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
krasilich
ak167 И не нужно недооценивать сервер БД, он быстрей чем кажется=))
Особенно если правильно составлена структура таблиц и грамотно выполняются запросы.
Ice
Ну вот, пока писал тест, всё,что хотел сказать, уже за меня сказали=)
Кому интересно - тест, пока жив мой айпишник.
Таблица содержит 2 107 244 записи. Индексирована по ID. Выполняет поиск на соответствие за 0,46...0,48 секунд

_____________
Пишите код, исходя из того, что все программисты, которые будут сопровождать вашу программу, — склонные к насилию психопаты, знающие, где вы живёте.
twin
А вес таблицы?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Ice
Цитата (twin @ 31.01.2010 - 17:14)
А вес таблицы?

Вес таблицы по MySQL Administrator : 96,4 М.

_____________
Пишите код, исходя из того, что все программисты, которые будут сопровождать вашу программу, — склонные к насилию психопаты, знающие, где вы живёте.
ak167
Цитата (Ice @ 31.01.2010 - 12:33)
Ну вот, пока писал тест, всё,что хотел сказать, уже за меня сказали=)
Кому интересно - тест, пока жив мой айпишник.
Таблица содержит 2 107 244 записи. Индексирована по ID. Выполняет поиск на соответствие за 0,46...0,48 секунд

Ice, это потому что к ней идет всего 1 запрос. А если к примеру у тебя форум и в нем миллион пользователей и онлайн сидит 500 человек!
Я же имел ввиду не только запросы для авторизации, но и все остальное, например, поиск, вывод тем ну и т.д. и т.п. Все это будет создавать большую нагрузку, поэтому я искал другой вариант.
Nikitian
Грамотно разрабатывайте структуру таблиц и приложения для уменьшения количества запросов и упрощения этих самых запросов. Про индексы вам уже написали - читайте. Ещё пара предложений:
* Используйте limit. Если вам нужна только одна запись, то и не заставляйте базу искать то, чего там уже нет.
* Денормализация - тоже очень неплохая вещь для оптимизации количества выборок.
* Экономия на спичках - вместо поиска по строке используйте поиск по числу. Например + ещё одно поле int login_crc, где crc32-хэш логина. И запрос where login_crc="'.crcr32($login).'"

Вообще, сперва пишите, а уже потом занимайтесь оптимизацией.
sergeiss
Цитата (Nikitian @ 31.01.2010 - 21:04)
Вообще, сперва пишите, а уже потом занимайтесь оптимизацией.

Золотые слова smile.gif Проверил это на себе. Пока таблицы небольшие, все запросы просто летают. Но потом "вдруг" оказывается, что начинают тормозить. То, что раньше выполнялось едва ли не мгновенно, начинает по мере роста объема данных выполняться сначала секунды, потом десятки секунд, потом сотни секунд... Я говорю не про простые выборки, а про всякие там джойны и прочие навороченные запросы. И объемы данных измеряются уже миллионами записей в разных таблицах, из которых надо сделать выборки небольшого количества данных (и, чаще всего, обработать их по ходу дела).

Вот тогда, действительно, стОит всерьёз задуматься об оптимизации. Потому что раньше этого просто не прочувствуешь.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
Ice
Цитата (ak167 @ 31.01.2010 - 20:25)
Цитата (Ice @ 31.01.2010 - 12:33)
Ну вот, пока писал тест, всё,что хотел сказать, уже за меня сказали=)
Кому интересно - тест, пока жив мой айпишник.
Таблица содержит 2 107 244 записи. Индексирована по ID. Выполняет поиск на соответствие за 0,46...0,48 секунд

Ice, это потому что к ней идет всего 1 запрос. А если к примеру у тебя форум и в нем миллион пользователей и онлайн сидит 500 человек!
Я же имел ввиду не только запросы для авторизации, но и все остальное, например, поиск, вывод тем ну и т.д. и т.п. Все это будет создавать большую нагрузку, поэтому я искал другой вариант.

Да хоть 500 тыщ, как на мыле в Новый Год smile.gif База многопоточна. Запросы выполняются не друг за другом, а параллельно. Всё зависит от того, насколько прально и верно составлен сам запрос и органиизована сама таблица, как уже было сказано выше.

_____________
Пишите код, исходя из того, что все программисты, которые будут сопровождать вашу программу, — склонные к насилию психопаты, знающие, где вы живёте.
Nikitian
Цитата (Ice @ 31.01.2010 - 17:37)
Да хоть 500 тыщ, как на мыле в Новый Год smile.gif База многопоточна. Запросы выполняются не друг за другом, а параллельно. Всё зависит от того, насколько прально и верно составлен сам запрос и органиизована сама таблица, как уже было сказано выше.

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

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.