Как Вы делаете запросы на поиск пользователя в базе данных? Насколько оптимально Вы используете ресурсы сервера? Пока база данных небольшая, эти вопросы будут для Вас совсем неактуальны. Но по мере роста файла БД и числа пользователей, которые одновременно совершают подобные запросы они, запросы, могут стать краеугольным камнем проектируемой системы.
Существуют несколько стереотипных приемов получить идентификатор пользователя:
1. «Натуральный»: Запросить ID по значению логина и пароля в таблице.
2. «Индексированный»: Предварительно осуществить индексацию полей логина и пароля.
3. «Суррогатный»: Сформировать суррогатный индекс по обоим полям.
4. «Хэшированный»: Преобразовать значение логина или логина и пароля в хэш, отобрать записи, соответствующие хешу, а затем из них выбрать записи по соответствующему логину и паролю. Разумеется, для данного метода необходимо сформировать поле со значением хэша, и проиндексировать его.
На больших Базах от Натурального лучше совсем отказаться, так как производительность проседает капитально. Его основное достоинство – простота запроса. Однако, преимущество весьма спорное, и зависит от самой СУБД и величины таблицы.
Индексированный и Суррогатный обеспечивают идеальные условия выполнения запроса, однако величина индекса составляет размеру самих полей логин и пароль. Кроме того, в некоторых СУБД индексироваться могут только поля, размер которых не превышает определенную величину, например 240 символов, в то время как действительное значение логина, в соответствии с международным стандартом на длину e-mail может существенно превышать это значение. Ну понятно, что найти уника имеющий адрес электронной почты состоящий из 300 символов сложно, однако, стандарт есть стандарт.
Хешированный метод имеет один недостаток: сложность в понимании того как им нужно пользоваться для новичка. В остальном – существенные преимущества: поскольку значение хэша является числом, то и индекс будет существенно компактней. К тому же, поисковые запросы по индексированным числовым полям осуществляются быстрее, чем по аналогичным символьным. Новички забывают так же тот факт, что разные строки могут возвращать одно и то же значение хэша, а значит использовать только хэш для идентификации пользователя недопустимо.
На форум Silverlight возникла необходимость в рассмотрении вопросов производительности, поскольку .Net генерирует разные значения хэша на разных версиях платформы. Если использовать хеш значение .Net то может оказаться выгодней использование Индексированного метода.
Чтоб разобраться с этим вопросом решено было провести эксперимент, который показывал бы производительность запросов для каждого из методов.
Справедливости ради нужно сказать, что «Суррогатный» метод использовался только для того, чтоб список эксперимента был полон.
Идея была в том, чтоб создать таблицу с большим числом записей и большим объемом данных, а затем воспользоваться каждым из методов для поиска идентификатора пользователя в начале, в середине и в конце таблицы.
Формат таблицы следующий:
PK Поле Тип
X ID INTEGER
HASH_FIELD BIGINT
LOG1 VARCHAR(100)
PASS1 VARCHAR(100)
LOG2 VARCHAR(100)
PASS2 VARCHAR(100)
LOG3 VARCHAR(100)
PASS3 VARCHAR(100)
Поля LOG1, LOG2, LOG3 были заполнены идентичными случайными символьными значениями. То же касалось полей PASS1, PASS2, PASS3. Значение символа находилось в пределах от 32 до 255 включительно. Всего было сгенерировано 1 миллион записей.
Поля LOG2 и PASS2 были проиндексированы отдельно. LOG3 и PASS3 – суррогатно.
Параметры плафтормы эксперимена:
ОС: Windows 2008, SP1 x64.
Железо: Intel Core2 Quad CPU 6600 2,40 Ghz, 8 Гиг.
СУБД: FireBird 2.1.
Размер файла базы: 1,29 ГБ (1 395 998 720 байт).
Для генерации хэш поля использовалась функция Hash (string) FireBird. Отметим, что в данной СУБД хэш имеет значение BigINT, а не INT как в .Net
Предполагалось получить три группы параметров на 10%, 50% и 90% записей таблицы (100-тысячная запись, 500-тысячная запись, 900 –тысячная запись), значения которых использовать для запросов по поиску идентификатора пользователя.
Однако, в самом начале эксперимента меня ждало некоторое разочарование… Очень хотелось построить красивые графики и показать эффективность каждого из методов. Минимальная дискретная величина доступная для статистики запроса составляет 1 миллисекунду. Но, большая часть запросов была выполнена быстрее!
Ниже привожу таблицу полученных результатов:
Метод Время запроса
10% 50% 90%
Natural 1с 888 мс 1с 888 мс 1s 887 мс
Индексированный 0 мс 0 мс 0 мс
Суррогатный 0 мс 0 мс 0 мс
Хэшированный 0 мс 0 мс 0 мс
Как видите, никаких существенных отличий в том, где расположена запись (в начале, конце, или середине таблицы не обнаружено). И в то же время, однозначно можно сделать вывод, что Натуральным методом лучше не пользоваться вовсе.
Несомненно радует то, что на таблицах с миллионом записей другие методы осуществляют поиск «мгновенно».
Коэффициент эффективности для всех индексов составил 0,000 000 999 999 997 475 242 708.
Выводы: Быстродействие запросов посредством хэш поля и строкового поля выявлены не были. Однако, Объем файла базы данных в случае использования индексирования текстовых полей возрастает в два раза. Таким образом, в случае использовании хэш поля, мы имеем значительно более компактную базу при идентичной производительности.
N.B.!: Не проводите таких экспериментах на рабочей базе, так как заливка данных занимает несколько часов!
Существуют несколько стереотипных приемов получить идентификатор пользователя:
1. «Натуральный»: Запросить ID по значению логина и пароля в таблице.
2. «Индексированный»: Предварительно осуществить индексацию полей логина и пароля.
3. «Суррогатный»: Сформировать суррогатный индекс по обоим полям.
4. «Хэшированный»: Преобразовать значение логина или логина и пароля в хэш, отобрать записи, соответствующие хешу, а затем из них выбрать записи по соответствующему логину и паролю. Разумеется, для данного метода необходимо сформировать поле со значением хэша, и проиндексировать его.
На больших Базах от Натурального лучше совсем отказаться, так как производительность проседает капитально. Его основное достоинство – простота запроса. Однако, преимущество весьма спорное, и зависит от самой СУБД и величины таблицы.
Индексированный и Суррогатный обеспечивают идеальные условия выполнения запроса, однако величина индекса составляет размеру самих полей логин и пароль. Кроме того, в некоторых СУБД индексироваться могут только поля, размер которых не превышает определенную величину, например 240 символов, в то время как действительное значение логина, в соответствии с международным стандартом на длину e-mail может существенно превышать это значение. Ну понятно, что найти уника имеющий адрес электронной почты состоящий из 300 символов сложно, однако, стандарт есть стандарт.
Хешированный метод имеет один недостаток: сложность в понимании того как им нужно пользоваться для новичка. В остальном – существенные преимущества: поскольку значение хэша является числом, то и индекс будет существенно компактней. К тому же, поисковые запросы по индексированным числовым полям осуществляются быстрее, чем по аналогичным символьным. Новички забывают так же тот факт, что разные строки могут возвращать одно и то же значение хэша, а значит использовать только хэш для идентификации пользователя недопустимо.
На форум Silverlight возникла необходимость в рассмотрении вопросов производительности, поскольку .Net генерирует разные значения хэша на разных версиях платформы. Если использовать хеш значение .Net то может оказаться выгодней использование Индексированного метода.
Чтоб разобраться с этим вопросом решено было провести эксперимент, который показывал бы производительность запросов для каждого из методов.
Справедливости ради нужно сказать, что «Суррогатный» метод использовался только для того, чтоб список эксперимента был полон.
Идея была в том, чтоб создать таблицу с большим числом записей и большим объемом данных, а затем воспользоваться каждым из методов для поиска идентификатора пользователя в начале, в середине и в конце таблицы.
Формат таблицы следующий:
PK Поле Тип
X ID INTEGER
HASH_FIELD BIGINT
LOG1 VARCHAR(100)
PASS1 VARCHAR(100)
LOG2 VARCHAR(100)
PASS2 VARCHAR(100)
LOG3 VARCHAR(100)
PASS3 VARCHAR(100)
Поля LOG1, LOG2, LOG3 были заполнены идентичными случайными символьными значениями. То же касалось полей PASS1, PASS2, PASS3. Значение символа находилось в пределах от 32 до 255 включительно. Всего было сгенерировано 1 миллион записей.
Поля LOG2 и PASS2 были проиндексированы отдельно. LOG3 и PASS3 – суррогатно.
Параметры плафтормы эксперимена:
ОС: Windows 2008, SP1 x64.
Железо: Intel Core2 Quad CPU 6600 2,40 Ghz, 8 Гиг.
СУБД: FireBird 2.1.
Размер файла базы: 1,29 ГБ (1 395 998 720 байт).
Для генерации хэш поля использовалась функция Hash (string) FireBird. Отметим, что в данной СУБД хэш имеет значение BigINT, а не INT как в .Net
Предполагалось получить три группы параметров на 10%, 50% и 90% записей таблицы (100-тысячная запись, 500-тысячная запись, 900 –тысячная запись), значения которых использовать для запросов по поиску идентификатора пользователя.
Однако, в самом начале эксперимента меня ждало некоторое разочарование… Очень хотелось построить красивые графики и показать эффективность каждого из методов. Минимальная дискретная величина доступная для статистики запроса составляет 1 миллисекунду. Но, большая часть запросов была выполнена быстрее!
Ниже привожу таблицу полученных результатов:
Метод Время запроса
10% 50% 90%
Natural 1с 888 мс 1с 888 мс 1s 887 мс
Индексированный 0 мс 0 мс 0 мс
Суррогатный 0 мс 0 мс 0 мс
Хэшированный 0 мс 0 мс 0 мс
Как видите, никаких существенных отличий в том, где расположена запись (в начале, конце, или середине таблицы не обнаружено). И в то же время, однозначно можно сделать вывод, что Натуральным методом лучше не пользоваться вовсе.
Несомненно радует то, что на таблицах с миллионом записей другие методы осуществляют поиск «мгновенно».
Коэффициент эффективности для всех индексов составил 0,000 000 999 999 997 475 242 708.
Выводы: Быстродействие запросов посредством хэш поля и строкового поля выявлены не были. Однако, Объем файла базы данных в случае использования индексирования текстовых полей возрастает в два раза. Таким образом, в случае использовании хэш поля, мы имеем значительно более компактную базу при идентичной производительности.
N.B.!: Не проводите таких экспериментах на рабочей базе, так как заливка данных занимает несколько часов!