Пароль не пересылается. Даже в виде хэша. Пересылается логин в виде хэша, а обратно отправляются пароли к нему из утечек, в виде хэшей с солью. И уже на сервере пользователя сравнивается с сохранёными паролями.
В теории это всё хорошо. А на практике - ты когда-нибудь пробовал отсортировать 2,5TB данных? Я пробовал и предпочитаю тот алгоритм, в котором сложнее всего напортачить, что бы не пришлось всё переделывать. И я измерял скорости. Узкое место - ввод вывод, так как на SSD скорость выше на порядки. И большая часть времени уходит именно на челночный бег головки по диску.
20 поисков в секунду на HDD это практически потолок, если не использовать зашкаливающие по сложности алгоритмы. 90% времени и так уходит на перемещение головки. При этом база у меня не одна, а разделена на 5 частей, в каждой из которых поиск происходит независимо, если слить будет 100 в секунду, но это сортировка 40 миллиардов строк, что долго. Про кэширование файла - у меня файл не один, а примерно 10000 во всех базах. Тоже в алфавитном порядке. Примерно то что ты и предложил с блоками. Все файлы одновременно ты не откроешь да и толку от этого ноль.
Спасибо за конструктивную критику. Моей целью было не только сделать быстрый поиск, но и упростить добавление новых данных. В случае с деревьями, это конечно, тоже удобно, но если где-то напортачить, то файл с данными потом фиг разберёшь. В этом плане текстовый файл гораздо надёжнее. Да и добавлять данные в базу можно просто закидывая отсортированные текстовики в папку, никакая индексация не нужна. Изучу позже тему деревьев, я мало пользовался ими на практике.
Кэш нужен, так как операционка кэширует большими блоками - по 64 или 256 килобайтов. А значит в кэш, который занимает не более 10% оперативки, влезет всего несколько десятков тысяч позиций. Если кэшировать только одну строку, это будет быстрее и влезут десятки миллионов позиций. Но для небольших файлов и кэша операционки хватит.
Про readahead - это скорее проблема, поищу потом способ это отключить. Но ты прав, можно и использовать в свою пользу. И кстати это ещё один аргумент за кэширование средствами программы.
А индекс по файлу у меня был не полнотекстовый, а именно бинарное дерево. Тест даже был не в пользу бинарного поиска, так как при поиске по файлу я использовал более сложный алгоритм, который искал не одно вхождение строки, а все, при этом без учёта регистра и с поддержкой лимита по количеству строк.
По поводу хранения в виде текста - в моём случае строки могут быть любой длины и varchar не подходит.
Это называется "read disturb". При частом чтении одной позиции заряд ячейки и соседний может измениться и что бы избежать потери данных, их приходится перезаписывать. Причём сразу блоком. Источник - уроки информатики. Не знаю, насколько это актуально для современных дисков, но решил не проверять.
Если интересно, то эта функция даёт только общий отчёт - сколько запросов найдено, а сколько нет. Я использовал её для класификации баз - какие уже добавлены, а какие нет, а так же собираюсь использовать это для бизнесовой части проекта - проверка всех аккаунтов какого-нибудь сайта на утечку. И что бы было безопасно, бот будет получать только логины в виде хэшей, искать по ним, хэшировать полученные пароли с той же солью, что и на сервере и в таком виде пересылать обратно.
Ты прав, у базы данных есть большое преимущество - накопление запросов. Если выполнять одновременно тысячи запросов, а не один, они выполнятся значительно быстрее. Но для справедливости тогда нужно реализовать эту же фичу и в бинарном поиске, что тоже возможно - достаточно при поиске делить запросы на две части - левую и правую и выполнять рекурсивный поиск с каждой из этих частей. Потом я, возможно, вроеду и такое сравнение.
C rb нельзя использовать readline и придётся писать велосипед. Ну а поиск золотым сечением это хорошая идея, спасибо за совет. Я его не тестировал на скорость, но насколько я помню, он актуален, когда много времени занимает сравнение элементов, а не чтение.
1) Да, mmap() может быть быстрее, но с ней достаточно просто напортачить, так как она может менять не только данные в файле, но и любые данные за его пределами. К тому же возникнут сложности при многопоточности (у меня она реализована). Но вариант тоже неплохой. 2) Я уточнял, что это актуально для больших строк. Замедление происходит при переходе из одного блока (8КБ кажется) в предыдущий. 3) Кэш операционки сохраняет очень большие фрагменты - по 64КБ или 256КБ обычно. Учитывая, что он занимает по умолчанию до 10% оперативки, максимально удасться кэшировать 250000 - 60000 позиций при 16GB оперативной памяти. Но фактически меньше, так как он постоянно очищается.
А если писать функцию кэширования самому, размер кэша одной позиции будет 0.1 Кб, а значит можно будет хранить десятки миллионов позиций и искать по ним быстрее. Я это сравнивал. Но ты прав, на небольших файлах и кэш операционки неплохо справляется.
Пароль не пересылается. Даже в виде хэша. Пересылается логин в виде хэша, а обратно отправляются пароли к нему из утечек, в виде хэшей с солью. И уже на сервере пользователя сравнивается с сохранёными паролями.
В теории это всё хорошо. А на практике - ты когда-нибудь пробовал отсортировать 2,5TB данных? Я пробовал и предпочитаю тот алгоритм, в котором сложнее всего напортачить, что бы не пришлось всё переделывать. И я измерял скорости. Узкое место - ввод вывод, так как на SSD скорость выше на порядки. И большая часть времени уходит именно на челночный бег головки по диску.
Опиской. Да, я использую SQLite.
20 поисков в секунду на HDD это практически потолок, если не использовать зашкаливающие по сложности алгоритмы. 90% времени и так уходит на перемещение головки. При этом база у меня не одна, а разделена на 5 частей, в каждой из которых поиск происходит независимо, если слить будет 100 в секунду, но это сортировка 40 миллиардов строк, что долго.
Про кэширование файла - у меня файл не один, а примерно 10000 во всех базах. Тоже в алфавитном порядке. Примерно то что ты и предложил с блоками. Все файлы одновременно ты не откроешь да и толку от этого ноль.
Спасибо за конструктивную критику. Моей целью было не только сделать быстрый поиск, но и упростить добавление новых данных. В случае с деревьями, это конечно, тоже удобно, но если где-то напортачить, то файл с данными потом фиг разберёшь. В этом плане текстовый файл гораздо надёжнее. Да и добавлять данные в базу можно просто закидывая отсортированные текстовики в папку, никакая индексация не нужна. Изучу позже тему деревьев, я мало пользовался ими на практике.
Кэш нужен, так как операционка кэширует большими блоками - по 64 или 256 килобайтов. А значит в кэш, который занимает не более 10% оперативки, влезет всего несколько десятков тысяч позиций. Если кэшировать только одну строку, это будет быстрее и влезут десятки миллионов позиций. Но для небольших файлов и кэша операционки хватит.
Про readahead - это скорее проблема, поищу потом способ это отключить. Но ты прав, можно и использовать в свою пользу. И кстати это ещё один аргумент за кэширование средствами программы.
А индекс по файлу у меня был не полнотекстовый, а именно бинарное дерево. Тест даже был не в пользу бинарного поиска, так как при поиске по файлу я использовал более сложный алгоритм, который искал не одно вхождение строки, а все, при этом без учёта регистра и с поддержкой лимита по количеству строк.
По поводу хранения в виде текста - в моём случае строки могут быть любой длины и varchar не подходит.
Это называется "read disturb". При частом чтении одной позиции заряд ячейки и соседний может измениться и что бы избежать потери данных, их приходится перезаписывать. Причём сразу блоком. Источник - уроки информатики. Не знаю, насколько это актуально для современных дисков, но решил не проверять.
Если интересно, то эта функция даёт только общий отчёт - сколько запросов найдено, а сколько нет. Я использовал её для класификации баз - какие уже добавлены, а какие нет, а так же собираюсь использовать это для бизнесовой части проекта - проверка всех аккаунтов какого-нибудь сайта на утечку.
И что бы было безопасно, бот будет получать только логины в виде хэшей, искать по ним, хэшировать полученные пароли с той же солью, что и на сервере и в таком виде пересылать обратно.
Ты прав, у базы данных есть большое преимущество - накопление запросов. Если выполнять одновременно тысячи запросов, а не один, они выполнятся значительно быстрее.
Но для справедливости тогда нужно реализовать эту же фичу и в бинарном поиске, что тоже возможно - достаточно при поиске делить запросы на две части - левую и правую и выполнять рекурсивный поиск с каждой из этих частей.
Потом я, возможно, вроеду и такое сравнение.
C rb нельзя использовать readline и придётся писать велосипед. Ну а поиск золотым сечением это хорошая идея, спасибо за совет. Я его не тестировал на скорость, но насколько я помню, он актуален, когда много времени занимает сравнение элементов, а не чтение.
1) Да, mmap() может быть быстрее, но с ней достаточно просто напортачить, так как она может менять не только данные в файле, но и любые данные за его пределами. К тому же возникнут сложности при многопоточности (у меня она реализована). Но вариант тоже неплохой.
2) Я уточнял, что это актуально для больших строк. Замедление происходит при переходе из одного блока (8КБ кажется) в предыдущий.
3) Кэш операционки сохраняет очень большие фрагменты - по 64КБ или 256КБ обычно. Учитывая, что он занимает по умолчанию до 10% оперативки, максимально удасться кэшировать 250000 - 60000 позиций при 16GB оперативной памяти. Но фактически меньше, так как он постоянно очищается.
А если писать функцию кэширования самому, размер кэша одной позиции будет 0.1 Кб, а значит можно будет хранить десятки миллионов позиций и искать по ним быстрее.
Я это сравнивал. Но ты прав, на небольших файлах и кэш операционки неплохо справляется.