Состоялся тут вопрос о хранение информации в базе, но состыковка в том, что к примеру взять систему обмена сообщениями между пользователями. Если посмотреть на то, что есть некоторые любители активно попереписываться, то вопрос стоит боком о распределение данных. Разбивку на несколько серверов, в голове у меня не стыкуется. К примеру есть вывод сообщений списком, то коннект к двум серверам терпимо, а вот если 5-ть серверов? То тогда идут мысли о репликациях и кластеризации базы, но как сделать, вопрос стоит в этом. Так как может быть в таблице и 200кк записей, а это и места не мало... Может есть какие либо вариации другие?
Количество пользователей? Количество активных пользователей? Количество сообщений в сутки? Средний объем сообщения? Пока этого нет - говорить не о чем.
Количество пользователей ~ 200 000 Количество активных пользователей? ~ 70 000 Количество сообщений в сутки? ~ 1кк Средний объем сообщения ~ от 1кб с каждым днем больше естественно...стоит лимит на сообщения пока что, но это слишком
в текстовые файлы. По каталогам. Инициант/Реципиент/дата/сообщения Это для истории. Для поиска Sphinx. База то зачем?
Там не все на базах. Но в любом случае - смысл хранить эту информацию в базах? Она отлично лежит в файлах. При этом сплитится по пользователям на произвольное число серверов. Без бубна. При текущей активности всю дневную переписку всех пользователей вообще можно хранить в мемкеше или просто в памяти. В базе можно держать списки пользователей и контакт-листы.
Вообще я спрашивал про базу, а не как хранить это на файлах. А по другой пример реализации, я спрашивал тоже по mysql. Так что Ваши мессаги я считаю оффтопом, ошиблись разделом.
Epro Если Вы врете, то это ваши личные проблемы. Я полагаю, что рунетовские проекты генерирующие 1ГБ контента в сутки исключительно за счет ввода текста пользователями - можно пересчитать по пальцам. А таких чьи разработчики не знают с какой стороны подойти к репликации, пожалуй нет вовсе. Что касается репликации, то - Репликация MySQL Что из этого оказалось неподъемным для Вас?
Мне кажется это, уже не Ваши проблемы. Моё мнение неподъемным для ВАС писать по клавиатуре, раз Вы не можете просто ответить в данной ветке. Вопрос был задан по mysql, Вы мне про файлы. Так что не нужно лезть в чужой огород. Я в силах сделать то, что мне нужно, НО услышать мнение со стороны, тоже порой не мешает Я задал конкретный вопрос, а вы разводите тут дискуссии. Смените тематику форума, данная тема для Вас слишком серьезна.
Вроде mysql cluster ставишь и он сам все разруливает. Так же для сообщений можно использовать партирование. P.s. У человека не обязательно проект доступен для инета. Я знаю, что некоторые организации переводят внутренние десктопные приложения на веб. Слышал, что для SAP делают веб-интерфейсы. Поэтому, неудивительно, что какой-нибудь мегафон делает веб-интерфейс. И совсем не удивительно, что там будет 70 тысяч пользователей онлайн.
Kreker, проблема еще в том, что ресурсу с большими обьемами кластеризация понадобится ГОРАЗДО РАНЬШЕ для других частей системы, чем для системы обмена сообщений пользовователей. Поэтому Simpliest прав, что-то из сказанного - ложь.
myql cluster не спасет на таких объемах. захлебнется. я бы смотрел в сторону маленьких серверков и простого шардинга. хранить все в одном месте - заипаться. наделал бы каналов. распределил бы их и ни жужжал. суть в том: идет разговор. под него выделяется канал. канал мапится на сервак и там живет. а сока серваков воткнуть - зависит от нарузки. мало мощности. втыкаем сервер. мапим балансер и вуаля. все довольны. все упрется в мапинг канала/сервера, но тут много вариантов
440Hz Ммм, и как разрулить шардинг в случае персистентности истории? Я не работал с MySQL в этом направлении, но чисто логически, как мы будем делать выборки? Сегодня нас с Петей балансером кинуло туда, а Васю с Вовой на другой сервер, завтра наоборот - историю рамазало по серверам. В случае с тем же партиционированием по дате там можно более менее построить что,где. И в зависимости от этого выбирать к какому серверу делать запрос. А в случае когда мы просто равномерно размазываем данные по куче серверов - непонятно... Или я что-то не понимаю(не знаю)?
номер_серера = fun(А,Б); причем fum(Б,А) может быть на другом сервере. где А и Б говорящие, т.е. всегда один и тот же сервер. выборки БД соответственно тоже с них, а собрать на клиенте данные с 2-х серверов и показать. говно вопрос.
встает вопрос равномерного размазывания, но это совсем другая история и рассказывать ее должен балансер