![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Не то, чтобы я нашел конкретную книжку, но вот материалы с которыми может быть полезно ознакомиться:
A Fresh Graduate's Guide to Software Tools and Development
http://www.comp.nus.edu.sg/~seer/book/2e/
Книжку пишут бывшие и настоящие студенты университета Сингапура, состоит из нескольких глав по разным темам. Книжке не хватает глубины, но если вы не знаете что гуглить - это очень полезная книжка. Из нее я например узнал про Paxos algorithm и получил наглядное представление об облачных сервисах от Google и Amazon ("Chapter 06: Scalability", "Chapter 01: Cloud Computing"). Другие главы тоже могут быть полезны вне контекста сабжа, возможно доберусь до них позже.
Autopilot: Automatic Data Center Management
http://research.microsoft.com/pubs/64604/osr2007.pdf
Тоже достаточно поверхностное описание как Майкрософт строит свои датаценты, какие проблемы решает их софт для выпаски и мониторинга десятков тысяч машин. Там нет конкретных решений, but it just may get you thinking. Описана, например, базовая логика, которая позволяет обслуживать машины в датацентрах не 24/7, а 8/5.
Everything You Always Wanted to Know About Synchronization but Were Afraid to Ask
http://sigops.org/sosp/sosp13/papers/p33-david.pdf
Достаточно близкая к железу статья на тему распараллеливания софта. Анализируется несколько архитектур, включая Xeon'ы. Анализируются накладные расходы на когерентность кэшей в многопроцессорных машинах. Так я например узнал, что треды попавшие на соседний сокет (процессорный сокет), могут давать до 7.5 бОльший оверхед. Т.е., скажем, атомарные операции на многопроцессорной машине могут внезапно начать работать почти в 10 раз медленнее, только за счет того, что ядро выперло парочку тредов на соседний процессор. Даже при использовании memory fences (блоки памяти вокруг переменных изменяемых атомарно, чтобы эти атомарные переменные не кучковались рядом на одном кэш-лайне).
Это не полный список, я ощущаю что надо почитать что-то еще, но, например, MongoDB, насколько я понял, является единственной открытой БД, в которой реализован Paxos. При этом оно таки eventually consistent. В итоге, я пришел к выводу, что лучше использовать традиционные реляционные СУБД для "обычных данных" (в моем случае не так часто изменяемых), используя master-slave репликацию (и просто переключать все в read-only при отказе мастера). И использовать монгу для обработки тяжелых клиентских запросов, для которых не нужна жесткая согласованность между инстансами БД.
Еще есть вариант выпереть всякий веб в облако, а железный кластер оставить "реальным" для тяжелой математики, но не уверен, что паранойя позволит это сделать.
A Fresh Graduate's Guide to Software Tools and Development
http://www.comp.nus.edu.sg/~seer/book/2e/
Книжку пишут бывшие и настоящие студенты университета Сингапура, состоит из нескольких глав по разным темам. Книжке не хватает глубины, но если вы не знаете что гуглить - это очень полезная книжка. Из нее я например узнал про Paxos algorithm и получил наглядное представление об облачных сервисах от Google и Amazon ("Chapter 06: Scalability", "Chapter 01: Cloud Computing"). Другие главы тоже могут быть полезны вне контекста сабжа, возможно доберусь до них позже.
Autopilot: Automatic Data Center Management
http://research.microsoft.com/pubs/64604/osr2007.pdf
Тоже достаточно поверхностное описание как Майкрософт строит свои датаценты, какие проблемы решает их софт для выпаски и мониторинга десятков тысяч машин. Там нет конкретных решений, but it just may get you thinking. Описана, например, базовая логика, которая позволяет обслуживать машины в датацентрах не 24/7, а 8/5.
Everything You Always Wanted to Know About Synchronization but Were Afraid to Ask
http://sigops.org/sosp/sosp13/papers/p33-david.pdf
Достаточно близкая к железу статья на тему распараллеливания софта. Анализируется несколько архитектур, включая Xeon'ы. Анализируются накладные расходы на когерентность кэшей в многопроцессорных машинах. Так я например узнал, что треды попавшие на соседний сокет (процессорный сокет), могут давать до 7.5 бОльший оверхед. Т.е., скажем, атомарные операции на многопроцессорной машине могут внезапно начать работать почти в 10 раз медленнее, только за счет того, что ядро выперло парочку тредов на соседний процессор. Даже при использовании memory fences (блоки памяти вокруг переменных изменяемых атомарно, чтобы эти атомарные переменные не кучковались рядом на одном кэш-лайне).
Это не полный список, я ощущаю что надо почитать что-то еще, но, например, MongoDB, насколько я понял, является единственной открытой БД, в которой реализован Paxos. При этом оно таки eventually consistent. В итоге, я пришел к выводу, что лучше использовать традиционные реляционные СУБД для "обычных данных" (в моем случае не так часто изменяемых), используя master-slave репликацию (и просто переключать все в read-only при отказе мастера). И использовать монгу для обработки тяжелых клиентских запросов, для которых не нужна жесткая согласованность между инстансами БД.
Еще есть вариант выпереть всякий веб в облако, а железный кластер оставить "реальным" для тяжелой математики, но не уверен, что паранойя позволит это сделать.
