Чем быстро генерировать такое?

hakuna matata, да, Та же база 210мб на продакшен сервере с десятками лямов запросов в сутки: Time: 0.0032 Sec

Думаю, при 20млн строк лучше разбить sqlite базу на 40 файлов по 500к строк или еще меньше. А при работе скрипта загружать базу в :memory: и сделать ее shared для всех процессов. И random для айдишников лучше делать предварительно средствами php, типа mt_rand(1, MAX_ID). А потом только уже делать запрос в базу с готовыми id "SELECT id, text FROM text WHERE id IN (1,34,56,78)".

Это с какого.. он изнасилует сервер?

Пока самое быстрое файловое чтение никто не изменял, и оно по прежнему самое быстрое и не ресурсоемкое:

fopen(,r)

fgets

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

Каждый вызов fgets в цикле будет считывать вам одну строку из файла.

Если вы не писали рандомно строки в файл, то принцип тогда такой - считываете 500-1000 строк в массив, шуфлите его и берете строки из него, когда 1000 закончится, дальше считываете опять 1000 следующих строк, такой подход тоже несильно нагрузит машину.

я понял что ты про него, но что значит "работает" ?

я думал ты про парсинг в нем... иначе что в нем может не работать ? ))

дают ли доры трафик на нем ? ну говорят дают ))), но я считаю что он устарел, потому что как минимум текст нужно готовить по другому

Как сделал я в своем доргене: решил вообще без баз, это сложно архитектурно, слишком много оперативы (ниже об этом). Динамический дорген, гружу на каждый домен по 100к строк мультикеев, выборка, например на древнем i5, тупо nginx + php7.3-fpm - это важно, эта версия гораздо быстрее, где-то каждая страница отдается за 0,1-0,2 сек, карта сайта динамическая отдается за 0,5 сек. Причем я постоянно подписываю разные макросы - это вообще не влияет. Скорость в зеленой зоне гугла всегда.

То есть я выбираю заранее на домен по 100к строк, кидаю папку - дор готов.

В общем, если вам нужно залить по 1к доменов в сутки - это вариант, с базой сложна - плюс она жрет просто немерено памяти, которая внезапно! очень утекает для nginx, когда у вас много доменов. По сути главным бутылочным горлышком становится nginx - если мало памяти, он будет просто падать на большом количестве доменов, архитектура, я в нём чет разочаровался.

Короче, кратко: php 7.3 может в динамике ну очень быстро все делать и смысла в базе имхо нет. В статике тоже нет: если я кеширую -одна страница выходит в 500к * умножаем на 100к страниц * умножаем на 1к доменов в сутки - многовато, 50 гиг в сутки.

ant_key, то, что без баз, это правильно, в статику всё кэшировать - самоубийство (кэшируется только если за 1-5 минут определенное кол-во раз запросили станицу - вот она только кэшируется и то каждый час делается фул очистка папки всей с кэшем, ну или 2 часа, смотря сколько доменов).

Грузить в память весь текст дора - это от не здорового настроения :)

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

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

У меня двух-трех миллионники крутятся на трехдолларовых хостингах без БД, чисто на файлах, никаких проблем с 1,5 Гб памяти и посещалкой в 50К-70К нет в принципе. Бывает редко, когда все ноды у хосетра резко начинают с диском работать - с дисковыми операциями тормоза, но память и проц в принципе не нужны никакие.

А на шаредах у меня по 20-70 доменов вспомогательных, на 20К-100К страниц каждый, тоже без БД, так я на шаредах этих за 1 доллар, самый менее всех потребляющий клиент (среди тех у кого по одному сайту даже там висит).

Сколько займет выборка 1000 случайных строк из sqlite базы на 20млн строк?

Смотря как ты построишь базу. Можно в бд табличке еще одно поле создать с генерацией в нем числа 20 000 000/1000 от 1 до 20000. Потом на это поле повесить индекс и просто выбирать уже из нужной тебе 1000. Займет доли секунды. where id_1000='номер нужной тысячи'.

Главное не делать выборок рандомных с помощью выборки rand() или random() точно не помню уже, которая их них в sqlite, а которая в mysql. Это конечно убьет сервер с пары запросов :D

решил пока на жако задачу, но чето очень мне он не нравится.

база кеев 20млн ничего не нагружает рандомом если дергать, только задумывается ненадолго в конце, когда строки удаляет

sema_87, ну удалять тем же запросом и с транзакцией, но это да, полюбому ресурсоемко.