[image]

Импортозамещение в ИТ

попытка использовать процессор байкал вместо импортных
 
1 12 13 14 15 16 17 18
RU спокойный тип #01.05.2021 09:53  @yacc#01.05.2021 09:18
+
+1
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★★
yacc>>> Ну тогда расскажи мне на простом примере - вот у тебя есть большой CSV для импорта. Распараллель его не 10 отдельных узлов. А лучше на 100. :D
Татарин>> Что именно распараллелить? Побить файл на 10 кусков? на 100 - это сложнее, да? :) И засунуть их балками в SQL? И?
yacc> Это я вытащу в отдельную ветку ибо ты ляпнул и не подумал.
yacc> Чтобы прочитать CSV файл надо его распрасить. Более того - в каждый кусок вставить заголовок, который идет первой строчкой. И после разбития на файлы тебя ждет ... повторный парсинг ( уже каждого куска ) !


тут всё зависит от конкретной реализации и что понимается под словом импорт.
CSV всё таки можно нарезать частями и загрузить в acquisition layer балком.
главное что бы памяти хватило на ETL сервере при доставке.
заголовок тебе не нужно вставлять к файлам, скорее наборот ты фастлоадишь уже в готовую заранее пустую таблицы такой же структуры.


yacc> Более того - для каждой строчки сделать валидацию на предмет того, что преобразование в целевой тип возможно и не нарушает его: скажем целевая строчка VARCHAR(200) а у тебя есть строка длиной 300, которую невозможно вставить без обрезания. Потом тебе результаты обработки ... мержить :p

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

yacc> Далее, тебе потребуется не 1 а 10 или 100 коннекций к базе, причем по сети польется уже 10-100 кратный поток данных через сетевой интерфейс, что забьет остальную работу.

если параллелить что бы на разные узлы грузить то всё таки нагрузку на сеть мы тоже распараллелим, это не аргумент.
к тому же у тебя ETLные ноды к нодам кластера могут по отдельным линкам сидеть, а пользовательская сеть - по другим интерфейсам.

что тебе реально забьёт работу так это смешанная нагрузка если ты будешь грузить на пределе - а уже и витрины надо рассчитать и ad-hockеры пришли на работу и стали базу бомбить кривыми джойнами на все узлы.


а так гринплам например умеет принять разные части данных на разные сегментные ноды, а затем уже после окончания прогрузки между сегментами их синхронизировать.

yacc> Далее, целевая таблица как правило одна - т.е. сразу будут локи, если в нее запихивают данные 10-100 процессов одновременно, а если ты на каждый процесс создашь отдельную, то все равно потом мержить в одну.

а как ты хотел? ты так или иначе сначала закинул в престейдж-STG как смог , затем прогрузка в обычный STG, затем генерация суррогатников и далее по слоям прогрузка данных.

yacc> Поздравляю - ты создал больше гемора чем ускорил :p

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

вообще CSV это легко, вот если нужно XML или JSON прожёвывать большой - это да, вот тут реально может быть много секса.

и опять же редко когда у тебя один CSV. нужно же файловый пакет от источника прогрузить в котором пачка CSV (согласно шины данных), подписанных ЭЦП, какие-то архивы, какие-то инкрменты пришли. соответственно оно может уже на этом уровне параллелиться естественным образом.
   88.088.0
Это сообщение редактировалось 01.05.2021 в 10:05
RU yacc #01.05.2021 10:19  @спокойный тип#01.05.2021 09:53
+
-
edit
 

yacc

старожил
★★★
с.т.> тут всё зависит от конкретной реализации и что понимается под словом импорт.
Разумеется

с.т.> CSV всё таки можно нарезать частями и загрузить в acquisition layer балком.
Это парсинг по-любому.

с.т.> главное что бы памяти хватило на ETL сервере при доставке.
Ну резать можно окном - это в общем-то не проблема.

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

с.т.> если параллелить что бы на разные узлы грузить то всё таки нагрузку на сеть мы тоже распараллелим, это не аргумент.
Гы, если у тебя кластер по каким то партициям ( что само по себе весело ), то просто разрезать несортированный файл не получится - ибо тогда каждая часть будет писать в разные узлы кластера - это уже не балк. Ну либо привет разрезание у тебя уже получится интеллектуальным - один файл надо умно разбить на куски, чтобы каждый кусок был к нужной ноде. Причем не факт что ты сбалансируешь нормально если данные неравномерны : скажем 1000 записей на ноду 1 и одна запись на ноду 2 целевого SQL.

