УСЛОВИЕ:
- В рассматриваемой СоцСети есть сущности КОЛИЧЕСТВО ЛАЙКОВ и СОСТАВ ПОЛЬЗОВАТЕЛЕЙ НАЖАВШИХ ЛАЙК.
- Лайки ставятся только КОММЕНТАРИЯМ пользователей к этим фотографиям.
- Лайки ставят ПОЛЬЗОВАТЕЛИ в реальном времени и отображаются они в реальном времени(как в ВК).
- На веб-странице выводится ~10 фотографий(РАНДОМНО) и 10 комментариев к каждой фотографии, у каждого комментария ~10-200 лайков , но вместе с цифрой кол-во лайков выводится СОСТАВ(список) ВСЕХ ПОЛЬЗОВАТЕЛЕЙ НАЖАВШИХ ЛАЙК.

ПРЕДПОЛОЖИТЕЛЬНАЯ структура хранения данных и ОБЪЕМ:
- реляционная нормализованная модель
- таблица ПОЛЬЗОВАТЕЛИ 100'000 записей
- таблица ФОТОГРАФИИ 1'000'000 записей
- таблица КОММЕНТАРИИ 5'000'000 записей (в ней же хранится счетчик лайков для каждой записи)
- таблица "СОСТАВ ВСЕХ ПОЛЬЗОВАТЕЛЕЙ НАЖАВШИХ ЛАЙК" 5'000'000 записей(содержит все ID коментариев и сериализованный список ID пользователей лайкнувших комментарий)
- таблица "УЧЕТ ЛАЙКОВ" (лайков/дизлайков) 500'000'000 записей (реализует связь многие-ко-многим между таблицами "ПОЛЬЗОВАТЕЛИ" и "КОММЕНТАРИИ")

КОЛИЧЕСТВО ОПЕРАЦИЙ в средней пиковой нагрузке:
- Лайков ~200шт/сек (предположительно 200 инсертов и 400апдейтов - 1 лайк это 1 Insert(в таблицу "УЧЕТ ЛАЙКОВ" и 2 Update (в таблице "КОММЕНТАРИИ" обновляется кол-во Лайков, в таблице "СОСТАВ ВСЕХ ПОЛЬЗОВАТЕЛЕЙ НАЖАВШИХ ЛАЙК" обновляется сериализованный список ID пользователей лайкнувших комментарий)
- Запросов Веб-страницы ~100 шт в секунду ( Select 300шт и Insert 100шт - 100шт таких последовательных запросов (Select 10_из_1млн"ФОТОГРАФИИ" JOIN 100_из_5млн"КОММЕНТАРИИ" +ПЛЮС+ *Select (10000/50)200_из_1МЛРД "УЧЕТ ЛАЙКОВ" +ПЛЮС+ *INSERT (100/50)2_из_5млн "СОСТАВ ВСЕХ ПОЛЬЗОВАТЕЛЕЙ НАЖАВШИХ ЛАЙК" +ПЛЮС+ Select 5тыс_из_100тыс "ПОЛЬЗОВАТЕЛИ")
* Использование кэширования(memcached) результатов для СОСТАВА ЛАЙКНУВШИХ ПОЛЬЗОВАТЕЛЕЙ в виде ключ-значение снижает нагрузку по SQL запросам чтения в 50 раз.

ЦЕЛЬ:
Наибольшая производительность при выполнении SQL запросов чтения/записи для указанного выше примера

ЗАДАЧА:
- определиться с архитектурой хранения данных в таблицах реляционной модели БД и инфраструктуру БД(репликации и их режимы чтения / записи , масштабируемость и горячий резерв)

ЖДУ ВАШИХ МНЕНИЙ

PS:
- желательно исходить из того что это будет MySQL или ее форк(maria,percona) ЕСЛИ ЭТО КОНЕЧНО ВОЗМОЖНО
- sql запросы на чтение в нормализованной реляционной модели выглядят очень страшно(много соединений таблиц) и похоже не смогут уложиться в заданные рамки


PPS: Хотелось бы услышать мнение по поводу следующего:
Инфрастрктура БД: СУБД MySQL Чтение данных осуществляется только из read-only экземпляров реплицирующих master(write).
Возможно ли настроить экземпляры таким образом чтобы каждый из них работал только со своим Партишеном(например в таблице "КОММЕНТАРИИ" записи распределяются по партишенам по 1млн записей и т.д.) или с определенной таблицей - т.е. чтобы на уровне инфраструктуры серверов один ТЯЖЕЛЫЙ запрос распределялся самой СУБД между несколькими read-only экземплярами (например при выполнении Select с JOINом из одного экземляра читались данные из одной таблицы, а из другого из второй таблицы(ну и по аналогии с партишенами)) ??

наверное все спят...

LSVMalterнаверное все спят много букв ...поправил :) Учитесь краткости.
Кратко: как хакнуть мускуль чтобы он летал как оракаль...

Вкратце суть такова:
Есть страница с ФОТОГРАФИЯМИ и КОММЕНТАРИЯМИ к ним, а у каждого КОММЕНТАРИЯ есть ЛАЙКИ и СПИСОК ЛАЙКНУВШИХ .
Нужно в реальном времени отображать эти СПИСКИ ЛАКНУВШИХ - т.е. как только где-то кто-то лайкнул КОММЕНТАРИЙ , то следущая загрузка этой страницы должна уже содержать в СПИСКЕ ЛАКНУВШИХ этот лайк (это я называю В РЕАЛЬНОМ ВРЕМЕНИ ).

Нужны советы как по структуре хранения данных так и по инфраструктуре СУБД, чтобы держать 1) нагрузку в 200 лайков/сек и 2) 100 загрузок сраниц/сек

