Можно начать с того, что не использовать лицензирование, которое, если верить вашим словам, может стоить значительно дороже железа. Я, конечно, не специалист по решениям от Microsoft, но google услужливо подсказывает, что Windows Server 2012 Foundation (вполне годный на небольшие сервера) стоит меньше $100, а Windows Server 2012 Standard стоит раз в 10-15 дороже; аналогично, MS SQL лицензируется пропорционально количеству ядер.
Если серьёзно, при умении пользоваться, внезапно, Linux оказывается ничем не хуже Windows (кроме проприетарных технологий типа C#), PostgreSQL ничем не хуже MS SQL, да и программировать можно не только для .NET.
Что касается «как надо» — надо так, чтобы решение оптимально решало бизнес-задачи. Если решение требует несравнимо больших капиталовложений, весьма ограниченно и очень дорого масштабируется и делает добавление ресурсоёмких фич аналогично ограниченным и крайне дорогим — это, очевидно, плохое решение.
Конкретно в данном случае, возможности шардинга при грамотной архитектуре особо не ограничены, поскольку вопросы, ответы, комментарии, голоса и авторы могут храниться даже в нормальном key-value хранилище, а решений для их индексации по всем интересующим выборкам более чем достаточно.
PS Спасибо за минус, это лучший способ поддержки дискуссии!
Да, их архитектура — хороший пример того, как делать не надо, и что получается с архитектурой при узости кругозора и отсутствии актуальных знаний.
На самом деле, особой проблемы в 1Tb оперативной памяти нет — 30 сверхдешёвых 1-юнитовых серверов с 32Gb памяти (или 60 — с 16Gb) не стоят почти ничего. Большая проблема в том, что даже при условии работы с таким количеством оперативной памяти, их приложение никак не масштабируется, что вынуждает их покупать сверхдорогие сервера с сотнями Gb памяти и сильно ограничивать функционал.
Хотя, мне кажется, самое интересное будет в статье про их приложение и написание кода — там при таком подходе должно быть много проблем.
Посмотрите на Go — там есть все эти реальные указатели и прочие плюшки (включая божественное избавление от проблем многопоточности), но программирование не похоже на переход через полосу препятствий на минном поле.
В таком случае на мой взгляд вы всё правильно делаете: даёте много практики и теорию для разрешения выявленных затруднений. Имеет смысл добавить разве что небольшое введение в тестирование интерфейсов — как это делать просто и правильно.
>о чем, по вашему мнению, нужно рассказывать на курсе по web?
На мой взгляд, существующим курсам (и вообще существующему IT-контенту) сильно недостаёт лекций про проблематику и принципы построения масштабируемых и распределённых систем, и про современные NoSQL базы данных. В результате, даже у казалось бы опытных разработчиков, из-за эффекта Даннинга-Крюгера появляется слепая вера в MongoDB, и команды таких разработчиков плодят системы без учёта возможности конкурентных изменений (которые обычно выглядят как редкие случайные баги) и сильно ограниченной масштабируемости (падающие от роста нагрузки или реализации бизнес-требований).
MongoDB — сам по себе неудачный пример — распределённое хранилище можно делать и со своей логикой. Например, кластер zookeeper'ов для синхронизации и центрального принятия решения, и ноды с неважно-каким-хранилищем. В рамках этого, «пропавшие» ноды просто помечаются в зукипере как нерабочие, и пока те полностью не синхронизируются с актуальными данными — не помечать обратно. Если пропало 2 ноды, и часть актуальных данных была только на них — это печально, но такое хранилище не может дать возможность изменять эти данные, в частности, покупать билеты.
Так что вариант — поставить в очередь, с возможностью отказа от покупки — вполне вариант.
Адекватность поведения баз при split brain — тема длительного исследования, и результаты большей частью безрадостные: aphyr.com/tags/jepsen
Что касается примера, логика базы/приложения без требований к availability может просто отказать в покупке билета или отложить в очередь, если нужная часть базы по каким-либо причинам требует времени для восстановления консистентности — в этом случае «двух билетов» продать не удастся.
Пока не выявлены нагруженные запросы, вы правы, никакого смысла в денормализации нет.
MongoDB ничуть не стандарт — просто наиболее разрекламированная как якобы универсальная. NoSQL базы обычно заметно более специализированны, нежели традиционные SQL-хранилища, поэтому о едином стандарте говорить бессмысленно. А равняются обычно на действительно крутые базы: Google BigTable/Spanner, Amazon Dynamo итп.
С кешами не всё так просто. В первом приближении, действительно, хватит тегов (хотя уже логика простановки тегов выдаёт структуру кеша). Далее, уперевшись в производительность хранилища, имеет смысл только частично обновлять кеш. Далее, можно переходить на персистентное хранилище для кеша, чтобы при перезапусках не было длительного простоя на разогрев, и при отсутствие данных не нагружать основное хранилище. Далее, для кеша можно использовать что-нибудь более структурированное, нежели простейший key-value типа memcached. Далее, в «кеше» можно данные разделять, и отдавать частично — например, диапазонами. Далее, можно не складывать в такой «кеш» высокодоступные данные в in-memory хранилищах, и использовать его как «индекс», или наоборот, хранить какие-нибудь частоизменяемые счётчики и флаги только в нём. Итд.
Тут на самом деле грань между кешем, индексом и денормализацией данных очень тонкая, и одно в другое при развитии проекта может переходить весьма легко. Я предлагаю обобщить это всё, называть денормализацией и применять единый подход к поддержке консистентности.
golang.org/doc/code.html — начните с этого.
На моём опыте оказалось удобно иметь GOPATH на директорию проекта, и внутри него держать все зависимости (например, git submodule'ями), и собирать встроенным go build (например, через Makefile).
Пути вида "../exec" имхо зло.
Денормализация в общем смысле — просто хранение части данных в нескольких местах.
Про blob: подумайте внимательно, изучите разные NoSQL решения и кейсы их использования, и больше не пишите ерунды.
Для кеша вам тоже нужно понимать его структуру, если вы не хотите его полностью инвалидировать при любом (даже не связанном с содержащимися данными) изменении. Вообще говоря странно, что вы после подробной публикации о способах кеширования пишите подобную ерунду.
Вы так говорите, как будто изменение структуры в SQL — простая и быстрая процедура в высоконагруженном проекте. Денормализация требует просто дополнительного отслеживания консистентности на уровне системного кода, что, конечно, вызывает трудности у тех, кто этого не умеет. Например, кеш — тоже денормализация.
Вообще говоря zest в редисе умеет between, и в базах данных нередко встречаются сущности разных типов, как всякие кортежи итп в Postgres'е, так и специальные типы данных вроде счетчиков в Cassandra. Реально серьезный недостаток в redis'е — отсутствие вторичных индексов, при надобности эмулируется на уровне приложения или lua-скриптов
Мне кажется, вы отвечали автору, а не мне, но не суть.
Полное администрирование нескольких бд конечно сложнее, но избавляет от геморроя для админов в последствии, когда перегружается центральная бд, и после, когда не хвататит производительности master — много slave'ов на запись. Дальше, конечно, применяется партицирование, что на уровне приложения означает переделывание его значительной части, а на уровне БД — хрупкое и требующее очень чуткого сопровождения решение.
Что касается денормализации данных: внезапно, для значительного повышения производительности и эффективности использования ресурсов, с определённого момента это необходимо. Простейшие транзакции — блокировки — реализуются миллионом разных способов, вплоть до простейшего в мемкеше/редисе.
По иному подходу к архитектуре — вы, безусловно, правы, однако умение с этим работать — важная часть профессии разработчика.
Помимо обычных ключей и хешей там есть множества, взвешенные множества, есть битовые маски и прочие приятные штуки типа pub-sub, транзакций и lua-скриптов. Как ни странно, этого достаточно, чтобы безусловно очень крупный youporn целиком на них переехал. На моём опыте редис удобен для хранения высокодоступных и частоизменяемых данных типа счётчиков, пользовательских флагов итп.
Странный пост. С одной стороны, очевидное: нет никакого смысла для хоть сколько-то технологически сложного проекта иметь только одну базу данных, с другой, предлагается использовать mysql и mongo вместе, что несколько странно в большинстве случаев.
В реальности, баз данных сейчас существует великое множество, не только SQL и NoSQL, но и NewSQL (например, VoltDB, прекрасно работающий, с сотнями тысяч транзакций в секунду, и прозрачно масштабируемый). Помимо этого, есть различные внешние решения для SQL, решающие их проблемы масштабируемости и отказоусточивости. В рамках есть богатые возможности для выбора между знакомыми разработчикам и админам технологиями и новыми для них, но лучше подходящими под задачи. Главное, разбираться во всём этом многообразии баз, с чем, к сожалению, у подавляющего большинства принимающих технологические решения есть проблемы, в результате чего применяются их «любимые» и не слишком подходящие технологии.
Весьма странно, что вы не смогли вернуть деньги по неподписанным транзакциям — насколько я помню условия mastercard/visa, ответственность за кардинг лежит на банке — получателе платежа, а не на владельце карты
На моём опыте переход к кастомам от обычных IEM'ов по росту удобства настолько значительный, что не вижу смысла брать не-кастомные IEM'ы. Недавно, кстати, doctorhead в Москве начали печатать кастомные насадки — так что удовольствие стало гораздо доступнее.
Что касается списка наушников в конце, некоторые производители универсальных IEM'ов дают возможность изготовить к ним кастомные насадке — например, Etymotic.
Если серьёзно, при умении пользоваться, внезапно, Linux оказывается ничем не хуже Windows (кроме проприетарных технологий типа C#), PostgreSQL ничем не хуже MS SQL, да и программировать можно не только для .NET.
Что касается «как надо» — надо так, чтобы решение оптимально решало бизнес-задачи. Если решение требует несравнимо больших капиталовложений, весьма ограниченно и очень дорого масштабируется и делает добавление ресурсоёмких фич аналогично ограниченным и крайне дорогим — это, очевидно, плохое решение.
Конкретно в данном случае, возможности шардинга при грамотной архитектуре особо не ограничены, поскольку вопросы, ответы, комментарии, голоса и авторы могут храниться даже в нормальном key-value хранилище, а решений для их индексации по всем интересующим выборкам более чем достаточно.
PS Спасибо за минус, это лучший способ поддержки дискуссии!
На самом деле, особой проблемы в 1Tb оперативной памяти нет — 30 сверхдешёвых 1-юнитовых серверов с 32Gb памяти (или 60 — с 16Gb) не стоят почти ничего. Большая проблема в том, что даже при условии работы с таким количеством оперативной памяти, их приложение никак не масштабируется, что вынуждает их покупать сверхдорогие сервера с сотнями Gb памяти и сильно ограничивать функционал.
Хотя, мне кажется, самое интересное будет в статье про их приложение и написание кода — там при таком подходе должно быть много проблем.
На мой взгляд, существующим курсам (и вообще существующему IT-контенту) сильно недостаёт лекций про проблематику и принципы построения масштабируемых и распределённых систем, и про современные NoSQL базы данных. В результате, даже у казалось бы опытных разработчиков, из-за эффекта Даннинга-Крюгера появляется слепая вера в MongoDB, и команды таких разработчиков плодят системы без учёта возможности конкурентных изменений (которые обычно выглядят как редкие случайные баги) и сильно ограниченной масштабируемости (падающие от роста нагрузки или реализации бизнес-требований).
Так что вариант — поставить в очередь, с возможностью отказа от покупки — вполне вариант.
aphyr.com/tags/jepsen
Что касается примера, логика базы/приложения без требований к availability может просто отказать в покупке билета или отложить в очередь, если нужная часть базы по каким-либо причинам требует времени для восстановления консистентности — в этом случае «двух билетов» продать не удастся.
MongoDB ничуть не стандарт — просто наиболее разрекламированная как якобы универсальная. NoSQL базы обычно заметно более специализированны, нежели традиционные SQL-хранилища, поэтому о едином стандарте говорить бессмысленно. А равняются обычно на действительно крутые базы: Google BigTable/Spanner, Amazon Dynamo итп.
С кешами не всё так просто. В первом приближении, действительно, хватит тегов (хотя уже логика простановки тегов выдаёт структуру кеша). Далее, уперевшись в производительность хранилища, имеет смысл только частично обновлять кеш. Далее, можно переходить на персистентное хранилище для кеша, чтобы при перезапусках не было длительного простоя на разогрев, и при отсутствие данных не нагружать основное хранилище. Далее, для кеша можно использовать что-нибудь более структурированное, нежели простейший key-value типа memcached. Далее, в «кеше» можно данные разделять, и отдавать частично — например, диапазонами. Далее, можно не складывать в такой «кеш» высокодоступные данные в in-memory хранилищах, и использовать его как «индекс», или наоборот, хранить какие-нибудь частоизменяемые счётчики и флаги только в нём. Итд.
Тут на самом деле грань между кешем, индексом и денормализацией данных очень тонкая, и одно в другое при развитии проекта может переходить весьма легко. Я предлагаю обобщить это всё, называть денормализацией и применять единый подход к поддержке консистентности.
На моём опыте оказалось удобно иметь GOPATH на директорию проекта, и внутри него держать все зависимости (например, git submodule'ями), и собирать встроенным go build (например, через Makefile).
Пути вида "../exec" имхо зло.
Про blob: подумайте внимательно, изучите разные NoSQL решения и кейсы их использования, и больше не пишите ерунды.
Для кеша вам тоже нужно понимать его структуру, если вы не хотите его полностью инвалидировать при любом (даже не связанном с содержащимися данными) изменении. Вообще говоря странно, что вы после подробной публикации о способах кеширования пишите подобную ерунду.
Полное администрирование нескольких бд конечно сложнее, но избавляет от геморроя для админов в последствии, когда перегружается центральная бд, и после, когда не хвататит производительности master — много slave'ов на запись. Дальше, конечно, применяется партицирование, что на уровне приложения означает переделывание его значительной части, а на уровне БД — хрупкое и требующее очень чуткого сопровождения решение.
Что касается денормализации данных: внезапно, для значительного повышения производительности и эффективности использования ресурсов, с определённого момента это необходимо. Простейшие транзакции — блокировки — реализуются миллионом разных способов, вплоть до простейшего в мемкеше/редисе.
По иному подходу к архитектуре — вы, безусловно, правы, однако умение с этим работать — важная часть профессии разработчика.
В реальности, баз данных сейчас существует великое множество, не только SQL и NoSQL, но и NewSQL (например, VoltDB, прекрасно работающий, с сотнями тысяч транзакций в секунду, и прозрачно масштабируемый). Помимо этого, есть различные внешние решения для SQL, решающие их проблемы масштабируемости и отказоусточивости. В рамках есть богатые возможности для выбора между знакомыми разработчикам и админам технологиями и новыми для них, но лучше подходящими под задачи. Главное, разбираться во всём этом многообразии баз, с чем, к сожалению, у подавляющего большинства принимающих технологические решения есть проблемы, в результате чего применяются их «любимые» и не слишком подходящие технологии.
Что касается списка наушников в конце, некоторые производители универсальных IEM'ов дают возможность изготовить к ним кастомные насадке — например, Etymotic.