с.т.> к тому же у тебя ETLные ноды к нодам кластера могут по отдельным линкам сидеть, а пользовательская сеть - по другим интерфейсам.
Так к самой базе все равно один канал, даже если у тебя не хосте несколько интерфейсов.

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

yacc>> Поздравляю - ты создал больше гемора чем ускорил :p
с.т.> это всё вопрос того что у тебя есть и того что нужно сделать. если нет мощности что бы успеть в окно прогрузки прогрузить тупо в лоб - добро пожаловать в мир геморроя.
Ну в случае того же ПФР имеем одну DB2 походу, которая там сама умеет параллелится.

с.т.> вообще CSV это легко, вот если нужно XML или JSON прожёвывать большой - это да, вот тут реально может быть много секса.
Не, CSV разумеется проще XML или JSON :p
   70.0.3538.6770.0.3538.67
RU спокойный тип #01.05.2021 10:35  @yacc#01.05.2021 10:19
+
+1
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★★
с.т.>> тут всё зависит от конкретной реализации и что понимается под словом импорт.
yacc> Разумеется
с.т.>> CSV всё таки можно нарезать частями и загрузить в acquisition layer балком.
yacc> Это парсинг по-любому.
с.т.>> главное что бы памяти хватило на ETL сервере при доставке.
yacc> Ну резать можно окном - это в общем-то не проблема.
с.т.>> это само собой что нужно мерджить потом где-то если ты ранее порезал. где-то выигрываешь - где-то проигрываешь.
yacc> Т.е. у тебя все равно вырисовывается один хост-координатор, который раскидывает работу и потом объединяет логи.

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

с.т.>> если параллелить что бы на разные узлы грузить то всё таки нагрузку на сеть мы тоже распараллелим, это не аргумент.
yacc> Гы, если у тебя кластер по каким то партициям ( что само по себе весело ), то просто разрезать несортированный файл не получится - ибо тогда каждая часть будет писать в разные узлы кластера - это уже не балк. Ну либо привет разрезание у тебя уже получится интеллектуальным - один файл надо умно разбить на куски, чтобы каждый кусок был к нужной ноде. Причем не факт что ты сбалансируешь нормально если данные неравномерны : скажем 1000 записей на ноду 1 и одна запись на ноду 2 целевого SQL.

да , скорее факт что перекосы будут возникать и с ними нужно будет бороться.

с.т.>> к тому же у тебя ETLные ноды к нодам кластера могут по отдельным линкам сидеть, а пользовательская сеть - по другим интерфейсам.
yacc> Так к самой базе все равно один канал, даже если у тебя не хосте несколько интерфейсов.
с.т.>> а так гринплам например умеет принять разные части данных на разные сегментные ноды, а затем уже после окончания прогрузки между сегментами их синхронизировать.
yacc> Деление на сегменты легаси базы - отдельная большая песня, не всегда возможная.

само собой. легаси в лоб так не будет работать. если на GP то оно будет с мастер-нодой работать, существование сегментов будет прозрачно.

yacc> yacc>> Поздравляю - ты создал больше гемора чем ускорил :p
с.т.>> это всё вопрос того что у тебя есть и того что нужно сделать. если нет мощности что бы успеть в окно прогрузки прогрузить тупо в лоб - добро пожаловать в мир геморроя.
yacc> Ну в случае того же ПФР имеем одну DB2 походу, которая там сама умеет параллелится.

ну сложно сказать. я давно DB2 не щупал, она же вроде не умела сама по себе параллелиться.
хотя опят же что под словом "сама умеет параллелиться" понимать.

скажем так, сама раскидать один запрос между узлами на которых лежат части данных и выполнить параллельно и вернуть результат - вроде как не умела.
   88.088.0
Это сообщение редактировалось 01.05.2021 в 10:41
RU yacc #01.05.2021 10:39  @спокойный тип#01.05.2021 10:35
+
-1
-
edit
 

yacc

