Вопрос по PHP/MySQL: философия в highload приложениях

[Mentos]

Вопрос скорее к Chesser'у и прочим гуру.
Пишу крупную БД, подскажите как делать структуру.

К примеру возьмем теоритический форум на PHP/MySQL с 1 миллиардом юзеров.

Есть классическая таблица users
id | email | password

Вот вопрос например подписи пользователей хранить в таблице users или создавать отдельную таблицу user_signature?
user_id | signature

т.е. крупные БД можно увеличить в горизональном положении? или это очень плохо сказывается на производительности? какие проблемы возникают?
какие вообще минусы или разницы нет?

в данный момент я все данные юзера держу в одной таблице users, во тне знаю правильно ли делаю

__________

Сразу же второй вопрос: как highload проектах делается бэкап? и восстановление?

у меня пока план такой - я буду делать репликацию БД на несколько серверов

__________

Третий вопрос: Я по плану собираюсь для повышения производительности, при изменении/добавлении в БД использовать мастер сервер, при просто чтении данных (select) использовать сервера реплики - хороший план? какие минусы и какие особенности такой схемы?

так же я собираюсь на всякий случай делать в ручную полный бэкап на отдельный сервер

но вот предположим ситуацию что хакер на мастер сервере сделает команду удаления всей БД, в след за мастером очистятся все слейв сервера - как потом мне с другого сервера восстановить бэкап, например он будет весить 500 GB

__________

Четвертый вопрос: допустим БД будет очень огромная, 20 TB - как реализовать и использовать такую БД?
просто сервак взять не получиться, не хватит места. Нужно смотреть в сторону облачных решений? как на них организовать безопасную и быструю работу? можно будет тупо с главного сервера выполнять все запросы select, update... и все будет так же быстро ? бэкап в ручную просто в другое облако?

[editeur]

т.е. крупные БД можно увеличить в горизональном положении? или это очень плохо сказывается на производительности? какие проблемы возникают?
какие вообще минусы или разницы нет?

горизонтально - значит храним _одну_ таблицу на разных серверах, деля ее по ключам, а не разбиваем ее на две, связанные 1 к 1.

Третий вопрос: Я по плану собираюсь для повышения производительности, при изменении/добавлении в БД использовать мастер сервер, при просто чтении данных (select) использовать сервера реплики - хороший план? какие минусы и какие особенности такой схемы?

план хороший, если нет очень частых записей, иначе схема может не справиться с нагрузкой

Четвертый вопрос: допустим БД будет очень огромная, 20 TB - как реализовать и использовать такую БД?
просто сервак взять не получиться, не хватит места.

смотри в торону шардирования таблиц. Например все пользователи с хешем фамилии, который при делении на 10 дает в остатке 0, лежат на первом сервере, остаток 1 - на втором и т.д. Соответстввенно твой скрипт делает обращения к разным серверам в зависимости от запроса. От SQL в этом случае можно что-то оставить, а можно и не оставлять, использовать тот же mysql только как key-value хранилище. С таблицами таких размеров ты все равно как привык - запросы с джойнами нескольких таблиц - работать скорее всего не сможешь, сортировки будут класть сервер наглухо.

но вот предположим ситуацию что хакер на мастер сервере сделает команду удаления всей БД, в след за мастером очистятся все слейв сервера - как потом мне с другого сервера восстановить бэкап, например он будет весить 500 GB

при миллиарде пользователей тебя будут волновать уже другие вопросы

[Mentos]

Сообщение от editeur

горизонтально - значит храним _одну_ таблицу на разных серверах, деля ее по ключам, а не разбиваем ее на две, связанные 1 к 1.

т.е. например делаем 10 серверов

пишем хеш функцию например от email которая будет отдавать значение от 1 до 10

далаее на 10 серверах храним разных юзеров?


может вообще нафиг все это, просто использовать 1 облачный сервак, какие минусы?

Сообщение от editeur

план хороший, если нет очень частых записей, иначе схема может не справиться с нагрузкой

