в первый парсинг файла я загружу 150 млн доменов в базу (хочется чтоб загрузка проходила не более 12 часов), каждый день обновляется примерно 150 тысяч доменов - хочется тоже, чтоб это было не более 12 часов
там вся боль сейчас в том, что вначале я партицию (по букву) выгружаю в redis, чтоб каждый запрос в pgsql не закидывать - и долго именно из pg перекладывается, т.к. я пачками выбираю (делаю where id > last_id limit 1000)
в первый парсинг файла я загружу 150 млн доменов в базу (хочется чтоб загрузка проходила не более 12 часов), каждый день обновляется примерно 150 тысяч доменов - хочется тоже, чтоб это было не более 12 часов
сейчас pgsql не вывозит такое
150mln ни о чем, пг норм Вам кх не особо нужен.
Но можете в кх хранить весь лог без удалений обновлений строк тоже
можно сделать табличку с логом всего, можно сделать mv, который отдедуплицирует события по одному домену, но при чтении вроде все равно надо будет домерживать. tld точно можно инлайнить, ns для начала тоже, какая там средняя длина массива?
еще можно самому всегда агрегировать по domain исходные данные, но 150М ключей - это обычно проблемы с памятью, надо смотреть какая предполагается аналитика и какая исходная событийная модель. что такое домен пропал из регистрации итд. Какие домены были удалены/обновлены вчера с доменной зоной = ru можно и по оригинальным событиям вообще без всякого updated_at посчитать.
а вот как у КХ с запросами, когда нужно получить 1 строку из всей таблицы по её ключу? на апдейтах у меня такая логика и подразумевается, что во время последующих парсингов я делаю на каждый домен запрос в базу и проверяю NSы в коде. Не упрусь в то, что КХ будет вывозить условно 100 запросов в секунду всего таких?
а как тогда быть? я не могу пачкой взять 100 доменов из базы и пачку в 100 доменов спарсить из файла, там если будут пропуски, то я замучаюсь понимать как это разрулить, особенно когда следующую пачку надо будет взять