Более подробно в начале ))

mad_nazgulMalter,

На сколько мне известно у MySQL есть решение для In Memory DB.
Там есть ограничения по ACID, но думая для лайков это не критично.
Может быть посмотреть в эту сторону?

Что такое "решение для In Memory DB"(ссылку если можно)? или это таблицы memory ?
транзакции не нужны, но нужно надежное хранение чтобы при внезапном low-votage данные не пропали - т.е. нужно однозначно дублировать данные на диск.

Жоао1) КОЛИЧЕСТВО ЛАЙКОВ и СОСТАВ ПОЛЬЗОВАТЕЛЕЙ НАЖАВШИХ ЛАЙК — это не сущности
2) модель у вас получается денормализованная и-за «сериализованного списка ID пользователей лайкнувших комментарий»
3) подозреваю, вам хватит таблицы "УЧЕТ ЛАЙКОВ": id_comment, id_user, like_or_dislike (bool)

1) это сущности, но не предметной области, а функционала программы (слова "в рассматриваемой СоцСети" следует читать как "в рассматриваемом функционале СоцСети")
2) да, денормализованная - здесь слова "реляционная нормализованная" использованы чтобы подчеркнуть исходную модель хранения информации
3) для хранения конечно хватит, а как быть со скоростью доступа к этим данным ? справится ли mysql с поставленной задачей?
спасибо

ЖоаоMalterа как быть со скоростью доступа к этим данным ? справится ли mysql с поставленной задачей?
Как всегда, все зависит от железа, нагрузки, качества проектирования… от того, какие у вас буду затраты на сериализацию и параллельное заполнение двух таблиц вместо одной . Ваш денормализованный вариант явно будет быстрее, если все заранее заполнено и обновляется редко.
это все какбэ понятно - лучше сделаешь лучше будет работать )))
вопрос в другом и он подробно расписан

fixxerЧто если выйти за пределы SQL и RDBMS? Handling five billion sessions a day – in real time
Можно мечтательно посмотреть на это )) но у меня столько скилла нету - слишком много незнакомых слов (kafka, storm, Amazon EMR, Hadoop, cassandra)

ЖоаоMalterэто все какбэ понятно - лучше сделаешь лучше будет работать )))
вопрос в другом и он подробно расписан
Вопрос именно не в другом: вы запроектировали себе гору проблем в виде «сериализованного списка ID», хранимого параллельно с нормальной таблицей. Поддержание этого списка в актуальном состоянии потребует частых UPDATE (т.е. блокировок при каждом новом лайке однажды лайкнутого комментария) там, где в правильной таблице будут частые INSERT и, возможно, очень редкие DELETE. Проведите эксперимент, когда, напр., два пользователя одновременно ставят лайк, еще один удаляет, а четвертый «меняет знак» лайка. Возможно, вам будет счастье.
Да именно в этих узких местах и вопрос. Я еще на запроектировал, а ищу решение.
Думал что кто-нибудь поделится опытом и расскажет про инфраструктуру которая поможет это решить (репликация, отдельные рид райт инстансы).

ШайтанПростите, что вмешиваюсь :)

а какое отношение "нагрузку в 200 лайков/сек" имеет к "БД с данными реального времени " ???
Здорово что вмешиваетесь.
Только я вашего вопроса не понял совсем. Что вы хотели спросить?

ШайтанMalterпропущено...

Здорово что вмешиваетесь.
Только я вашего вопроса не понял совсем. Что вы хотели спросить? да именно то и спросил: "а какое отношение "нагрузку в 200 лайков/сек " имеет к "БД с данными реального времени " ???"
что такое вообще 200 лайков в сек для современной БД? так, один раз чихнуть
при чём тут упоминание о реальном времени ?
200 лайков - это 200 изменений в данных, которые должны быть использованы сразу же в последующих запросах чтения (300селектов/сек).
Вот и хотел узнать как современная БД mysql способна с этим справится, но не за счет увеличения производительности железа, а за счет всяких хитрых и не очень хуков.