mayton2019, железо там нормальное, 980pro диск с 7гбс чтением, и процессор 5950 32 потока. Дамп не я делаю, а программист, возможно только снапшот и поможет.
mayton2019, с ext4, но не суть, вопрос в том, есть ли другие методы ускорения, кроме снапшотов, и если снапшот то в какой конфигурации он будет более надежен. Как я понимаю, снап можно делать и LVM и средствами ФС btrfs, ZFS(но ее на проксмоксе нет).
В общем, программист как-то решил задачу, утилита сперва переводит домены в цифры и потом вычисляет пересечение, в итоге кушает 32гб оперативы и работает сутки, но результат есть. Я бы наверно переводил в однобайтные символы юникода, так меньше символов понадобится, но и так работает.
mayton2019, пока это размышления, а цель, хочу небольшой поисковик сделать, который будет искать только по товарам и услугам, по сайтам которые привязаны к юрлицам, размышлял как лучше закодировать русские слова встречающиеся в товарах и услугах чтобы быстрее работало, например слово "автоматический выключатель" переводить в "1$g 3#h" получится с 51 байта на 7 а это уже в 7 раз и чем длиннее слово тем больше экономии, так можно весь коммерческий рунет (около 2млн сайтов) запихнуть в диск 980pro 2tb, храня только названия товаров и услуг, у меня уже есть рунет коммерческий с глубиной сканирования 2, и занимает он 3тб но там каждый сайт в зип архиве а он в 16 раз сживает страницу.
Остается самая главная проблема поисковиков, это ранжирование, но тут все просто мой другой проект b2book.ru поможет. Если кому интересно присоединиться, пишите в телегу https://t.me/evgenij_nef
А то решение что первым в голову пришло, оно не рабочее?
Берем первый домен, выводим все фразы по нему со списками доменов, считаем сколько каждый из доменов дублируется в троках, отсекаем те домены что по статистике встречаются редко (если домен А встречается 10000раз а домен Б 100 раз то зачем нам писать в базу домен Б). Далее пишем в базу те домены что остались, будет их 1000 - 10000 не больше. И так идем далее, и с каждым новым выводом доменов будет все меньше, так как предыдущий из базы нужно исключать так как по нему уже все подсчитано.
Тут главная идея чтобы читать не последовательно по списку, а брать все данные по домену и анализировать, и писать в базу только то что ценно.
mayton2019, 50 колонок, это 50 доменов по одной поисковой фразе, конечно можно это урезать и оставить лишь первые 10, но тогда данные будут неточные, так как есть сайты которые по выдаче на 5 странице, а по ценности для пользователя первичны. Могу скинуть ссылку на базу на почту, если интересно, но там много гб.
mayton2019, На первый взгляд задача проста, я так ее и поставил программисту, сам я не являюсь программистом. Таблица это база данных поисковой выдачи, 150млн фраз и по каждой фразе 50 доменов из выдачи. Задача найти похожие сайты по тематике. Поисковые фразы я убрал, они не нужны, сама строка говорит что гипотетически домены схожи, остается только статистику подсчитать.
Была идея идти другим путем: к каждому домену сформировать хэш из всех фраз что у него есть и сравнивать уже хеши.
Adamos, построчно выйдет очень много данных писать придется, а там часть пар нужно просто отбросить , и поэтому нужно выводить все по одному слову и обрабатывать.
Akina, одно слово встречается в 200к строк максимум, и пересекается в строках с 50к словами максимум, из которых 90% нет смысла даже писать так-как там пересечение незначительно по количеству.
Если говорить о точностях, то вы правы, но если оперировать вероятностями, то возможно по совокупности факторов предположить аффилированность, вот про совокупность этих факторов я и говорю. Как Fingerprint который состоит из многих параметров, каждый из которых не уникален но совокупность увеличивает точность.
John Smith, raid 10 всему голова, но избыточность большая, тут вопрос баланса надежности и затрат. Цена 1тб - 2тр, при условии что диск будет 8-14тб, а в рейде10 будет 4тр.
Как я понимаю программного контроллера нет, такой только самому писать.
"Не все. Потеряются только те, которые лежали на вышедшем из строя диске." - да, только те что на диске, но если запись последовательная то да этом диске будут все версии бекапов за неделю, а если будет запись на разные диски, то всегда останется более свежая версия.
John Smith, не всегда нужна такая избыточность, если бекап делается регулярно, например раз в час, и пишется на разные диски, то вероятность потери данных с одного диска не велика а если и потеряется то останутся данные на других, например 2 часовой давности.
Если диски 14тб и их объединить в RAID6 или 5 то писать бекапы оны будут до китайской пасхи, и при выходе из строя одного диска, на остальные ляжет такая нагрузка что не факт что не выйдет еще. RAID10 для бекапов слишком избыточен, тут я думаю нужно оперировать потребностями и вероятностями, чтобы выжать из железа максимум.