Спеціалізовані серверні процесори Microsoft Cobalt 200 отримали 132 ядра ARM

[ArmagedoonZergs]

ArmagedoonZergs
Ну так зроби натурні тести, подивимось. Думаю всім цікаво буде.
Ти виходиш з того що ці папугометри мають рівну продуктивність, а це явно не так.

Ти правий, звісно не так.
Але для наших веб додатків, найбільша проблема це память і швидкість доступу/роботи бд.
І чесно скажу, по моєму досвіду, це типове навантаження в Azure. Тому в них так віртуалки і зроблені з таким перекосом в память.

Простіше кажучи, з 100мс очікування відповіді, там на роботу CPU буде мінімум. Навскидку <10ms.

Якщо буде не впадлу на вихідних зроблю.


Та і ти сам розумієш, мова ж не про те яка там в % різниця. А про те що АРМ по факту вже тут, вже користуємось. А не десь там колись в перспективі.

[SergiusTheBest]

Я про Azure.
https://cloudprice.net/vm/Standard_B4ls_v2
https://cloudprice.net/vm/Standard_B4pls_v2
І так по всій лінійці.

Ось дивлюся на Azure https://azure.microsoft.com/en-us/prici ... #bs-series і там також немає, щоб в 2 рази ціна відрізнялась:
B2pts v2 (ARM) - $6.1320/month
B2ts v2 (Intel) - $7.5920/month
B2ats v2 (AMD) - $6.8620/month

Відправлено через 2 хвилини 11 секунд:

Якщо буде не впадлу на вихідних зроблю.

На phoronix є тести. Воно сильно залежить від типу навантаження: десь ARM вигідно, десь - ні.

[Alligator]

Ну порівнювати продуктивність трьох віртуалок у розрізі Azure це м'яко кажучи рандом, багато чого залежить від сусідів по серверу та актуального навантаження яке через пару годин може буде геть іншим.

[yuriy_dd]

Але для наших веб додатків, найбільша проблема це память і швидкість доступу/роботи бд.

в загальному випадку. Я це вирішив радикально - переписав всі критичні місця використовуючи свої бінарні структури - вдалось покращити швидкість в 10,000 і більше разів (заодно і розмір даних зменшив в рази/на порядок, і позбувся data bloating)
позбувся випадків коли запит ні з того ні з сього виконується на порядки довше
база - PostgreSQL

[ArmagedoonZergs]

Але для наших веб додатків, найбільша проблема це память і швидкість доступу/роботи бд.

в загальному випадку. Я це вирішив радикально - переписав всі критичні місця використовуючи свої бінарні структури - вдалось покращити швидкість в 10,000 і більше разів (заодно і розмір даних зменшив в рази/на порядок, і позбувся data bloating)
позбувся випадків коли запит ні з того ні з сього виконується на порядки довше
база - PostgreSQL

А масштабуєш ти свої бінарні структури як? А якщо сервіс впаде тоді що? А це я так, питання в повітря.

[yuriy_dd]

А масштабуєш ти свої бінарні структури як?

ну якщо кластер - то кожна нода має все що їх необхідно для роботи локально
обовязково - доступ лише локально, по мережі - всі переваги втрачаються через пінг

А якщо сервіс впаде тоді що?

але якщо у вас кластер то падіння ноди не вплине

основне - треба зробити роботу з отримання даних - сильно швидшою - в 10^5 разів, і зменшити самі дані - тоді оперативки вистачить на більший обєм даних
конкретно в мене - терабайти, таблиці більше млрд рядків

простий запит - дати всі продукти для даної категорії (зі всіма підкатегоріями), посортувавши по ціні, дати 3-ю сторінку з 50 продуктів на сторінку
цей запит не можливо оптимізувати використовуючи типові підходи
індекси - не допоможуть

[ArmagedoonZergs]

А масштабуєш ти свої бінарні структури як?

ну якщо кластер - то кожна нода має все що їх необхідно для роботи локально
обовязково - доступ лише локально, по мережі - всі переваги втрачаються через пінг

А якщо сервіс впаде тоді що?

але якщо у вас кластер то падіння ноди не вплине

основне - треба зробити роботу з отримання даних - сильно швидшою - в 10^5 разів, і зменшити самі дані - тоді оперативки вистачить на більший обєм даних
конкретно в мене - терабайти, таблиці більше млрд рядків

