Здравствуйте, 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 серверами с чётко управляемой конфигурацией. Облако — это просто обещания, что ЕСЛИ вдруг завтра весь Бангладеш захочет у вас зарегаться, ваш сервис не упадёт. Оно мне надо?
