Size: a a a

2020 November 30

А

Алексей in learn.java
Но если хранить не ипы, а диапазоны, то по мере парсинга памяти будет потребляться все меньше и меньше
источник

DK

Dmtr Klkv in learn.java
Ну ок, а если хранить 4 листа для каждой позиции в адресе. И дальше удалять только при совпадении во всех четырех?
источник

DK

Dmtr Klkv in learn.java
Тогда это 4 листа по 256 индексов.
источник

АК

Алексей Костырев... in learn.java
192,168,13,1
17,88,55,1
удаляй единицу из последнего листа. И второй адрес будет уже неуникальным.
источник

DK

Dmtr Klkv in learn.java
Чего?
источник

АК

Алексей Костырев... in learn.java
Ладно, не суть. Глупость сказал. Удалить из файла я строку не могу, а проверять по твоим листам... бред это, количество уникальных значений я так не посчитаю.
источник

А

Алексей in learn.java
Dmtr Klkv
Ну ок, а если хранить 4 листа для каждой позиции в адресе. И дальше удалять только при совпадении во всех четырех?
Не понял мысль
источник

АК

Алексей Костырев... in learn.java
Была идея сделать boolean[ 256 ] [256 ] [256 ] [256 ] и при нахождении соответствующей координаты фолс на тру менять... но тоже в пямять не лезет.
источник

АК

Алексей Костырев... in learn.java
Те же 16 ГБ минимально нужны.
источник

DK

Dmtr Klkv in learn.java
Алексей
Не понял мысль
Бред какой-то сморозил я...
источник

АК

Алексей Костырев... in learn.java
Пока единственно работающим алгоритмом видится посоветованный выше  external sorting, но оно  будет очень медленно работать, плюс еще 109 гигов на диске дополнительно скушает.
источник

DK

Dmtr Klkv in learn.java
Но мне кажется тут нужно подумать в сторону представления данных, например по позициям. А не брать весь адрес целиком. Может дерево строить.
источник

N

Nick in learn.java
Алексей Костырев
Те же 16 ГБ минимально нужны.
потому что вы булеан юзаете, используйте byte и будет уже 4Гб
источник

АК

Алексей Костырев... in learn.java
Вариант конечно...
источник

N

Nick in learn.java
а если напишите нормальную обертку над битами, то 4Гб ужимаются в 0.5Гб
источник

DC

Denis Chikanov in learn.java
Nick
потому что вы булеан юзаете, используйте byte и будет уже 4Гб
Решать эту задачу через урезание хэшсета/дерева только по памяти - так себе номер
источник

А

Алексей in learn.java
Nick
потому что вы булеан юзаете, используйте byte и будет уже 4Гб
С фига ли? Один ip никак не займет меньше 4 байт. Всего существует 4 "гигабайта" ипов по 4 байта
источник

DC

Denis Chikanov in learn.java
С учётом того, что айпишники тривиально маппятся в инты, мне на самом деле нравится идея с деревом диапазонов
источник

N

Nick in learn.java
Алексей
С фига ли? Один ip никак не займет меньше 4 байт. Всего существует 4 "гигабайта" ипов по 4 байта
хороший вопрос, многа букав:
рассмотрим множество всех ip адресов. Мощность 2*32. Эта мощность соответствует множеству 2*32 отдельных битов, если мы сгруппируем эти отдельные биты в байты по 8 штук, то получается 2*29 байт (512Мб) - звучит интересно и нам чтобы это использовать необходимо лишь одно - реализовать симметричное отображение (может забыл уже как зовется поправьте).
Отображением ip в конкретный бит будет преобразование ip в номер бита ip в инт, а инт уже и есть номер бита. И обратное - номер бита в ip.

Так что берем массив из 512кк байт, пишем небольшую обертку по преобразованию ip в два инта номер байта и номер бита в байте и обратно. И готово
источник

N

Nick in learn.java
суть в подходе, на чем реализовывать не имеет значения
источник