Перед новым годом компании скидывали валюту, чтобы закрыть налоги. К весне курс может повыситься до 100
В биржу сейчас ежедневно на поддержание курса на бирже сливают валютных ценностей (в основном юани) на сумму 16,7 млрд рублей до конца месяца, потом в районе 15. Надолго хватит?
То есть правильно я понял - имя файла соответствует искомому айдишнику? Если я хочу проверить например айди 12345, я вычисляю хэш от него и пытаюсь на диске найти файл с соответствующим именем(хэшем)? А как формируется дерево? Или оно не нужно? Я думал так:
/base/ 10000 10001 10002 20000 20001 20001...
если мне прилетает айди 10010 - я его ищу в каталоге 10000если 22000 - ищу в каталоге 20000и так далее,Или все файлы в одном каталоге?
Тогда я не понимаю как это будет работать.вот есть на диске условно 10 файлов. 1.txt, 2.txt, 3.txt ... мне нужно обратиться системными средствами к нужному каталогу, вычитать все имена файлов в нем - это уже IO операция. Потом для каждого имени получить MD и уже на его основе построить дерево?
классический unordered map
Скорость будет зависеть от глубины ведра (односвязного списка), которая зависит от качества hash-функции определяющей ведро.
В данном случае стоит идти дальше и строить дерево, добиваясь, чтобы в одном файле было не более 1-й строки. Условно брать md5 от имени файла, разбивать по 2 символа и каждый следующий уровень размещать в подкаталоге.
а-ля: MD5 (FileName) = 1e621df39e053ff6bc7db7bb1c616cc1
так мы исключаем возможность "разбухания" каталога на любом уровне ограничив его 256-ю файлами, а доступ к элементу будет осуществляться одним системным вызовом fopen, без всяких последующих хождений по файлам (связным спискам). По сути скорость (за вычетом хеш-функции) обращения сравняется со скоростью открытия сокета для доступа к БД и на порядок обгонит работу с ней.
Мне кажется, ты счас описал NoSQL))) Ну примерно. Но правильно я понял - хэши имен файлов нужно где-то хранить? И тогда постоянно заботиться о целостности?
Естественно. Это не магия, просто готовая оболочка для работы. С кучей возможности. Можно конечно с файлами, но потом - хочу скорости - значит придумываем индексирование/хэшь, хочу параллельность - начинаем извращаться с одновременным доступом, хочу надежность - придумываем транзакции. По мне лучше потратить время продуктивнее. Я не могу годами писать мертворожденный фремфорк)))
Честно - если я для похожего кейса предложу клиенту такое решение - меня наверное уволят одним днем... Обычно мы приходим к тем, у кого такие костыли и чиним) Например работал с медициноской компанией, которая у всех на слуху была в ковидные времена - помогали им обработать сотни миллионов записей с геномами человека в экселе. Сецчас врач загружает результаты анализа, система анализирует и на основе статистики предлагает лекарства и лечение.
Ты, наверное первый, кто приводя пример кода сразу написал про тесты и про эксепшены! дважды респект)))Да, я про такое и говорил, находим файл по маске, открываем, читаем/пишем, закрываем.Вместо того чтобы в 2-х строчках открыть сессию с БД и сделать туда запрос)))
Для меня преимущества БД очевидны для эього кейса
К счастью, у меня таких нет)))
Хочешь сказать что копирование нескольких тысяч файлов будет быстрее?
А заказчик и не должен уметь все это делать - это работа разработчика, настроить все так, чтобы клиент даже не думал, что там внутри. С таким подходом он не сможет и забэкапить файлы. О каких больших обьемах ты говоришь - я не понимаю. По факту ТС работает со списками ID. Работая с БД это несколько запросов, очень простых. Примитивные транзакции. С файлами нужно продумать хорошенько иерархию. Типа 100000.txt хранит айдишники до 100000, 200000.txt - до 200000 и тд. То есть я так понимаю, скрипт должен работать с произвольными именами, сначала определять в каком файле искать, открывать его, проверять на соответствие...
Насчет надежности такого метода у меня тоже есть сомнения. Если файл открыт для чтения, а в это время в него будет писаться новый айдишник, что произойдет? У меня нет опыта в таком, а в базе я знаю как это будет работать. Достаточно использовать ACID совместимые БД.
а что по скорости тут?
Просто уточнил, нет придирок, может я не так прочитал)
Ну, в отличие от большинства местных графоманов, у тебя есть знания, вот мне и интересно стало уточнить. Все мы тут развлекаемся, но и учимся) По крайней мере некоторые.
Например? Применительно к задаче? При хранении большого обьема данных, при необходимости быстрого доступа, например по индексу, чем?
Я наверное не понял, Имеешь ввиду что SQLlite не реляционная?
Когда? Как-то все ответы не подтверждены.
Например, если ТС будет хранить данные в NoSQL DB like MongoDB, он получит самый быстрый доступ по хэшу обьекта, остальные способы не сравнятся. Но проиграют по памяти
Просто надо уметь есть))) Например Раклет - запах ужасный, но вкус просто божественный, когда его поджаришь на гриле, польешь им мясо или бутерброд - не оторваться. Или плесневелые сыры - не все они годяться чтобы сразу есть. Мы перестали заморачиваться с фондю - просто кидаешь кружочек жирного камамбера, полив его оливковым маслом с чесноком и рядом порезаный багет французский - под сухое Примитиво Пугла и фильм вечером самое то. А пицца с бурратой? Но вот сыры типа Горгонзолы - действительно гадость для меня.
