Коллеги, подскажите по архитектуре. Сервис, аналог яндекс.диска или гугл.драйв, но

не по хранению файлов, а просто данные компаний (всякая отчетность и тд).

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

Пользователей предполагается много, порядка 1млн. Вообще меньше, но запас поставили такой.

Как лучше спроектировать постгрес? Варианты:
1. Сливаем все данные в одну схему в таблицы по сущностям: например: table_users, table_orders и т.д. И секционируем эти огромные таблицы по дате, а внутри секционируем по пользователям.
2. Каждого пользователя заливаем в отдельную schema, у каждого будет своя синхронизация локальной базы со своей schema. И в отдельной schema сделать возможность общего доступа к данным. Типа schema это как место на яндекс.диске. У каждого пользователя своя.

Вот как будет логичней архитектуру создать?

Прекратите выдумывать оптимизацыи -- с вашым опытом у вас не получается. Никаких партицыонирований, разных схем, составных строк и документов в jsonах -- только классические значения, классические отношэния между таблицами и простые смыслы у всего. Когда потребуется -- тогда и будете делать, притом, 100% -- совсем не то, что собрались сейчас.

Хорошо, можете пояснить чем плохи мои решения?

Да много чего вы предложыли. Таблицы не в 1НФ, DDL в обычной работе, миллионы схем (ладно, десятки тысяч), партицыонирование без показаний (оно тут непростое, потому это всегда слёзы, и чаще всего -- торможэние).

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

Колонка типа "iduser.idaction" -- очень типичное нарушэние 1НФ. Главное, в данном случае -- безо всякой пользы. И да, суть в том, что вашы оцэнки того, что "полезно" или "быстро" -- пока что крайне далеки от реальности. Ну, вот не знаю -- опыта нехватает или там божэственного откровения -- но вот все эти рассуждения "зачем бегать по таблице всех пользователей", " селать ее гибче" -- являются полной ерундой.

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

1) Для начала -- есть шанс, что дажэ не взялся бы. Это, фактически, мульти-мастер, а мульи-мастер для взаимосвязанных данных -- это всегда боль, разрешэние конфликтов, привлечение экспертов для этого разрешэния и необходимость в тренировке пользователей. В общем, ... мало там не покажэтся, я думаю. 2) А сама репликацыя -- хранил бы с каждой строчкой changetime, плюс отметки в базах о последней успешной синхронизацыи. Всё, что появилось с последней успешной синхронизацыи -- отправляется на сервер и получается оттуда. Последний изменившый побеждает, если нет каких-то важных конфликтов (например, если эту строчку не хочется потерять, а изменили её в двух местах). И да, примерно всё остальное -- чётко по предметной области.

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

Благодарю, есть над чем подумать. Можете подкинуть какие-нибудь ресурсы на эту тему с кейсами или бестпрактис?

> Всё, что появилось с последней успешной синхронизацыи -- отправляется на сервер и получается оттуда. Вот это прямо напоминает "Любая, даже самая сложная, проблема обязательно имеет простое, лёгкое для понимания, неправильное решение." ;) Я, к несчастью, видел несколько систем "репликации", сделанных по этому принципу. Естественно, все они работали неправильно (теряли данные). Если что — их проблема в том, что реальное время не имеет никакого отношения к "видимому" порядку выполнения транзакций. Т.е. строка с меньшим changetime вполне может появиться в базе позже (в реальном времени), чем строки с большим. Разумеется, подобные системы "теряют" такие строки.

Чтобы этого не было -- надо, конечно, блокировать отметку синхронизацыи, чтобы сам процэсс видел консистентные данные и никто не мог в ведомую базу ничего записать пока синхронизацыя не завершытся. И да, Вы, скорее всего, видели множэство автоматических онлайн мульти-мастеров, которых делали чтобы было прозрано для "пользователя" и нагрузка распределялась. У этих-то вообще мало шансов быть нормальными. Если бы задача стояла так -- то я бы посоветовал вообще оставить надежду. Синхронизацыя пользовательских данных при участии пользователя, с другой стороны -- в общем реальна. Вон, git тому примером. Только, понятно, тяжко там всё.

> и никто не мог в ведомую базу ничего записать пока синхронизацыя не завершытся А это не поможет. Проблема-то в работе с источником данных. > И да, Вы, скорее всего, видели множэство автоматических онлайн мульти-мастеров Да если бы. Обычная однонаправленная "синхронизация". > Только, понятно, тяжко там всё. Готовые системы триггерной репликации (например, Slony) вполне справляются, тем не менее.

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

я уже читаю :)

почему "Слони"? "Слоны" же, вроде Бартунов с Сигаевым запустили в начале нулевых тему.

Не знаю, не видел тех заявлений Сигаева с Бартуновым.

не, автор jan wieck, но да - слоны

Ян Вик, автор Слонов, рассказывал, что это именно Слоны.

> Поможэт. Наверное, авторы этих систем синхронизации тоже так думали... но не помогло. ;) > Например, слони однонаправленный А я всего лишь про такой случай и писал, собственно. И уже там можно запросто "накосить", используя "простые и очевидные" подходы.