Как лучше спроектировать базу MySql на несколько ТБ?

Question

[2slide]

В планах создать социальную сеть. Для определённого круга людей.
Будет использоваться LAMP (apache mysql php).
По подсчетам БД будет наполнятся на 100gb месяц.

Как лучше спроектировать БД.
1. Одну базу или несколько, одну для статей другую для комментариев..?
2. Как будет вести MySql при таких объемах? (все странички сайта будут кэшироваться и подружатся через аякс).
3. Если создать несколько бд например для комментариев то как искать нужную бд для вывода? (создать связывающую бд с индексами где будет хранится адрес сервера бд, а потом конектица и выводить нужные записи. Может так?

Буду благодарен за помощь.

Comments

[2slide]

Прошу не отвечать-Зачем социальная сеть. Еже есть. Социальные сети зло и т.д.

Answer 1

[SkyTaurus]

Вот тут Дмитрий Бородин CEO TopFace описывает как нужно делать архитектуру spb-borodin.livejournal.com/596.html

Comments

[NewTypes]

@skytaurus о, спасибо за ссылку на блог.

[2slide]

@SkyTaurus спасибо очень интересно.

[SkyTaurus]

и вот тут он же php.spb.ru

Answer 2

[Сергей]

Социальные сети зло. Не нужно их множить. =)

Comments

[2slide]

Смотря какие)

Answer 3

[Влад Животнев]

> Как будет вести MySql при таких объемах?
Х**во он себя будет вести через пару месяцев (ну или через 4 месяца, если у вас будет 256 гов памяти).
С другой стороны, 100 гб в месяц у вас там и не будет. А если и будет - то прекратите хранить в базе картинки и другую чушь.

> Если создать несколько бд например для комментариев то как искать нужную бд для вывода?
if comment_id < 1000000 and commend_id > 0 then use mysql1
if comment_id < 2000000 and comment id > 1000000 then use mysql2
Примерно так. А вообще это называется шардированием, как его организовывать - решать вам. Обычно делают метабазу, в которой хранят диапазоны id-шников и соответствия с конкретным сервером. К тому же на сервера со старыми комментариями нагрузка со временем будет и меньше и их можно будет "решардировать" - т.е., например, сливать 3 старых базы в 1 и править id-ники в метабазе. А 2 освободившихся сервера ставить под запись для новых комментариев.

> Одну базу или несколько, одну для статей другую для комментариев..?
Тупиковый путь, если объём данных станет больше определенного порога.
Станет много статей - загнется mysql со статьями, станет много комментариев - ....
В любом случае, нужно и делить по типу хранимых данных, и шардировать.

Answer 4

[NewTypes]

Кто-то где-то определенно врет. Как полмиллиона пользователей может сгенерировать 100гб за месяц? Вы там может сервис "в интернет по паспорту" пишете по заказу гос структур? Где на каждыцй пук - обязательный лог.
А нужен ли mysql?

Comments

[2slide]

может и 100 переборщил но 40 точно. Никто не говорил про полмиллиона. В несколько раз больше.

[NewTypes]

Я просто пробежался по предыдущим вопросам

[2slide]

Будем писать очень масштабный проект вот и вопросы появляются сами собой. Нужно продумать архитектуру.

Answer 5

[Егор Казанцев]

ну ну , данные вконтакте весят примерно 1ТБ и вконтакт для всех . Так что не фантазируйте про несколько ТБ

Comments

[kazmiruk]

Эм... Обычно бесит когда так говорят, но можно пруф? Очень интересно почитать сколько и чего у ВК.

[2slide]

@kazmiruk согласен. Вот www.insight-it.ru/masshtabiruemost/arkhitektura-vk...

[2slide]

@saintbyte Instagram - Через несколько месяцев суммарный размер базы данных перевалил за 60Гб www.insight-it.ru/masshtabiruemost/arkhitektura-in...

[kazmiruk]

@2slide спасибо, очень интересно. А по поводу оптимизации\не оптимизации - человек, отписавшийся выше и прав, и не прав одновременно, ИМХО. Если Вы уверены в количестве пользователей (есть уже пользовательская база и т.п.), то лучше заложить все сразу, так как на живой базе делать будет все очень трудно. Если это все только Ваши догадки (я про объемы данных), то лучше сделайте простейший прототип за пару месяцев с минимумом функционала, для того, чтобы понять куда дальше развиваться (почитайте 37 signals книжку). И раз зашла речь про интсаграмм - они используют очень интересный подход к шардингу, который позволяет заложить его сразу и только при необходимости масштабироваться + даже если написать весь код без учета шардинга, но используя их подход, то это значительно облегчит Вам жизнь в будущем. Статья - instagram-engineering.tumblr.com/post/10853187575/...

[kazmiruk]

@2slide ну и все таки за несколько месяцев инстаграмм имел базу в 60Гб, а Вы говорите про 100 Гб в месяц и терабайты суммарного объема БД.

[Сергей]

Человек хочет захватить мир. Чо вы паритесь

[Егор Казанцев]

@kazmiruk Да к ты бота напиши и проверь.
у меня получилось 10 гигов на id имя-фамилию от 180 млн. акков, при этом я не применял ещё никаких техник чтоб сократить объем. около 70 гигов весит Xml от 25 процентов акков. Аватары ... вот аватары могу весить много, но аватары тот же вк не хранит в базе.

[kazmiruk]

@saintbyte т.е. Вы написали бота, который спарсил весь вконтакт и определил, что вся база ВК весит 1Тб? Мне кажется, что реальные цифры значительно больше, так как кроме ФИО ВК хранит еще тексты некоторых постов, личные сообщения, группы, статусы названия\продолжительность аудио и видеозаписей и много чего еще. Вы просто указали довольно точную цифру и я подумал, что где-то пропустил раскрытие архитектурных особенностей и статистических данных ВК.

[Егор Казанцев]

@kazmiruk Да просто бот. Не я один такой - похоже тренд парсить вконтакт был пару лет назад 8) Сколько данных будет - зависит от вас: БД можно для скорости денормализировать как это делается в phpBB, а можно заняться нормализацией.