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

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

Здравствуйте, cybrex, Вы писали:

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

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

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

media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf — не совсем то что вам надо, но в целом интересно познакомится. Там и общие советы есть, не только на AWS завязанные.

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

Куча полезных советов про системы.
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//people/jeff/stanford-295-talk.pdf
(с картинками тут http://artamonov.ru/2009/10/27/lessons-from-large-distributed-system/ )


Про базы в целом как-то так:
— до тех пор, пока добавление новой машины под базу не стало еженедельной/дневной рутиной забыть про NoSQL как маркетинговый булшит
— если больше читаем, чем пишем: вместо JOIN добавляем дополнительные поля, которые обновляются триггерами
— если больше пишем, то не используем FK, поменьше индексов; синхронно реплицируем в память (и надеемся на UPS), асинхронно на диск
— вместо агрегаторных функций дополнительные поля (и/или дополнительные таблицы), которые обновляются триггерами или кроном
— если за какой-то промежуток данные в базе не менялись, то запрос в неё должен попасть только в случае "кэш сдох"

Конечно, всё это из разряда common sense и "устранить узкие места".


Ещё random links:
— http://highscalability.squarespace.com/ (много полезных мыслей размазано по очень много статей)
— http://bret.appspot.com/entry/how-friendfeed-uses-mysql
— http://natishalom.typepad.com/nati_shaloms_blog/2008/05/twitter-as-an-e.html

Всем спасибо за советы и ссылки! Буду изучать

G>Книг таких не видел. Но изучение архитектуры проектов говорит о том что заранее продумать правильную высоконагруженную архитектуру нереально, обычно начинают с чего-то простого, а потом развивают.

Да не, все не так плохо, нормальную нагруженную архитектуру с нуля сделать тоже не сложно.
Просто большая часть проектов, где пришлось использовать нагруженную архитектуру "выстрелили" практически с нуля и росли темпами, для разработчиков изначально не предполагаемыми. А если есть оценки нагрузки, сделать под них конкретную архитектуру — не такая уж и проблема.

Кстати, именно поэтому читать статьи с insight-it надо аккуратно — там просто склад примеров, которые как удачные, так и не слишком.

G>Есть вариант сразу задумываться о cloud решениях, если правильно следовать гайдлайнам, то можно получить хорошо масштабируемое решение, только на начальном этапе может довольно дорого получиться.

Ну, cloud вообще довольно дорогой получается. И сильно привязан к вендору.

Здравствуйте, cybrex, Вы писали:

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

Можно посмотреть доклады с Highload'ов. Там, правда, очень и очень разный уровень, но что-то найти можно.
Какой-то обзорый доклад по нагрузкам (средним) там и у меня есть —
http://webcrunch.ru/library/development/highload-basics/about-highload-systems/
(и, отдельно, презентация — http://download.yandex.ru/company/experience/rit2008/highload_philipp.pdf)

Но вообще лучше сделать постановку и взять консультацию у кого-нибудь с опытом. Хотя бы часть грабель не придется самому изучать.

Здравствуйте, Дельгядо Филипп, Вы писали:

G>>Книг таких не видел. Но изучение архитектуры проектов говорит о том что заранее продумать правильную высоконагруженную архитектуру нереально, обычно начинают с чего-то простого, а потом развивают.

ДФ>Да не, все не так плохо, нормальную нагруженную архитектуру с нуля сделать тоже не сложно.
"Нормальную" — да, "хорошую" — нет.

ДФ>Просто большая часть проектов, где пришлось использовать нагруженную архитектуру "выстрелили" практически с нуля и росли темпами, для разработчиков изначально не предполагаемыми. А если есть оценки нагрузки, сделать под них конкретную архитектуру — не такая уж и проблема.
Только откуда взять более-менее точные оценки, чтобы не ошибиться на порядок? Это наука еще посложнее высоконагруженной архитектуры.

G>>Есть вариант сразу задумываться о cloud решениях, если правильно следовать гайдлайнам, то можно получить хорошо масштабируемое решение, только на начальном этапе может довольно дорого получиться.
ДФ>Ну, cloud вообще довольно дорогой получается.
Скорее нет.

ДФ>И сильно привязан к вендору.
Скорее да.