Sly32

Рейтинг
370
Регистрация
29.03.2012
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
Мне кажется, сопоставимо со скоростью запроса в БД. Может и имеет место быть такой подход

Понятно, что тема древняя, но все же: Нужно разделять задачи. Если отдельно вывести ПДФку - никаких проблем, все браузеры это поддерживают на сегодня. Если в составе  ХТМЛ страницы - то нет. Но есть вариант - преобразовать в png. Для этого хватает библиотек и работает очень быстро. Мы на их основе писали сервис для создания пдф документов на сайте.
Последняя поездка в Рим в ноябре была просто великолепна, Италия то место куда хочется вернуться. Но вот следующего отдыха прямо жаркие споры и я предложил компромисс. - круиз по средиземному морю на недельку. Давняя мечта. Кто бывал в таком - поделитесь плиз впечатлениями, советами. Пока смотрю маршрут типа выход из Испании, Гибралтар, Сардиния и конечный пункт - Рим а оттуда на самолете домой. 
NoMoreContent #:

Представьте медиапродюсера среднего уровня, которому нужна система с данными по YouTube. Гигабайтов на 200. Он хочет периодически смотреть там статистику, аналитику, прогнозы, тренды и что-то еще по своим интересам.

Что он хочет получить - три сервера с приложением (бэкенд/фронтенд), БД, slave-БД?
Срок изготовления - полгода. Стоимость условно USD 85.990 и еще USD 15.000 на поддержку в будущем. 
Где он ничего не сможет сделать сам, кроме пользования интерфейсом.

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

Хранение данных - Однозначно PostgreSQL.  Она соответствует принципам ACID, но позволяет гибко к ним относиться, в частности I-solation доктрина - я  могу отступить и позволить чтение  данных во время записи. Но в данном случае это неважно. Для надежности - настраивается репликация, которая и бэкап и масштабирование одновременно.

Бэкенд - скорее всего это будет FastApi приложение, полностью RESTful, что бы не было в дальнейшем проблем с расширением. Ну и конечно же помним про принципы SOLID -  именно для этого. 

На фронте  -  скорее всего React, хотя на старте можно прикрутить шаблонизатор Jinja2 прямо в FastApi и не заморачиваться особо, 

Что мы получим:

Простое АПИ, легко масштабируемое. Мне не нужно заморачиваться с созданием файловой системы и ее целостностью. Изначально делаю дизайн базы данных. Любое изменение обеспечено миграциями, я люблю Alembic, но тут кому что, хоть руками пиши. Заходел заказчик добавить какую-то инфу в базу или новую выборку - никаких проблем.

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

Я Все ваши эти ваши VPS/VDS считаю пережитком прошлого. Облака - наше все. В моем случае это будет Амазон, конечно же. собрать инфраструктуру - ну наверное полдня с нуля, а потом все это добавляется в terraform и не нужно быть девопсом высокгого класса, чтоб это развернуть. Достаточно получить креды и стартануть локально скрипт башевский - инструкция на страницу! 

А при желании разобраться - что проще чем читать YML- файл? Это всяко легче чем выолнять линуксовые команды. Вот пример кода, который поднимет базу, уверен что даже тот кто это счас прочитает впервые, поймет что там происходит.

resource "aws_db_instance" "fastapi-db" {
  allocated_storage    = 5
  storage_type         = "gp2"
  instance_class       = "db.t3.micro"
  identifier           = "fastapi-db"
  engine               = "postgres"
  engine_version       = "14"
  parameter_group_name = "default.postgres14"

  username = var.db_username
  password = var.db_password
  db_name = "postgres"

  vpc_security_group_ids = [aws_security_group.sg-postgres.id]
  publicly_accessible    = true # Only for testing!
  skip_final_snapshot    = true
}

Никаких пошаговых инструкций не будет, кроме как получить креды. Все разворачивание полностью  автоматическое. Репозиторий из гитхаба и CI/CD.

Все это собрать будет однозначно быстрее для меня возни с файловой системой.  По цене - точно не дороже. 

Если бы не намечающаяся на сегодня пьянка с друзьями - к понедельнику бы выкатил бы POC, через неделю MVP.

Даже интересно стало - за сколько бы я такое реализовал.

Так что не вижу никаких преимуществ ни по одному из пунктов решения с файловой системой. Особенно на миллионах записей

Александр #:

Если будет возможность хотя бы просто повариться в их котле, хоть на пол шишечки - обязательно стоит. Дядьки серьезные и планы у них - нагнуть Мир ;)

Ну зачем бы им его нагибать, когда он и так им с потрохами принадлежит?))) моя давняя мечта - Гугл и рядом не стоит с ними. 

Александр #:

Разгон идет последний год, а после того, как впервые было заявление о том, что Блэкрок зайдет в крипту (не недавний заход, а заявление), инфляция резко пошла вверх. В общем-то, им выгоден сейчас дешевый бакс.
Всегда перед кризисом Блэкрок наращивает капитал там, куда он будет переводиться всеми в сам кризис, а то, что кризис на пороге, сомнений нет.

P.S.: в Китае сейчас жесть будет, лопнет пузырь жилищный, в РФ кабзда после девальвации рубля и двойного подъема ставки - производство все в заднице.
Будет весело :D

Понятно. Согласен в принципе с оценкой. Надо походу идти к ним работать) В смысле в эти все фонды. Я в Вангард прошел три этапа собесов, а потом предложили более интересную позицию со стеклм мне интересным и не пошел дальше. Может и зря

Всего: 7322