Кто может подсказать по теоретическим вопросам по архитектуре таких сайтов, как соц.сети, сайты знакомств (интересует back-end: БД, картинкохранение)?

Доброго времени суток.

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

Интересуюсь данной тематикой давно, прочитал уже кучу информации с разных источников (Хабра, СтакОверФлов, Медиум и многое другое), и как бы по отдельности все понятно, а собрать все в целостную картину не могу.

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

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

Пора перейти к конкретике. Берем любую соц. сеть (ВК, Фейсбук и тд) + какие то сайты знакомств (Мамба, Баду).

Вопросы:
1. В какой БД предпочтительней хранить профили юзеров? SQL\NoSQL? Postgresql, Mongo, варианты? Может даже ElasticSearch?
2. В какой БД хранить часто изменяющуюся информацию, такую как:
а) лайки
б) ленту топовых пользователей (обычно в верхней части сайта)
в) постоянно меняющуюся сортировку юзеров, которые платят деньги, чтоб оказаться самым-самым первым.
Redis? Я знаю, что перед перезагрузкой сервера можно сохранить все на диск, а что делать, когда сервак завис? Деньги юзер уплатил, сервак завис - юзер не очень доволен :) Тогда может Cassandra? Если все же Редиску, то как определить, как часто (может даже, по каким методикам) нужно "бекапить" информацию, сохраняя ее в основной базе?
г) в какой бд собирать данные о пользователе, к примеру для обеспечения безопасности (с каких ай-пи заходит, как часто переходит по разным страницам - вдруг он открывает по 100 страниц за раз?), данные для аналитки?

3. Чаты. Признаюсь, не гуглил еще. Куда хранить чаты?
4. Гео данные, а точнее поиск пользователей по координатам в определенной области, как они далеко друг от друга, и др. PostGIS? Может ElasticSearch?
5. Поиск пользователей по возрасту, полу, знаку зодиака, школе, городу, опять же, по гео радиусу и еще кучи характеристикам. ElasticSearch? Работал с Solr, но что-то в нем не понравилось. Не тянет меня к нему, нету внутри такого "о, вот это классный продукт"... Может мало работал.

Касательно п4 и п5, а точнее ElasticSearch... нужен ли он, или можно упереться на основную базу? Если нужен, то где именно? Вот вопрос возникает: Если, к примеру, используется для профилей основная БД, то есть ли смысл выгружать эти профили в ElasticSearch, тем самым получаем еще одну систему хранения профилей (дублирование), или стоит лить профили сразу в Эластик (т.е. используем ее как основную БД)? Если хранить профили и в основной БД и в ElasticSearch, то по какой методике синхронизировать (как часто?)? К примеру, я работал в одном проекте в связке Python\Django\Haystack\Solr, так в документации Haystack говориться, что в реал-тайме Solr лучше не индексировать, так как реал-тайм нагружает серьезно систему и лучшее решение - это делать периодическую индексацию.

6. Чтобы бы вы использовали для хранение изображений? Facebook Haystack Image Data Store?

Прошу прощение, что написал много, но "какой вопрос задашь, такой и получишь ответ". Хотелось показать комплекс и глубину вопросов, чтоб получить более "глубокий" ответ что-ли.

Если подвести краткий итог:
1. Какую БД вы бы использовать для "основных"\"статических" данных?
2. Какую БД вы бы использовать для динамических данных? Если in-memory - как бы "бекапили" на случай зависания? Репликой? Стоит ли сливать периодически данные в какую то БД на диск? Если "да", как определить это самое время?
3. Куда сохранять чаты?
4. Какую систему использовать под хранение гео данных и для поиска по запросам пользователей?
5. Нужна ли вообще такая система как ElasticSearch? Если да, то где происходит грань, "что брать из БД, что брать из Эластика"?
6. Где\как хранить фотки?

И общее для всех пунктов: хочется поработать с системами, которые не доставляют большой головной боли при "взрослении" проекта (репликация, шардинг).

Спасибо!
  • Вопрос задан
  • 2120 просмотров
Решения вопроса 1
1. Любую реляционную базу. MySQL, PostgreSQL или что угодно что вы умеете
2. Redis Cluster, ни ни как основное доверенное хранилище. только как кеш.
3. как и все - в реляционную БД
4. Весь поиск в ElasticSearch. Все фильтрации с гео - тоже туда. И не забывает про lookup фильтры. (это типа join'ы)
5. ElasticSearch тоже не доверенное хранилище. Пару раз обновите маппинг и поймете почему.
6. Glusterfs/Ceph - если хочется самому хранить. amazon s3 - если хватит на него денег.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
Stalker_RED
@Stalker_RED
Вы написали огромную стену текста, но даже не попытались почитать как сделано у тех самых гигантов, которые вы перечисляете? Это ведь не секретные техники, почти у всех есть дев-блоги, многие на конференциях доклады дают, куча лекций по хайлоаду.

А вот и "глубокий" ответ: если вы думаете, что существует волшебный универсальный рецепт типа "все чаты храним в %databasename%", и "все фотки храним в %storagename%", то вы ошибаетесь. Придется учитывать специфику проекта, проводить сравнение разных подходов на реальных данных, и так далее.
Ответ написан
Kwisatz
@Kwisatz
Больше web-приложений, хороших и разных
На половину оптимизационных вопросов гуглите YAGNI.
По бд возьмите PostgreSQL или Oracle. В обоих есть инструменты для решения всех ваших вопросов. Естественно оракловая база стоит немалых денег.
На NoSQL вообще не смотрите. Единственный сценарий использования NoSQL это таблицы фактов (как например лента пользователя) когда сами данные важнее связей между различными сущностями.
Ответ написан
Acuna
@Acuna
Заполнил свой профиль
О хранении картинок расскажу. У ВК тут все просто на самом деле: имеется просто куча своих серверов дабы не забивать каналы хостера трафиком, в БД хранятся прямые ссылки на эти картинки, привязанные к id каждого поста. Прелесть этого метода в том, что при переезде на новые сервера на них можно создать такую же структуру папок и никакие ссылки менять не нужно. Простые смертные, разумеется, ни VPN, ни даже выделенные сервера для хранения чего-либо не используют в принципе - трафик забьет все каналы хостера уже при 1000 хостов в день, да и место невообразимо дорого. Используются системы хранения типа Amazon S3 или Google Cloud Storage - оплачивается объем занятого места и объем скачанного исходящего трафа (просмотр юзерами фоток - это, по сути, их скачивание). Экономия раз в 10 получается. Серьезно.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы