А ты можешь лучше?

Я поставлю эту фразу на второе место по оправданию неудавшихся проектов.

Это так же один из отзывов на мою трилогию.

Могу я лучше или нет - это просто не имеет значения. Действительно ли вам надо быть экспертом в определённой области, чтобы критиковать? Конечно нет. Более того, приём "сначала сделай лучше, а потом суди" - вы сможете найти в книге преступлений против логики. Это не ответ на то, почему проект оказался неудачным.

Треугольный мир

Какое самое частое использование компромиссного треугольника?

Ответ: для оправдания неудавшихся проектов (я слышу эту "трилогию" постоянно). Проблема заключается в том, что в реальности эта концепция работает не так, как многим хочется чтобы она работала.

Компромиссный треугольник хорош, когда перед вами сидят студенты - вы можете нарисовать это на доске и объяснить, что изменение одной стороны влечёт за собой изменение другой (или сразу двух). Это замечательно - никаких проблем с этим.

В реальности я могу взять треугольник, утащить менеджера в ресторан и впихнуть в эту концепцию всё что угодно. Найдите самых лучших людей по C++ и посадите их писать проект для СУБД. В результате будет провал с последующим переписыванием всего и вся на C++ :) В реальности вы можете потратить кучу денег и не получить ничего. Я уже ссылался на эту историю про систему из одной таблицы - вы можете потратить сколько угодно времени и денег, прежде чем осознаете, что ничего не будет работать.

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

Слишком много проектов управляется не треугольником, а четырёхугольником, четвёртая сторона которого зовётся "глупость".

Третья итерация, часть III

Девять к одному

Есть хорошая статья (спасибо Тому Кайту за ссылку). Она утверждает, что 10% вещей в жизни происходит без вашего контроля. Оставшиеся 90% определяются вашей реакцией.

90% определяется вашим собственным выбором. Теперь, если я возьмусь перефразировать это на проектирование и разработку приложений для СУБД Oracle - 90% успеха зависит от того, как вы написали и спроектировали своё приложение. СУБД даёт вам лишь 10% того фундамента, который вы можете использовать (или нет). Ребята из Redwood Shores дали вам возможность, остальное определяете вы сами.

Индикатор выбора

Сегодня я получил замечательный комментарий от Кевина Клоссона - желание переписать продукт с нуля является хорошим индикатором правильности сделанных выборов.

Не пытайтесь использовать proof by design из этого списка - если вы спроектировали что-то, не способное масштабироваться в Oracle - это не означает, что Oracle не способен масштабироваться. Оглянитесь и посмотрите на то, каким образом вы выбирали.

Уроки истории

История нас учит - не важно, сколько у вас денег и не имеющих выбора клиентов (которым вы можете продавать всё что угодно). Сегодняшних королей завтра никто уже не помнит - имейте это в виду.

И последнее

Гималаи - это не лучшее место для жизни.

Третья итерация, часть II

Игнорируйте Ларри

Особенно, если его фамилия Эллисон. Хотя... это будет не очень умно. Существует закон Эллисона, который утверждает:

"Полезность информации увеличивается экспоненциально по мере устранения её фрагментации".

Иными словами - чем больше информации собрано у вас в одном месте, тем больше от неё пользы.

Теперь достаньте мне что-нибудь из кэша Гималайского сервера приложений. Что? Угадали - вы не можете написать запрос к этим данным на SQL... Ох, да - вы можете сделать дамп содержимого кэша. Проблема в том, что пользователи хотят анализировать данные. Вы закончите тем, что загрузите этот дамп обратно в СУБД... Если сумеете разобраться в содержимом - очевидно, писатели дампа никогда не задумывались над тем, что кто-то захочет его использовать. Но даже там от него вряд ли будет много пользы.

Вы когда-нибудь слышали про Read Consistency? Люди, которые не заморачивали себя изучением СУБД, вряд ли хотели иметь дело с такими "мелочами", как получение корректного результата. Кого это волнует - мы просто пролетим по памяти и выгрузим то, что там находится. Мусор на входе, мусор на выходе. Унося информацию в Гималаи, они не только экспоненциально уменьшили её полезность, но и сделали невозможным обратную консолидацию. Ваш бизнес использует информацию или информация использует ваш бизнес?

Кто такие ROI и TCO?

Наверное, это ники из моей ICQ? Не угадали.

ROI - это отношение заработанных/потерянных на инвестиции денег к самой инвестиции.

TCO - суммарная стоимость владения, учитывающая как прямые, так и косвенные расходы на владение чем-либо.

Как это может быть связано с Гималайскими серверами приложений?

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

Здесь вы можете найти ссылку на презентацию с результатами консолидации приложений в Oracle Global Operations Data Center. В результате они улучшили ROI, уменьшили TCO, сделали систему более управляемой... Замороченные на консолидации ребята явно не сошли с ума?

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

Опять этот Эллисон

Вот вам ещё один закон Эллисона (на сей раз не Ларри, а Харлан):

"Два наиболее часто встречающихся элемента во вселенной - это водород и глупость".

Третья итерация, часть I

Миф репликации

Многие верят, что имея перегруженный сервер, они могут поставить рядом второй такой же, настроить двустороннюю репликацию и снизить нагрузку на существующий сервер вдвое. В конечно итоге, ведь 1+1=2, поэтому, добавляя в два раза больше железа мы сможем работать в два раза быстрее, верно? Ответом будет только "может быть".

Что необходимо сделать одному серверу, чтобы выполнить транзакцию?

1. Выполнить транзакцию.

Что необходимо сделать находящемуся в репликации серверу?

1. Выполнить транзакцию.
2. Поместить транзакцию в очередь на репликацию.
3. Организовать передачу на другие узлы.
   
4. После успешного применения транзакции, удалить её из очереди.

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

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

Гималайская мечта

И так, вы думаете что масштабирование системы заключается в бесконечном добавлении Гималайских серверов приложений?

Добро пожаловать в реальный мир

Как только вы организуете вынесенный из СУБД кэш - вы, по-сути, собираетесь делать репликацию. Изменяющиеся данные в СУБД необходимо синхронизировать с внешним кэшем. Если вы допускаете изменение данных в кэше приложения - изменения необходимо синхронизировать обратно в СУБД. Вот и готова двусторонняя репликация. Чем больше узлов вы добавляете - тем больше становится нагрузка на каждый из узлов в отдельности.

Вам необходимо ещё больше железа, чтобы делать ту же самую работу ещё медленней.

Кто-то прогулял начальную школу

Если количество изменений данных в СУБД превышает количество запросов этих данных с серверов приложений - затраты на синхронизацию будут несоизмеримо выше, чем запрос тех же данных напрямую из СУБД.

Один такой "High Speed" сервер приложений, использующий "новейшую технологию кэширования, кардинально увеличивающую производительность и масштабируемость" (попробуйте погуглить это) за одну синхронизацию кэша потреблял ресурсы, достаточные для недельной работы системы, если бы никакого кэша не было вообще и все запросы шли напрямую к СУБД Oracle. А синхронизацию он выполнял каждые двадцать минут. Упс... Похоже, кто-то просто не умел считать.

Но ведь 1+1=2

И это правда. Только в данном случае - это оказалась результирующая нагрузка на каждый компонент системы.