Что быстрее поиск по файлу JSON в PHP или в базе посредством MySQL?

Question

[Alex]

Есть небольшая база с примерно 1000 записями. Нужно реализовать поиск AJAX (с моментальной выдачей результатов уже при наборе текста поиска) по одному полю `name`. Что будет лучше в плане скорости и нагрузки, сделать JSON файл и искать по нему при помощи PHP или же сделать FULLTEXT поле и искать уже по базе при помощи запроса в mysql?

Comments

[tukreb]

Быстрее будет в PostgreSQL, ОЧЕНЬ БЫСТРО (нано секунды, потому что там есть индексы). А в MySQL сделайте тесты и сравните с php, но в сравнение с PostgreSQL, будет медленнее в тысячи раз, а если точнее в 25000x раз.

[Константин]

tukreb, индексы и в мускуле есть.

[Константин]

Можно еще извращаться и сделать таблицу INMEMORY, и тогда будет очень быстро.

[tukreb]

Константин, там костыль, а не индекс https://dev.mysql.com/doc/refman/8.0/en/create-tab...

Indexing a Generated Column to Provide a JSON Column Index
As noted elsewhere, JSON columns cannot be indexed directly.

Быстрее PostgreSQL только специально заточенная под JSON база, да и то не факт, что тот же NoSQL БД сильно быстрее будут

[Дмитрий]

tukreb, PostgreSQL серебрянной пулей не является.

[Константин]

tukreb, я как понимаю вопрос тут стоял про файловую БД в JSON, или же какая то SQL бд. Тут не совсем про то чтоб в SQL положить json и по нему искать быстро. SQL конечно под это дело не совсем годен.

[Akina]

tukreb,

там костыль, а не индекс

Во-первых, откуда Вы взяли, что данные в MySQL хранятся в JSON. Автор об этом не говорит ни полслова. JSON звучал только и исключительно в варианте выноса всех данных на клиента.

Во-вторых, при чём тут вычисляемое поле. О нём также нет ни слова.

В третьих, поиск в момент набора текста - это поиск по подстроке. Вот тут Вы правы - PostgreSQL имеет типы индексов, позволяющие эффективно обрабатывать запросы такого типа. В отличие от MySQL, где столько же эффективные структуры придётся делать вручную (впрочем, это вполне возможно).

[Дмитрий]

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

Answer 1

[AUser0]

Быстрее будет выгрузить всю базу (без разницы из чего, из базы данных, или из JSON-файла) в Javascript нужной страницы, а потом именно Javascript ищет в этом всём выгруженном.

Comments

[Sanes]

1000 записей. Пользователи скажут спасибо.

[AUser0]

Тогда посчитайте объём выгрузки 1000 записей, а потом объём запросов/ответов на каждый введённый символ в строке поиска.

[Sanes]

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

Answer 2

[Vitsliputsli]

Если это обычный вопрос, что лучше, то храните в БД. Если реально пытаетесь выиграть несколько миллисекунд, то положите это все в redis.
В принципе, хранение в массиве php скорее всего тоже будет достаточно быстрым, при условии использования php-fpm и без json.
Если нужен поиск подстроки в строке, то на таких объемах тоже вполне быстро будет работать. На больших придется рассматривать, что-то вроде Elastic, т.к. СУБД это делают плохо, а MySQL очень плохо.

Answer 3

[Дмитрий]

Ну пока вы в php не реализуете какого нибудь daemon'a который будет держать в памяти содержимое файла, индексы и прочее - MySQL будет быстрее.

Comments

[Vitsliputsli]

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

[Дмитрий]

Vitsliputsli, php-fpm будет держать в памяти то что нужно ему, и сильное подозрение что никакой php-fpm не догадается считанный с диска json файл держать в памяти.

[Vitsliputsli]

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

[Дмитрий]

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

Есть вариант хранить данные уже в php массиве и запихнуть в предзагрузку. Ну это такое себе решение

[Vitsliputsli]

Дмитрий,

Есть вариант хранить данные уже в php массиве и запихнуть в предзагрузку

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

[Дмитрий]

Vitsliputsli, ага при каждом изменении файла перезапуск fpm?

Какие накладные расходы и чем они будут больше чем взаимодействие между nginx и php-fpm?

Answer 4

[Akina]

Что будет лучше в плане скорости и нагрузки

Определитесь. Или в приоритете скорость, или нагрузка. Но не то и другое одновременно.

Если приоритетна скорость - то данные должны быть предварительно (а не в момент поступления запроса) загружены в PHP и там проиндексированы, причём должен использоваться алгоритм индексирования, обеспечивающий высокую скорость поиска. Поскольку речь идёт о поиске по подстроке, то, вероятно, это суффиксное дерево или аналогичная индексирующая структура.

Если приоритетна нагрузка - то поиск следует производить средствами СУБД.

Answer 5

[rPman]

1000 записей скорее всего можно на клиента выгрузить и в javascript искать это будет самый быстрый вариант

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

Если говорить про конкретный случай, то загрузка дампа памяти из файла в готовом виде типа var_export, или лучше igbinary_serialize, будет самым эффективным способом

Но нужно понимать что если алгоритм поиска сложный, не просто по подстроке, то тут уже сам php будет давать накладные расходы

Answer 6

[mayton2019]

Недавно я смотрел доклад Бартунова (это один из ведущих разработчиков Postgres в РФ ), вобщем он хвастался, что на поисковых операциях по Json , pg быстрее чем MongoDb.

Answer 7

[Sanes]

MySQL конечно. За 1000 записей в браузере надо на Северный полюс ссылать.

Comments

[mayton2019]

Если это IndexedDb то я думаю можно. Границы возможного браузер подвинул в последнее время.
Если-бы мне 20 лет назад сказали что в браузере можно в 3D игры играть я-бы послал по адресу.
А сегодня мой ребенок играет в Unity-игры.

[Sanes]

mayton2019, не забывайте про мобилки и старые дешевые ноутбуки. Они сам браузер еле тянут. Вряд ли тут речь идёт про 1000 строк (заголовков).

[mayton2019]

Sanes, про мобилы я согласен. Аргумент. Я вообще противник нагрузки браузера. В моём представлении идеальный веб - это веб 1997 года. Когда всё было открыто. Когда сайт был ДОКУМЕНТОМ который можно было спокойно скачать с картинками и почитать в оффлайне. Когда были надежды на XML/RDF/Semantic Web.
Когда никто не противостоял роботам парсерам а наоборот выкладывал доки и базы в открытую. (Библиотека Мошкова).

Мобилы - это другая боль. Перегрев. Посадка аккумулятора. Вот полезные эффекты от 3д-мобильных игр. Вообще зачем играть в мобилу когда есть PS, Xbox. Я не понимаю.

Кстати детишки которые кликают и свайпят по гладкому экрану еще получат проф-заболевания суставов пальцев. Я получил такое от мышки. И готов спорить что просто этот вопрос еще не исследовали врачи.