Исправление byko3y, (текущая версия) :
https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/nish...
Ух ты, наконец индус-лектор с хорошим английским. Аж приятно слушать.
По содержанию лекции — я теперь начинаю понимать, откуда растут корни некоторых современных решений фейсбука:
https://habr.com/post/593167/
У фейсбука был относительно успешный опыт внедрения распределенного кэша на memcached и распределенных транзакций на «сагах» — техническое руководство окончательно решило, что можно продолжать ничего не менять, писать на тех же PHP с мускулем до посинения... пока они наконец не упёрлись в потолок по операциям записи, которых вроде бы «немного» и в основном происходят операции чтения, но на таком масштабе «немного» выглядит устрашающе — десятки тысяч транзакций в секунду на распределенной высокосогласованной БД находятся где-то около технологического предела для нынешних интернет-каналов.
По сути, фейсбук слепил на диком числе костылей банальный statefull уровень бизнес-логики (с memcached в основном общаются PHP-worker-ы). Это к слову о том, почему микросервисы на самом деле не работают: они просто перекладывают проблему на другое узкое место — БД/кэш. Примерно из таких соображений лично я посчитал, что будет хорошей идеей сделать универсальный механизм для создания statefull логики в питоне:
https://github.com/byko3y/python-shared-objects
К сожалению, моя задумка так и осталась моей, потому что всех остальных более чем устраивают костыли, уже имеющиеся в экосистеме питона.
По теме треда — я сомневаюсь, что автор будет проектировать-реализовывать систему хотя бы на миллион пользователей. Если посмотреть на диаграмму на 15:00, то можно заметить, что авторы системы никак не решили проблему одновременного изменения одной ячейки из нескольких регионов. Индус оправдывается, что чтение-запись ячейки скорее всего будет происходить в рамках одного региона, потому вроде как ему пофиг, но это опасный совет, который может оказаться вредным для посетителей LOR, разрабатывающих крупные высоконагруженные распределенные системы уровня фейсбука.
Какие знания я применил для того, чтобы вываливать вам аналитику из этого сообщения? Я просто прочитал исходные документы и прокрутил в уме разные сценарии работы системы — вот и весь самый лучший совет по теме. Вы не можете в голове смоделировать работу распределенной системы? Ну что ж, я боюсь, что чтение книжки вам с этим не поможет, этот навык получается тренировкой помноженным на особенности восприятия.
Исправление byko3y, :
https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/nish...
Ух ты, наконец индус-лектор с хорошим английским. Аж приятно слушать.
По содержанию лекции — я теперь начинаю понимать, откуда растут корни некоторых современных решений фейсбука:
https://habr.com/post/593167/
У фейсбука был относительно успешный опыт внедрения распределенного кэша на memcached и распределенных транзакций на «сагах» — техническое руководство окончательно решило, что можно продолжать ничего не менять, писать на тех же PHP с мускулем до посинения... пока они наконец не упёрлись в потолок по операциям записи, которых вроде бы «немного» и в основном происходят операции чтения, но на таком масштабе «немного» выглядит устрашающе — десятки тысяч транзакций в секунду на распределенной высокосогласованной БД находятся где-то около технологического предела для нынешних интернет-каналов.
По сути, фейсбук слепил на диком числе костылей банальный statefull уровень бизнес-логики (с memcached в основном общаются PHP-worker-ы). Это к слову о том, почему микросервисы на самом деле не работают: они просто перекладывают проблему на другое узкое место — БД/кэш. Примерно из таких соображений лично я посчитал, что будет хорошей идеей сделать универсальный механизм для создания statefull логики в питоне:
https://github.com/byko3y/python-shared-objects
К сожалению, моя задумка так и осталась моей, потому что всех остальных более чем устраивают костыли, уже имеющиеся в экосистеме питона.
По теме треда — я сомневаюсь, что автор будет проектировать-реализовывать систему хотя бы на миллион пользователей. Если посмотреть на диаграмму на 15:00, то можно заметить, что авторы системы никак не решили проблему одновременного изменения одной ячейки из нескольких регионов. Индус оправдывается, что чтение-запись ячейки скорее всего будет происходить в рамках одного региона, потому вроде как ему пофиг, но это опасный совет, который может оказаться вредным для посетителей LOR, разрабатывающих крупные высоконагруженные распределенные системы уровня фейсбука.
Какие знания я применил для того, чтобы вываливать вам аналитику из этого сообщения? Я просто прочитал исходные документы и прокрутил в уме разные сценарии работы системы — вот и весь самый лучший совет по теме. Вы не можете в голове смоделировать работу распределенной системы? Ну что ж, я боюсь, что чтение книжки вам с этим не поможет, этот навык получается тренировкой помноженным на особенности восприятия.
Исходная версия byko3y, :
https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/nish...
Ух ты, наконец индус-лектор с хорошим английским. Аж приятно слушать.
По содержанию лекции — я теперь начинаю понимать, откуда растут корни некоторых современных решений фейсбука:
https://habr.com/post/593167/
У фейсбука был относительно успешный опыт внедрения распределенного кэша на memcached и распределенных транзакций на «сагах» — техническое руководство окончательно решило, что можно продолжать ничего не менять, писать на тех же PHP с мускулем до посинения... пока они наконец не упёрлись в потолок по операциям записи, которых вроде бы «немного» и в основном происходят операции чтения, но на таком масштабе «немного» выглядит устрашающе — десятки тысяч транзакций в секунду на распределенной высокосогласованной БД находятся где-то около технологического предела для нынешних интернет-каналов.
По сути, фейсбук слепил на диком числе костылей банальный statefull уровень бизнес-логики (с memcached в основном общаются PHP-worker-ы). Это к слову о том, почему микросервисы на самом деле не работают: они просто перекладывают проблему на другое узкое место — БД/кэш. Примерно из таких соображений лично я посчитал, что будет хорошей идеей сделать универсальный механизм для создания statefull логики в питоне:
https://github.com/byko3y/python-shared-objects
К сожалению, моя задумка так и осталась моей, потому что всех остальных более чем устраивают костыли, уже имеющиеся в экосистеме питона.
По теме треда — я сомневаюсь, что автор будет проектировать-реализовывать систему хотя бы на миллион пользователей. Если посмотреть на диаграмму на 15:00, то можно заметить, что авторы системы никак не решили проблему одновременного изменения одной ячейки из нескольких регионов. Индус оправдывается, что чтение-запись ячейки скорее всего будет происходить в рамках одного региона, потому вроде как ему пофиг, но это опасный совет, который может оказаться вредным для посетителей LOR, разрабатывающих крупные высоконагруженные распределенные системы уровня фейсбука.
Какие знания я применил для того, чтобы вываливать вам аналитику из этого сообщения? Я просто прочитал исходные документы и прокрутил в уме разные сценарии работы системы — вот и весь самый лучший совет по теме. Вы не можете в голове смоделировать работу распределенной системы? Ну что ж, я боюсь, что чтение книжки вам с этим не поможет, этот навык получается тренировкой помноженным на особенности восприятия.