старожил
★★★
с.т.> ну сложно сказать. я давно DB2 не щупал, она же вроде не умела сама по себе параллелиться.
с.т.> хотя опят же что под словом "сама умеет параллелиться" понимать.
с.т.> скажем так, сама раскидать один запрос между узлами на которых лежат части данных и выполнить параллельно и вернуть результат - вроде как не умела.

Там параллельность посредством SMP между процессорами и на SELECT плюс на индексы ( что уже очень неплохо )

DB2 symmetric multiprocessing: Database parallelism within IBM i | Manualzz

advertisement advertisement * Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project advertisement //  manualzz.com
 

Да Она покупается как опция и не идет по умолчанию
   70.0.3538.6770.0.3538.67
ZA Татарин #01.05.2021 14:26  @yacc#01.05.2021 08:22
+
-
edit
 

Татарин

координатор
★★★★★
yacc> Ты тупишь или реально думаешь что взяли двоичный дистрибутив Постгресс и тупо запустили на эмуляторе ?
Да, именно так я и думаю.

yacc> Там же прямо говорится
yacc> Постгресс в исходниках - это легаси код.
Бинарный.
   89.0.4389.12889.0.4389.128
EE Татарин #01.05.2021 14:48  @yacc#01.05.2021 09:18
+
+2
-
edit
 

Татарин

координатор
★★★★★
yacc> Чтобы прочитать CSV файл надо его распарсить. Более того - в каждый кусок вставить заголовок, который идет первой строчкой. И после разбития на файлы тебя ждет ... повторный парсинг ( уже каждого куска ) !
Нет, это если делать по-тупому, если хочется проиграть в производительности. А мне нужен выигрыш.

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

Сначала я побью файл на куски грубо - по байтам, разбив разметку (и да, получив "рваные", заведомо невалидные записи на границах. Потом я на разных хостах приведу предвалидацию этих кусков и начну балк импорт на SQL-сервера (ессно, разные). На начальной машине я пробегусь по границам блоков, прочитаю эти записи, обработаю их и импортирую. Потом на SQL-серверах я приведу таблицы в виду наиболее удобный для импорта.
Тут многое зависит от специфики данных, которую ты опустил, но на практике в абсолютном большинстве случаев тут можно сделать многое. Например, в какой-то момент мне было удобно балк-импортировать (правда не CSV, но это уже детали) в колумн-бейсед сиквел таблицу, потому что индекс строится только один раз, потом проводить быструю (колумн-бейсед, специфика данных была такой) первичную предобработку, а потом её в фоне (первыми - первоочерёдное, по датам) импортировать в главную базу с нормальными индексами и таблицами. К тому моменту, когда данные требовались, они были уже в базе, а хвост дотягивался ещё несколько дней, всегда впереди потребности. Локов не было, потому что были нормально сделаные ключи. Это инструмент, которым вообще не грех пользоваться (да, обычная MS SQL, держала 28Тб базу и порядка 10-100к запросов в секунду).

Да, это всё сильно зависит от специфики, как и конкретное решение, но специфика ВСЕГДА есть, тебе просто нужно уметь обратить её себе на пользу.

Ты мыслишь как кулхацкер-пионер (нет готовых скриптов - нет решения), а должен бы как программист. В смысле, программист работающий на результат, а не грамотно составляющий отмазки, почему всё медленно, фигово и через жопу. Это тоже можно, но это другой цирковой жанр.
   89.0.4389.12889.0.4389.128
EE Татарин #01.05.2021 14:53
+
+1
-
edit
 

Татарин

координатор
★★★★★
Хорошая описушка детальных потрохов "Эльбрусов" разных поколений с комментариями.

Российские процессоры Эльбрус-16С, Эльбрус-12С и Эльбрус-2С3 получат ядра шестого поколения архитектуры E2K

На мероприятии Elbrus Tech Day компания МСЦТ рассказала о текущих достижениях и планах развития серии российских процессоров Эльбрус. Сейчас наиболее современным CPU этой линейки является Эльбрус-8СВ на базе архитектуры E2K (Эльбрус 2000) пятого поколения, но в ближайшие годы появятся сразу три SoC шестого поколения: Эльбрус-16С, Эльбрус-2С3 и Эльбрус-12С. //  servernews.ru
 
   89.0.4389.12889.0.4389.128
RU yacc #01.05.2021 16:29  @Татарин#01.05.2021 14:26
+
-
edit
 

yacc

старожил
★★★
yacc>> Ты тупишь или реально думаешь что взяли двоичный дистрибутив Постгресс и тупо запустили на эмуляторе ?
Татарин> Да, именно так я и думаю.
И думаешь абсолютно неправильно
Потому что постгре входит в состав ОПО Эльбрус. И входила на момент тестирования в ПФР

Здесь ты мимо


yacc>> Постгресс в исходниках - это легаси код.
Татарин> Бинарный.
В исходниках
   70.0.3538.6770.0.3538.67
RU yacc #01.05.2021 18:26  @Татарин#01.05.2021 14:48
+
-
edit
 

yacc

старожил
★★★
Татарин> А мне нужен выигрыш.
Пока у тебя не получается :)

