Php и невероятное количество чисел.

Lotus Petal

Новичок
Приветствую дамы и господа.

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

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

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

По большому счету нужно сгенерировать числа допустим от 1 до 999999999999 и выгрузить их в любой текстовик. Пока я делаю это в объеме 999999, все получается неплохо, там кода то на 8 строк всего. Но повышая количество нулей в основном конечном числе сервер на котором я пытаюсь это сделать естественно говорит fatal error out of memory. Ожидаемо. Сам текстовик с таким количеством данных тянет на 4-5 гигов.

Однако мой путь привел меня сюда за советом, потому что являясь начинающим программистом, мой мозг помимо дельной логики естественно заводит меня в тупики моего бредогенератора, поэтому я сходу не могу дать ответ.

Я думал о том, что возможно стоит использовать задержку между определенным количеством перебора, чтобы дать серверу "выдохнуть", но это не избавляет от проблемы перегруженной памяти. Может быть стоит генерировать по 50 000 - 500 000 чисел и записывать в файл частями, тем самым используя меньший объем памяти но увеличивая сроки вычисления. Т.к. это в основном теория, сроки вычисления не важны, однако чтобы опровергнуть смысл слова "невозможно" это должно быть не 80 лет, пусть сроки будут не 10 секунд и не 10 минут, день, два три дня это не важно. Пусть никто никогда так не сделает, но этот результат тот, который мне нужен и я пока в замешательстве от того, как его можно достичь.

Буду рад совету заядлых программистов, даже если вы посмеетесь над моими начинаниями с высоты своего опыта.
 

Фанат

oncle terrible
Команда форума
Может быть стоит генерировать по 50 000 - 500 000 чисел и записывать в файл частями, тем самым используя меньший объем памяти
 

Lotus Petal

Новичок
Может быть стоит генерировать по 50 000 - 500 000 чисел и записывать в файл частями, тем самым используя меньший объем памяти
Это как идея приходила мне в голову, но это как я понимаю надо использовать несколько циклов в одном скрипте, возможно даже больше десятка (десятка? 999999999999 для генерации до этих границ похоже нужны будут тысячи циклов). И это каждый должен генерировать определенное количество, записывать, а следующий подхватывать с последнего числа и продолжать с последующим дописыванием в тхт файл верно? (поправьте если моя логика ошибочна, обучаясь я стараюсь уяснить для себя истину, что в скрипте нужно избегать дублирования одинаковых циклов и я пока еще смутно понимаю, где это нормально, а где нет, поэтому по дефолту считаю это не совсем верным). Насколько велика вероятность того, что этот скрипт затянется на неделю или больше или так же положит сервер? Я работаю сейчас в web программировании а там сервера от 128-512 ОЗУ для сайтов, само собой любое тестирование на них изначально провально, поэтому теорикрафчу.

Для себя я еще вникаю в этот вопрос, чтобы понять все доступные методы оптимизации, это пригодится мне в будущем я уверен, когда я буду сталкиваться с реальными задачами. Что можно сделать? Что нужно сделать? Что не нужно делать? Что бы сделали вы?
 
Последнее редактирование:

ksnk

прохожий
999999999999 , даже при средней длине изображения числа - 5 символов, займет 5000 террабайт. Это не особо нереально, но даже и сейчас довольно дорого :)
Есть какой то практический смысл в таком наборе чисел ?
 

Lotus Petal

Новичок
999999999999 , даже при средней длине изображения числа - 5 символов, займет 5000 террабайт. Это не особо нереально, но даже и сейчас довольно дорого :)
Есть какой то практический смысл в таком наборе чисел ?
Практический думаю только для себя и понимании масштаба ошибок и грамотной оптимизации в самых сложных ситуациях. А т.к. это теорикрафтинг то здесь можно оперировать любыми цифрами для того, чтобы приблизится к желаемому результату. 5000 терабайт это реально очень много, но если бить цикл на части как и сказал Фанат выше, допустим делать файлы по 1-5 террабайт, а скрипт дальше создавал второй файл с именет file2.txt и тд, а первый выгружать, в общем отказаться от проблемы конечного веса файла, понятно, что это очень много. В случае неограниченного дискового пространства возможно ли оптимизировать данную ситуацию чтобы она делалась в реально обозримые сроки (ну там от часа до недели допустим).
 

Фанат

oncle terrible
Команда форума
Я помню тут бегал такой же велеречивый. Это не ты был?
Вместо этого словесного поноса взял бы и попробовал написать код.
Было бы примерно в 999999999999 раз полезнее
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
распределенные вычисления
создаешь базу, например https://aws.amazon.com/ru/dynamodb/
делаешь докер-образ с приложением на php, которое хреначит числа в базу в диапазоне от и до,
запускаешь 100500 jobs-контейнеров на разные диапазоны - например, в https://aws.amazon.com/ru/eks/
... profit (у Амазона)
задача на пару дней

почитай для разнообразия про smart-контракты - они не то что числа генерят, проплаченный контракт может 10-символьный пароль подобрать по sha, вычислив все комбинации за несколько минут
 

WMix

герр M:)ller
Партнер клуба
я не понимаю, в чем вопрос? удержится ли скрипт при переборе 999999999999 чисел или хватит ли места? файл это что угодно открыл стрим в /dev/null и перебирай, нужен текст, перенаправь вывод. нарубить на куски это вторая проблема и решается хоть php хоть bash
 

S.Chushkin

Пофигист
21-й век. Программисты-гуманитарии пошли, - калькуляторов не знают. :)

999999999999 * 6.5 = ~6.5 терабайт данных
6500000 / 50 = ~130000 секунд (HD, запись - самая медленная операция)
130000 / 3600 = ~36 часов работы

Хочется быстрее, - SSD и несколько потоков.
 

Lotus Petal

Новичок
Я помню тут бегал такой же велеречивый. Это не ты был?
Вместо этого словесного поноса взял бы и попробовал написать код.
Было бы примерно в 999999999999 раз полезнее
Я уже написал, код рабочий и простой, но попадает в разряд "нереального" потому что он простой, а я не очень умный. Я здесь за поиском аналогов и новых знаний.
 
Последнее редактирование:

Lotus Petal

Новичок
распределенные вычисления
создаешь базу, например https://aws.amazon.com/ru/dynamodb/
делаешь докер-образ с приложением на php, которое хреначит числа в базу в диапазоне от и до,
запускаешь 100500 контейнеров на разные диапазоны - например, в https://aws.amazon.com/ru/eks/
... profit (у Амазона)
задача на пару дней

почитай для разнообразия про smart-контракты, как они не то что числа генерят, там хорошо проплаченный контракт может 10-символьный пароль подобрать по sha, вычислив все комбинации за несколько минут
Спасибо, я почитаю эту информацию, выглядит полезной.
 

Фанат

oncle terrible
Команда форума
Какой код ты написал? Который все числа в памяти держит?
"новые знания" надо не на пустом месте искать, а совершать осмысленные телодвижения.
Делать что-то, смотреть на результат, и если не устраивает - то переделывать.
А фантазии "я не знаю чего мне надо, но хочу лучше" надо оставить девочкам пубертатного возраста.
 

Lotus Petal

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

Фанат

oncle terrible
Команда форума
давай-давай
прислушайся

результатом будет очередное пространное эссе на тему непознаваемости мира
 
Сверху