Wataru, 16 бит должны дать 65536 чисел. Памяти, конечно, немного, хотя Пых еще подожрет...
Да, в нем есть gmp_popcount. Но вызов функции - сам по себе дорогая операция.
В общем, наверное, об этом стоит подумать руками и посмотреть, что выйдет.
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, никакого отношения к авторизации не имеющие и не являющиеся исключительной информацией этой сущности (раз у вас могут быть персональные данные без пользователя)? Отделите и не мучайтесь.
Да, в нем есть gmp_popcount. Но вызов функции - сам по себе дорогая операция.
В общем, наверное, об этом стоит подумать руками и посмотреть, что выйдет.