Татарин> Давай только сразу договоримся, что речь идёт действительно о больших CSV, где это имеет смысл - сотни Гб, того порядка, регулярных таких операциях и соответсвующих базах.
Именно про это я и говорю. Полностью согласен.

Татарин> Ты мыслишь как кулхацкер-пионер (нет готовых скриптов - нет решения), а должен бы как программист. В смысле, программист работающий на результат, а не грамотно составляющий отмазки, почему всё медленно
Ха! Пока что у тебя взгляд именно кулхацкера и вот тут это наглядно вижу :

Татарин> Сначала я побью файл на куски грубо - по байтам, разбив разметку (и да, получив "рваные", заведомо невалидные записи на границах.
Так вот это сразу означает самописный ETL на низком уровне, потому что ни один ETL продукт так не делает

Татарин>Потом я на разных хостах приведу предвалидацию этих кусков и начну балк импорт на SQL-сервера (ессно, разные).
Для начала - если у тебя куча серверов, то бишь MPP, то это сразу указывает на аналитическую направленность решения - т.е. DataWarehouse.
Базы транзакций - OLTP - на основе MPP не делают, потому что с гарантией у тебя гемор с целостностью

The rise of MPP platforms — Comparing SMP to MPP Architecture

The motivation for writing this is to explain the major difference between SMP and MPP platforms. I will also explain their appropriate… //  afroinfotech.medium.com
 
Disadvantages of MPP:
...
- Enforcement of constraints: Primary, foreign key, unique constraints are not maintained because the nodes are not sharing the same pieces of data. There won’t be a way to validate the data integrity easily.
 

Это я тебе с самого начала говорил, но ты меня не слушаешь.

так что если тебе надо процессить банковские счета - забудь пока про MPP.

Татарин> Тут многое зависит от специфики данных, которую ты опустил, но на практике в абсолютном большинстве случаев тут можно сделать многое.
Специфика простая - данные как есть, не сортированные по шардингу.
Поэтому ты не знаешь какую порцию на какой ноде загружать.
Если ты тупо разбил на куски по размеру, не заботясь о том кому чего - каждый кусок надо инсертить на каждой ноде, а потом фильтровать какие данные именно для нее.

Ну да - MCSE это не совсем про программирование, особенно часть про DW - поэтому я мыслю тут не как программист, а как SE :D
   70.0.3538.6770.0.3538.67

EG54

опытный

EG54>> Эх, расшифровать бы почему Российский рынок маленький и не может проглотить наукоемкую продукцию?
yacc> Потому что всего порядка 150 млн потенциальных потребителей, в то время как компании типа IBM шуруют на мировом рынке - в том числе и в РФ
Я имел в виду не обывателя с потребностями кнопки вкл-выкл. И наукоемкую промышленность. С ней то как?
   77
RU yacc #02.05.2021 15:03  @Татарин#01.05.2021 14:53
+
-
edit
 

yacc

старожил
★★★
Татарин> Хорошая описушка детальных потрохов "Эльбрусов" разных поколений с комментариями.
Можно посмотреть вот это видео

Elbrus Tech Day: "Эльбрус" как основа импортозамещения. Константин Трушкин, АО "МЦСТ"
Выступление Константина Трушкина, заместителя генерального директора АО "МЦСТ" по маркетингу на конференции Elbrus Tech Day от 17 февраля 2021 года. Про нормативно-правовое регулирование, линейку техники на базе "Эльбрус" и перспективы развития. Материалы конференции Elbrus Tech Day: http://mcst.ru/materialy-meropriyatiya-elbrus-tech-day
   70.0.3538.6770.0.3538.67

yacc

старожил
★★★
Кстати, на видео это есть, но вот на слайдах конференции почему-то нет
(слайд в аттаче )

Решение на Эльбрус-4С, ЦОД около 180 серверов, на постгре. Обрабатывает до 2 млн XML сообщений в сутки.
Или.. 23148 в секунду.

Что там про "Тройку" было ? А про банки ? :D
Прикреплённые файлы:
v_elbrus.jpg (скачать) [1892x1058, 420 кБ]
 
 
   70.0.3538.6770.0.3538.67
Это сообщение редактировалось 02.05.2021 в 15:24
+
+1
-
edit
 

yacc

старожил
★★★
Ну и про Elbrus Tech Day
Материалы можно посмотреть тут

Материалы конференции Elbrus Tech Day/МЦСТ

Материалы прошедшей конференции Elbrus Tech Day //  www.mcst.ru
 

Отмечу интересное на мой взгляд
1. Доклад от PostgesPro

Как можно видеть
- Нативная сборка быстрее бинарной трансляции на 40% (ФСТЭК)lcc 1.21)

