Программирование[9]

ETL это ебаный баззворд который НИЧЕГО не значит

весь скл это ETL, кроме изменения структуры, охуеть просто

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

GoldRobot написал 2 минуты назад:

А ну если терабайты, то конечно лучше не пихать так как кант

Тока ты об этом ни словом ни духом сразу не сказал

 

Какое ТЗ поставил, такое решение и получил 

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

Kant написал Только что:

ты пытаешься засунуть логику обновления в запрос, который для этого не предназначен

Почему?

Запрос предназначен. Он просто не работает когда возникает больше одного exluded на строку.

Да нет сука временных таблиц, я потому и жопу рву.

Ну да, я вижу нюанс, ты каких-то тараканов используешь

В чем профит?

потому что он не преназначен

у тебя несколько строк могут приехать, инсерт обрабатывает строки по одной и не может обработать несколько по своему определению

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

я вообще уже не ферштейн, что в результате твой код должен получить. Учитывая, что там написано on duplicate by (user) или как-то там, то предполагается, что в результирующей таблице юзер указан не более 1 раза или шо? Если так, то зачем на вход вообще подавать более старые записи, когда они гарантированно откинутся более  новыми записями

да и похуй на временные таблицы, если там нет их нормальных, всегда можно ебнуть не временную таблицу с именем "тупойтаракан20200717173815" и делитнуть ее в конце

или вообще держать одну такую с фиксированным именем, если у вас дампалка одна и не работает параллельно, либо ждать будет вторая пока таблица залочена в транзакции

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

GoldRobot написал 12 минут назад:

В чем профит?

горизонтальная масштабируемость 

А точнее даже она у нас и так есть, но тут типо ребалансинг искаропки.

Слушай, а что у тебя за сервис вообще такой, что данных о постах в три колонки набирается терабайтами в день?

Мне летит 25к в секунду со всего казахстана, когда нужно схоронить номер телефона и номер симки с пятком других столбцов, и у меня с хранимой в виде текста инфой набирается ну 150гигов день.

А тут терабайты

Kant написал 12 минут назад:

Учитывая, что там написано on duplicate by (user) или как-то там, то предполагается, что в результирующей таблице юзер указан не более 1 раза или шо? Если так, то зачем на вход вообще подавать более старые записи, когда они гарантированно откинутся более  новыми записями

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

GoldRobot написал 1 минуту назад:

Слушай, а что у тебя за сервис вообще такой, что данных о постах в три колонки набирается терабайтами в день?

Мне летит 25к в секунду со всего казахстана, когда нужно схоронить номер телефона и номер симки с пятком других столбцов, и у меня с хранимой в виде текста инфой набирается ну 150гигов день.

А тут терабайты

 

Я абстрагировал задачу. Но на деле там да 3 колонки, юзерайди, время и json payload 

Всмысле ты про терабайты просто так ляпнул или терабайты это вместе с нагрузкой в виде джсона? 

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

Ну может преувеличены в раз 10,не более 

Kant написал 16 минут назад:

всегда можно ебнуть не временную таблицу с именем "тупойтаракан20200717173815" и делитнуть ее в конце

А вот не все так просто, учитывая что это дистрибьютет хуйня кто знает что она под капотом крутить начнет. Ты же не хочешь чтобы оно пошло настраивать по всем нодам лидерство, место на диске выделять и прочую метахуйню творить чтобы потом её дропнуть.

Потом вакуум пойдет ещё.

Потому я и спрашивал сколько у тебя инстансов и прочая туфта

FeelYourDestiny написал 10 часов назад:

Жужа, ты не находишь странным, что проблемы с поиском только у тебя?

они просто ещё не знают, что у них проблемы ...

Это у меня проблемы? Нет, это проблемы у вас, просто вы еще не почуствовали насколько большие проблемы. (с) Жужа

GoldRobot написал 9 минут назад:

Это у меня проблемы? Нет, это проблемы у вас, просто вы еще не почуствовали насколько большие проблемы. (с) Жужа

тут согласен!

