Sly32

Рейтинг
367
Регистрация
29.03.2012

5 страниц обсуждений и никто не удосужился выяснить что это за система. А это не про сверстать сайтик. Ну понятно, откуда тут 16 баксов на посмотреть, когда мечта - найти хостинг за доллар)))

Именно поэтому я в названии написал "вебмастер" - в кавычках))) И они стройными рядами побежали отмечаться в теме и доказывать... а непонятно что даже. Не попытавшись даже понять, про что этот новый продукт)

-= Serafim =- #:

Такое ощущение, что ты подключил интернет и по любой ерунде спешишь всех уведомить. Смотрите, я нашел новый инструмент! Я даже сумел его протестировать и запустить! Я молодец! Я вчера купил книгу по гоу, а сегодня узнал что такое докер и AI инструменты! Ура! 

Ты забыл еще что-нибудь про джуна вкренчить

Алеандр #:

Чет я понаписал, понаписал в ответ аргументы. А теперь подумал, да какой смысл. Вы просили поделиться реальным опытом, я поделился. В ответ, начинается выдумывание гипотетически возможных проблем там, где они могут быть при любой технологии в силу кривых ручонок не специалистов и тех, кто просто напросто не знает другие технологии и не пробовал их на практике. Так что нет, спасибо, я пас в таком обсуждении, где разумное объяснение извращается до бессмысленного даже с точки зрения банальной логики.

Ваше право. В любом случае, спасибо за интересную дискуссию и что пошарили свой опыт. Лично мне было интересно и полезно. 

Алеандр #:
Это не максимально эффективное решение, при том, что в структуре есть данные, которые нужно разделить - их правильнее разделять построчно, если уж их пишете все в один файл и читать так же построчно. Построчное чтение легче, проще, может быть завершено по результату найденного вхождения и не потребует постоянной загрузки всего файла в память с последующим циклом проверки этих данных.

Еще раз - это ВООБЩЕ не оптимальное решение! цль была - примерно оценить скорость чтения записи в сравнении с БД.  И даже в таком варианте я признаю, что это сопоставимо. Если грамотно организовасть файловую систему, оптимизировать запись и чтение - это может быть быстрее, чем использовать БД. По крайней мере на небольших обьемах и сопоставимо по потреблению памяти.  Так понятнее? Не в рамках вопроса пытаться написать оптимальный скрипт на базе кода который я привел - он не для этого был написан.

Алеандр #:
Какое отношение роллбэк имеет к статично размещенному в директории файлу?

Я могу затереть занные в файле, могу многократно писать одно и тоже, могу удалить случайно файл, могу записать в него недопустимые символы и он перестанет читаться.... Все это нужно предусматривать. А при работе с SQL все это уже есть

Алеандр #:
Организация правильности БД никаким образом не влияет на отказоустойчивость базы

Влияет. все то что я написал выше. Например достаточно тип поля сделать уникальным и я избавляюсь от необходимости каждый раз проверять, есть ли такой айди в таблице. Добавление в CONSTRAIN ONDELETE Cascade - упростит мне очистку базу от ненужных данных. То есть вся та работа, которяа должна будет сделана при работе с файлами при работе с БД УЖЕ реализована. Да банальный бэкап обычно есть на любом хостинге. Наверное, давно не работал но сомневаюсь, что я ошибаюсь. 
Так что никакой гипотетичности. Все это пройдено собственными граблями на проектах с месячными бюджетами за который этот форум можно купить десяток раз. Поэтому я так критически отношусь к идее работы с файлами  в данном случае. 

livetv #:
Что это Вас потянуло на концепцию пан-сам-склепал, а не на энтерпрайсные решения?

Ну почитайте весь тредможет и не нужен будет мой ответ? Вкратце - стало интересно проверить, наклепал - убедился что со временем поиска больших проблем не будет. Понятно, что это только как студенческая лаба, такое решение никогда в жизни в прод не пойдет. Чисто сравнить скорость. 

NoMoreContent #:

Только вот тут каждый раз происходит чтение всего файла в память, а затем разбивка по пробелам?

В некоторых случаях эффективнее было бы читать построчно файл, где по 1 записи на строку.

Все верно, там можно оптимизировать, я не ставил такую цель. в моем случае файл содержащий сто тысяч слов занимает примерно 600 килобайт, при этом обрати внимание что в файл пишется все в одну строку -нет смысла читать построчно.  Ну и размер файла можно ограничивать количеством айдишников в нем. Целью было проверить концепцию и я убедился что в данном случае скорость достаточно высока.

Остаются вопросы к надежности и удобству. 

Алеандр #:
С бэкапом так же проблем нет. Основная проблема тут в том, что, конечно, самих файлов много и будет значительно дольше собираться сам архив, но, кроме этого - никаких трудностей.

Я например могу накидать вам кучу трудностей, которые вы даже не отследите. Например, у вас будет бэкапится файл с ошибкой и вы даже не будете понимать что не так: просто он будет исключен их поиска, соответственно  результат не нарантирован. А найти ошибку - ну я даже не представляю навскидку как. 

При правильной организации БД это будет исключено. Роллбэк неправильно транзакции нарантирует что у вас БД будет  D-  устойчивой. Опять же правильно нстроенный бэкап позволяет хранить кучу версий базы на промежуток времени. 

Shelton724 #:

Про миллион не знаю, но есть у меня один "странный" проект, где файлов больше 400 000 (ну так исторически сложилось), сервер с ним бэкапится примерно за то же время, что и соседний, где файлов в 100 раз меньше, файл бэкапа не раздут.

Понятно, до этой части я не дошел. Проверю в моем случае как только перепишу скрипт по принципу 1 айпишник - 1 файл. 

А можно поинтересоваться - что значит бэкапить сервер? Что вы именно там бэкапите если базы нет? Имеете ввиду вот эти 400 тыщ?

Алеандр #:
Может быть, невнимательно прочитал все ответы, но по искомой задаче: зачем все id хранить в одном файле? У меня полно сайтов-самописов, с похожими задачами, решаю  элементарно - создаю файл с нужным id в структуре папок. Проверка на наличие этого id не требует каких-либо ресурсов, кроме того, чтобы проверить, есть ли такой файл в системе. Причем, если нужно зачем-то отмечать, от кого именно блок этого id - в сам файл записывать эту информацию. На проверку наличия файла это никак не влияет, а если нужна расширенная информация - она есть в самом файле. И, собственно, все.

такой вариант обсуждался. Я пока реализовал альтернативный. Высказывались опасения - как себя будет вести файловая система с миллионом файлов, насколько легко это все будет забэкапить. Поделитесь опытом.

Sly32 #:
все id хранить в одном файле?

Не все, разбивается на батчи по первым двум цифрам например и потом поиск идет только в соответсвующем файле

Не могу остановиться, так заинтересовался этой темой. По итогу написал себе скрипт, который делает поиск по файлу значений. Конечно все условно, поставил следующие лимиты. Адрес - 5-ти значное число. Храниться в 

в файле значения неотсортированы. Пример скрипта на пайтона -

import os
import random
import time
from functools import wraps


def 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 wrapper


class 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 script
Found file 40000 for checking ip 49342
Count of records: 433209
This ip(49342) was blocked for download
Execution time: 0.04430103302001953

Это локально, без всяких HTTP запросов, на 4-х ядерном core i5 10gen 16RAM
Мне кажется, сопоставимо со скоростью запроса в БД. Может и имеет место быть такой подход

Всего: 7117