Т.е. много не выиграешь

И даже на нативной сборке и Эльбрус-8С проигрыш Интелу 2-3 раза.
( Т.е. про Эльбрус-4С речь и не идет )

Какой выход ? - как я и говорил - взяться за Си и ассемблер. Но не надо на нем собственно приложение писать - можно и БД написать - и это сделали:

2. Доклад РЕЛЭКС
( Если кто не знает - создатели отечественной БД "Линтер" )

Например оттуда
Особенности Эльбрус
- Сложный контекст задачи, 2 дополнительных аппаратных стека
- Необходимо отключать прерывания в моменты сохранения и восстановления контекста
- Создание контекста, освобождение и переключения контекста — это системные вызовы
Следствие:
Дорогое переключение контекста
 (3.2 мкс на Эльбрус vs 0.5 мкс на Intel)
 


И вот что получается если написать свою БД
TPC-C ( Дальнейший рост показателей блокируется пропускной способностью HDD ) 200 000
транзакций в минуту
Сервер Эльбрус-8С 4 процессора по
 8 ядер с тактовой частотой до
 1300 МГц
 
   70.0.3538.6770.0.3538.67
ZA Татарин #03.05.2021 13:45  @yacc#02.05.2021 15:07
+
+1
-
edit
 

Татарин

координатор
★★★★★
yacc> Кстати, на видео это есть, но вот на слайдах конференции почему-то нет
yacc> (слайд в аттаче )
yacc> Решение на Эльбрус-4С, ЦОД около 180 серверов, на постгре. Обрабатывает до 2 млн XML сообщений в сутки.
yacc> Или.. 23148 в секунду.
yacc> Что там про "Тройку" было ? А про банки ? :D
? Так а что? Во-первых, сколько есть, столько и обрабатывает.

Во-вторых, смотря что в тех ХМЛ и как обрабатывает.
Суперкомпутер "Фугаку" вообще по 1 ХМЛ в пару дней обрабатывал, а там всё-таки петафлопсы... когда сборку белков считаешь, это ещё хорошая скорость. Без понимания того, в чём обработка заключается и какие даннеы обрабатываются - нет смысла обсуждать.

"Тройку" и банки "Эльбрусы" потянут.
   89.0.4389.12889.0.4389.128
ZA Татарин #03.05.2021 13:54  @yacc#01.05.2021 18:26
+
+2
-
edit
 

Татарин

координатор
★★★★★
yacc> Так вот это сразу означает самописный ETL на низком уровне, потому что ни один ETL продукт так не делает
Так частично - понятно, что самописный. Если бы существовало готовое решение - о чём бы мы говорили?

Татарин>>Потом я на разных хостах приведу предвалидацию этих кусков и начну балк импорт на SQL-сервера (ессно, разные).
yacc> Для начала - если у тебя куча серверов, то бишь MPP, то это сразу указывает на аналитическую направленность решения - т.е. DataWarehouse.
Нет.

