Представим, что есть три сайта. 1) us.www.com 2) de.www.com 3)ru.www.com
У каждого сайта есть свой сервер, своя статика и своя база данных. И все эти сервера находятся далеко друг от друга. Можно ли сделать так, что бы эти три сайта, были одним целым. Что бы статический и динамический контент, например добавляемый на сайт us.www.com, был продублирован и на остальные сайты. То есть, что бы база данных и статика была абсолютно одинаковой на всех сайтах. Например, Майкл Джексон, находясь в США, регистрируется на сайте us.www.com и добавляет свои фотографии на свой профиль, как в инстаграм. Получает лайки и комментарии. Я тем временем находясь в РФ, захожу на сайт ru.www.com, ввожу в поисковик сайта "Майкл Джексон" и попадаю на его страницу, с его фотками, лайками и комментариями, только результат я получаю не с сервера, которая находится в США, а с сервера, которая находится в РФ. Это что-то типа CDN. Можно ли реализовать такое, что бы всё работало корректно и быстро? И какие технологии можно использовать для этого.
Я новичок в этом деле, скажите пожалуйста, а xdcr можно с любой базой данных использовать? Читал про sql, nosql, mysql, но всё равно сложно понять что есть что, когда ты с этим ни разу не сталкивался. Я примерно представляю свою бд и сейчас опишу её, а вы скажите пожалуйста к какому типу бд это относится. Представьте есть пользователь с id1, он создал запись на сайте, у записи будет id1.1, первый "1" это указывает на id пользователя, а второй id "1", указывает на первую его запись. Если он оставит комментарий у себя в записи, то у коммента будет id 1.1.1, 1.1.2, 1.1.3 и тд. Так же у пользователя будут куча других значений в таблице, к примеру лайки, избранное, ч.с, имя и тд. На сайте будет поисковик, в котором можно будет найти пользователя по всяким разным фильтрам, записи по разным фильтрам и тд.
cheburek_ilon, обычная классическая БД, почему 1.1.1 непонятно, все это делается внешними ключами.
У XDCR преимущества, что не столкнетесь с сложностями master-master СУБД репликации, гибко можете настраивать, чем и как обмениваетесь, но все это потребует написания кода. С одной стороны это не так сложно, но и не так просто - если опыта в разработке мало, то не стоит браться за эту задачу, проще будет взять готовое решение вроде master-master СУБД репликации, но там есть свои сложности и достаточно серьезные, почему многие и внедряют XDCR.
XDCR подразумевает обмен данными между ДЦ через приложения по отдельному каналу, например http. Как правило формируется очередь (в базе или в брокере) и на основе ее формируется пакеты обновления для другого ДЦ. Воркеры берут пакеты из очереди и отправляют в другие ДЦ (1 поток - 1 воркер). Пакет - это не обязательно 1 запись в таблицы, если записи в разных таблицах связаны, то их нужно передавать в одном пакете (это не значит, что связанные по внешним ключам нужно передавать в одном пакете, смотрите по ситуации). Если происходит ошибка в обмене, вся очередь для сбойного ДЦ останавливается до момента устранения ошибки (если поделили очередь на независимые потоки, то можно останавливать только сбойный поток).
При 2-3 ДЦ достаточно простой схемы "все обмениваются со всеми". Одним из важных моментов - это разделение транзакций по потокам, чтобы если транзакция обрабатывается на 1ом ДЦ, то все что с ней связано далее, тоже обрабатывалось на 1ом ДЦ (чтобы апдейты одной и той же записи не прилетели на разные ДЦ). У вас это пользователи, которых вы в любом случае будете привязывать к определенному ДЦ. Не нужно их привязывать навсегда, только в рамках текущей сессии.
Это несомненно возможно - см. Facebook, Linkedin и проч.
Но трудно, особенно для базы данных - и принципиально (см. https://en.wikipedia.org/wiki/CAP_theorem - это насчет "и корректно, и быстро"), и технически для "старых" БД типа MySQL или Postgres.
Поэтому советую или для начала использовать более простую архитектуру (один сервер, или несвязанные сервера в разных регионах), или взять архитектора и быть готовым к тому, что это сложно и дорого.
Не так трудно, как кажется на первый взгляд.
MySQL - это старая СУБД? Или MySQL 5.7 старая? В любом случае делать подобное через СУБД очень плохой вариант, не то, чтобы невозможно, но очень близко к этому из-за проблем, которые получим. А если делать, не через СУБД, то абсолютно без разницы какая она.
Про статику - с вероятность 99.(9)% это файлы, которые синхронизируются штатными инструментами типа rsync в момент публикации изменений, если это upload файлы, то в перед публикацией файлы асинхронно рассылаются по всему кластеру.
Про базы данных
что бы всё работало корректно и быстро?
Если скорость раняет большое расстояние между серверами, то проблема решается master-master репликацией, изредка медленно будут работать записи но чтения максимально быстрые из локальной копии.
Простой