простий запит - дати всі продукти для даної категорії (зі всіма підкатегоріями), посортувавши по ціні, дати 3-ю сторінку з 50 продуктів на сторінку
цей запит не можливо оптимізувати використовуючи типові підходи
індекси - не допоможуть

Надіюсь що ти троль.
Бо якщо ти на серйозі це пишеш поставлю за тебе свічечку.

[yuriy_dd]

Бо якщо ти на серйозі це пишеш поставлю за тебе свічечку.

я серйозно. І можу це довести.

якщо ви з таким не стикались - ну то просто трохи мало досвіду, або малі дані були у вас.

Відправлено через 3 години 18 хвилин 49 секунд:
або ви в принципі не в курсі як сервер БД виконує запит, як працюють індекси і тд

[Scoffer]

цей запит не можливо оптимізувати використовуючи типові підходи

Це лише означає що курс реляційних БД у тебе не в одне вухо влетів, а в інше вилетів, а пролетів десь поряд з австралією. Для початку нічого тримати мільярд рядків в одній таблиці якщо типовий запит вибирає кілька десятків з категорійною розбивкою. Це очевидно висока просторова локальність даних, котру можна заюзати поділивши ці дані на відповідні таблиці та/або матеріальні представлення. А далі можна подумати над сегментацією та/або шардінгом, якщо знадобиться, що взагалі не факт.
Амазон перш ніж впертись в можливості традиційної реляційної бд накопила кілька сотень петабайт даних в ній, і тільки потім почала задумуватись над зміною архітектури, для прикладу. Такі ноунейм контори як нині почивша блекбері і все ще чомусь жива епл теж тримають свої дані на реляційних скбд. На ораклі, якщо бути точним. І лише ти тут один д'артаньян, у котрого бд не може впоратись з запитами

Відправлено через 3 хвилини 29 секунд:
І так, аплє тримає свої дані на ораклі на х86, а не на арм-макбуках в якихось самопальних бінарних структурах

[yuriy_dd]

Для початку нічого тримати мільярд рядків в одній таблиці якщо типовий запит вибирає кілька десятків з категорійною розбивкою

а якщо критерії пошуку - не лише по категоріям, а також бо багатьом іншим полям? я навів простий приклад, якщо ви подумаєте добре або маєте досвід - то дійдете що рішення цієї проблеми нема

І так, аплє тримає свої дані на ораклі на х86

цілком можливо, хоча і Оракл підтримує АРМ, і все більше клієнтів переходять на АРМ - і пропозиція АРМ - банально економічно вигідніша
пс: з останього - хто запропонує Оракл для нового проекту - ризикує бути звільненим

[Scoffer]

а якщо критерії пошуку - не лише по категоріям, а також бо багатьом іншим полям?

То вивчай як це зроблено в вже існуючих системах.

спойлер

Цих моделей даних для каталогів вагон на будь-який смак.

якщо ви подумаєте добре або маєте досвід - то дійдете що рішення цієї проблеми нема

Всього-то 15 років з БД працюю, і за дивним збігом обставин рішення завжди знаходилось

хто запропонує Оракл для нового проекту - ризикує бути звільненим

Я коли пропоную оракл для нового проекту, то його беруть і купують. Тому що вже не раз обпалились на самоварах, втратили суми з дуже багатьма нулями і винайняли мене щоб таких проблем більше не мати. По факту виявилось що оракл не просто так ставить свої ціники і його продукти вигідні для бізнесу саме в грошовому еквіваленті
Але до того треба ще дорости. Це ти можеш в гаражному кооперативі "вася пупкін і ко" ліпити свої бінарні структури. Справжній великий бізнес таке собі дозволити не може, дорого

[yuriy_dd]

Цих моделей даних для каталогів вагон на будь-який смак

звичайно що багато
але я вам задав маленьке конкретне питання по одній таблиці

Всього-то 15 років з БД працюю, і за дивним збігом обставин рішення завжди знаходилось

мірятись хочете? то я маю досвіду раза в два довше за вас
а ви не в змозі навіть зрозуміти про що йде мова

По факту виявилось що оракл не просто так ставить свої ціники і його продукти вигідні для бізнесу саме в грошовому еквіваленті

є багато інших рішень в тому числі платних
є й багато безкоштовних на якій йде масовий перехід наприклад Postgre (ним я успішно користуюсь вже 15 років),MySQL (мені особисто не подобається)

ліпити свої бінарні структури