Kant написал 2 часа назад:

ETL это ебаный баззворд который НИЧЕГО не значит

весь скл это ETL, кроме изменения структуры, охуеть просто

 

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

под эти баз ворды миллиард сервисов на aws запустили, пиздец просто.

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

и так сотен пять тестов на пару часов 

а не эти ваши алгоритмы ссаные

madvlaydin написал 31 минуту назад:

а не эти ваши распределенные хайлоады ссаные

fxd

Index написал 6 часов назад:

Хотите задачу?

Есть итерируемая колекция упорядоченная по мере добавления (например посты этого топика).

В коллекции лежат сущности (посты) у которых есть какой-то ключ. (например имя пользователя).

Задача разбить коллекцию на батчи. В каждом батче лежит не более одного сообщения от каждого из пользователей.

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

Пример.

[А-1,Б-1,В-1,Б-2,В-2,Г-1,Б-3,А-2,Г-2,А-3] - где имя ключ число время+payload для наглядности

Разбиваются на

[А-1,Б-1,В-1], [Б-2,В-2,Г-1], [Б-3,А-2,Г-2], [А-3]

Но это разбиение на основе быстрого алгоритма - разрезаем коллекцию как только появляется не дистинкт ключ и сбрасываем дистинкт стейт.

Но можно разбить более эффективно.

[А-1,Б-1,В-1,Г-1], [Б-2,В-2,Г-2], [Б-3,А-3]

 

Вот собственно задача как это сделать изящно, функционально, чтобы батчи были максимально объемные, их было как можно меньше, но все это не превышая O(n) и без больших объемов памяти.

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

 

Естественно число ключей и их диапазон не известен заранее.

А да, забыл ключевое.

Можно отбросить те данные для которых есть ключи в поздних батчах. Это если работа на конечной коллекции.

 

tl:dr это все сводится к тому, что

UPSERT INTO xxx (key,value) VALUES

(...),

(...),

(...),

(...),

(...);

 

Захлебывается если в списке дублируется одинаковый PK констрейнт.

UPSERT INTO xxx (key,value) VALUES

(...),

(...);

UPSERT INTO xxx (key,value) VALUES

(...),

(...),

(...);

Отработает нормально, если их разнести.

 

Нужно по сути в бд занести самый последний payload на ключ.

Храним для каждого ключа номер последнего батча, куда мы засунули значение. И тогда для уже встретившегося ключа значение кладем в + 1 от прошлого номера батч.

А если стрим бесконечный, то храним батчи в очереди и по таймауту дропаем начало очереди, а для новых ключей будем батчи отчитывать от номера дропнутого

besteady написал 2 минуты назад:

Храним для каждого ключа номер последнего батча, куда мы засунули значение. И тогда для уже встретившегося ключа значение кладем в + 1 от прошлого номера батч.

Чел

А что ты будешь делать когда несколько первых пачек нужно будет удалить отдав в базу?

GoldRobot написал 2 минуты назад:

besteady написал 6 минут назад:

Храним для каждого ключа номер последнего батча, куда мы засунули значение. И тогда для уже встретившегося ключа значение кладем в + 1 от прошлого номера батч.

Чел

А что ты будешь делать когда несколько первых пачек нужно будет удалить отдав в базу?

Просто обновить значение на max(то что было записано, номер первого существующего)

Index написал 5 часов назад:

синтаксис SQL ругается, мол не может эксклюдить больше чем одну запись сорян.

Актуальный стейт юзеров: юзер_айди | сообщение_айди

Берешь срез сообщений (сообщение_айди | юзер_айди | тайстепмп | текст) за день и обновляешь только те строки юзеров, у которых новые сообщения

Разве это не так должно работать чи не

besteady написал 14 минут назад:

GoldRobot написал 16 минут назад:

 

Просто обновить значение на max(то что было записано, номер первого существующего)

Что значит "просто"

Вот у тебя 100 лямов юзеров

Для каждого из загружаемого батча тебе придется пройти по каждому из 100 лямов и поправить ключик