Интенсивная передача данных из LAN в БД вебсайта (синхронизация)

Question

[ChemAli]

Стоит задача обеспечить постоянное обновление информации на сайте. Единица информации — это, грубо говоря, страница с рядом сопутствующих параметров-атрибутов (скажем, название, теги, дата и пр., неважно).

На сайт попадают только меняющиеся данные, а не вся БД. Информация обновляется в живом порядке. В идеале нужно отражать на сайте то же состояние БД в котором она находится на сервере внутри корпоративной сети. То есть при каждой правке единицы она отправляется на сайт.

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

• Интенсивность потока до 1500 единиц в час.
• Объем данных в одной единице ~3 кб + служебный мусор от xml/json.
• Требования к устойчивости минимальные: полная актуализация после обрыва коннекта в течение часа-двух.

Нормален ли такой подход? Если нет, то как можно сделать лучше?

Возможно, есть стандартные общепринятые решения, которые улизнули из сектора обстрела?

Comments

[ComodoHacker]

Вы бы хоть назвали используемые БД и фреймворки, там же много специфики.

[ChemAli]

БД локальная — FileMaker Server (может смениться через год-другой). Изменения данных отслеживаются с помощью триггеров. На сайте Postgre- или MySQL, еще не решено. Сайта нет. Вероятнее всего, будет самописное.

[ComodoHacker]

Ух ты, первый раз за много лет слышу про FileMaker, да еще в продакшене. Может напишете статью про него?

Видел его давным-давно на компьютерной выставке в 90-х. Тогда же и маки первый раз увидел. :) Давали потрогать вживую макось, ClarisWorks, FileMaker и т.п. Вставить видеоролик QuickTime в документ. Это было так круто в то время!

Answer 1

[ComodoHacker]

Самая лучший вариант репликации — отсутствие репликации. :) Потому что это еще одна потенциальная точка отказа в системе, которую нужно мониторить, еще один источник головной боли как для админов, так и для разработчиков. То есть решение — сайт берет данные непосредственно из корпоративной БД.

Если по каким-то причинам это вас не устраивает (обдумайте причины еще раз), то сделайте репликацию средствами БД. Это будет надежнее, чем вы сможете сами написать и оттестировать в разумные сроки.

Если же БД не умеет то, что вам нужно, или просто очень хочется сделать свой велосипед, тогда вперед. Вначале выберите модель pull или push. Исходя из ваших требований, лучше pull, но это менее безопасно. Возиться с xml/json не стоит, пишите прямо в БД. Везде вставляйте код для мониторинга. Очередь изменений может переполняться при длительном отсутствии связи. На случай большой рассинхронизации неплохо иметь код «полной перезаписи всего».

Comments

[ChemAli]

Спасибо, ваше мнение очень ценно.

Answer 2

[strib]

Посмотрите в сторону репликации данных средствами самих БД. К примеру накат redo-log.

Comments

[ChemAli]

Полная репликация ненужна. В паблик попадает лишь строго отобранная часть информации. Плюс хочется избавиться от привязки к определенным СУБД в локалке и на сервере (в перспективе они могут сменяться). Поэтому хочется получить более-менее универсальный инструмент, который будет реализовать лишь надежную и достаточно быструю передачу порционных данных.

[strib]

Тогда какое-нибудь приложение ETL (extract, transform, load) — в сети полно образцов.
sourceforge.net/search/?q=etl.

Как второй вариант, достаточно сложный, очень много подводных камней. Основная БД пишет задачи на экспорт в очередь, которую сканируют N обработчиков и на основании задач и переданных параметров пишут данные в другие базы. Т.е. весь код промежуточного звена будет в одном месте. Как основу разработки могу порекомендовать посмотреть на фреймворк Pythomnic (www.pythomnic3k.org/).

Answer 3

[Пума Тайланд]

Нахрен вам вообще репликация, делайте все в одной бд и храните её бекап на всякий случай(а лучше два).
Для доступности сделайте второй канал в офис.
1500 на 3 кб это 4.5МБ, трафик ниочемный, потянет даже резервный 3г или ваймакс.

Answer 4

[kader]

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

Comments

[ChemAli]

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

Answer 5

[ChemAli]

Парадигма сменилась. Будем заливать все данные разом по крону. Всем спасибо, все красавчики!