Ну и надо правильно настроить реплицирование, чтобы отставание небольшое было

Ну это относильено acid

Почему?

Ну а за счёт чего будет выигрыш скорости?

Я думал над ассинхронным реплецированием

Ну а за счёт чего будет выигрыш скорости?

ну да..

Выигрыш в скорости запросов?

Но для тренировки можешь конечно на одной машине и разных виртуалках

Записи, чтения

Если на разных машинах, то ширина канал достаточная должна быть

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

Колбасить на бекенде и кидать в mongodb какую нибудь

Можешь посмотреть в сторону Apache airflow

Я так понял etl какой-то

Колбасить на бекенде и кидать в mongodb какую нибудь

а так как у монги с чтением получше, чем у постгреса(по слухам, хз на самом деле), то сортировать уже беком программно и выплевывать через api

Я так понял etl какой-то

?

Можешь посмотреть в сторону Apache airflow

позырю

Extract transform load

Extract transform load

Да, такой процесс

а так как у монги с чтением получше, чем у постгреса(по слухам, хз на самом деле), то сортировать уже беком программно и выплевывать через api

чтение упирается в ЭТ, и тут на деле реализация вашего железа.

чтение упирается в ЭТ, и тут на деле реализация вашего железа.

ЭТ?

электронная техника

В чтении много нюансов . Например можно читать асинхронно кусочками

сомневаюсь что бест практикс, игнорируются в чтение топовых решениях ПО

Обычный read - синхронный , но есть io_submit, который асинхронный .

Лан, спасибо за инфу

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

И часто ему это надо?

И часто ему это надо?

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

И часто ему это надо?

По запросу, по сути

Сервис по сути отчеты рисует

По запросу, по сути

Ну я имел ввиду как часто запросы и сколько времени выполняется сейчас запрос

Ну я имел ввиду как часто запросы и сколько времени выполняется сейчас запрос

15 секунд....

Ну 15 секунд можно и подождать

Это же отчёты

Ну 15 секунд можно и подождать

В лучшем случае

Лишь бы это не тормозило всю остальную систему

Ну я имел ввиду как часто запросы и сколько времени выполняется сейчас запрос

Ну суть в том, что это будет в итоге частый запрос

Лишь бы это не тормозило всю остальную систему

Не тормозит

Ну суть в том, что это будет в итоге частый запрос

Как часто?

Проблема в записи потом будет

Какой записи. Ты же сказал отчёт

Как часто?

Ну рпс не скажу

это уже называется не здоровый перфекционизм

Ну аналитический отчёт же не строится каждую секунду. Хорошо если раз в час. Не?

Какой записи. Ты же сказал отчёт

Процесс такой. Файл приходит, файл парсится и сохраняет 200к записей в базу. 200к записей сохраняются долго джангой

Чо

Приходят сейчас раз в день, потом будут проходить, раз в 10 минут

Ты только что говорил "построить отчёт по базе"

Теперь мы что-то пишем

Давай целиком задачу

Погоди тогда секу)

Ку

Есть кто юзает filebrowser под джангой?

Django-filebrowser

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

Есть кто юзает filebrowser под джангой?

Хз что это. Кажется, он не работает когда больше одного сервера. Или я не прав?

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

Насколько продолжительный?

Насколько продолжительный?

от 3 месяцев

Есть джанга + постгрес + nginx Внутри джанги написал скрипт, который собирает файлики которые приходят раз а день на почту. Файлики парсятся и данные складываются в базу(есть также таблицы зависимостей, которые указывают с чем соотносить данные из файлика). Есть апи, которая ходит в базу за данными (там всякие методы, которые фильтруют и сортируют сырые данные нужным образом). Один из методов забирает сырые данные и считает всякое, выкидывая новые сущности(типа взять дельту за определенную дату). Так как данных дохрена, вытаскивает он это очень долго. Фронт из этих данных формирует отчетики и графики

от 3 месяцев

Ух.

