То есть правильно я понял - имя файла соответствует искомому айдишнику? Если я хочу проверить например айди 12345
что в вашей задаче ключ, и что его значение?в предложенном решении файл - ключ, содержимое - значение
Не боитесь что у вас inode закончатся в системе?
неа, я осознаю с чем работаю и (по-прежнему) больше боюсь кривой хеш-функции
Зачем вы пытаетесь изобрести SQLite?
Так пятница же :)
вычитать все имена файлов в нем - это уже IO операция. Потом для каждого имени получить MD и уже на его основе построить дерево?
не ВСЕ имена. В одном файле - одно значение. По сути, если значение не нужно (а нужны только ключи), то файл может быть пустым и даже не быть вообще - финальным будет также каталог
вот есть на диске условно 10 файлов. 1.txt, 2.txt, 3.txt ... мне нужно обратиться системными средствами к нужному каталогу
У нас есть 2 задачи:
1) внести имя файла в список2) узнать, есть ли такое имя файла в списке
в обоих случаях мы вычисляем хеш файла (пусть md5, хотя это не лучший вариант)
MD5 (1.txt) = dd7ec931179c4dcb6a8ffb8b8786d20bMD5 (2.txt) = c3d57eb88086a04b1e04d06a9b6188e5MD5 (3.txt) = 3d70dca5cadfff6563d95a05a0b2a0f3MD5 (10.txt) = ecd44780e3d8ebde70851f940606bc7e
то есть файлы лягут в каталоги, и если нам нужен только хеш, то даже файла создавать не будем
$ mkdir -p "./dd/7e/c9/31/17/9c/4d/cb/6a/8f/fb/8b/87/86/d2/0b"
1.txt:dd 7e c9 ... 0b2.txt:c3 d5 7e ... e53.txt:3d 70 dc ... f310.txt:ec d4 47 ... 7e
2) узнать, есть ли такое имя файла в списке (опять же вычисляем хеш и проверям есть ли такой каталог)
$ ls -1 "./dd/7e/c9/31/17/9c/4d/cb/6a/8f/fb/8b/87/86/d2/0b" && echo "exists" exists$ ls -1 "./dd/7e/c9/31/17/9c/4d/cb/6a/8f/fb/8b/87/86/d2/AA" || echo "not exists" ls: ./dd/7e/c9/31/17/9c/4d/cb/6a/8f/fb/8b/87/86/d2/AA: No such file or directory not exists
Мне кажется, ты счас описал NoSQL))) Ну примерно.
Ну там всё сложнее, тот же редис использует разные способы индексации, в некоторых случаях и классический B-Tree
Но правильно я понял - хэши имен файлов нужно где-то хранить?
Нет, хеши вычисляются в момент обращения (чтения/записи)
а что по скорости тут?
классический unordered map
Скорость будет зависеть от глубины ведра (односвязного списка), которая зависит от качества hash-функции определяющей ведро.
В данном случае стоит идти дальше и строить дерево, добиваясь, чтобы в одном файле было не более 1-й строки. Условно брать md5 от имени файла, разбивать по 2 символа и каждый следующий уровень размещать в подкаталоге.
а-ля: MD5 (FileName) = 1e621df39e053ff6bc7db7bb1c616cc1
1e 62 1d ... c1
так мы исключаем возможность "разбухания" каталога на любом уровне ограничив его 256-ю файлами, а доступ к элементу будет осуществляться одним системным вызовом fopen, без всяких последующих хождений по файлам (связным спискам). По сути скорость (за вычетом хеш-функции) обращения сравняется со скоростью открытия сокета для доступа к БД и на порядок обгонит работу с ней.
Применительно к данному коду (как пример неудачной хеш-функции), если большинство имён файлов будут начинаться с условного "aa" мы и получим проблему глубокого ведра.
Ну вот же - я всегда подозревал, что Набоков не сам писал свои тексты :)
Кусок моей статьи (100 % авторский контент)
- Human (4%) - AI (96%)
Автопереведёнка биографии гугл-транс
- Human (62%) - AI (38%)
Deepl
- Human (18%) - AI (82%)
Только что сгенерированное описание фрукта (gpt 3.5)
Там указано, что исключительные права на контент принадлежат пользователю, и это фактически означает, что можно использовать как угодно, в том числе в коммерции.
Нашёл, это было не в соглашении, а в их телеграм-канале.
Ну получается, что, да, на текущий момент можно использовать без подписи.
Ну с такой логикой даже с сайтов бесплатных картинок брать ничего нельзя, могут же поменять правила в будущем.
Да, это я уже проходил. Удалось договориться полюбовно.
Но с точки зрения логики последнее изменение более логичное.
Странно, не могу найти именно формулировку, о том, что можно использовать изображение в коммерческих целях при наличии ссылки, но уверен, что она была.
