GavriKos, я уже писал: количество нулей - 20%-30% в массе. Критической разницы нет.
Впрочем, это позволяет дешево отсечь хотя бы часть данных хотя бы в некоторых случаях - когда в одной из записей менее 95% от нулей другой. Хуже в любом случае не будет.
Да, спасибо, тут вы мне помогли.
Боюсь, тогда задача сократится до "где взять столько памяти". Умножаем десятки тысяч записей на тысячи нулей в них - получаем сотни миллионов записей в этой таблице. Добавляем к этому, что в подсчете нужны все нули не только новой строки, но и сравниваемой, только не сумма, а пересечение... впрочем, это еще можно оптимизировать. Но вот запрос-то к такой базе вы как себе представляете? SELECT record_id, COUNT(1) FROM positions WHERE number IN (тысячи чисел) GROUP BY record_id ? По стомиллионной таблице? Смело...
GavriKos, фокус как раз в том, что количество нулей в строке вообще не играет роли. У двух строк с одним-единственным нулем в одном и том же месте будет 100%, у двух с половиной нулей строго в начале и строго в конце - 0%.
Дмитрий Ярощук, нет, не постарался. Теперь читающий вообще не понимает, о чем речь. Какие-то желуди, какой-то стек и какое-то максимальное качество. Бред.
Wataru, а в чем тогда оптимизация? Только в хранении?
После которого мне нужно будет переводить данные из БД в числа для подсчетов, добавить еще две бинарные операции - и в результате все равно два раза пересчитывать каждый байт-символ. Я не уверен, что на Пыхе это не окажется медленнее того, что уже есть.
Такое ощущение, что код писал человек, а задание - робот.
Стоит перечитать этот выкидыш клавиатуры и по возможности вернуть ему растерянный в процессе набора смысл.
Wataru, да тут как не извращайся, а из бинарных данных нужен тернарный вывод - то, что пойдет только в числитель, то, что пойдет в числитель и знаменатель и то, что пойдет лесом. Без двух операций и подсчета результата в каждой не выйдет.
GavriKos, навскидку нулей - 20%-30%, и длинной чередой они не идут, перемежаются.
Я, в принципе, понял идею: заменить строки количествами ненулей до следующего нуля и в одном цикле двигать два счетчика, глядя на их совпадения. Боюсь только, данные перехеривают эту оптимизацию своей неподходящей структурой. Сравнений больше, а совпадения все равно случайны.
Кабы это была карта со сплошными участками "лес-море-горы" - да, можно было бы сравнивать и так. У меня же крестики, нолики и хренолики, в которых после нолика с вероятностью под 80% - ненолик.
Wataru, нет, мне нужно симметричное сходство. Нули только в искомой строке делают его асимметричным.
Нужно именно количество позиций, где хотя бы в одной из строк 0.
Руслан Федосеев, а там за меня эльфы будут проблемы решать?
Я вот сейчас с этим корчусь, однако сайт работает, посетители довольны, бизнес не теряет бабло.
На VPS без достаточного опыта администрирования я все проблемы огребу в одно лицо, и круглосуточной будет не ТП хостера, а моя собственная головная боль.
Общий процент нулей близок, разбросаны они довольно хаотично, так что по половине строки выводы делать в общем случае еще рано, разве что цифры совсем околонулевые. Но они, именно за счет хаотичности, совсем низкими и не будут - вероятность совпадения 1/3 же...
Оптимизация хранения, имхо, менее критична, чем затраты на разворачивание. Длина строк не больше нескольких килобайт, много не наэкономишь.
shurshur, проблема спорадическая, не чаще раза в день. А может и пару недель не замечаться.
Кроновыми задачами тоже столько не забьешь, там только две ежеминутные (шедулеры Лары и Битрикса, задачами отнюдь не заваленные), одна раз в 10 минут, одна раз в 2 часа (эти опрашивают внешние API и за ними я внимательно слежу) и несколько - раз в сутки, разбросанные по времени. С тем временем, когда они выполняются, никакой корреляции нет, наоборот, они отрабатывают вечером-ночью-утром, а SSH я теряю в рабочее время, когда ничего, кроме тех четырех, запускаться не должно.
Кирилл Гладиков, я бы предложил для начала переименовать таблицу user в auth, например, чтобы избавиться от ложных представлений. А user_data - в personal_data и не прибивать ее гвоздиком к регистрации или пользователю, а свободно связать через поле в той таблице, которой эти personal_data нужны. Так юзер, агент и клиент могут обладать одними и теми же персональными данными, раз они у вас могут быть одним человеком. Или агент сможет иметь их, не будучи пользователем вообще.
А зачем user - логике, отвечающей за авторизацию - поля first_name и last_name, никакого отношения к авторизации не имеющие и не являющиеся исключительной информацией этой сущности (раз у вас могут быть персональные данные без пользователя)? Отделите и не мучайтесь.
shurshur, ограничены не только обработчики PHP, но и системные процессы в целом, и именно в их ограничение (по утверждениям ТП) я упираюсь. Как раз PHP и Apache работают себе и не ломаются.
Не создается новый процесс shell при входе по SSH (соответственно, получаю отлуп) и не запускаются задачи CRON, тоже требующие нового процесса. Причем тянуться это может часа три - даже не представляю, что может забивать столько процессов в течение такого времени.
Причем я на этом сервере - пользователь, никаких изменений лимитов я выполнить просто физически не могу.
smilingcheater, вопрос как раз в том, КАК и ЧТО мне можно проверить в этой ситуации.
Я вон запустил PS из PHP-скрипта, не имея подключения. Он показал 14 процессов, а не 40.
И куда мне дальше копать?
Я, признаться, даже эти результаты не уверен, как трактовать. Что означают эти первые пять строчек со вчерашними скриптами, в частности. Если про 8.1 еще может оказаться, что на те сайты никто и не заходил с той поры, то сайт на php8.0 работает в режиме API для сервисов, к нему обращения идут хотя бы раз в минуту стабильно. А мне показывает его запросы суточной давности.
Впрочем, это позволяет дешево отсечь хотя бы часть данных хотя бы в некоторых случаях - когда в одной из записей менее 95% от нулей другой. Хуже в любом случае не будет.
Да, спасибо, тут вы мне помогли.