Котк души - структура большой базы. Очень прошу помочь

Spear

почемучка
Крик души - структура большой базы. Очень прошу помочь

Здравствуйте!
Сразу хочу (сразу!) поблагодарить всех участников РНР клуба, особенно тех, кто мне помогал. несмотря на мои, иногда глупые, вопросы - я неплохо поднял свой уровень кодинга на РНР, успешно віполнил много заказов, стараюсь писать правильно и красиво.

Очень хотел поблагодарить, чесслово.

А теперь по теме - у меня просто огромнейшая проблема.
Я разрабатываю сервис блогов, который в будущем будет развиваться и собирается дорасти до социальной сети внушительных размеров (блоги, соц. закладки, соц. новости, сети вроде фейсбука).

Единственная проблема у меня в данный момент - это реализация базы данных.
Речь идет н ео связи и прочих шткуках, для помощи в которых мне пришлось бы полностью описывать структуру бд.

Проблема для кого-то, возможно, и тривиальна, но для меня - это закрытые двери.
Я говорю о том, как правильно хранить огромного размера базы данных?

Например таблица с записями в блогах.
Каждая текстовая запись блога будет создавать минимум 1 запись в эту таблицу. Кроме этого, в эту таблицу записываются также и записи картинок, загруженного видео.

Грубо говоря:
post_id - номер записи
blog_id - идентификатор блога
p_type - тип сообщения ('txt' - текст, 'img' - картинка, 'vid' - видео, 'mp3' - аудио-запись).
content - текст записи (для картинок и файлов это будет описание, например)

Не думаю что есть смысл приводить детальную структуру этой таблицы.

После запуска проекта, рекламы и продвижения, после того как он соберет свою аудиторию (а мы уверены что та коно и будет, т.к. у нас есть ряд преимущество перед другими сервисами Рунета и локализованных западных (Livejournal) - эта таблица распухнет до десятков миллионов записей (например сообщение в 15 фотками - это уже 16 записей в таблицу).

Ради интереса я смотрел исходники популярного (но более чем неаккуратно написанного) WorpdressMU - там разработчики делают набор таблиц для каждого блога. То есть на каждый зарегистрированный блог создается таблица:
posts
comments

и так далее. (выглядит как 1_posts, 1_comments). Я незнаю, чем они руководствовались, но видимо чем-то да руководствовались.

Был вариант поступать подобным образом, но в одном наборе таблиц хранить не 1 блог а, скажем, 1000.
Но в таком случае крайне нудобно выводить, скажем, каталог всех картинок, которые люди опубликовали в своем блоге - т.к. все они будут в разных наборах таблиц. Это не невозможно, просто крайне неудобно. И, почему-то, мне кжается что неправильно.


Я попытался посомтреть исходники того же LiveJournal (это OpenSource) - но проблема в том что мои познания в перле заканчиваются примерно на том, что вверху каждого файлика там, зачем-то, пишут # usr/bin или что-то такое )

Форумчане. профессионалы, опытные кодеры - я ОЧЕНЬ сильно надеюсь и расчитываю на вашу помощь. я не прошу написать мне код или что-то подобное - я прошу просветить меня, как эту проблему решают взрослые дяди?

Навряд ли тот же blogger.com держит все десятки миллионов записей в одной таблице?

Сразу хочу сказать что у нас уже выделены под проект два сервера - один под движок, скрипты, второй под файлы. В будущем сервера будут докупаться - то есть я не морочу Вам голову лишь бы для того, чтобы сделать блог-сервис на 30 человек, который будет хоститься на хостинге за 5 долларов в месяц.

Очень, очень на Вас надеюсь. Это уже просто крик души!

Блоговая часть нашего проекта будет похожа на vox.com
 

HraKK

Мудак
Команда форума
разработчики делают набор таблиц для каждого блога.
Бредово звучит, ибо при больших обьемах начнет тормозить FO

-~{}~ 05.11.07 16:58:

После запуска проекта, рекламы и продвижения, после того как он соберет свою аудиторию (а мы уверены что та коно и будет, т.к. у нас есть ряд преимущество перед другими сервисами Рунета и локализованных западных
Я бы так не надеялся. Если вы не можете спроектировать таких мелочей, то ваша вся система ляжет очччень быстро от нагрузок. Независимо от базы.
Если у вас такие грандиозные планы - наймите программиста, и лучше не одного.
 

Spear

почемучка
HraKK
я понимаю, что веры в меня у Вас не много :) но те мне менее маоя задача - разработка. Да и я бы не стал назвать вопрос о нагрузке на БД "мелочами". Это единственное, с чем у меня возникли проблемы.

Народ, пожалуйста, помогите делньыми советами, ссылками. Или все рождаются с этой информацией сразу в голове? :)
 

HraKK

Мудак
Команда форума
таблица распухнет до десятков миллионов записей (например сообщение в 15 фотками - это уже 16 записей в таблицу).
10.000.000*15*50кб хотябы фотка = 7,5 Тета байт,
вы выделите стока места? Спуститесь на землю совет.

-~{}~ 05.11.07 17:03:

Spear
Дельный совет - учите орфографию.

-~{}~ 05.11.07 17:04:

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

-~{}~ 05.11.07 17:06:

Spear
Вы хоть знаете что такое распределенная архитектура?
 

Spear

почемучка
7,5 Тета байт,
вы выделите стока места?
несколько серверов помогут решить эту проблему.
Потому-то я и пытаюсь узнать как правильно решать эту проблему. Просто докупить 2-3 сервера с парой терабайт на дисках ведь не решать проблему - нужно научить движок понимать что есть второй, третий, десятый сервер.

