Добрый день подскажите, пожалуйста, как лучше организовать БД для следующего проекта. Есть автобусные станции, когда автобус подъезжает к станции бортовой компьютер передаёт через WiFi на сервер определённую статистику и данные, что-то сервер передаёт обратно - синхронизация. Вот здесь возникает вопрос по организации сервера... или серверов . Вариантов как мне видится может быть 2:
1) один центральный сервер с REST сервером, который осуществляет синхронизацию по Интернет с компьютерами автобусов + БД PostgreSQL, где всё хранится. На сервере также работает Web-клиент, через который производится администрирование и управление посредством команд REST-серверу. Т.е на сервере имеем: REST + БД PostgreSQL + Web-клиент (Веб сервер).

2) локальные сервера (БД + REST) на каждой станции (вдруг Интернет будет медленный или отсутствовать на время) + центральный (БД + Веб-клиент), который может быть одновременно и локальным.
Вот по 2-му варианту, т.к. он мне представляется наиболее предпочтительным, и возникает вопрос: как организовать хранилище данных в PostgreSQL, центральное или распределённое, репликацию как организовать, полное дублирование на каждом сервере или частичное, какие инструменты применять и желательно подсказать как их применять: возможно подскажите ссылку на руководство или учебное пособие? Структура данных наверное будет не очень сложной, но их может быть достаточно много: сотни автобусов и хранение информации на протяжении большого периода времени.

Благодарю!

--
С уважением,
Алексей.

kira ivanov,

авторНе совсем понятно - при чем здесь PostgreSQL....Не причём, про его всегда использую в качестве БД.

kira ivanovА если в конкретном месте нет интернета, то ценность переданной в локальное место информации минимальна. Тут уж легче логику "бортового компьютера" переписывать - копить не переданную инфу и передавать все при удачной попытке соединения.Спасибо, интересный вариант. Подумаю. Хотя больше нравится вариант, когда сервера на нескольких станциях и между ними настроена репликация: на каждом полная копия БД. Как лучше её организовать средствами PostgreSQL?

Тогда автобус сможет связаться с сервером, связь с которым лучше. Видимо выберу среднее между вашим вариантом и своей идеей. Там ещё надо большие видео файлы передавать на бортовой компьютер, синхронизировать. Тоже есть вопрос: как их лучше хранить и закачивать: с одним сервером проблем нет, если несколько - надо как-то их тоже дублировать на локальные сервера. Это наверное уже лучше через REST делать.

kira ivanovЕсли боитесь большого объема базы, то почитайте здесь и заранее продумывайте структуру б.д.Да вроде не боюсь, за ссылку спасибо, посмотрю.

kira ivanovза REST при работе с б.д., извините но "убивать надо"Извините, но почему?! Что не так? Там же не только данные передаются, ещё кое какая управляющая информация. REST-сервис по моему самое то. REST получает данные и записывает в базу и наоборот, что не так?! Все так делают. Кроме того, не думаю, что это хорошая идея, чтобы бортовой компьютер видел базу и общался с ней напрямую, пусть через сервисы общаются, через API, ему о базе вообще ничего знать не положено.

kira ivanovВы точно уверены, что хорошо знаете "что такое REST" - насколько в курсе я, это передача состояния.Я хорошо знаю :) - Representational State Transfer — «передача состояния представления». Я понял: вы бы хотели, чтобы я применял термин RESTful :

wikiREST (сокр. от англ. Representational State Transfer — «передача состояния представления») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы. В определённых случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле[уточнить] компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является альтернативой RPC[1].

В сети Интернет, вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно «GET» или «POST»; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса[2][3].

Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».
kira ivanovREST из базы ни чего не получает и ничего туда не пишет. REST это "протокол" обмена между сервером и "бортовым компьютером", но не для работы приложения с б.д..Это ежу понятно. Моя первая фраза была про REST-сервер (далее просто REST ), реализующий определённые сервисы, а сервер пишет в БД.

kira ivanovМультимастер репликаций из коробки нету, есть только master-slave а slave = realonly, выход один - писать тригера (скрипты) ручками... "словите" здесь - немерено всегоВот ради этого ответа и затевал эту тему :) Может из коробки нету, а расширение уже есть, ваши сведения устарели: :)
https://2ndquadrant.com/en/resources/bdr/
https://blog.2ndquadrant.com/bdr-is-coming-to-postgresql-9-6/
https://habrahabr.ru/post/227959/
Начну конечно с одного сервера, а там посмотрим.

kira ivanovпочитайте про архитектуру ютуба, применительно к роликам. Под это действительно желательно иметь ряд серверов, но только для отправки контента на "бортовой компьютер"Вот пошли ценные советы, а не поучения. :) Спасибо, посмотрю. А точной ссылки не дадите? Накопал несколько источников:
https://www.insight-it.ru/highload/2012/arkhitektura-youtube-2012/
https://www.insight-it.ru/highload/2008/arkhitektura-youtube/
- или есть лучше?

Благодарю! :)

kira ivanovпочитайте про архитектуру ютуба, применительно к роликам. Под это действительно желательно иметь ряд серверов, но только для отправки контента на "бортовой компьютер"
Предлагаете настроить свой CDN и файлы грузить через какой-нибудь nginx proxy? Вроде не сильно сложно настроить: https://habrahabr.ru/company/sports_ru/blog/198598/

qwwqхотите -- ставите "буфера" везде.
А как "буфер" по вашему должен работать? Можете подробнее объяснить пожалуйста?

qwwq, благодарю!

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