Скорость проверки наличия значения в массиве. Что быстрее?

Question

[DaBags]

Имеется:
1. Массив в 74 000+ значений
2. Одно значение

Как быстрее пройдет проверка на наличие значения в массиве если:
1. Массив загрузить в базу данных mysql
2. Массив загрузить в файл

Суть вопроса: При регистрации пользователя на сайте нужно проверять доменный адрес его почты (в базе содержатся домены временной/одноразовой почты) и сравнивать со списком. Как обработка пройдет быстрее и с минимум нагрузки?
Может можно как то проверить скорость при обоих вариантах? Не будет ли большой нагрузки на базу данных при переборе значений?

P.S. в будущем планируется добавление значений в массив.

Answer 1

[Максим Федоров]

в БД быстрее, чем в файле

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

нужно проверять доменный адрес его почты

Не будет ли большой нагрузки на базу данных при переборе значений?

Что за перебор значений? Поиск по значению — как раз НЕ перебор, а использование оптимизированных структур и обходов по ним, с индексом будет моментально, даже быстро будет если не 74тыс+, а 74млн+

Comments

[DaBags]

Что за перебор значений?

Возможно не так выразился, т.к. не силен в терминологии.
Например, имеется список адресов:
gmail.com
yandex.ru
mail.ru
rambler.ru

Пользователь вводит почту при регистрации, например: [e-mail]
Получаем адрес домена почты (все что после @ - mail.ru) и далее сравниваем есть ли mail.ru в списке

[Максим Федоров]

DaBags, доработал ответ, берите БД

[Дмитрий]

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

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

[Developer]

DaBags, если так важна работа с доменами, то имеет смысле в БД ввести дополнительное поле - domain, а адрес почты (левую часть) писать в другое поле

[FanatPHP]

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

В данном случае тебе не хватает опыта в понимании стандартных задач. У тебя в голове есть теория, заложенная в небольшой механический органчик, который выдает определенную мелодию по ключевому слову, "Когда не нужны реляционные отношение". Но реальная БД кроме обеспечения связей между таблицами умеет много других гитик. И поэтому даже если не нужны отношения, то всё равно будет быстрее.

[Дмитрий]

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

[FanatPHP]

Дмитрий, заметь, кроме тебя здесь все получили нужную им информацию. Возможно, проблема не в форуме ;-)

[Дмитрий]

FanatPHP, Еще одно такое же.

[DaBags]

Developer, Это требуется только на стадии регистрации/смены почты. Разделять поле с почтой на 2 в уже действующем проекте с 5к пользователей проблематично будет. Проще explode("@", $mail) и выполнить одну проверку

[Максим Федоров]

DaBags, все верно делаете

[Developer]

DaBags, разумеется, это надо делать на этапе регистрации. Даже странно, что возникли сомнения в этом.
Насчёт 5к в действующем проекте - вообще не проблема. Я и на бОльших данных (миллионы) менял структуру таблиц. Пишется простой скрипт (лучше на SQL), база приостанавливается в 4 часа ночи, когда юзеров минимум и таблица обновляется. Время - секунды, а то и быстрее

[DaBags]

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

[Developer]

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

[DaBags]

Developer, почитал, для этого у меня уже знаний не хватит, да и на данном этапе считаю что оно не нужно.

Answer 2

[Дмитрий]

Без разницы, главное чтобы значения были в массиве сортированы, а в базе индексированы. Тогда и там и там поиск будет происходить моментально. В массиве он естественно должен быть бинарным.

Comments

[Максим Федоров]

как в файле он будет моментальным? даже если отсортирован

[Дмитрий]

Максим Федоров, А как в базе он будет моментальным, если даже индексирован? Так и в файле.

[Максим Федоров]

Дмитрий, вы серьезно?

[Дмитрий]

Максим Федоров, В теме у человека просто список доменов, простой обычный список доменов. Там нет никаких реляций, ничего. В чем проблема в плане скорости прочитать отсортированный список из файла и бинарным поиском выяснить есть ли в нем нужное значение? Я могу чего-то не понимать, просто поясните.

[FanatPHP]

В чем проблема

в "прочитать"

[Дмитрий]

FanatPHP, А БД постоянно висит в памяти? Так же читается из файлов и так же кешируется при повторном обращении.

[FanatPHP]

А БД постоянно висит в памяти
надеюсь я удовлетворил твою тягу к ценной информации

[Дмитрий]

FanatPHP, Спасибо, я перепроверю данную информацию.

[FanatPHP]

Это правильно. Доверяй - но проверяй!

[Максим Федоров]

Дмитрий, не просто список, а очень большой список
а еще программа на PHP

то есть у нас не массив, а файл или БД, что как бы и спросил ТС, пусть обозвав "массив" данных массивом

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

[Максим Федоров]

aktuba, так

доступ к файлу !== доступ к файлу и поиск по нему БЕЗ написания структур, алгоритмов и прочего

[FanatPHP]

aktuba, Да, доступ к индексу в памяти по сокету быстрее чем **чтение файла в массив заново каждый раз**. Учи матчасть.

[FanatPHP]

aktuba, о загрузке

[FanatPHP]

aktuba, ну чтобы доказать всем, какой ты умный - да, опкеш и засирание памяти на пустом месте
а в реальной жизни ты все равно положишь в БД :)

[Максим Федоров]

aktuba,

в данном случае речь идёт о поиске по ключу в плоском массиве

Подождите, я немного не понимаю — есть файл со списокм доменов, вы его загрузили
Откуда O(1)? Или вы имеете в виду, что файл будет описывать массив PHP и домены будут в качестве ключей? И его загружать в память при работе? ну может быть... Хотя похоже на изыскания так себе, костылки какие-то, если учесть, что БД так и так будет скорее всего в проекте, да и писать код для изменения/удаления кажется сомнительным делом в такой ситуации

[Максим Федоров]

aktuba,

ну сохранили в php-файл в виде

return [
'mail.ru' => true
...
];

Вы считаете удобным добавлять/изменить такое содержимое?

[Максим Федоров]

aktuba, но подчеркну (в прошлом комменте тоже это отметил), что способ вполне допустимы при отсутствии и диком не желании ставить БД, можете описать в виде ответа

[FanatPHP]

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