ThunderCat, т.е. вполне себе можно нормализовать структуру в вордпрессе? Фраза про смешно была не в смысле что это невозможно, а в том, что в вордпрессе мало кто так делает? Ок, тогда понял вас, спасибо.
ThunderCat, понятное дело, что вариант плохой, но делать то что? Нормализовывать вы пишите смешно, но именно это и предлагаете.
Индексы не панацея, не всегда в таблице миллионы данных, а фуллскан может быть очень быстрым на нескольких десятках тысяч, т.к. просмотреть последовательно все страницы проще, чем бегать по индексу и выбирать по id каждую строчку. Да и оптимизатор в любой СУБД далеко не идеален, и ошибается он достаточно часто. Но, конечно, можно забить на эти "мелочи" и делать всегда стандартно, выбирая не лучший вариант, но работать будет.
ThunderCat, отличное описание, но это и так понятно, мой вопрос был в другом, если это не вордпресс сделал, значит плагин, но даже так, значит в плагине должны быть инструменты для десериализации и подготовки объекта в адекватном виде. И, тогда этим инструментом и надо воспользоваться. Да, придется забрать все записи, но они хотя бы будут уже в адекватном виде, и автор сможет по ним искать. Быть может их не так много, и автору этого будет вполне достаточно.
Не говоря уже о том, что "полный прямой перебор всех записей, минуя индексы бд" не всегда худший сценарий, а бывает, что наилучший. Проблема указанных запросов не в этом, а в использовании функций regexp или like, вот они действительно сильно замедлят фильтрацию.
Пока звучит как "в нашей микросервисной архитектуре мало сервисов и мы решили запилить еще". Т.к. непонятно что это за сервис и с чего он вдруг понадобился, как это все связано с хранением в других сервисах и т.п. Быть может это какая-то бессмысленная хрень, а может это чтото вроде DWH, но текущего описания для понимания совсем недостаточно.
ThunderCat, дада, добродушный смех на Тостере. Я честно хз, как там wordpress делает, но логично предположить тогда, что автор просто не так как нужно получает данные. Раз ему они приходят сырые, а не уже обработанные. Тут то бы кто подсказал.
Zailox, разумеется либо-либо, загузчик не может передать управление сразу 2м процессам. Используйте openrc как init, и в нем запускайте свой скрипт, как IvanU7n и написал. Openrc судя по доке и inittab и еще куча конфигов есть.
Shimpanze, я про то, что пока неизвестна задача, может и не так, и не это нужно.
Из предыдущей задачи, я так понял, нужно просто знать входит ли значение в массив. Для этого достаточно функции in_array, без всякого преобразования массива.
И только если она будет долго отрабатывать, и есть время на преобразование массива, тогда можно использовать хеш-таблицу, но здесь лучше сделать массив вида: [ 'foo'=>1, 'bar'=>1, ... ], и по нему проверять только существование ключа через array_key_exists.
Shimpanze, ну вы сами прикиньте, вместо того, чтобы работать напрямую с массивом, вы используете прослойку в виде объекта. Соответственно гораздо больше памяти, и медленней.
Михаил Р., кому как, если не занимаетесь ежедневно перехватом и модернизацией запросов по разным протоколам, то универсальный инструмент вроде Fiddler не особо то и нужен, и узко специализированное решение будет проще.
Александр Вялых, извиняюсь, если ввел в заблуждение, проверил, да, вы и alexalexes правы, еще в 7ке zval перетащили в bucket, а bucket в arData. А я то считал, что как раньше данные php-шного массива лежат отдельно. А так, у нас один сишный массив на который ссылается хештаблица, и прям в нем лежит zval (понятно, что zval не обязательно уже данные, но все же).
Т.е. при rehash, необходимо перестроить хештаблицу и не просто массив с указателями, а массив со сложной структурой. Одно дело скопировать массив с интами, а другое дело с структурой, где только интов целая гора. Но, видно это меньшее из зол.
PHP не поддерживает многопоточность. Есть несколько методов её эмуляции.
Можно помучать Яндекс запросом и что-то почерпнуть для себя.
Вы пишите, что нет многопоточности, и даете ссылку как использовать многопоточность. И это не эмуляция, это реальные потоки.
Другое дело, что применение потоков не нашло поддержки, и таже библиотека pthreads уже долгое время не поддерживается.
alexalexes, а вы про это, ну не совсем так. Сишные массивы, про которые вы пишите, фиксированного размера и при необходимости их расширения придется создавать новый и заполнять его - разумеется это очень дорого. PHP-стандартные массивы устроены совершенно по-другому, копирование данных при их расширении не нужно, поэтому в php - расширение проходит дешево. Да, нет гарантии, что любое добавление элемента выполнится за одно и тоже минимальное время, как вы правильно заметили, некоторые добавления происходят дольше - в этих случаях идет перестройка хеш-таблицы, да, это относительно не быстро на больших таблицах, но и не провал производительности как было бы при пересоздании всего массива.