Если ему положить тест из пары десятков строк с дублями

внутри - они их корректно отбрасывает?-

v1 := crc32.ChecksumIEEE([]byte("ofslchic0687@aol.com:angels1")) v2 := crc32.ChecksumIEEE([]byte("chandler_underwood@yahoo.com:supersnow111")) fmt.Println(v1, v2) Вывод: 4124419246 4124419246

я там выше вариант предлагал

Линканите, не вижу

Это судьба) Тогда так и map[uint64]struct{} соответственно : tab := crc64.MakeTable(crc64.ISO) v1 := crc64.Checksum([]byte("ofslchic0687@aol.com:angels1"), tab) v2 := crc64.Checksum([]byte("chandler_underwood@yahoo.com:supersnow111"), tab) fmt.Printf("%08X\n", v1) fmt.Printf("%08X\n", v2)

Приветствую. На 235 млн. просто зависает, нагрузка на ЦП 30%, память используется почти под завязку. Считываю файл по одному, думал что, из-за того, что открываю много соединений, т.к. файлов много, но все равно зависает. Возможно, что map[uint64]struct{} рехешится, хотя я и использую map[uint64]bool, но вряд ли это многое поменяет. Что посоветуете ?

У вас 235 млн уникальных строк?

Да, map[uint64]bool отсеивает коллизии, а в []string я храню сами строки

и они не жмутся, тем же deflate, например?

Неа, не думал об этом, просто сырые строки

Зачем хранить строки? Это забивает память, после чего система начинает свопиться и жутко тормозит. Неуникальные надо сразу записывать в файл и в памяти не держать, в этом вся суть.

Такое на Spark решается достаточно просто, и даже если памяти меньше чем данных, он сам сбросит на диск. Это конечно не Go, и скорее всего это будет медленнее чем аккуратная ручная реализации, но проще, и потом можно заскейлить на несколько серверов, одной строкой получить поддержку S3, или сделать дополнительные манипуляции со строками

Да, я уже догадался вчера) Вроде записывает, но как-то странно ведёт себя программа, крашится иногда или просто зависает. Хотя бывает зависает, а бывает при бОльших объемах нормально

А что в краше пишет? У go очень вменяемая диагностика при панике по сравнению с другими языками.

Пока что не словил, как только через cmd открыл, то и вылетов не было 🤯

А с коллизиями как? Не возникает на таком хеше?

На 5млн точно нет, с большим кол-вом пока что не пробовал, как будет информация я напишу

Коллизии пока что не проверял. Другими способами было 225млн. и дальше было очень медленно. С этим методом 425млн. и дальше идет медленно очень, как и раньше, но вот это число почти в два раза увеличилось. Из-за чего замедление может быть? Это из-за рехеширования мапы?

А что у вас в валуях мапы? Строка или структура?

map[uint64]bool

Я думал может с гц чего, но в этом случае он должен скипать содержимое мапы

Нагрузка на ЦП 30%, оператива 95-98%

А своп как поживает?

Замедление из-за того, что мар стал очень большой, я не думаю что от этого можно избавиться без разработки альтернативных структур, заточенных специально под задачу. Например, использовать не 1 map, а слайс из 26 map, по первой букве строки. Тогда каждый будет в 10+ раз меньше и добавление в него на порядки быстрее. Но тут уж надо разбираться, что важнее - сложность алгоритма или время. У нас время не было критично, так как это часть большого процесса. Как часто оно будет запускаться?

Не часто будет запускаться

А сколько памяти оно на 425 млн сожрало? Я думаю, если скорость критична - стоит шардировать по первому символу строки или даже по паре. Выше написал как вариант.

12 ГБ вроде

Стоит попробовать шардировать, то есть сделать slice (даже array из 27 элементов, буквы + все остальное) из map и в каждый map класть только строки с этой буквы.

Да, в этом есть смысл, я уже пробовал, просто хз получится ли увеличить кол-во. Я попробую самые популярные библиотеки + этот метод и напишу

Там 5 строк кода лишних, с этого точно стоит начать.

Где?

Разбить один map на 27 штук по первой букве.

Я вам предлагал ключи пожать тем же deflate

uint64 сжать ?

А что вы с коллизиями делаете?

Я беру строку "e" и делаю key = crc64.Checksum([]byte(e), data.tab) Потом проверяю значение этого key в мапе, если false(то есть уникальная строка), то я отправляю в запись в выходной файл и ставлю ключу, true в мапе