Прежде всего, хотелось бы отметить широту исследования. Действительно, автор столкнулся как со многими технологиями, так и с обычными человеческими вопросами... Немного непоследовательно и эмоционально, но, вцелом, всё понятно. Даже до боли знакомо... Прошу заранее не кидать камни за невмнимательность, но, если упростить, то задача сводится к следующему:
Нужно сравнить один S3 с другим S3, дослать недостающие файлы и удалить лишние.
Для этого надо сравнить два списка на 1 млрд строк.
Каждый список состоит из 100 тыс. кусочков, каждый кусочек до 100 тыс. строк.
По отсутствующим в получателе строкам нужно дослать файл, или удалить, если отсутствует в источнике.
Имеем некоторое общее ограничение ширины сети, скажем, 100 мегабайт в сек. Также, есть некоторая протокольная задержка (latency), которая может плавать в широком диапозоне.
Имеем некоторое ограничение скорости записи на диск в получателе. Но для упрощения, считаем, что пройдер в большинстве случаев 100 Мб/с обеспечить может.
Пробуем уложиться в "бережливый" формат общения с протоколом провайдера, не создавая ненужной нагрузки.
Предусмотреть, что маленькие файлики важнее больших.
Предусмотреть, что провайдер может подкидывать точечные замедления скорости и отказы.
Анализируем:
Первое бутылочное горлышко - это сеть. Мы можем отправлять 1 файл на максимальной скорости или 1000 файлов одновременно. на минимальной. Мы можем запросить 100 тыс. подсписков по одному, либо сразу все. В идеале, алгоритм должен адаптироваться и добавлять/убирать потоки по мере оценки возможностей провайдеров в реальном времени. Сюда же закладываем latency.
Второе место - это сравнение 1 млрд строк. Выделение десятков гигабайтов памяти - не самая лучшая идея, для любого ЯП. Используем итерационный алгоритм - берём по одной строке и сравниваем. S3 отдаёт список отсортированный по ключу, ведь так? Другой вопрос - как сравнивать строки быстро. А много ли это 1 млрд? Оказывается, для одного из самых медленных языков Питона это всего 41 сек. (разбор тут https://www.youtube.com/watch?v=utTaPW32gKY)
Третье место (гипотетическое) - где хранить очередь файлов. Вот, мы сравнили списки и обнаружили несколько десятков миллионов файлов на обработку. Тут уже выбор: либо мы храним и разбираем всю очередь у себя, либо передаём бережливому брокеру очереди (привет Redis), либо обрабатываем по блочно. Брокер наиболее интересен тем, что может выстроить очередь по приоритетам, например, по размерам файлов. А также, может сохранять очередь на диск, что важно при локальных отказах и перезагрузках.
Также, вопрос, нужно ли загружать файл себе локально? Автор обнаружил, что можно принимать и отправлять файл блоками. Отличная мысль, это использовать. Подозреваю, что все перечисленные ЯП так умеют.
Выводы:
Нужен скрипт, который через асинхронные потоки сможет запрашивать, сравнивать и отправлять данные.
В зависимости от подключения брокера, нужен второй скрипт, который умеет разбирать очередь и перенаправлять/удалять файлы.
По моей субъективной оценке, с этим может справиться Питон на базовой асинхронке из коробки. Тысяча асинхронных потоков для него не проблема (учитывая, что это худший случай работы сети, и большинство потоков будут простаивать). Подозреваю, что одного ядра CPU и 1Гб ОЗУ будет достаточно. Добавлю, что с помощью LLM такой скрипт можно запечь в течение часа (да, с логированием, мониторингом и даже даш бордом). Не боги горшки обжигают :)
Я не противник Rust, но он всё таки для более глубоких системных задач. Также, он даёт существенный выйгрыш, когда есть очень много коротких сетевых запросов. Например, при общении сетевых устройств или разработке мессенджеров. Наверняка ребята из Битрикс24 мессенджера могут поделиться с вами этими болями :)
Отмечу, что ощущается какая-то незавершённость в этой истории. Хотелось бы увидеть продолжение в дальнейшем движении в сторону холодного хранилища и все вытекающие с этим нюансы ;)
Случай настолько заинтересовал, что я даже зарегистрировался на Хабре, чтобы прокомментировать :) Излагаю исключительно личное мнение и ни на что не претендую.
Обратил внимание на комментарии, типа, "повысьте финансовую грамотность" или "наймите маркетолога", и я к ним присоединяюсь, но дело тут совсем в другом...
Я чувствую, что автор создаёт что-то настоящее, и имеет тот редкий навык, когда цель именно сделать что-то хорошее, а не обогатиться. Однако, автор совсем немного увлёкся, и забыл для кого и зачем :)
Я не очень разбираюсь в настольных играх, но у меня двоё детей, и я периодически исследую рынок на предмет "развивающих технологий". Игрушки, книги, гаджеты, приложения, школы... Да, рынок действительно имеет популярные решения, но по настоящему достойных в нём мало... Не нужно недооценивать детей, считая, что они от ограниченности проводят время в телефонах и планшетах. Они умнеют быстрее, чем мы думаем, но и интерес теряют быстрее также. И, чем быстрее мы пытаемся их обучить, развить, и сделать лучше, тем быстрее этот интерес теряется. А именно, дети чувствуют фальш, когда им пытаются подсунуть сублимированную и пережёванную реальность в белой и пушистой безопасной обёртке, фактически, накручивая на стандартные винтики. Дети хотят взрослиться, а именно это мы им не даём...
Но хватит философии! Что именно я предлагаю автору: 1. Провести реинкарнацию лучших игр, добавив "жизненность". а) игра должна оставаться в первую очередь игрой, то есть РАЗВЛЕКАТЬ - идём на встречу к ребёнку, то есть смотрим, тренды, хайпы, мемы, читаем мангу и прочее. б) развитие прячем под ковёр - присутствующие игровые механики и граничения сами выведут ребёнка в нужное русло. Это не про "химию" или "электричество", это про "котиков призрачных самураев". в) никаких инструкций к игре :) Т.е. ребёнок берёт игру и учится на ходу. Привет Роблокс и Майнкрафт :) 2. Маркетплейсы и площадки не обязательны для продвижения. Там работа на объёмы и прибыль. Нишевый продукт не найдёшь, даже если очень ищешь. Делаем свой (!) интернет магазин. Дайте посетителю глотнуть свежего воздуха, после душных однообразных маркетплейсов... Даже, если там будет всего один продукт. 3. Работаем только на предзаказ. Продукт изысканный, нишевый, требует терпения. Штампуем только при наборе массы. 4. И самое главное - делаем игру "запрещённой" )) Т.е. афишируем, что "вы берёте игру на свой страх и риск, мы крайне не рекомендуем в неё играть". Большими буквами, на главной коробке )) 5. Я бы ещё поразмыслил о коллекционном моменте. Т.е. в каждом комплекте должен быть свой уникальный предмет, влияющий в какой то мере на всю игру. 6. Поскольку, дети сейчас реже собираются, то настроить синхронизацию настольной карточной игры через интернет, чтобы играть удалённо... Одним или несколькими комплектами. 7. Чуть не забыл: ценник ставим заградительный (!). 10К руб. за коробку, не меньше. Если уж, вкладываетесь в реальное развитие своих детей, то вкладываетесь, и цените это. Серьёзный продукт должен стоить чуть больше, чем один перекус в семейном ресторане. Не так ли?
И знаете что, ни один монстр на рынке не сможет с вами конкурировать. Им такая модель не по карману ;)
Дяде, на минутку, 72 года.
Дай бог каждому айтишнику пройти такой длинный путь и остаться в ясном уме и здравой памяти.
Искренне желаю автору успехов и новых интересных исследований!
Прежде всего, хотелось бы отметить широту исследования. Действительно, автор столкнулся как со многими технологиями, так и с обычными человеческими вопросами... Немного непоследовательно и эмоционально, но, вцелом, всё понятно. Даже до боли знакомо...
Прошу заранее не кидать камни за невмнимательность, но, если упростить, то задача сводится к следующему:
Нужно сравнить один S3 с другим S3, дослать недостающие файлы и удалить лишние.
Для этого надо сравнить два списка на 1 млрд строк.
Каждый список состоит из 100 тыс. кусочков, каждый кусочек до 100 тыс. строк.
По отсутствующим в получателе строкам нужно дослать файл, или удалить, если отсутствует в источнике.
Имеем некоторое общее ограничение ширины сети, скажем, 100 мегабайт в сек. Также, есть некоторая протокольная задержка (latency), которая может плавать в широком диапозоне.
Имеем некоторое ограничение скорости записи на диск в получателе. Но для упрощения, считаем, что пройдер в большинстве случаев 100 Мб/с обеспечить может.
Пробуем уложиться в "бережливый" формат общения с протоколом провайдера, не создавая ненужной нагрузки.
Предусмотреть, что маленькие файлики важнее больших.
Предусмотреть, что провайдер может подкидывать точечные замедления скорости и отказы.
Анализируем:
Первое бутылочное горлышко - это сеть. Мы можем отправлять 1 файл на максимальной скорости или 1000 файлов одновременно. на минимальной. Мы можем запросить 100 тыс. подсписков по одному, либо сразу все. В идеале, алгоритм должен адаптироваться и добавлять/убирать потоки по мере оценки возможностей провайдеров в реальном времени. Сюда же закладываем latency.
Второе место - это сравнение 1 млрд строк. Выделение десятков гигабайтов памяти - не самая лучшая идея, для любого ЯП. Используем итерационный алгоритм - берём по одной строке и сравниваем. S3 отдаёт список отсортированный по ключу, ведь так? Другой вопрос - как сравнивать строки быстро. А много ли это 1 млрд? Оказывается, для одного из самых медленных языков Питона это всего 41 сек. (разбор тут https://www.youtube.com/watch?v=utTaPW32gKY)
Третье место (гипотетическое) - где хранить очередь файлов. Вот, мы сравнили списки и обнаружили несколько десятков миллионов файлов на обработку. Тут уже выбор: либо мы храним и разбираем всю очередь у себя, либо передаём бережливому брокеру очереди (привет Redis), либо обрабатываем по блочно. Брокер наиболее интересен тем, что может выстроить очередь по приоритетам, например, по размерам файлов. А также, может сохранять очередь на диск, что важно при локальных отказах и перезагрузках.
Также, вопрос, нужно ли загружать файл себе локально? Автор обнаружил, что можно принимать и отправлять файл блоками. Отличная мысль, это использовать. Подозреваю, что все перечисленные ЯП так умеют.
Выводы:
Нужен скрипт, который через асинхронные потоки сможет запрашивать, сравнивать и отправлять данные.
В зависимости от подключения брокера, нужен второй скрипт, который умеет разбирать очередь и перенаправлять/удалять файлы.
По моей субъективной оценке, с этим может справиться Питон на базовой асинхронке из коробки. Тысяча асинхронных потоков для него не проблема (учитывая, что это худший случай работы сети, и большинство потоков будут простаивать). Подозреваю, что одного ядра CPU и 1Гб ОЗУ будет достаточно. Добавлю, что с помощью LLM такой скрипт можно запечь в течение часа (да, с логированием, мониторингом и даже даш бордом). Не боги горшки обжигают :)
Я не противник Rust, но он всё таки для более глубоких системных задач. Также, он даёт существенный выйгрыш, когда есть очень много коротких сетевых запросов. Например, при общении сетевых устройств или разработке мессенджеров. Наверняка ребята из Битрикс24 мессенджера могут поделиться с вами этими болями :)
Отмечу, что ощущается какая-то незавершённость в этой истории. Хотелось бы увидеть продолжение в дальнейшем движении в сторону холодного хранилища и все вытекающие с этим нюансы ;)
Искренне желаю удачи в исследованиях!
Случай настолько заинтересовал, что я даже зарегистрировался на Хабре, чтобы прокомментировать :) Излагаю исключительно личное мнение и ни на что не претендую.
Обратил внимание на комментарии, типа, "повысьте финансовую грамотность" или "наймите маркетолога", и я к ним присоединяюсь, но дело тут совсем в другом...
Я чувствую, что автор создаёт что-то настоящее, и имеет тот редкий навык, когда цель именно сделать что-то хорошее, а не обогатиться. Однако, автор совсем немного увлёкся, и забыл для кого и зачем :)
Я не очень разбираюсь в настольных играх, но у меня двоё детей, и я периодически исследую рынок на предмет "развивающих технологий". Игрушки, книги, гаджеты, приложения, школы... Да, рынок действительно имеет популярные решения, но по настоящему достойных в нём мало... Не нужно недооценивать детей, считая, что они от ограниченности проводят время в телефонах и планшетах. Они умнеют быстрее, чем мы думаем, но и интерес теряют быстрее также. И, чем быстрее мы пытаемся их обучить, развить, и сделать лучше, тем быстрее этот интерес теряется. А именно, дети чувствуют фальш, когда им пытаются подсунуть сублимированную и пережёванную реальность в белой и пушистой безопасной обёртке, фактически, накручивая на стандартные винтики. Дети хотят взрослиться, а именно это мы им не даём...
Но хватит философии! Что именно я предлагаю автору:
1. Провести реинкарнацию лучших игр, добавив "жизненность".
а) игра должна оставаться в первую очередь игрой, то есть РАЗВЛЕКАТЬ - идём на встречу к ребёнку, то есть смотрим, тренды, хайпы, мемы, читаем мангу и прочее.
б) развитие прячем под ковёр - присутствующие игровые механики и граничения сами выведут ребёнка в нужное русло. Это не про "химию" или "электричество", это про "котиков призрачных самураев".
в) никаких инструкций к игре :) Т.е. ребёнок берёт игру и учится на ходу. Привет Роблокс и Майнкрафт :)
2. Маркетплейсы и площадки не обязательны для продвижения. Там работа на объёмы и прибыль. Нишевый продукт не найдёшь, даже если очень ищешь. Делаем свой (!) интернет магазин. Дайте посетителю глотнуть свежего воздуха, после душных однообразных маркетплейсов... Даже, если там будет всего один продукт.
3. Работаем только на предзаказ. Продукт изысканный, нишевый, требует терпения. Штампуем только при наборе массы.
4. И самое главное - делаем игру "запрещённой" )) Т.е. афишируем, что "вы берёте игру на свой страх и риск, мы крайне не рекомендуем в неё играть". Большими буквами, на главной коробке ))
5. Я бы ещё поразмыслил о коллекционном моменте. Т.е. в каждом комплекте должен быть свой уникальный предмет, влияющий в какой то мере на всю игру.
6. Поскольку, дети сейчас реже собираются, то настроить синхронизацию настольной карточной игры через интернет, чтобы играть удалённо... Одним или несколькими комплектами.
7. Чуть не забыл: ценник ставим заградительный (!). 10К руб. за коробку, не меньше. Если уж, вкладываетесь в реальное развитие своих детей, то вкладываетесь, и цените это. Серьёзный продукт должен стоить чуть больше, чем один перекус в семейном ресторане. Не так ли?
И знаете что, ни один монстр на рынке не сможет с вами конкурировать. Им такая модель не по карману ;)