Ребят, не сочтите за слоупока, просто недавно образовалась классическая проблема "босс прочитал новое слово в Тырнетах и теперь мы все дружно бежим его претворять в жизнь". Слово это Azure. Сам хайп я давно уже игнорирую как только впервые о нём прочитал, но сейчас пришлось ещё раз провозиться с кучей обзоров и даже конкретных уроков, что только подтверждает моё первичное мнение:
Azure — это СТЕНА из новоиспечённых API, разделяющая старые технологии от старых программистов. Разумеется, в стене есть дыры (функции API), через которые за денюшку можно взглянуть за стену. Ну, это всем известный факт — если раньше разово продавали продукт и клиент исчезал, то теперь через облако доить клиента можно бесконечно.
Что же мне до сих пор не ясно? Пожалуй, самую малость: я вполне допускаю, что упустил какую-то архиважную деталь и моё видение облаков чересчур уж капиталистично. Вопрос: ЧТО конкретно мне может дать облако сверх того, что я имел до этого?
Вы все знаете стек старых технологий: сервер-железо, ОСь, виртуальные машины, диспетчеры нагрузки, кластеры, СУБД, Web-сервер, Windows-service (да-да, самый обычный типа Windows Time и использующий нативный TCP), Web-service (SOAP), может даже Protocol Buffers, C#, WPF, список всем очевиден, мы все с этим работали. И вот сейчас, даже при всей очевидности доящей роли облаков, клиенты смотрят на новые ворота и отчаянно пытаются их открыть. Я как инженер понимаю, что это новое проприетарное болото и трата времени.
Из хорошего — "резиновые" ресурсы. То есть, при приходе толпы людей, сервера сами поднимутся и запустятся для обработки всей толпы, потом обратно съёжатся, не потребляя деньги.
Из плохого — когда я работал с Azure, у него было сразу три вебморды — старая, новая и сверхновая. И хрен-то найдёшь то что нужно.
Здравствуйте, Kolesiki, Вы писали:
K>Что же мне до сих пор не ясно? Пожалуй, самую малость: я вполне допускаю, что упустил какую-то архиважную деталь и моё видение облаков чересчур уж капиталистично. Вопрос: ЧТО конкретно мне может дать облако сверх того, что я имел до этого?
K>Ваши мнения?
Тезисно: Новая серебряная пуля — DevOps. Изменение цикла разработки и деплоймента приложений. Можешь выпускать апдейты по 10 раз в день и они в течение секунд становятся доступны всем кастомерам. Клиенту не нужно свое железо для установки софта и персонал для его администрирования. Нет поддержки зоопарка старых версий.
Здравствуйте, Kolesiki, Вы писали:
K>Что же мне до сих пор не ясно? Пожалуй, самую малость: я вполне допускаю, что упустил какую-то архиважную деталь и моё видение облаков чересчур уж капиталистично. Вопрос: ЧТО конкретно мне может дать облако сверх того, что я имел до этого?
ИМХО, облако — это ресурсы по требованию. Т.е., понадобился сервер или ресурс какой — развернул его за минуты (и часто настроил за еще несколько минут или часов).
Не нужен — стопорнул и в стороночку сложил или удалил, чтобы не мешался.
Всё остальное — про скорость, дешевизну и прочее — это маркетологический буллшит, на который не надо обращать особого внимания. Оно, как раз, по-разному бывает.
С>Из хорошего — "резиновые" ресурсы. То есть, при приходе толпы людей, сервера сами поднимутся и запустятся для обработки всей толпы, потом обратно съёжатся, не потребляя деньги.
Только резиновость нужно самому архитектурно поддерживать, а если монолит то никакой резиновостью и не пахнет.
Резиновыми их можно было бы назвать, если все было бы прозрачно на уровне кода, например:
long* array = new long [дайте мне 100 террабайт памяти]; //и сотню процессоров для параллельной обработки этого массива
Здравствуйте, turbocode, Вы писали:
С>>Из хорошего — "резиновые" ресурсы. То есть, при приходе толпы людей, сервера сами поднимутся и запустятся для обработки всей толпы, потом обратно съёжатся, не потребляя деньги.
T>Только резиновость нужно самому архитектурно поддерживать, а если монолит то никакой резиновостью и не пахнет. T>Резиновыми их можно было бы назвать, если все было бы прозрачно на уровне кода, например: T>
T>long* array = new long [дайте мне 100 террабайт памяти]; //и сотню процессоров для параллельной обработки этого массива
T>
Для этого 20 лет уже как существует всякое там MPI, а сотню процессоров вам всё равно никто не даст. То есть, бывают вроде машины со 128 ядрами, но это что-то редкое.
С>Для этого 20 лет уже как существует всякое там MPI, а сотню процессоров вам всё равно никто не даст. То есть, бывают вроде машины со 128 ядрами, но это что-то редкое.
В этом и проблема что это физически одна машина со 128 ядрами, а не облако десятка физических машин в сумме которые дают 128 ядер но которое можно выдать пользователю как одну машину на уровне операционной системы.
Здравствуйте, Слава, Вы писали: С>Из хорошего — "резиновые" ресурсы. То есть, при приходе толпы людей, сервера сами поднимутся
Ну не, в это не особо верится. Как правильно заметили, резиновость надо самому поддерживать (не будет же MS ради тебя SQL-кластер лепить!), плюс наверняка для "поднимутся" нужно покупать отдельный план, где тебе гарантируют макс.количество "резерва".
Железо — оно же 100% осталось старое, никто облака из космических технологий не делал. Просто судя по интерфейсу, от прогеров скрыли вообще всё и теперь ты даже не знаешь, где и как работает твоя система — голое ли железо, VM, docker или вообще на одном IIS тыщща вебсайтов — вот что меня пугает.
Раньше ты мог делать чёткий запас по надёжности, причём сам запас зависел от задачи — где узко, там и расширяем. Как это можно сделать в облаках — понятия не имею (например, запросить 1ТБ ОЗУ или организовать шардинг БД).
Здравствуйте, v6, Вы писали:
v6>Тезисно: Новая серебряная пуля — DevOps. Можешь выпускать апдейты по 10 раз в день
Хех... так ведь шлёпать релизы можно и без облаков! Более того — откуда возьмётся это ускорение, если сама суть разработки продукта не поменялась? Как и раньше, это белка в колесе "разработка-тестирование-фидбэк-разработка-тестирование до стадии <<и так сойдёт — можно в релиз>>".
v6> Клиенту не нужно свое железо для установки софта и персонал для его администрирования.
С чего бы? Облако — всего лишь новое название "сервер, где я запустил сервис". Если переделать всё под веб-морду — тогда да, но это вряд ли относится к девопсу.
v6> Нет поддержки зоопарка старых версий.
Увы, есть и никакая методология это не изменит, "зоопарк — он в сути программы". Даже новая вебморда не искоренит факта, что есть старые версии файлов и их тоже нужно уметь открывать.
Здравствуйте, _ABC_, Вы писали:
_AB>ИМХО, облако — это ресурсы по требованию.
Да, очень близко к сути их рекламы. Грусть-тоска в том, сколько это стóит и какую именно часть нужно расширять. И каким конкретно путём. Скажем, тормозную БД можно:
1. Поставить на более мощный проц
2. Увеличить память
3. Поставить сверхбыстрый RAID
4. Сегментировать таблицы
5. Сбросить устаревшие данные
6. Собрать SQL-кластер с балансировщиком и поэтессами
7. Сбросить лишнюю нагрузку (если там ещё файлопомойка и Web)
8. Поменять СУБД(!)
9. Поменять бестолкового админа на того, кто действительно умеет тюнинговать параметры сервера.
Путей — много и все они разной стоимости. Кто и как это решает в облаке, вот в чём вопрос! Не всё можно решить "а подключим мы ещё один сервер!", тут нужен чёткий план трассировки всех компонент.
Я это к чему: теряя контроль над исполняющей средой, мы превращаемся в беспомощных хомячков, прыгающих вокруг мелкомягкой цитадели: "Эй, там, на баржé! Подкрутите там чёнть, система тормозит!".
Т.е. в данном случае мы ухудшаем качество системы
Здравствуйте, Kolesiki, Вы писали:
K>Да, очень близко к сути их рекламы. Грусть-тоска в том, сколько это стóит и какую именно часть нужно расширять. И каким конкретно путём. Скажем, тормозную БД можно: K>9. Поменять бестолкового админа на того, кто действительно умеет тюнинговать параметры сервера.
Единственный правильный ответ. Всё остальное — гадание методом тыкания пальцем в неизвестную область.
K>Я это к чему: теряя контроль над исполняющей средой
В общем-то, определенные гарантии по производительности и надежности они дают. Вопрос в деньгах.
K>Т.е. в данном случае мы ухудшаем качество системы
Ну... Я бы сказал, что сценарии разные бывают. Я представляю себе сценарии, когда облако удобнее и выгоднее.
Правда, они к моей сфере не относятся никак пока что.
Самое главное (ИМХО), что оно даёт — поощряет писать приложения, которые легко горизонтально масштабируются. Это с точки зрения программистов.
С точки зрения клиентов добавилась опция "кластер по требованию", то есть это такая ферма, которая сама расширяется/сужается в зависимости от нагрузки. При этом можно по-прежнему взгромоздить Azure Services на обычный сервак и крутить всё in-house.
То есть облако — это всего лишь особый вид обычного хостинга, просто в отличие от "классического" хостинга, облако можно перенастраивать по ходу дела и прозрачно для самого приложения. И на деньги облака завязаны не более, чем сам хостинг. Собственно, вопрос "хостинг vs облако" чаще всего с практической точки зрения сводится к "клиент не может пользоваться приложением при определённой нагрузке, но зато расходы фиксированны" vs "клиент всегда может пользоваться приложением, но расходы могут плавать".
Здравствуйте, Kolesiki, Вы писали:
K>Ну не, в это не особо верится. Как правильно заметили, резиновость надо самому поддерживать
Резиновость поддерживается на уровне архитектуры. Если система построена на stateless-сервисах, то она легко масштабируется. От Azure требуется только добавлять/удалять ноды в кластер. Правда, вот этого Azure автоматически делать вроде бы пока не умеет.
Плюс, Azure даёт кучу сервисов "из коробки" — там и load balancer есть, и failover-переключение при падении ноды на ASF кластере и service locator и ServiceBus для обмена сообщениями.. там длинная портянка со списком сервисов.
Если архитектура не заточена под масштабируемость, то Azure выступает лишь в виде обычного хостинга. Ну с некоторой возможностью ручного масштабирования через переключение между вариантами доступных мощностей.
K>Просто судя по интерфейсу, от прогеров скрыли вообще всё и теперь ты даже не знаешь, где и как работает твоя система — голое ли железо, VM, docker или вообще на одном IIS тыщща вебсайтов — вот что меня пугает.
Можно поднять там VM и иметь полный доступ, практически к "голому" железу.
Интерфейс — да, сделано, видимо, маркетологами. Куча свистоперделок, а некоторые необходимые вещи физически не доступны через веб-интерфейс.
K>Раньше ты мог делать чёткий запас по надёжности, причём сам запас зависел от задачи — где узко, там и расширяем. Как это можно сделать в облаках — понятия не имею (например, запросить 1ТБ ОЗУ или организовать шардинг БД).
А как сделать 1 ТБ ОЗУ на физической машине? Уже есть такое железо?
Запасы надёжности там вполне настраиваемые. Всё от бюджета зависит.
Здравствуйте, Kolesiki, Вы писали:
K>Azure — это СТЕНА из новоиспечённых API, разделяющая старые технологии от старых программистов. Разумеется, в стене есть дыры (функции API), через которые за денюшку можно взглянуть за стену. Ну, это всем известный факт — если раньше разово продавали продукт и клиент исчезал, то теперь через облако доить клиента можно бесконечно.
K>Что же мне до сих пор не ясно? Пожалуй, самую малость: я вполне допускаю, что упустил какую-то архиважную деталь и моё видение облаков чересчур уж капиталистично. Вопрос: ЧТО конкретно мне может дать облако сверх того, что я имел до этого?
Ответ простой, но тебе не понравится. Azure это не про технологии, Azure это про бизнес. А технологии — следствие.
Здравствуйте, Kolesiki, Вы писали:
v6>>Тезисно: Новая серебряная пуля — DevOps. Можешь выпускать апдейты по 10 раз в день
K>Хех... так ведь шлёпать релизы можно и без облаков! Более того — откуда возьмётся это ускорение, если сама суть разработки продукта не поменялась? Как и раньше, это белка в колесе "разработка-тестирование-фидбэк-разработка-тестирование до стадии <<и так сойдёт — можно в релиз>>".
И с какой скоростью можно "шлепать релизы", и как быстро они попадают к кастомеру и как быстро появляется фидбек от них? В традиционном сценарии фазы этого процесса растягиваются на месяцы, в случае облака это становятся часы и минуты.
От итераций "разработка-тестирование-фидбэк" давно уже уходят.
v6>> Клиенту не нужно свое железо для установки софта и персонал для его администрирования.
K>С чего бы? Облако — всего лишь новое название "сервер, где я запустил сервис". Если переделать всё под веб-морду — тогда да, но это вряд ли относится к девопсу.
Нет. Вот раньше ваш продукт требовал sql-сервер. И клиенту приходилось покупать железо и лицензии, находить персонал, который имеет соответствующую квалификацию для администрирования. Что потом делать с этим добром, если ваш продукт уже не нужен — тоже вопрос. А теперь вы просто клиентский тенант просто пользуется облачным хранилищем и клиент платит только за то, что реально использовал и ничего не администрирует.
v6>> Нет поддержки зоопарка старых версий.
K>Увы, есть и никакая методология это не изменит, "зоопарк — он в сути программы". Даже новая вебморда не искоренит факта, что есть старые версии файлов и их тоже нужно уметь открывать.
Поддержка старых версий файлов — это малая часть от нагрузки (причем выполняется однократно) при поддержке старых версий и обязательстве вносить новые фичи в 2-3 последних релиза параллельно.
Здравствуйте, Kolesiki, Вы писали:
_AB>>ИМХО, облако — это ресурсы по требованию.
K>Да, очень близко к сути их рекламы. Грусть-тоска в том, сколько это стóит и какую именно часть нужно расширять. И каким конкретно путём. Скажем, тормозную БД можно: K>1. Поставить на более мощный проц K>2. Увеличить память K>3. Поставить сверхбыстрый RAID K>4. Сегментировать таблицы K>5. Сбросить устаревшие данные K>6. Собрать SQL-кластер с балансировщиком и поэтессами K>7. Сбросить лишнюю нагрузку (если там ещё файлопомойка и Web) K>8. Поменять СУБД(!) K>9. Поменять бестолкового админа на того, кто действительно умеет тюнинговать параметры сервера.
См. вертикальное масштабирование vs горизонтальное масштабирование.
Облака — они все про горизонтальное. Конечно, это нужно поддерживать на уровне архитектуры.
Здравствуйте, v6, Вы писали:
v6>И с какой скоростью можно "шлепать релизы", и как быстро они попадают к кастомеру и как быстро появляется фидбек от них? В традиционном сценарии фазы этого процесса растягиваются на месяцы, в случае облака это становятся часы и минуты.
v6>От итераций "разработка-тестирование-фидбэк" давно уже уходят.
Выглядит как, что в паттерне "х..як, х..як и в продакшен" сократили фазу "в продакшен" и зациклили "х..як" за деньги клиента. Не, для бизнеса это возможно и в самом деле прибыльно...
Здравствуйте, Michael7, Вы писали:
v6>>И с какой скоростью можно "шлепать релизы", и как быстро они попадают к кастомеру и как быстро появляется фидбек от них? В традиционном сценарии фазы этого процесса растягиваются на месяцы, в случае облака это становятся часы и минуты.
v6>>От итераций "разработка-тестирование-фидбэк" давно уже уходят.
M>Выглядит как, что в паттерне "х..як, х..як и в продакшен" сократили фазу "в продакшен" и зациклили "х..як" за деньги клиента. Не, для бизнеса это возможно и в самом деле прибыльно...
Автотесты. В том числе довольно экзотические и интеллектуальные типа Netflix Chaos Monkey
Здравствуйте, turbocode, Вы писали:
T>В этом и проблема что это физически одна машина со 128 ядрами, а не облако десятка физических машин в сумме которые дают 128 ядер но которое можно выдать пользователю как одну машину на уровне операционной системы.
orleans (для самостоятельного хостинга) и azure service fabric — именно оно. И автомасштбирование есть и настройка через API прямо из запущенного сервиса.
T>>В этом и проблема что это физически одна машина со 128 ядрами, а не облако десятка физических машин в сумме которые дают 128 ядер но которое можно выдать пользователю как одну машину на уровне операционной системы.
S>orleans (для самостоятельного хостинга) и azure service fabric — именно оно. И автомасштбирование есть и настройка через API прямо из запущенного сервиса.
Что оно? Там везде требуются микросервисы, а я хочу чтобы монолит видел что у него в распоряжении есть 1280 ядер и 100 терабайт памяти, так же как и TaskManager на уровне операционной системы — а будут ли эти ядра физически на одной машине или на сотне отдельных в одной сети не важно.
Здравствуйте, turbocode, Вы писали:
T>Что оно? Там везде требуются микросервисы, а я хочу чтобы монолит видел что у него в распоряжении есть 1280 ядер и 100 терабайт памяти, так же как и TaskManager на уровне операционной системы — а будут ли эти ядра физически на одной машине или на сотне отдельных в одной сети не важно.
Да нивопрос как бы, правда по выгодности предложение из серии "при покупке квартиры — кепка в подарок".
Или вы хотите ферму с той же суммарной производительностью, с теми же задержками и чтоб ещё и бесплатно?
Если серьёзно — прямые руки гораздо дешевле обходятся. Пример StackOverflow или Age of Ascent как бы намекает.
S>Да нивопрос как бы, правда по выгодности предложение из серии "при покупке квартиры — кепка в подарок". S>Или вы хотите ферму с той же суммарной производительностью, с теми же задержками и чтоб ещё и бесплатно?
Я хочу чтобы облака были настоящими, а не фейковыми как сейчас.
Здравствуйте, Artem Korneev, Вы писали:
AK>А как сделать 1 ТБ ОЗУ на физической машине? Уже есть такое железо?
Есть. Недорого, всего $10 в час у Амазона. В инстансе x1.32xlarge стоит 2Тб памяти и 128CPU. На их спотах можно иногда дешевле купить.
Здравствуйте, turbocode, Вы писали:
S>>orleans (для самостоятельного хостинга) и azure service fabric — именно оно. И автомасштбирование есть и настройка через API прямо из запущенного сервиса. T>Что оно? Там везде требуются микросервисы, а я хочу чтобы монолит видел что у него в распоряжении есть 1280 ядер и 100 терабайт памяти, так же как и TaskManager на уровне операционной системы
Что значит "TaskManager на уровне операционной системы"? В Amazon'е покупатель получает полный контроль над ОС, нынче там даже амазоновский гипервизор крутится на отдельном железе. За небольшую деньгу можно гарантировать, что инстанс будет монопольно вообще использоваться для избежания проблем с побочными эффектами других жильцов или из-за требований закона.
T> — а будут ли эти ядра физически на одной машине или на сотне отдельных в одной сети не важно.
А это уже физически нереально. Скорость света никто не отменял — интерконнекты между разными машинами всегда будут медленнее, чем локальный доступ.
T>> — а будут ли эти ядра физически на одной машине или на сотне отдельных в одной сети не важно. C>А это уже физически нереально. Скорость света никто не отменял — интерконнекты между разными машинами всегда будут медленнее, чем локальный доступ.
Все что я хотел это GRID на уровне операционной системы, чтобы можно было выполнять монолиты на GRID-е и в таком случае можно было бы запустить SQLServer на 10000 процессорах и 100TB памяти и не нужны были бы все эти noSQL.
Здравствуйте, Cyberax, Вы писали:
AK>>А как сделать 1 ТБ ОЗУ на физической машине? Уже есть такое железо? C>Есть. Недорого, всего $10 в час у Амазона. В инстансе x1.32xlarge стоит 2Тб памяти и 128CPU. На их спотах можно иногда дешевле купить.
Здравствуйте, Artem Korneev, Вы писали:
AK> AK>>А как сделать 1 ТБ ОЗУ на физической машине? Уже есть такое железо? AK> C>Есть. Недорого, всего $10 в час у Амазона. В инстансе x1.32xlarge стоит 2Тб памяти и 128CPU. На их спотах можно иногда дешевле купить. AK> Вопрос был про физическую машину, не облачную VM.
А какая разница? Одна или более VM находятся на одной физической машине, так что ответ на твой вопрос — да, есть такое железо.
Здравствуйте, Artem Korneev, Вы писали:
AK>>>А как сделать 1 ТБ ОЗУ на физической машине? Уже есть такое железо? C>>Есть. Недорого, всего $10 в час у Амазона. В инстансе x1.32xlarge стоит 2Тб памяти и 128CPU. На их спотах можно иногда дешевле купить. AK>Вопрос был про физическую машину, не облачную VM.
Так это реальная физическая машина, просто доступ к ней через Amazon. Даже скажу по секрету, инстансы типа x1.32xlarge все работают на выделенном железе, так что на физической железке никого другого не будет.
Здравствуйте, turbocode, Вы писали:
C>>А это уже физически нереально. Скорость света никто не отменял — интерконнекты между разными машинами всегда будут медленнее, чем локальный доступ. T>Все что я хотел это GRID на уровне операционной системы, чтобы можно было выполнять монолиты на GRID-е и в таком случае можно было бы запустить SQLServer на 10000 процессорах и 100TB памяти и не нужны были бы все эти noSQL.
Невозможно в принципе. Без разницы на чём делать — от физических ограничений не уйти. Ну то есть, запустить-то оно запустится, но вот из-за оверхедов по блокировке будет работать медленнее, чем на IBM PC XT. Чтобы работало быстрее — нужно распределять на уровне логики, а там уже и CAP-теорема приходит.
C>Невозможно в принципе. Без разницы на чём делать — от физических ограничений не уйти.
От каких ограничений?
C>Ну то есть, запустить-то оно запустится, но вот из-за оверхедов по блокировке будет работать медленнее, чем на IBM PC XT. Чтобы работало быстрее — нужно распределять на уровне логики, а там уже и CAP-теорема приходит.
Сейчас SQLServer работает на 8-ми ядрах, почему не сможет работать на 100000 ядрах?
Здравствуйте, turbocode, Вы писали:
C>>Невозможно в принципе. Без разницы на чём делать — от физических ограничений не уйти. T>От каких ограничений?
Скорость света и пропускная способность каналов связи.
На частоте 2ГГц за один такт свет проходит примерно 15 сантиметров (одна световая наносекунда — это 30 сантиметров). Если машины расположены за 10 метров друг от друга, то за время прохождения сигнала в одну сторону пройдёт около 30 тактов (реально ещё больше).
Пропускная способность ограничена частотой света, который проходит через оптоволокно и выше ультрафиолета не подняться. Так что интерконнеты между узлами нельзя масштабировать бесконечно.
C>>Ну то есть, запустить-то оно запустится, но вот из-за оверхедов по блокировке будет работать медленнее, чем на IBM PC XT. Чтобы работало быстрее — нужно распределять на уровне логики, а там уже и CAP-теорема приходит. T>Сейчас SQLServer работает на 8-ми ядрах, почему не сможет работать на 100000 ядрах?
Потому, что он масштабируется не линейно. Так что с какого-то момента добавление ядер будет делать его МЕДЛЕННЕЕ. И этот "какой-то момент" наступает даже до 128 ядер.
С этим можно бороться, но на выходе неминуемо получается та или иная форма NoSQL. Так чтобы взмахнуть волшебной палочкой и получить сразу ACID на 100500 узлах и с мгновенной работой — не получится.
C>Пропускная способность ограничена частотой света, который проходит через оптоволокно и выше ультрафиолета не подняться. Так что интерконнеты между узлами нельзя масштабировать бесконечно.
Конечно слать по одной ASM команде через сеть и ждать ответа никакая скорость света не поможет, а вот если посылать тред с целой подпрограммой то это не загрузит сеть — но это должно работать на уровне операционной системы прозрачно.
T>>Сейчас SQLServer работает на 8-ми ядрах, почему не сможет работать на 100000 ядрах? C>Потому, что он масштабируется не линейно. Так что с какого-то момента добавление ядер будет делать его МЕДЛЕННЕЕ. И этот "какой-то момент" наступает даже до 128 ядер.
Запросы паралеляться хорошо, особенно на чтение. Что же там такое что может замедлять на 128 ядрах?
C>С этим можно бороться, но на выходе неминуемо получается та или иная форма NoSQL. Так чтобы взмахнуть волшебной палочкой и получить сразу ACID на 100500 узлах и с мгновенной работой — не получится.
Как будто сейчас мгновенная работа у SQLServer, на это никто и не рассчитывает.
Здравствуйте, turbocode, Вы писали:
C>>Пропускная способность ограничена частотой света, который проходит через оптоволокно и выше ультрафиолета не подняться. Так что интерконнеты между узлами нельзя масштабировать бесконечно. T>Конечно слать по одной ASM команде через сеть и ждать ответа никакая скорость света не поможет, а вот если посылать тред с целой подпрограммой то это не загрузит сеть — но это должно работать на уровне операционной системы прозрачно.
А к памяти как этот поток обращаться будет?
C>>Потому, что он масштабируется не линейно. Так что с какого-то момента добавление ядер будет делать его МЕДЛЕННЕЕ. И этот "какой-то момент" наступает даже до 128 ядер. T>Запросы паралеляться хорошо, особенно на чтение. Что же там такое что может замедлять на 128 ядрах?
Блокировка, чтобы проверить, что никто другой не пишет в этот момент. Ну и даже запросы на чтение параллелятся плохо, если все данные не помещаются на один узел.
C>Блокировка, чтобы проверить, что никто другой не пишет в этот момент. Ну и даже запросы на чтение параллелятся плохо, если все данные не помещаются на один узел.
Возможно я не правильно выразил свою мысль но я не против, если внутри SQLServer будет noSQL (или MapReduce или GRID) при условии что внешнее API для конечного пользователя будет выглядеть как обычный SQL.
Здравствуйте, turbocode, Вы писали:
C>>Блокировка, чтобы проверить, что никто другой не пишет в этот момент. Ну и даже запросы на чтение параллелятся плохо, если все данные не помещаются на один узел. T>Возможно я не правильно выразил свою мысль но я не против, если внутри SQLServer будет noSQL (или MapReduce или GRID) при условии что внешнее API для конечного пользователя будет выглядеть как обычный SQL.
А пофиг. Бесконечное масштабирование SQL с произвольными join'ами невозможно, как и невозможно масштабирование ACID-семантики.
C>А пофиг. Бесконечное масштабирование SQL с произвольными join'ами невозможно, как и невозможно масштабирование ACID-семантики.
таблицы и джоины это всего лишь абстракция ( а абстракция не может быть невозможной ), а как это масштабирование будет реализовано внутри мне пофиг — лишь бы работало как обычный SQL.
Здравствуйте, Cyberax, Вы писали:
C>А пофиг. Бесконечное масштабирование SQL с произвольными join'ами невозможно, как и невозможно масштабирование ACID-семантики.
Не спорь с троллем, это бесполезно. Персонаж не за знаниями сюда пришел.
Здравствуйте, _ABC_, Вы писали:
K>>Я это к чему: теряя контроль над исполняющей средой _AB>В общем-то, определенные гарантии по производительности и надежности они дают. Вопрос в деньгах.
Разве я о гарантиях? Я про контроль. Скажем, если я чётко знаю, что крутится на сервере, я могу дополнительно навешать необременительных сервисов за ту же стоимость. Или поставить firewall именно для этого сервера, где данные для фильтра будут браться с надёжной дискетки другого компа. Кто такую гибкость предоставит в облаке?
K>>Т.е. в данном случае мы ухудшаем качество системы _AB>Ну... Я бы сказал, что сценарии разные бывают. Я представляю себе сценарии, когда облако удобнее и выгоднее. _AB>Правда, они к моей сфере не относятся никак пока что.
Вот! И в моей области тоже нет гипертребований. Грубо говоря, средний бизнес (коего большинство) запросто обойдётся доморощенным админом и 5-10 серверами с чётко управляемой конфигурацией. Облако — это просто обещания, что ЕСЛИ вдруг завтра весь Бангладеш захочет у вас зарегаться, ваш сервис не упадёт. Оно мне надо?
Вопрос: ЧТО конкретно мне может дать облако сверх того, что я имел до этого?