yacc> Базы транзакций - OLTP - на основе MPP не делают, потому что с гарантией у тебя гемор с целостностью
Ты просто не встречался с топовыми решениями.

yacc> так что если тебе надо процессить банковские счета - забудь пока про MPP.
Если надо процессить банковские счета, у меня такая задача в принципе не стоИт.

yacc> Специфика простая - данные как есть, не сортированные по шардингу.
yacc> Поэтому ты не знаешь какую порцию на какой ноде загружать.
Слушай, это уже пошли сплошные предположения, и, я так это понимаю, ты будешь каждый раз вводить условия, которые делают плохо для конкретного решения. Поскольку выкатывать из кустов белые рояли ничуть не сложно, ты всегда будешь "впереди", это вполне очевидно. :)
Бороться с этой "тактикой" я смысла не вижу.
В реальной жизни у меня сначала более-менее есть понимание, что именно я решаю, а потом я уже занимаюсь решением задачи.

yacc> Если ты тупо разбил на куски по размеру, не заботясь о том кому чего - каждый кусок надо инсертить на каждой ноде, а потом фильтровать какие данные именно для нее.
Да, если у меня таблица побита (а не, допустим, ноды с копиями и ленивым синком), то да. Если так, то будут фильтровать и формировать побитые запросы.

yacc> Ну да - MCSE это не совсем про программирование
Тут вопрос скорее в том, ищешь ли ты решение или пытаешься доказать, что всё плохо. :)
Последнее - гораздо легче (а в сочетании с возможностью брать из воздуха новые обстоятельства - так вообще к-к-ккомбо!), но в жизни требуется первое. Часто даже в духе "но ты же коммунист, Иванов!". И ничего, как-то решается.
   89.0.4389.12889.0.4389.128
ZA Татарин #03.05.2021 14:00  @yacc#02.05.2021 15:24
+
+1
-
edit
 

Татарин

координатор
★★★★★
yacc> Какой выход ? - как я и говорил - взяться за Си и ассемблер. Но не надо на нем собственно приложение писать - можно и БД написать - и это сделали:
Я уже говорил, что ты не напишешь ничего путного на ассемблере. А на ассемблере под "Эльбрус" писать ещё более бессмысленно: трудоёмкость "нормального" программирования на ассемблере помножается на необходимость оптимизировать в кодах. Производительность программиста и при написании на ассемблере неприемлимо низкая, а тут - просто нет никакого смысла.

А С - просто один из компилируемых ЯВУ, не имеющий преимуществ по скорости перед другими.

Ну и неплохо тот же "Эльбрус" смотрится - см. сравнение с "Ксеоном".
Затыки при работе с ХДД было бы смысл обсуждать, если б приводилась производительность той же МС Сиквел или Оракла на том же сценарии.
   89.0.4389.12889.0.4389.128
RU yacc #03.05.2021 18:47  @Татарин#03.05.2021 13:54
+
-
edit
 

yacc

старожил
★★★
yacc>> Для начала - если у тебя куча серверов, то бишь MPP, то это сразу указывает на аналитическую направленность решения - т.е. DataWarehouse.
Татарин> Нет.
Да. greenplum так и говорит - для аналитики.

yacc>> Базы транзакций - OLTP - на основе MPP не делают, потому что с гарантией у тебя гемор с целостностью
Татарин> Ты просто не встречался с топовыми решениями.
Ну и где в банках OLTP на MPP делают ?
Там быстрее IBM i ставят

yacc>> так что если тебе надо процессить банковские счета - забудь пока про MPP.
Татарин> Если надо процессить банковские счета, у меня такая задача в принципе не стоИт.
Внесение внешних данных ?
Да ну ?

yacc>> Специфика простая - данные как есть, не сортированные по шардингу.
yacc>> Поэтому ты не знаешь какую порцию на какой ноде загружать.
Татарин> Слушай, это уже пошли сплошные предположения, и, я так это понимаю, ты будешь каждый раз вводить условия, которые делают плохо для конкретного решения.
Это стандартная ситуация - импорт данных. По-умолчанию он не сортирован - в каком виде тебе его дадут в том и загружай. Раскидать на куски по нодам по логике - уже твоя задача, как и сортировка, если она тебе нужна.

