Как разбить базу?

[AndreyKl]

Как разбить базу?

В чём собственно вопрос: рано или поздно дискового места на сервере для базы данных начнёт нехватать. Каким образом разбивать базу данных?

Слышал, что у yahoo например, есть база (postgres) размером больше петабайта. Как они её хранят?

Может ли кто посоветовать что почитать-полистать по этому поводу?

Вопрос более подробно

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

1. для того, чтобы удалять файлы сейчас приходится ставить картинке специальное состояние в базе "ожидаетУдаления". И на конкретном сервере запускать раз в минуту по крону скрипт по который удаляет с диска файлы (WHERE idServer='currentId' AND state='waitingForRemove).

2. Сейчас невозможно как либо просто сделать картинку аватаром, поскольку сервера для хранения аватара и картинки могут не совпадать.. надо либо по nfs монтировать, либо по http забирать.. в общем много телодвижений нужно. А если файлы были бы в базе - это организовывалось бы достаточно легко.

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

По этому решил перенести файлы в базу данных. Однако пугает то, что места мне на дисках одного сервера рано или поздно не хватит. Поэтому возникает вопрос, который озвучен выше.

 

[Фанат]

жесть

 

[AndreyKl]

поясни?

-~{}~ 08.09.08 14:31:

Автор оригинала: *****
жесть

Не мог бы ты пояснить, в чём конкретно "жесть". Хотя бы поверхностно.

 

[Фанат]

ну как тебе объяснить...
юмор ситуации заключается в том, что общая тенденция для высоконагруженных проектов состоит в сокращении доли динамического контента.
А ты задаешься вопросом,как её увеличить, причем на порядки.
Ты уверен, что серверу хватит памяти отдавать все эти картинки?

 

[AndreyKl]

Автор оригинала: *****
Ты уверен, что серверу хватит памяти отдавать все эти картинки?

> Ты уверен, что серверу хватит памяти отдавать все эти картинки?

ну как тебе объяснить...
Картинки кешируются на отдающем сервере. То есть скорее всего - да, я думаю, что хватит. Хотя может и не хватит.. я не знаю что с базой делать. Когда буду знать, наверное, смогу сказать точнее, может даже смогу рассчитать. Хотя может это лишь наживание лишних проблем. Конечно, решение будет принято окончательно лишь после изучения вариантов.

В любом случае, спасибо за внимание.

 

[Фанат]

кэширующий сервер - это те же файлы на диске. которые так же надо удалять со всеми теми неочевидными "трудностями", которые ты тут описал.
сейчас,как я понимаю,кэширующего нет, и он только планируется?

 

[AndreyKl]

> Сейчас, как я понимаю,кэширующего нет, и он только планируется?

Да, я, не удержался и приукрасил, ради красного, так сказать, словца. Ты верно понял.

Так или иначе, но проблем с удалением, при использовании кеширующего сервера не предполагается.


Всё же вопрос не в этом.

-~{}~ 08.09.08 16:47:

проблем с удалением из кеша, я имею ввиду. Использование кеширующего сервера предполагается и с текущей архитектурой. Ввиду того, что scsi диски дорогие, особенно, маленькие.

 

[Фанат]

А зачем тебе скази диск, особенно маленький?
И почему наличие кэширующего сервера предполагается при текущей архитектуре? Если картинки кэшировать вообще не надо?
ты понимаешь разницу между проблемами "менять полностью архитектуру и усложнять систему в 10 раз" и "я ниняю, где картинку для аватарки найти"?

 

[AndreyKl]

Автор оригинала: *****
А зачем тебе скази диск, особенно маленький?
И почему наличие кэширующего сервера предполагается при текущей архитектуре? Если картинки кэшировать вообще не надо?
ты понимаешь разницу между проблемами "менять полностью архитектуру и усложнять систему в 10 раз" и "я ниняю, где картинку для аватарки найти"?

А зачем тебе скази диск, особенно маленький?

Ну в общем и целом, как я себе вижу ситуацию, если тебе действительно интересно.

SAТА диски довольно дешёвые. Получается, что хранение на них информации довольно дёшево и достаточно надёжно (в райд 5). Картинки довольно большие. Хранятся долго(Со времени последнего посещения пользователем ресурса хранятся год.). Большей частью картинки запрашиваются одни и те же за короткий промежуток времени, но запрашиваются довольно интенсивно (wa в top (linux) сейчас около 5, что начинает ощущаться). Маленькие скази диски raid1 при случайном чтени оказываются примерно в 3 раза быстрее больших sata в райд5. Возникла идея сохранять часто запрашиваемые картинки на сервере с быстрыми дисками, а хранить все картинки на медленном, но ёмком сервере и запрашивать с него нужные картинки. Примерно так.

Ты понимаешь разницу между проблемами "менять полностью архитектуру и усложнять систему в 10 раз" и "я ниняю, где картинку для аватарки найти"?

Понимаю.

Надёюсь, я ответил, на твои вопросы.
Спасибо за проявленный к теме интерес.

 

[Sad Spirit]

AndreyKL, Фоннат-то дело говорит.

Пробежимся по пунктам: в Яху конечно же нет петабайтной базы в Postgres'е, есть петабайтная база в продукте, частично основанном на коде Postgres'а. Ясен хобот, над этим продуктом работала большая толпа разработчиков, и начинали они не с задавания подобных вопросов в форуме.

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

Картинки в базе хранить, конечно, удобно в силу транзакционности: непротиворечивые резервные копии, репликация, удаление помянутое... Но надо понимать, что если мы картинку кладём на диск и отдаём тем же Апачем, то Апач уже умеет проверять метаданные и отдавать всякие волшебные ответы 206 и 304. А если мы картинку положим в базу и будем отдавать скриптом, то эту логику, в частности, нам придётся переписывать.

Быстрые-медленные диски --- всё фигня, рейд из "медленных" сата дисков легко забьёт любой ширины канал в интернеты. Выигрыш только за счёт большей скорости позиционирования на более быстро крутящихся дисках. Ну и наиболее часто запрашиваемые картинки лучше хранить в памяти, а не на "быстром scsi".

Ни в коем случае не клади базу на raid5.

 

[AndreyKl]

Автор оригинала: Sad Spirit
AndreyKL, Фоннат-то дело говорит.
Пробежимся по пунктам: в Яху конечно же нет петабайтной базы в Postgres'е, есть петабайтная база в продукте, частично основанном на коде Postgres'а. Ясен хобот, над этим продуктом работала большая толпа разработчиков, и начинали они не с задавания подобных вопросов в форуме.

Насколько я читал, там был код postges, только способ хранения данных был изменён с построчного на постолбцовый. То есть утверждалось, что изменения совсем не большие. К сожалению, ссылку не сохранил. Но это не так важно в данном случае, я полагаю ). В основном меня интересует вопрос - как разнести базу постгрес по машинам. Читал о способе вроде "берёшь таблицы и кладёшь их на разные машины", но этот способ не сильно подходит, потому что таблица в основном будет увеличиваться одна.

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