Тогда первый

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

так неизвестно - это еще больше.

Есть джанга + постгрес + nginx Внутри джанги написал скрипт, который собирает файлики которые приходят раз а день на почту. Файлики парсятся и данные складываются в базу(есть также таблицы зависимостей, которые указывают с чем соотносить данные из файлика). Есть апи, которая ходит в базу за данными (там всякие методы, которые фильтруют и сортируют сырые данные нужным образом). Один из методов забирает сырые данные и считает всякое, выкидывая новые сущности(типа взять дельту за определенную дату). Так как данных дохрена, вытаскивает он это очень долго. Фронт из этих данных формирует отчетики и графики

Хм. Вот я тут даже не знаю зачем тут постгрес и монга одновременно

так неизвестно - это еще больше.

Возможно ты можешь сделать часть этого неизвестного

Хм. Вот я тут даже не знаю зачем тут постгрес и монга одновременно

Ну а представь количество новых сущностей, за один день, если в одном отчёте 100к строк

Или 200

Есть джанга + постгрес + nginx Внутри джанги написал скрипт, который собирает файлики которые приходят раз а день на почту. Файлики парсятся и данные складываются в базу(есть также таблицы зависимостей, которые указывают с чем соотносить данные из файлика). Есть апи, которая ходит в базу за данными (там всякие методы, которые фильтруют и сортируют сырые данные нужным образом). Один из методов забирает сырые данные и считает всякое, выкидывая новые сущности(типа взять дельту за определенную дату). Так как данных дохрена, вытаскивает он это очень долго. Фронт из этих данных формирует отчетики и графики

Ну в целом ты можешь хранить в денормализованном виде и в постгресе

Ну в целом ты можешь хранить в денормализованном виде и в постгресе

Что ты имеешь ввиду?

Ну а представь количество новых сущностей, за один день, если в одном отчёте 100к строк

100к строк - это уже не отчёт, а какие-то сырые данные для отчета

Что ты имеешь ввиду?

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

Ребят как инкапсулу обойти помогите плез ?

Ребят как инкапсулу обойти помогите плез ?

Что это?

капча

наподобии

Возможно ты можешь сделать часть этого неизвестного

по тебе лучше интересное и неизвестное, чем пилить велосипеды ? )

Христофор Колумб

капча

Попробуй написать автору сайта, может быть он тебе даст нормальное апи

по тебе лучше интересное и неизвестное, чем пилить велосипеды ? )

Лучше новое чем велосипед. Лучше интересное чем скучное.

Но возможно второе решается без велосипедлстроения

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

А как тогда мне связи искать. На строки, по которым искать, индексы поставить? Дело даже не в join, а в огромных выборках

А как тогда мне связи искать. На строки, по которым искать, индексы поставить? Дело даже не в join, а в огромных выборках

Эм. Зачем искать связи?

У тебя в постгресе есть blob, hset, json поля. Можешь юзать

Если тебе всегда надо вытаскивать какую-то сущность целиком - нет особого смысла её нормализовать и класть в кучу таблиц.

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

Эм. Зачем искать связи?

Суммировать данные нужно отталкиваясь от связных обектов

Ты можешь при записи считать. Если запись реже чем чтение

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

а какой срок тогда стоит брать во внимание? месяц? недели?

ты прям как шар предсказаний)))

а какой срок тогда стоит брать во внимание? месяц? недели?

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

Если это никому ненужная вещь, ты за месяц-другой без mvp выгораешь

Ты можешь при записи считать. Если запись реже чем чтение

К сожалению, не могу, потому что не знаю будут ли запрошенны данные за эту дату при записи

К сожалению, не могу, потому что не знаю будут ли запрошенны данные за эту дату при записи

Почему бы не иметь избыточность ради скорости

Если это никому ненужная вещь, ты за месяц-другой без mvp выгораешь

хороший инсайт, спасибо

настроить то, где оно отображается, чтобы нормально отображалось