Вы хоть знаете что такое распределенная архитектура?
нет. пожалуйста, просветите меня! Я серьезно. Я не буду обижаться ни на какие выпады в мою сторону - мне необходимо понять как правильно делать проект.
 

HraKK

Мудак
Команда форума
Spear
Понимаете, такие проекты относятся к классу высоконагруженых, и лишь одним знанием тут не оберешся. Очень много подводных камней, набиваемых только на практике. Могу вам с 100% гарантией сказать что бы вы не сделали, вам при средней нагрузке уже придется все переделывать.
 

Spear

почемучка
нанивать разработчика - не вариант :( Поэтому все что мне остается это совершенствовать свой уромень знания БД, РНр, нагрузок.

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

Ведь тут однозначно есть люди, которые реализовали подобноЕ, или знают как это правильно делаться.
Буду благодаре нза ссылки на статьи, или подсказки - куда копать. Правда копаю я не очень :)
 

Ralph

Дикий столяр
Странно,докупить два-три-восемь серверов-это легко реализуемый вариант,а нанять квалифицированного разработчика-это не вариант ??? :-/
 

MiksIr

miksir@home:~$
В двух словах... вам нужен архитектор. Если по существу:
Первая стадия - горизантальное маштабирование, т.е. увеличение кол-во серверов и репликация между ними, вторая стадия -
партишенинг, т.е. разделение данных по каким-то признакам (наример, дата, логин пользователя и т.п.) по разным таблицам (которые в свою очередь на разных серверах и т.д.)
Только, рассуждения о стать N1 в рунете и отсутствие возможности брать квалифицированный персонал... success story подобные можно на пальцах перечесть, и все они испытывали огроооомные проблемы в детский период, т.е. переделывали все заново.
 

Spear

почемучка
MiksIr
вопросик - то есть даже если вдыелить 1 сервер под таблицу записей (posts) - это вариант?
Просто мне казалось что как-то разбивают таблицу, черт его, правда знает, как.

Прорепликацию тоже ничего не знаю - буду исктаь. Сейчас читаю Inside LiveJournal's Backend, спасибо magicу.
 

MiksIr

miksir@home:~$
кому-то вариант... а кому-то и нет и он будет одну эту таблицу разносить на несколько серверов. Например, кому нужны старые записи в блогах? Ну почти никому по сравнению с новыми записями - можно их разделить. Или хранить посты разных юзеров на разных базах.
Работа с такими распределенными хранениями подразумевает, что у Вас есть хороший проект, и Вы знаете какие данные, какие их сочетания и в каких местах Вам нужны. После этого под эти требования проектируется архитектура.
 

Spear

почемучка
MiksIr
Отлично, супер!
Спасибо. Я уже более-менее представляю как нужно работать, как буду потом рзаделять.

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

Но можно убрать на другой(другие) сервера записи, которые не предназначены для публичног опросмотра (эти записи текстов\картинок\файлов\мущыки) не должны появляться в общем списке, да и вобще нигде кроме как в блоге конкретного пользователя не фигурируют.

Хорошо, действиетльно.

Дочитаю\доизучаю тот док. ЛайвЖурнала и буду искать хороший материал, который нормально объяснит как правильно использовать репликацию.

Спасибо всем за помощь! Если будут ещё дополнения или ссылки - буду только благодарен. Топик обновляю регулярно.

ещё рза спасибо огромное!
 

HraKK

Мудак
Команда форума
Разрешите пожелать вам успеха) Я в это правда не верю в силу скептизма, но... Хочется что бы даже такие самопальные проекты чего-то добились.

Но предупреждаю сразу - лучше подстелите солому.
Сорри за офтоп.
 

Spear

почемучка
HraKK
Спасибо :) я уже знаю намног обольше по данному вопросу, чем часа три назад. Я верю что все поулчится :)
 

HraKK

Мудак
Команда форума
Spear
Самое плодотворное что ты можешь вынести из общения в этом треаде это сознание того что ты нечего незнаешь. Все остальное будет коственно.

Думаю стоит поступить так - не заморачивайся на 10.000.000 юзерах. Заморочся на 10.000 на 1 сервере. Если тенденция будет хорошая, то заплатить 5-10к за такой проект думаю не составит труда?
 

Spear

почемучка
HraKK
в общем-то не составит, конечно. Но даже не 10к юзеров а 8к могут притормозить сервер. Допустим в среднем каждый будет делать по записи в день (кто-то ни одной не сдлеает, кто-то сдлеает 2-3).
8к записей в день. Из этих записей, скажем, каждая восьмая (~ 1к записей) будет содержать 2 картинки.
Т.к. каждая картинка это дополнителньая запись в базу постов то получаем ещё 2к записей. Итого в день имеем 10к записей в таблицу постов. Год - 365 000 записей.

С одной стороны не много, с другой - все равно придется писать по-взрослому. И даже если придется принимтаь в команду ещё одного (двух, пятерых) кодеров - хотелось бы, чтобы они не переписывали все с нуля.

Да и в себя я тоже, в общем-то, верю :)

Ещё раз всем спасибо,
допонления приветствуются ;)
 

Mols

Новичок
Думаю если бы у меня были подобные задачи (страшно даже подумать о таком))) - я бы точно смотрел в сторону PostgresQL.
 

Gas

может по одной?
Spear
При таких вопросах проект под описанные нагрузки сделаете врят-ли, зато скилзы можно проказать очень хорошо :)
 
Сверху