Спасибо, скорее всего учту совет. Но всё же может ссылки есть?

Картинки в базе хранить, конечно, удобно в силу транзакционности....

спасибо )

то Апач уже умеет проверять метаданные и отдавать всякие волшебные ответы 206 и 304. А если мы картинку положим в базу и будем отдавать скриптом, то эту логику, в частности, нам придётся переписывать.

она уже написана..

Быстрые-медленные диски --- всё фигня, рейд из "медленных" сата дисков легко забьёт любой ширины канал в интернеты.

Неправда твоя. Был у нас проект на поддержке - хостинг видео. Диски не справлялись.

Выигрыш только за счёт большей скорости позиционирования на более быстро крутящихся дисках. Ну и наиболее часто запрашиваемые картинки лучше хранить в памяти, а не на "быстром scsi".

Видео, по понятным причинам, не удавалось хранить в памяти. С картинками проще, конечно, поскольку размер меньше существенно. Но всё же картинки большие у нас.

Ни в коем случае не клади базу на raid5.

Сейчас она на raid1, а тогда был контроллер с баратейкой, так что всё было не так страшно

 

[fixxxer]

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

фигня какая, ага =)

>>Неправда твоя. Был у нас проект на поддержке - хостинг видео. Диски не справлялись.

так, ты картинки или видео хранишь?

в целом выкинь идею с базой из головы, она плохая.

 

[Sad Spirit]

Автор оригинала: AndreyKl
В основном меня интересует вопрос - как разнести базу постгрес по машинам. Читал о способе вроде "берёшь таблицы и кладёшь их на разные машины", но этот способ не сильно подходит, потому что таблица в основном будет увеличиваться одна.

Берёшь одну таблицу и кладёшь её на разные машины, разбивая первичный ключ на диапазоны. Кажется, это называют шардингом, и на этом форуме даже есть специалисты, хотя и не конкретно по Postgres'у.

Спасибо, скорее всего учту совет. Но всё же может ссылки есть?

Ну почитай про то, как базы Скайпа устроены. У них как раз Postgres используется, более близкий к оригиналу, чем в Яху.

Неправда твоя. Был у нас проект на поддержке - хостинг видео. Диски не справлялись.
Видео, по понятным причинам, не удавалось хранить в памяти. С картинками проще, конечно, поскольку размер меньше существенно. Но всё же картинки большие у нас.

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

Сейчас она на raid1, а тогда был контроллер с баратейкой, так что всё было не так страшно

Речь не о батарейке, а о том, как происходит запись на raid5. Особенно плохо, если на 5-м рейде будет лежать и база, и журнал транзакций.