Зло, например, потому что владельцу «проприетарного магазина приложений» (iTunes итп) может внезапно не понравиться ваше приложение «Вконтакте», с миллионам пользователей и большим вложением в рекламу, и приложение пропадёт из каталога, и, в худшем случае, с конечных устройств. Причём мотивация может быть не только «мы вас предупреждали», но и зачистка рынка для выпуска собственного конкурирующего продукта.
Прямая зависимость потребления от преследования наркоторговцев и точек продаж — общеизвестный факт, разделяемый специалистами. Конкретные цифры в этом разрезе приводит, например, Ройзман.
Поражает обилие теоретиков в комментариях и идеалистов в опросе. Реальность такова, что употребление наркотиков в России сейчас ограничивается предложением, потому любое ограничение интернет-продаж и досок объявлений с наркотическими веществами прямо влияет на демографическую ситуацию. Про остальное (включая детское порно) никакой явной зависимости на демографию дать нельзя.
То есть, инструмент отслеживания и ограничения конкретных видов интернет-деятельности нужен, но должен быть явно ограничен, и не волей нынешних «законодателей».
Зависит от проекта. В целом, это инициализация карты классов, проектных конфигов, nginx конфигов, npm install + bower install, сборка статики, генерация спрайтов, кодогенерация итд.
В PHP проектах деплой просто выкладывается в новую папку, и инит проекта перегенерирует локальный nginx конфиг — это заведомо избавляет от проблем с кешем, позволяет действительно быстро откатываться и даёт действительно graceful reload сугубо командой nginx reload.
Читайте оригинал, он, как обычно, гораздо содержательнее, и заведомо не содержит «творческих находок» переводчика
>The Seagate Barracuda Green 1.5TB drive, though, has not been doing well. We got them from Seagate as warranty replacements for the older drives, and these new drives are dropping like flies. Their average age shows 0.8 years, but since these are warranty replacements, we believe that they are refurbished drives that were returned by other customers and erased, so they already had some usage when we got them.
Митинг — дело полезное, если пришедшие могут устроить серьёзные беспорядки — просто как демонстрация силы без её применения. К сожалению, для московских митингов это не так.
Очевидно, голосование в интернете мало связано с политической активностью голосовавших, потому при игнорировании властью интернет-электората ввиду малочисленности результаты голосования заведомо будут иметь второстепенную роль.
Однако, хабр не для политики, потому топик, скорее всего, улетит в черновики.
Хабы прекрасно ищутся поиском — никогда с этим не было проблем. Глобальный поиск по хабру часто эффективнее делать через google, но с этим тоже никаких проблем. По опциям поиска — согласен, бывает нужно, но всё-таки надо понимать, что это редкий кейс, и мало кто этим будет пользоваться. Вероятно, имеет смысл сразу взять поисковые опции google'а (в крайнем случае — яндекса), для уменьшения порога входа.
По-настоящему «бурлящих идеями» тоже крайне мало, по меньшей мере в IT сфере. И на них держится будущее компании, когда вместо «насилия трупа» компания активно развивается. Хотя, безусловно, умение и готовность хорошо работать тоже важно.
Московские и питерские конторы сейчас активно пылесосят всю Россию в поисках хороших программистов, всё больше готовы работать с удалёнщиками — это тоже выравнивает рынок. Про 80+ оценку для сеньора на удалёнку — согласен.
При работе в полноценной IDE это не вызывает проблем — сразу видны сигнатуры. В PHP, конечно, есть неочевидные вещи, но за исключением редких кейсов (на самом деле почти исключительно неперехватываемые фаталы с неочевидной причиной) язык вполне пригоден для крупного enterprise программирования — как Java, только гораздо более лаконичная и удобная в разработке.
Спасибо за замечание, вы абсолютно правы. Проблема в том, что для того, чтобы сервер смог эффективно пользоваться таким количеством памяти, ему может понадобится 8 процессоров по 4-6 ядер, серверу потребуется высокопроизводительный raid с multipath io, 10Gbps сетка и прочие страшные вещи.
Например, потому что вы можете не видеть этих проблем, или они могут считать их неразрешимыми. Даунтаймы для обслуживания, высокие требования к эффективности работы кода и sql-запросов, трудность в добавлении ресурсоёмких фич — это всё те вещи, которых вы не увидите (кроме даунтайма). У них действительно большая команда для сервиса с объективно не очень большим количеством фич, и не быстро изменяющимся — это тоже может быть проблемой.
Цифры можно приводить только под конкретные требования и ресурсы. Те продукты, с которыми я работаю, заведомо не помещаются в scale up архитектуру, кратко моё мнение относительно сложности работы со scale out архитектурой в комментариях выше.
Судя по выводам, вы не разбираетесь в технологии, тесты которой смотрите. Pgpool-II — надёжное и эффективное решение для синхронной репликации.
Железо, конечно, дешевле программистов, но вы упускаете тот факт, что SO сами пишут, что для того чтобы их приложение нормально работало даже на их серверах-монстрах, им приходится серьёзно оптимизировать производительность, в том числе поскольку стоимость сервера при scale up растёт совсем не линейно, и старые сервера надо куда-то девать. При работе с шардингом такой проблемы нет; более того, в ряде случаев можно выкладывать совсем неэффективный код и оптимизировать позже по факту наличия потребностей и ресурсов на это.
Что касается стоимости поддержки шардинга — вы правы, она есть. Но это единоразовые затраты на разработку обёртки для этого или внедрения существующего решения, издержки на что значительно снижаются, если в команде было понимание и опыт работы с такими решениями.
Что касается джойнов, на мой взгляд, вы за них слишком сильно цепляетесь. Слишком редко действительно нужны сложные запросы (поскольку без них код получается слишком раздутым, или нужен неадекватно большой трансфер промежуточных данных) — большей частью для сложной аналитики, а для этого есть специализированные решения, в которые можно, например, экспортировать данные. Слишком редко действительно нужна нормализация, и обеспечение в коде денормализации, несмотря на мифы, весьма простое.
Если же действительно нужны транзакции, очень хочется джойнов, или просто хочется работать с привычными инструментами, всегда можно шардить MySQL или PostgreSQL, и там уже иметь всё что нужно. Это не сложно, это не создаёт значительных сложностей в поддержке, для этого есть готовые решения, и оно эффективно. Конечно, решение не полностью заменяет единую базу, но на действительно больших объёмах данных выборки не по основному ключу можно делать снаружи (например, в единой базе данных, для выборок по тегам/разделам/рейтингу), и это тоже несложно.
Про нерешённость проблем, посмотрите доклады на VLDB, некоторые доклады на Highload++ и прочие специализированные мероприятия — люди успешно решают «нерешённые проблемы», и рассказывают об этом тем, кто готов слушать.
Например, если верить вашим словам, у SO есть «нерешённая проблема» — приходится часто делать длительный даунтайм сервиса для обслуживания.
PS У стартапов другие проблемы — при такой архитектуре они при скачкообразном росте нагрузки внезапно упираются в сервер, и вынуждены вкладывать значительные деньги в покупку нового, потому как сервера-монстры с большим количеством процессоров и памяти мало у кого можно арендовать, а стоимость облаков минимум в разы выше.
Failover можно без особых проблем реализовать на уровне приложения. Хороший failover для mysql/postgres называется master-slave репликация (для особо важных случаев — синхронная), для особо ленивых — на уровне приложения или middleware. Настраивается просто, работает эффективно.
Шардинг можно делать на уровне приложения или middleware — это избавляет бд от неумения эффективно горизонтально масштабироваться.
Джойны, конечно, штука нужная и удобная, но на практике неэффективная для Big Data. Данные можно денормализовывать под запросы, можно «джойнить», «доставать данные по индексам» итд на уровне приложения или middleware.
Что касается ACID, практически всегда consistency не нужно (достаточно eventual consistency), как и, с оговорками, не нужна атомарность, и в этом случае оно реализуется даже простейшими распределёнными блокировками, без транзакций. Подводные камни, конечно, есть, но они многими решены, и в этом нет ничего супер-сложного и уникального — обычная инженерная работа.
Что касается вашей ссылки, помимо весьма ограниченного подхода, она написана больше 4 лет назад, когда NoSQL решений было заметно меньше, и многие не были достаточно хорошо сделаны для production-использования.
То есть, инструмент отслеживания и ограничения конкретных видов интернет-деятельности нужен, но должен быть явно ограничен, и не волей нынешних «законодателей».
>The Seagate Barracuda Green 1.5TB drive, though, has not been doing well. We got them from Seagate as warranty replacements for the older drives, and these new drives are dropping like flies. Their average age shows 0.8 years, but since these are warranty replacements, we believe that they are refurbished drives that were returned by other customers and erased, so they already had some usage when we got them.
Очевидно, голосование в интернете мало связано с политической активностью голосовавших, потому при игнорировании властью интернет-электората ввиду малочисленности результаты голосования заведомо будут иметь второстепенную роль.
Однако, хабр не для политики, потому топик, скорее всего, улетит в черновики.
Например, потому что вы можете не видеть этих проблем, или они могут считать их неразрешимыми. Даунтаймы для обслуживания, высокие требования к эффективности работы кода и sql-запросов, трудность в добавлении ресурсоёмких фич — это всё те вещи, которых вы не увидите (кроме даунтайма). У них действительно большая команда для сервиса с объективно не очень большим количеством фич, и не быстро изменяющимся — это тоже может быть проблемой.
Цифры можно приводить только под конкретные требования и ресурсы. Те продукты, с которыми я работаю, заведомо не помещаются в scale up архитектуру, кратко моё мнение относительно сложности работы со scale out архитектурой в комментариях выше.
Железо, конечно, дешевле программистов, но вы упускаете тот факт, что SO сами пишут, что для того чтобы их приложение нормально работало даже на их серверах-монстрах, им приходится серьёзно оптимизировать производительность, в том числе поскольку стоимость сервера при scale up растёт совсем не линейно, и старые сервера надо куда-то девать. При работе с шардингом такой проблемы нет; более того, в ряде случаев можно выкладывать совсем неэффективный код и оптимизировать позже по факту наличия потребностей и ресурсов на это.
Что касается стоимости поддержки шардинга — вы правы, она есть. Но это единоразовые затраты на разработку обёртки для этого или внедрения существующего решения, издержки на что значительно снижаются, если в команде было понимание и опыт работы с такими решениями.
Что касается джойнов, на мой взгляд, вы за них слишком сильно цепляетесь. Слишком редко действительно нужны сложные запросы (поскольку без них код получается слишком раздутым, или нужен неадекватно большой трансфер промежуточных данных) — большей частью для сложной аналитики, а для этого есть специализированные решения, в которые можно, например, экспортировать данные. Слишком редко действительно нужна нормализация, и обеспечение в коде денормализации, несмотря на мифы, весьма простое.
Если же действительно нужны транзакции, очень хочется джойнов, или просто хочется работать с привычными инструментами, всегда можно шардить MySQL или PostgreSQL, и там уже иметь всё что нужно. Это не сложно, это не создаёт значительных сложностей в поддержке, для этого есть готовые решения, и оно эффективно. Конечно, решение не полностью заменяет единую базу, но на действительно больших объёмах данных выборки не по основному ключу можно делать снаружи (например, в единой базе данных, для выборок по тегам/разделам/рейтингу), и это тоже несложно.
Про нерешённость проблем, посмотрите доклады на VLDB, некоторые доклады на Highload++ и прочие специализированные мероприятия — люди успешно решают «нерешённые проблемы», и рассказывают об этом тем, кто готов слушать.
Например, если верить вашим словам, у SO есть «нерешённая проблема» — приходится часто делать длительный даунтайм сервиса для обслуживания.
PS У стартапов другие проблемы — при такой архитектуре они при скачкообразном росте нагрузки внезапно упираются в сервер, и вынуждены вкладывать значительные деньги в покупку нового, потому как сервера-монстры с большим количеством процессоров и памяти мало у кого можно арендовать, а стоимость облаков минимум в разы выше.
Шардинг можно делать на уровне приложения или middleware — это избавляет бд от неумения эффективно горизонтально масштабироваться.
Джойны, конечно, штука нужная и удобная, но на практике неэффективная для Big Data. Данные можно денормализовывать под запросы, можно «джойнить», «доставать данные по индексам» итд на уровне приложения или middleware.
Что касается ACID, практически всегда consistency не нужно (достаточно eventual consistency), как и, с оговорками, не нужна атомарность, и в этом случае оно реализуется даже простейшими распределёнными блокировками, без транзакций. Подводные камни, конечно, есть, но они многими решены, и в этом нет ничего супер-сложного и уникального — обычная инженерная работа.
Что касается вашей ссылки, помимо весьма ограниченного подхода, она написана больше 4 лет назад, когда NoSQL решений было заметно меньше, и многие не были достаточно хорошо сделаны для production-использования.
PS Значит, по хабру ходит маньяк — фанат ограниченных проприетарных решений.