Форум успешных вебмастеров - GoFuckBiz.com

  Форум успешных вебмастеров - GoFuckBiz.com > Бизнес-решения > Скрипты, программы и технические решения
Дата
USD/RUB59.0900
BTC/USD0.0000
Скрипты, программы и технические решения Обсуждаем скрипты, программы и новые технологии.

Закрытая тема
Опции темы Опции просмотра
Старый 31.03.2014, 17:01   #1
Mentos
VM
 
Регистрация: 03.10.2013
Сообщений: 175
Бабло: $56020
По умолчанию Вопрос по PHP/MySQL: философия в highload приложениях

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

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

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

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

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

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

__________

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

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

__________

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

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

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

__________

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

Последний раз редактировалось Mentos; 31.03.2014 в 17:11.
Mentos вне форума  
Старый 31.03.2014, 18:07   #2
editeur
Senior Member
 
Регистрация: 27.09.2013
Сообщений: 620
Бабло: $89330
По умолчанию

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

Цитата:

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

Цитата:

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

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

Последний раз редактировалось editeur; 31.03.2014 в 18:13.
editeur вне форума  
Старый 31.03.2014, 18:25   #3
Mentos
VM
 
Регистрация: 03.10.2013
Сообщений: 175
Бабло: $56020
ТС -->
автор темы ТС По умолчанию

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

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

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


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


Цитата:
Сообщение от editeur Посмотреть сообщение
план хороший, если нет очень частых записей, иначе схема может не справиться с нагрузкой
запросов как раз таки теоритически будет очень много(
в секунду от 5 - 20 запросов

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

Цитата:
Сообщение от editeur Посмотреть сообщение
при миллиарде пользователей тебя будут волновать уже другие вопросы
ну просто хотелось бы понять заранее, чтобы потом не останавливать систему и не думать что за пиздец твориться


кстати а кластер можно как то реализовать без глубоких знаний, или это очень сложно? может софт есть готовый
__________________
-
Mentos вне форума  
Старый 31.03.2014, 18:49   #4
editeur
Senior Member
 
Регистрация: 27.09.2013
Сообщений: 620
Бабло: $89330
По умолчанию

Цитата:
может вообще нафиг все это, просто использовать 1 облачный сервак, какие минусы?
Минусы в том, что облачные серваки лежат на обычных железках.
Такие вещи _все_ делают горизонтальным шардированием. Смотри в сторону map-reduce.
Цитата:
в секунду от 5 - 20 запросов
Это хуйня, а не нагрузка, если при этом не перестраивается куча индексов.
В принципе если бы у тебя была всего одна таблица, это бы потянул один сервак. Но у тебя же там их много, все с индексами и прочим.
Цитата:
ну просто хотелось бы понять заранее, чтобы потом не останавливать систему и не думать что за пиздец твориться
Я ж говорю, если напишешь систему, которая будет при таких нагрузках хоть как-то ворочаться, и там действительно наберется пусть не миллиард, пусть миллион пользователей, этот вопрос решится сам собой.
Можно придумать кучу вариантов. Можно например все запускать на виртуалках и бэкапить образ виртуальной машины.
В любом случае это все не так просто, там же будут еще кэши и прочее, надо будет продумать как поднимать эти кэши, что делать, если после простоя все эти миллиард нетерпеливых пользователей кинутся логиниться, все сразу, и будут этим потоком класть раз за разом сервер и т.д. Что делать со статистикой и логами.

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

да, и еще ты похоже несколько оптимистичен насчет 20 транзакций в секунду. Если у тебя там миллиард пользователей и каждый из них просто логинится 1 раз в 10 дней, получаем 100 миллионов логинов в день. Эти логины надо где-то как-то сохранять, сессии там и прочее, получаем уже больше тысячи событий в секунду, и это только логины пользователей, больше ничего. И эти 1000/сек распределены неравномерно, будут часы, когда будет 5000, и будут когда 500. Даже если для сессий используются кэши, это все равно уже очень серьезная нагрузка.
editeur вне форума  
Старый 31.03.2014, 19:32   #5
Mentos
VM
 
Регистрация: 03.10.2013
Сообщений: 175
Бабло: $56020
ТС -->
автор темы ТС По умолчанию

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

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

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


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

т.е. часто буду чистить БД и переносить мусорные записи на другие сервера, тем самым децентрализуя БД
__________________
-
Mentos вне форума  
Старый 01.04.2014, 11:03   #6
Jeff
Senior Member
 
Регистрация: 17.06.2010
Сообщений: 143
Бабло: $56380
По умолчанию

А у тебя вот прям сразу планируется миллиард пользователей? Или развитие будет таки постепенным? Я бы посоветовал тебе так сильно сейчас не заморачиваться этими делами, так как все равно это все прийдется переделывать нафиг конга соберется "миллиард" пользователей :-) Ты извини, но судя по твоим вопросам ты не совсем понимаешь что такое просто проектирование БД и как оно работает. Так что мне кажется что наиболее грамотной стратегией будет разработать проект без оглядки сразу на "миллиард" пользователей, а когда пользователей станет действительно много, то проект должен начать приносить прибыль и в этот момент уже можно нанять грамотную команду, которая этот проект напишет как надо.
Jeff вне форума  
Старый 01.04.2014, 16:03   #7
arma
Пионер
 
Аватар для arma
 
Регистрация: 21.12.2007
Сообщений: 197
Бабло: $37745
По умолчанию

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

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

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

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


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

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

Последний раз редактировалось arma; 01.04.2014 в 16:09.
arma вне форума  
Старый 01.04.2014, 23:26   #8
lorien
Senior Member
 
Аватар для lorien
 
Регистрация: 18.05.2009
Сообщений: 879
Бабло: $177835
Отправить сообщение для lorien с помощью Skype™
По умолчанию

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

По поводу миллиарда пользователей. Есть такой сайтик - вконтакте. Так вот там всего 250 миллионов пользователей
lorien вне форума  
Старый 02.04.2014, 18:19   #9
chizer
Senior Member
 
Аватар для chizer
 
Регистрация: 01.02.2011
Сообщений: 732
Бабло: $191845
По умолчанию

Та вы не понимаете. Современные разрабы настолько суровы, что делают сайты с поправкой на хрумер
chizer вне форума  
Старый 02.04.2014, 18:38   #10
GameAgregator
Senior Member
 
Аватар для GameAgregator
 
Регистрация: 17.11.2011
Сообщений: 137
Бабло: $38560
Отправить сообщение для GameAgregator с помощью ICQ Отправить сообщение для GameAgregator с помощью Skype™
По умолчанию

Цитата:
Сообщение от lorien Посмотреть сообщение
+1 к постам jeff и arma

По поводу миллиарда пользователей. Есть такой сайтик - вконтакте. Так вот там всего 250 миллионов пользователей
Offtopic
__________________
GameAgregator.com - конверт гемблинг трафика со всего мира. Казино, слоты, покер, рулетка, нарды. Есть решения под Android и iOS.
GameAgregator вне форума  
Закрытая тема



Опции темы
Опции просмотра