люди які мають достатньо знань можуть зробити краще
наприклад те що я зробив витримує до 10 млн запитів на секунду на одне ядро, що сильно перевищує можливості будь-якої БД
ви ж знаєте можливості БД якими користуєтесь?

часто з таких підвальних рішень виходять готові open sourcсні продукти якими користуються багато хто

[Scoffer]

наприклад те що я зробив витримує до 10 млн запитів на секунду на одне ядро, що сильно перевищує можливості будь-якої БД

Ну да, куди ж там тому ораклу таймтен на 1.2 мільярда селектів на секунду з таблиці в 640 мільйонів строк.

спойлер

котрий на відміну від твого одоробла виступає справжнім кешем до ораклдб з інкрементальнім оновленням данних, можливістю виступати райт-бек кешем, повною acid і отим всім.

наприклад Postgre

Постре гівно, але навіть до нього можна прикрутити редіс в подібній до таймтен схемі і отримати більш-менш керовану і продуктивну систему.
Але краще трішки розкошелитись хоча б на sql server де опція in-memory OLTP прямо з коробки і за дуже дешево, за бюджет одного-двох таких костильних погромістів

часто з таких підвальних рішень виходять готові open sourcсні продукти якими користуються багато хто

Рівно в нулі випадків. Корисні опенсорц продукти це ті, за котрими стоять багатомільярдні корпорації.

ви ж знаєте можливості БД якими користуєтесь?

Я очевидно знаю. А ти якби знав, то не писав би костилі.
Враховуючи що винаймають персонал з мого погодження, а не з твого, рекомендую над цим задуматись

[yuriy_dd]

Ну да, куди ж там тому ораклу таймтен на 1.2 мільярда селектів на секунду з таблиці в 640 мільйонів строк

звичайно буде питанням які параметри були заліза
а також що за number of database elements

виступає справжнім кешем

логічне питання - а для чого до оракла прикручувати ще кеш? розписуються у безпорадності?

можна прикрутити редіс

можна - але воно займає сильно більше як опреративки так і диску, ще й пухне в процесі оновлень
і доступ по key/value - таки досить повільний

Але краще трішки розкошелитись хоча б на sql server де опція in-memory OLTP прямо з коробки

ключеве слово - кеш - щоб звідти взяти, треба спочатку покласти
а якщо ймовірність звертання за тим же прямує до нуля?

Враховуючи що винаймають персонал з мого погодження

ви навіть не розумієте що ви як чтарший раб який хвалить свою галеру

Відправлено через 1 хвилину 49 секунд:

А ти якби знав, то не писав би костилі

це не костилі, це реалізація моєї переваги
я і до сервера БД доступаюсь напряму, без стороніх бібліотек

[Scoffer]

yuriy_dd
Немає у тебе ніякого сервера бд. Ти не можеш вставити чи оновити одну строку свого одоробла, про що сам раніше казав. А це значить що це не бд за визначенням.
Тим часом таймтен це повноціна реляційна скдб. Редіс це неповноціна, але таки скбд. Ін-меморі олтп в сіквел сервері це невід'ємна частина сіквел сервера, ін-меморі таблиці створюються просто в звичайних базах, суперзручно.
А розділяють дані для наповлення і данні для олтп тому що це структурно різні дані. Спочатку дані нормалізуються як мінімум по третій формі, а то можна і по всій п'ятій для однозначного безпомилкового заповлення з джерела, а потім денормалізуються в олтп-кешах для швидкості віддачі запитів. Це правильна архітектура, з такою можна гарно жити до багатьох петабайт і багатьох мільйонів запитів і ні про що не думати. А у тебе архітектура абітурієнта, котрому ще не розказали жодної лекції щодо баз даних. Просто костиль і все тут. Змирись з цим.

[yuriy_dd]

Немає у тебе ніякого сервера бд

знайдете де я це назвав сервером БД? я це завжди називав бінарними структурами

Ти не можеш вставити чи оновити одну строку свого

саме так - як і будь який інший кеш

Тим часом таймтен це повноціна реляційна скдб

вона краща/швидша за Оракле?

Спочатку дані нормалізуються як мінімум по третій формі, а то можна і по всій п'ятій для однозначного безпомилкового заповлення з джерела, а потім денормалізуються в олтп-кешах

десь так і є

А у тебе архітектура абітурієнта

я вам задав простий приклад запиту - нічого з того що ви назвали не допоможе його виконати швидко