запросов как раз таки теоритически будет очень много(
в секунду от 5 - 20 запросов

Сообщение от editeur

смотри в торону шардирования таблиц. Например все пользователи с хешем фамилии, который при делении на 10 дает в остатке 0, лежат на первом сервере, остаток 1 - на втором и т.д. Соответстввенно твой скрипт делает обращения к разным серверам в зависимости от запроса. От SQL в этом случае можно что-то оставить, а можно и не оставлять, использовать тот же mysql только как key-value хранилище. С таблицами таких размеров ты все равно как привык - запросы с джойнами нескольких таблиц - работать скорее всего не сможешь, сортировки будут класть сервер наглухо.

кстати БД мне нужна с транзакциями, щяс использую InnoDB
запросы с джойнам вообще не использую

Сообщение от editeur

при миллиарде пользователей тебя будут волновать уже другие вопросы

ну просто хотелось бы понять заранее, чтобы потом не останавливать систему и не думать что за пиздец твориться


кстати а кластер можно как то реализовать без глубоких знаний, или это очень сложно? может софт есть готовый

[editeur]

может вообще нафиг все это, просто использовать 1 облачный сервак, какие минусы?

Минусы в том, что облачные серваки лежат на обычных железках.
Такие вещи _все_ делают горизонтальным шардированием. Смотри в сторону map-reduce.

в секунду от 5 - 20 запросов

Это хуйня, а не нагрузка, если при этом не перестраивается куча индексов.
В принципе если бы у тебя была всего одна таблица, это бы потянул один сервак. Но у тебя же там их много, все с индексами и прочим.

ну просто хотелось бы понять заранее, чтобы потом не останавливать систему и не думать что за пиздец твориться

Я ж говорю, если напишешь систему, которая будет при таких нагрузках хоть как-то ворочаться, и там действительно наберется пусть не миллиард, пусть миллион пользователей, этот вопрос решится сам собой.
Можно придумать кучу вариантов. Можно например все запускать на виртуалках и бэкапить образ виртуальной машины.
В любом случае это все не так просто, там же будут еще кэши и прочее, надо будет продумать как поднимать эти кэши, что делать, если после простоя все эти миллиард нетерпеливых пользователей кинутся логиниться, все сразу, и будут этим потоком класть раз за разом сервер и т.д. Что делать со статистикой и логами.

кстати БД мне нужна с транзакциями, щяс использую InnoDB
запросы с джойнам вообще не использую

Если честно не думаю, что для форума с такой нагрузкой так уж нужны транзакции. Механизм разрешения конфликтующей инфы в БД думаю будет лучше, если у тебя такм конечно не проводятся финансовые транзакции. И на таком объеме данных, кроме джойнов, сервер будет класть сортировка, или там какой-нибудь select count(*) where ...

да, и еще ты похоже несколько оптимистичен насчет 20 транзакций в секунду. Если у тебя там миллиард пользователей и каждый из них просто логинится 1 раз в 10 дней, получаем 100 миллионов логинов в день. Эти логины надо где-то как-то сохранять, сессии там и прочее, получаем уже больше тысячи событий в секунду, и это только логины пользователей, больше ничего. И эти 1000/сек распределены неравномерно, будут часы, когда будет 5000, и будут когда 500. Даже если для сессий используются кэши, это все равно уже очень серьезная нагрузка.

[Mentos]

Сообщение от editeur

да, и еще ты похоже несколько оптимистичен насчет 20 транзакций в секунду. Если у тебя там миллиард пользователей и каждый из них просто логинится 1 раз в 10 дней, получаем 100 миллионов логинов в день. Эти логины надо где-то как-то сохранять, сессии там и прочее, получаем уже больше тысячи событий в секунду, и это только логины пользователей, больше ничего. И эти 1000/сек распределены неравномерно, будут часы, когда будет 5000, и будут когда 500. Даже если для сессий используются кэши, это все равно уже очень серьезная нагрузка.

ну 20 запросов это сейчас

в будущем я хз сколько будет

вобщем буду делать одни большие таблицы, master server и 2 слейва
в случае отказа мастера, быстро делать новый мастер из старого слева


я так подумал у меня в БД вся инфа может делиться на нужную сейчас и старую-архивную

т.е. часто буду чистить БД и переносить мусорные записи на другие сервера, тем самым децентрализуя БД

[Jeff]

А у тебя вот прям сразу планируется миллиард пользователей? Или развитие будет таки постепенным? Я бы посоветовал тебе так сильно сейчас не заморачиваться этими делами, так как все равно это все прийдется переделывать нафиг конга соберется "миллиард" пользователей :-) Ты извини, но судя по твоим вопросам ты не совсем понимаешь что такое просто проектирование БД и как оно работает. Так что мне кажется что наиболее грамотной стратегией будет разработать проект без оглядки сразу на "миллиард" пользователей, а когда пользователей станет действительно много, то проект должен начать приносить прибыль и в этот момент уже можно нанять грамотную команду, которая этот проект напишет как надо.

[arma]

Ты походу слишком загружаешь себя пока что ненужной фигней.
20 запросов в секунду к БД - не нагрузка это, пару К в секунду тоже не сильная нагрузка в наше время.

Сейчас пример покажу:
300-3к запросов в секунду к MySQL,
это один сервер c3.xlarge на Amazon,
load в районе 0.1
При том что на DB-сервере еще и Gearman, Redis, Memcached крутится.

Бэкап через Percona XtraBackup (MySQL сервер тоже на Percona).

Делать MySQL slave под SELECT запросы - правильно думаешь.


Я за то чтобы не усложнять жизнь самому себе.
Когда наметится реально охуенный рост - тогда уже будешь думать о перейстройке на всякие шардирования итд.

О сильном росте БД - мы для себя решили что будем складывать что можно в Mongo или Cassandra на отдельных серверах, вместо того чтобы давать MySQL разрастись до терабайтов.

[lorien]

+1 к постам jeff и arma

По поводу миллиарда пользователей. Есть такой сайтик - вконтакте. Так вот там всего 250 миллионов пользователей

[chizer]

Та вы не понимаете. Современные разрабы настолько суровы, что делают сайты с поправкой на хрумер

[GameAgregator]

Сообщение от lorien

+1 к постам jeff и arma

По поводу миллиарда пользователей. Есть такой сайтик - вконтакте. Так вот там всего 250 миллионов пользователей

Так, может, ТС и FB просчитал как обогнать по трафу... а вы ВК
А вообще да, вопрос задан как бы теоретический с миллиардом пользователей, но на самом деле лучше далеко от практики не уходить