5 страниц обсуждений и никто не удосужился выяснить что это за система. А это не про сверстать сайтик. Ну понятно, откуда тут 16 баксов на посмотреть, когда мечта - найти хостинг за доллар)))
Именно поэтому я в названии написал "вебмастер" - в кавычках))) И они стройными рядами побежали отмечаться в теме и доказывать... а непонятно что даже. Не попытавшись даже понять, про что этот новый продукт)
Такое ощущение, что ты подключил интернет и по любой ерунде спешишь всех уведомить. Смотрите, я нашел новый инструмент! Я даже сумел его протестировать и запустить! Я молодец! Я вчера купил книгу по гоу, а сегодня узнал что такое докер и AI инструменты! Ура!
Ты забыл еще что-нибудь про джуна вкренчить
Чет я понаписал, понаписал в ответ аргументы. А теперь подумал, да какой смысл. Вы просили поделиться реальным опытом, я поделился. В ответ, начинается выдумывание гипотетически возможных проблем там, где они могут быть при любой технологии в силу кривых ручонок не специалистов и тех, кто просто напросто не знает другие технологии и не пробовал их на практике. Так что нет, спасибо, я пас в таком обсуждении, где разумное объяснение извращается до бессмысленного даже с точки зрения банальной логики.
Ваше право. В любом случае, спасибо за интересную дискуссию и что пошарили свой опыт. Лично мне было интересно и полезно.
Еще раз - это ВООБЩЕ не оптимальное решение! цль была - примерно оценить скорость чтения записи в сравнении с БД. И даже в таком варианте я признаю, что это сопоставимо. Если грамотно организовасть файловую систему, оптимизировать запись и чтение - это может быть быстрее, чем использовать БД. По крайней мере на небольших обьемах и сопоставимо по потреблению памяти. Так понятнее? Не в рамках вопроса пытаться написать оптимальный скрипт на базе кода который я привел - он не для этого был написан.
Я могу затереть занные в файле, могу многократно писать одно и тоже, могу удалить случайно файл, могу записать в него недопустимые символы и он перестанет читаться.... Все это нужно предусматривать. А при работе с SQL все это уже есть
Влияет. все то что я написал выше. Например достаточно тип поля сделать уникальным и я избавляюсь от необходимости каждый раз проверять, есть ли такой айди в таблице. Добавление в CONSTRAIN ONDELETE Cascade - упростит мне очистку базу от ненужных данных. То есть вся та работа, которяа должна будет сделана при работе с файлами при работе с БД УЖЕ реализована. Да банальный бэкап обычно есть на любом хостинге. Наверное, давно не работал но сомневаюсь, что я ошибаюсь. Так что никакой гипотетичности. Все это пройдено собственными граблями на проектах с месячными бюджетами за который этот форум можно купить десяток раз. Поэтому я так критически отношусь к идее работы с файлами в данном случае.
Ну почитайте весь тредможет и не нужен будет мой ответ? Вкратце - стало интересно проверить, наклепал - убедился что со временем поиска больших проблем не будет. Понятно, что это только как студенческая лаба, такое решение никогда в жизни в прод не пойдет. Чисто сравнить скорость.
Только вот тут каждый раз происходит чтение всего файла в память, а затем разбивка по пробелам?
В некоторых случаях эффективнее было бы читать построчно файл, где по 1 записи на строку.
Все верно, там можно оптимизировать, я не ставил такую цель. в моем случае файл содержащий сто тысяч слов занимает примерно 600 килобайт, при этом обрати внимание что в файл пишется все в одну строку -нет смысла читать построчно. Ну и размер файла можно ограничивать количеством айдишников в нем. Целью было проверить концепцию и я убедился что в данном случае скорость достаточно высока.
Остаются вопросы к надежности и удобству.
Я например могу накидать вам кучу трудностей, которые вы даже не отследите. Например, у вас будет бэкапится файл с ошибкой и вы даже не будете понимать что не так: просто он будет исключен их поиска, соответственно результат не нарантирован. А найти ошибку - ну я даже не представляю навскидку как.
При правильной организации БД это будет исключено. Роллбэк неправильно транзакции нарантирует что у вас БД будет D- устойчивой. Опять же правильно нстроенный бэкап позволяет хранить кучу версий базы на промежуток времени.
Про миллион не знаю, но есть у меня один "странный" проект, где файлов больше 400 000 (ну так исторически сложилось), сервер с ним бэкапится примерно за то же время, что и соседний, где файлов в 100 раз меньше, файл бэкапа не раздут.
Понятно, до этой части я не дошел. Проверю в моем случае как только перепишу скрипт по принципу 1 айпишник - 1 файл.
А можно поинтересоваться - что значит бэкапить сервер? Что вы именно там бэкапите если базы нет? Имеете ввиду вот эти 400 тыщ?
такой вариант обсуждался. Я пока реализовал альтернативный. Высказывались опасения - как себя будет вести файловая система с миллионом файлов, насколько легко это все будет забэкапить. Поделитесь опытом.
Не все, разбивается на батчи по первым двум цифрам например и потом поиск идет только в соответсвующем файле
Не могу остановиться, так заинтересовался этой темой. По итогу написал себе скрипт, который делает поиск по файлу значений. Конечно все условно, поставил следующие лимиты. Адрес - 5-ти значное число. Храниться в
в файле значения неотсортированы. Пример скрипта на пайтона -
import osimport randomimport timefrom functools import wrapsdef timer(func): """ Return calc time of execution wrapped function""" @wraps(func) def wrapper(self, *args, **kwargs): start = time.time() result = func(self, *args, **kwargs) print(f"Execution time: {time.time() - start}") return result return wrapperclass SimpleFinder: def __init__(self): pass def add_ip(self): name = random.randint(40000, 49999) # name = 49342 print(f"Function started. got Ip: {name}") file_name = self.get_filename(name) if self._if_exist(file_name): # print(f"File {file_name} exists") self.add_butch(file_name, name) else: # print(f"File {file_name} does not exists") self.create_butch(file_name, name) def get_filename(self, name): first_name = str(int(name / 10000)) return "".join((first_name, "0000")) def _if_exist(self, filename): files_list = (os.listdir("file_finder/storage")) if filename in files_list: return True return False def create_butch(self, file_name, name): with open(f"file_finder/storage/{file_name}", "w+") as f: f.write(str(name)) f.write(" ") def add_butch(self, file_name, name): with open(f"file_finder/storage/{file_name}", "a+") as f: f.write(str(name)) f.write(" ") @timer def find_ip(self, name): filename = self.get_filename(name) if filename: print(f"Found file {filename} for checking ip {name}") with open(f"file_finder/storage/{filename}") as f: data_ip = f.read() if data_ip: ip_list = data_ip.split(' ') print(f"Count of records: {len(ip_list)}") if str(name) in ip_list: print(f"This ip({name}) was blocked for download") return print(f"This ip({name}) can be download!!!")if __name__ == "__main__": # res = SimpleFinder() # res.add_ip() print(timer.__doc__) print("="*120) print("Start script") # for i in range(100000): # res = SimpleFinder() # res.add_ip() # SimpleFinder().add_ip() res = SimpleFinder().find_ip(49342)
Результат выполнения для поиска по файлу с примерно полмиллиона записей:
Start scriptFound file 40000 for checking ip 49342Count of records: 433209This ip(49342) was blocked for downloadExecution time: 0.04430103302001953
Это локально, без всяких HTTP запросов, на 4-х ядерном core i5 10gen 16RAMМне кажется, сопоставимо со скоростью запроса в БД. Может и имеет место быть такой подход