Татарин> В реальной жизни у меня сначала более-менее есть понимание, что именно я решаю, а потом я уже занимаюсь решением задачи.
В реальное жизни тот кто предоставляет импорт большого файла тоже не хочет ставить ORDER BY ибо это тормозит запрос. А с точки зрения бизнес-логики все нужные данные он дал - и ему пофиг как и по какой логике по шардам у тебя раскидано.

Татарин> Да, если у меня таблица побита (а не, допустим, ноды с копиями и ленивым синком), то да. Если так, то будут фильтровать и формировать побитые запросы.
Ноды в MPP придерживаются правила shared-nothing т.е. о друг-друге они не знают.

yacc>> Ну да - MCSE это не совсем про программирование
Татарин> Тут вопрос скорее в том, ищешь ли ты решение или пытаешься доказать, что всё плохо. :)
Нет решения для Эльбрус-4С. Точнее частичное решение - своя СУБД, под процессор, а не такие костыли.
Либо выходи из зоны комфорта - плати часть наличными ибо транзакция будет идти дольше.

Татарин> но в жизни требуется первое. Часто даже в духе "но ты же коммунист, Иванов!". И ничего, как-то решается.
Не, решить-то можно... тормозами на клиентской стороне. Ну да - не за секунду пройдет платеж, а за минуту, а кому сейчас легко ? :)
   70.0.3538.6770.0.3538.67
RU yacc #03.05.2021 18:56  @Татарин#03.05.2021 14:00
+
-
edit
 

yacc

старожил
★★★
Татарин> Я уже говорил, что ты не напишешь ничего путного на ассемблере. А на ассемблере под "Эльбрус" писать ещё более бессмысленно: трудоёмкость "нормального" программирования на ассемблере помножается на необходимость оптимизировать в кодах.
Ты не допираешь, что не надо ВСЕ писать на ассемблере ? :D
Так вот - критические куски типа планировщика - вполне придется писать именно на нем, чтобы на максимум использовать возможности VLIW
Или ты не в курсе что в ядре ОС есть ассемблерные куски ?

Татарин> А С - просто один из компилируемых ЯВУ, не имеющий преимуществ по скорости перед другими.
Огромные преимущества ввиду низкоуровневости

Татарин> Ну и неплохо тот же "Эльбрус" смотрится - см. сравнение с "Ксеоном".
На совершенно другом движке СУБД без блокировок. А вот на посгре - не смотрится.
   70.0.3538.6770.0.3538.67
RU yacc #03.05.2021 18:57  @Татарин#03.05.2021 13:45
+
-
edit
 

yacc

старожил
★★★
Татарин> "Тройку" и банки "Эльбрусы" потянут.
Эльбрус-4С - нет
   70.0.3538.6770.0.3538.67
CA Unix #05.05.2021 05:50  @спокойный тип#29.04.2021 08:38
+
-
edit
 

Unix

опытный

с.т.> всё не так уж просто с кластеризацией...
И потому на нашем хлебушке и маслице да с икоркой бывает! :D

с.т.> ... предположу на уровне кластера там сделано резервирование, раком так сказать (RAC) - чисто для отказоусточивости.
Но ведь можно сделать не как ВТБ, а как Dell лет 10 назад ;)
   78.078.0
+
-
edit
 
yacc> Через неделю соколиный глаз допер, что код, который хорошо работает на x64, проседает на VILW так как сильно не использует возможности процессора. :D
А кто сказал, что хорошо?
Что это не была оптимизация задачи под количество человекочасов на решение - в стиле тяпляп и в продакшн?
А как замаячил рост нагрузки - решили пересчитать наиболее очевидные места. Как ту же организацию баз. Где впихивание лишних полей может означать рост каждой строки, смешение означать удлиннение запросов и обработки, и надо заняться комбинаторикой на тему оптимальной формы.

yacc> Или переведем с русского на русский - чтобы оптимизатор компилятора
Не факт. См выше.
   51.0.2704.10651.0.2704.106
Последние действия над темой
1 12 13 14 15 16 17 18

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru