Nick
а еще время на миграцию самих данных никто не отменял
Roman
если вам просто перенести данные из одной бд в другую, меняя только немного "схемы"/"модели", то за пару дней можно
а если менять логику и архитектуру под конкретную бд, то действительно долго
что значит "менять логику и архитектуру под конкретную бд" ? мне нужно перенести полностью с nosql (mongo) на sql (postgres) я так понимаю со всеми схемами и соответственно запросами
Daniil
что значит "менять логику и архитектуру под конкретную бд" ? мне нужно перенести полностью с nosql (mongo) на sql (postgres) я так понимаю со всеми схемами и соответственно запросами
если переносить “в тупую”, то можно столкнуться с критичным падением производительности
Roman
а еще время на миграцию самих данных никто не отменял
миграция меняет же структуру базы это не то, а мне переписать проект на другую базу я имею введу
Богдан
что значит "менять логику и архитектуру под конкретную бд" ? мне нужно перенести полностью с nosql (mongo) на sql (postgres) я так понимаю со всеми схемами и соответственно запросами
тогда, если проекту 2 года и имеет в себе миллионы документов, то это займет, как уже сказали, около года
Roman
Roman
yopp
+/-
Roman
что можно делать год?
Roman
тогда, если проекту 2 года и имеет в себе миллионы документов, то это займет, как уже сказали, около года
да там много записей в базе
Богдан
да, только делать бакеты по часам например
то есть, если надо результаты за месяц, то надо сделать 30 бакетов (по суткам)
yopp
да
Daniil
что можно делать год?
вы не говорите какой объем приложения. Может там два года делалась 1000 строк
yopp
если у вас нет интеграционных тестов, то умножайте на два ещё
Roman
вы не говорите какой объем приложения. Может там два года делалась 1000 строк
как проверить количество строк?
yopp
в моей практике ещё ни одно «мы щас возьмём и за две недели переедем с одного хранилища» не заканчивалось за две недели и даже за два месяца ;)
Roman
вы не говорите какой объем приложения. Может там два года делалась 1000 строк
129716 total
это весь бэк
Roman
а это src 18429 total
Богдан
да
спасибо, сейчас буду думать
но, судя, по докам для бакета - лучше все-таки каждый апдейт отдельно сохранять как документ, иначе как потом прогонять по массиву из поля одного документа
yopp
бакеты для временных рядов единственное вменяемое решение
Богдан
бакеты для временных рядов единственное вменяемое решение
я сейчас тогда четко сформулирую тз, возможно плохо написал я
Богдан
прогонять что?
Есть станция, которая каждую минуту на сервер посылает апдейт с текущей датой и значениями датчиков
Сейчас это все сохраняется в бд отдельным документом:
id_station, timestamp_of_station, temperature, pressure
Требуется предоставлять макс/мин/ср за определенный период (неделя, месяц, день), а также для макс/мин даты, когда были эти значения
Также требуется предоставлять апдейты по точной даты и страничной навигацией (через сорт и скип)
yopp
и всё это великолепно решается бакетами по суткам :)
yopp
или даже по часам
yopp
проблема с документом на каждую запись в том, что поддерживающие индексы будут размером с данные и выборки будут требовать сканирования множества документов
yopp
бакеты будут гораздо эффективнее по ряду причин:
1) дедупликация метаданных, например идентификаторов данных
2) сжатие: prefix compressions для multikey индексов
3) сжатие: document compressions для самого бакета
yopp
если у вас постраничный вывод по датам, это вообще отлично
Богдан
проблема с документом на каждую запись в том, что поддерживающие индексы будут размером с данные и выборки будут требовать сканирования множества документов
если у меня в поле одного документа будет массив апдейтов, как его в бакете тогда использовать и указывать?
yopp
что вы имеете ввиду?
yopp
в чем могут возникнуть трудности?
смена хранилища в среднем потребует от вас ощутимо переписать ту часть, которая работает с этим хранилищем. обычно это большая часть логики.
а смена модели хранилища потребует в принципе заново написать эту часть
yopp
и это только make it work
yopp
если тестов нет, то отладка будет самой сложной частью
yopp
не ведитесь на «быстро перепишем»
yopp
не перепишите, инфа 99%
yopp
смена хранилища это очень дорогая операция
yopp
по этому она имеет смысл только если это даст какую-то дикую экономию сразу
Roman
смена хранилища это очень дорогая операция
какой у вас был опыт с переписыванием проекта на другую базу?
Nick
в чем могут возникнуть трудности?
у вас данные в монге плоские или вы используете вложенную структур json и каково количество коллекций примерное?
yopp
как консультант :)
yopp
плюс когда был архитектором нам несколько раз приходилось это делать
yopp
долго, дорого, очень сложно
yopp
я вобщем-то с монгой так и познакомился десять лет назад :)
Roman
у вас данные в монге плоские или вы используете вложенную структур json и каково количество коллекций примерное?
там много сущностей примерно до 25 и все они тесно связаны например через populate кажная некоторые даже несколько раз
Roman
плюс когда был архитектором нам несколько раз приходилось это делать
так как переписывали ? с орм на орм ?
Богдан
что вы имеете ввиду?
наверное, имею ввиду, как бакету указать, чтобы он перебирал нужный мне массив и определял элементы массива для вывода
Roman
плюс когда был архитектором нам несколько раз приходилось это делать
по каким причинам призодилось переписывать? проект рос и база не справлялась? и что в итоге ? произволительность выросла?
Nick
миграция меняет же структуру базы это не то, а мне переписать проект на другую базу я имею введу
вы именно проект заново переписываете или же все оставляете, но хотите поменять только слой доступа к бд?
Roman
Nick
т.е. только слой доступа к данным
Roman
короче орм поменять и все
yopp
yopp
по каким причинам призодилось переписывать? проект рос и база не справлялась? и что в итоге ? произволительность выросла?
в одном из проектов существенная часть данных это были динамические иерархические структуры описывающие состояние разных PLCшек. entity-attribute-value схема очень плохо работала, по этому мы начали искать другие модели данных и тогда только-только вышла монга
yopp
но мы делали «глубокий рефакторинг» и понимали что весь старый код надо будет выкинуть
Roman
какаю даст производительность если переезать с монги на постгрес?
yopp
никакую
yopp
даже хуже
yopp
вы просто потратите кучу денег и времени просто так
yopp
и получите сломанный напрочь продукт
yopp
считать надо цифры
yopp
для того чтоб что-то оптимизировать, надо чётко понимать где проблема
yopp
и качественно убедиться что предлагаемое решение, действительно решит проблему
yopp
смена хранилища без чёткого понимания проблемы и без чёткого ответа на вопрос как именно новое хранилище решает проблему и какие новые проблемы оно создаст — к огромным убыткам
Богдан
почему? тим лид считает по другому ()правда он молодой еще
https://m.habr.com/ru/company/ruvds/blog/507518/
Просто как пример, что иногда не стоит гнаться за чем-то и переделывать всё
Nick
а как по другому? архитектура базы всеравно поменяется
по другому - переписать все с нуля, вплоть до выбора другого языка, набора фреймворков, перестройки архитектуры и т.п. разные варианты
yopp
самый главный вопрос: чем вас текущее хранилище не устаривает
Назар
Есть коллекция товаров и каждый день у каждого товара приходит новая цена. Она может быть такая же как и старая, но не суть. Как правильно хранить цену, чтоб потом можно было получить товары у которых цена не менялась например 3 последних дня?