Уважаемые коллеги соклубники, за советом решил обратиться к вам.
Имеем СУБД MySQL имеем клиентов на VFP. Все прекрасно работает и всех устраивает на 100%, но руководство решило? что нужен WEB и понеслось. Ладно Вэб-морду нарисовали, но теперь стал вопрос с отчетами.
А отчеты - это очень большие таблицы графы на строки а в пересечениях суммы. Все это хорошо работало на технологии клиент-сервер, где в качестве сервера выступал MySQL, ну а клиент был написан на VFP, с системой автоматического обновления, построения кубов (отчетов) и т.д. и все это работало хорошо за счет распределения нагрузки по формированию отчетов между сервером и кучей клиентов. (т.к. каждый клиент запускал формирование куба на своей машине)
Формирование происходило следующим образом: к серверу делались запросы по вытаскиванию данных из 10 основных таблиц (в основном без джойнов), таблицы за год получались большими от 500 тыс. до 1,5 млн. записей, все это вытягивалось на клиента
На клиенте: производилась обработка строились индексы и при помощи SCAN (по основной таблице) и SEEK по дополнительным, за один проход формировался куб данных который содержал в себе данные в виде ID строка, графа.
Далее эти кубы заливались на сервер при помощи LOAD DATA INFILE.
Из полученного куба (мы называли его срез) получали агрегированные данные выборкой вида SELECT SUM(d_Summ) FROM … GROUP BY, а также использовали для расшифровки показателей SELECT * FROM … LEFT JOIN. Но это все предыстория, скорость формирования этих кубов с количеством записей в кубе около 60 млн. была примерно 45 минут, это в принципе всех устраивало, если учесть, что таким образом мы получали около 50 таблиц размером 495x30 строк/граф (в ячейках суммы) и самое главное одновременно могло формироваться от 50 до 100 срезов (за счет того, что нагружались клиенты). Куб формировался 45 минут по годовым данным (за месяц в разы меньше), а уже из сформированного куба данные вытаскивались за секунды.
Но решили надо использовать WEB и ни какого VFP.
Стал я искать решение, которое бы позволило формировать такие кубы, при этом основное требование обеспечить возможность одновременного формирования от 50 до 100 кубов.
Рассматривали технологию хранимых процедур с переходом на PostgreSQL (в этом случае сервер нагружается одновременным выполнением ХП и как выяснилось не вариант - умирает)
Поговорил с java разработчиками, тоже говорят Java съест всю оперативку, при такой нагрузке. Посмотрел вариант php и python в последнем использование кортежей, так же приводит к тому, что все в оперативку - резюме надо увеличивать количество серверов приложений до тех же 50-100 штук.
Может я конечно и мыслю по старинке, но сейчас существующий вариант работает и вроде сервачек не сильно мощный и отдельных серверов приложений нет (все за счет клиентов). А вот как это реализовать с использованием Web технологий пока ума не приложу.
Вот теперь прошу коллег дать совет в какую сторону все таки смотреть? Как можно реализовать задачу по сложной обработке данных, с применением web технологий? Что использовать в качестве обработчика данных, я так понимаю это будет крутиться на сервере приложений, для которых больше 3-5 машин не дадут.

OLAP, ETL, Data Warehouse.
Искать, сравнивать, оценивать финансовые возможности. Может проще купить мощную систему и выгнать 90% разрабов, чем городить свой огород. А может хватит и простых недорогих решений. 1.5М записей не выглядит серьёзным объёмом, а куб в 500*30*100 вообще до смешного мал.

Игорь, спасибо за твое авторитетное мнение.
Я наверно немного не правильно описал.
Основная проблема это предварительная подготовка данных, формирование срезов формата ID, строка, графа, регион, сам срез это таблица содержащая в себе от 60 до 70 млн. записей. И вот формировать этот срез хотят одновременно до 100 пользователей с разными параметрами.
А уже потом по срезу строятся агрегированные таблички размером 500x30x100 и это построение занимает секунды.(индексы соответствующие есть).

> Но это все предыстория, скорость формирования этих кубов с количеством записей в кубе около 60 млн. была примерно 45 минут

...Т.е. основное время (45 мин) занимает некая-то программа на VFP на клиентской машине, которая из этих SELECT-ов (которые извлекаются быстро (?)) делает нужный "куб" ? И цель - замена этой 45-минутной клиентской программы на мгновенную на ПХП, или ПХП + какое-то спецприложение на сервере (?)

() А выгнать всех имеющихся разрабов и прикупить САП вместе с поддержкой - это верный путь ;)

of63
> А выгнать всех имеющихся разрабов и прикупить САП вместе с поддержкой - это верный путь ;)

Дожились... Одни VFP-разрабы советуют где-то выгнать таких же....

Если я правильно понял, то у Вас организация работы выглядит так

Рабочая база данных -> Пользователь 1 -> Промежуточная база данных для отчетов пользователя 1 -> Отчет 1
Рабочая база данных -> Пользователь 2 -> Промежуточная база данных для отчетов пользователя 2 -> Отчет 2
Рабочая база данных -> Пользователь 3 -> Промежуточная база данных для отчетов пользователя 3 -> Отчет 3

При переходе на web хранилище для "промежуточной базы данных отчетов" становится общим. Единым для всех пользователей.

Ну, вообще-то, обычно так оно и есть. То, что сделано у Вас - это "не естественное" положение дел. Никто и никогда не формирует промежуточную базу данных под одного конкретного пользователя. Оно всегда "общее". Одинаковое для всех и выглядит это так

Рабочая база данных -> Промежуточная база данных для отчетов

Промежуточная база данных для отчетов -> Отчет пользователя 1
Промежуточная база данных для отчетов -> Отчет пользователя 2
Промежуточная база данных для отчетов -> Отчет пользователя 3

Это, разумеется, потребует переделки структуры этой самой промежуточной базы данных и алгоритма его заполнения. Возможно, будет чуть больше времени. Но обновление промежуточной базы данных делается обычно раз в сутки. И потом в течении дня из него просто берут данные для отчетов

Поскольку обновление промежуточной базы данных для отчетов становится регулярной (периодической) операцией, а не делается "на лету" под конкретного пользователя, то каким именно способом будет происходить его обновление - совершенно не важно. Можно оставить тот же самое использование VFP



Исправлено 2 раз(а). Последнее : Владимир Максимов, 13.01.20 12:13

BOBAN

of63
> А выгнать всех имеющихся разрабов и прикупить САП вместе с поддержкой - это верный путь ;)

Дожились... Одни VFP-разрабы советуют где-то выгнать таких же....

Когда я это советую, я вам подмигиваю ;)
Вообще, это не мой совет, это цитата.

Владимир Максимов
Если я правильно понял, то у Вас организация работы выглядит так

Нет вы меня поняли неправильно.
Рабочая база и промежуточные таблицы расположены на mySQL сервере.
Промежуточная таблица доступна всем пользователям (и ей пользуется большое количество пользователей)
Но промежуточную таблицу может формировать любой пользователь.
Формирует он ее средствами VFP и потом загружает в mySQL (сделано это так, что пользователь формирует текстовый файл типа json и потом средствами быстрой загрузки данных, загружает в таблицу mySQL).
После того как эта таблица сформирована на mySQL, доступ к ней имеют все пользователи и по ней уже получают агрегированные отчеты и списки данных.
Задача в том, что бы заменить модуль который формирует эту промежуточную таблицу, при этом основное требование возможность формировать эти промежуточные таблицы параллельно с разными входными условиями (в основном разный период, вырезать из сформированных таблиц определенный период не получиться т.к. идет просчет сроков при формировании выходной таблицы).
VFP справляется с такой задачей на ура и ни какого штата VFP разработчиков, что бы их разогнать нет.
VFP хорошо справляется с задачей потому, что используется часть ресурсов компьютеров пользователей, которые и формируют эту промежуточную таблицу у себя, но потом загружают ее для общего доступа на сервер. (при этом даже эти пользователи в последующем имеют доступ только к таблице на сервере, локального доступа нет).
Теперь нет клиентов для того, что бы отдавать свои ресурсы для формирования промежуточной таблицы.
Т.е. пользователи хотят получить 50-100 промежуточных таблиц и при этом их формирование должно идти параллельно. (Они так привыкли и не хотят ждать очереди).
Т.е. вопрос: что может справиться с одновременным формированием этих промежуточных таблиц в количестве 50 штук и не умрет на день.
ХП на Оракле умирает (пробовали писать их, конечно может разрабы не оптимизировали их, но что есть).
Вот я и думаю какую среду установить на сервера приложений (придется наверно делать их несколько) что бы распараллелить эту задачу.



Исправлено 2 раз(а). Последнее : JuK, 13.01.20 16:25

Чтобы выполнять 50-100 процессов VFP одновременно (одинаковых 45 минутных) нужно 50-100 ядер процессора. Или "оптимизировать" 45-минутную прогу VFP на порядок, тогда за 45 мин которые согласны ждать юзеры) уложится 10 процессов по 5 мин...

Если удалось записать эту 45-минутную процедуру на ХП оракла, то за сколько выполняется эта ХП? Тоже за 45 мин? Может что-то недооптимизировано в процедуре VFP?

() Для нас и сутки-двое не предел, и записей в таблицах БД до 10-20 млн, так что 45 мин - это не удивительно, и причина не в скорости чтения БД, а в сложности алгоритма, т.е. в скорости ядра проца, который выполняет программу VFP, и выкинуть лишнее не получается...

of63
Если удалось записать эту 45-минутную процедуру на ХП оракла, то за сколько выполняется эта ХП? Т

Нет не 45 минут часа 3-4. Но при условии что она одна работает если запараллелить то умирает на сутки.

of63
Чтобы выполнять 50-100 процессов VFP одновременно (одинаковых 45 минутных) нужно 50-100 ядер процессора. Или "оптимизировать" 45-минутную прогу VFP на порядок, тогда за 45 мин которые согласны ждать юзеры) уложится 10 процессов по 5 мин...

Он и так оптимизирован, ну можно конечно еще пооптимизировать, минут на 5 меньше будет. Тут вопрос в другом, реально ли это все повторить с использованием ВЭБ технологий и если возможно, то что использовать, я уже думаю ну поднимаем мы штук 10 серверов приложений, тогда в какую сторону смотреть php, python, хранимые процедуры или что-то еще. Понятно можно смотреть в сторону ETL, BI. Например Cognos, но оно все вешается при одновременно выполнении. Наверно придется объяснять, что для реализации с использованием WEB нужно определять регламент формирования срезов и только таким образом ограничивать нагрузку.



Исправлено 2 раз(а). Последнее : JuK, 13.01.20 18:31

При таком длинном алгоритме на фоксе все же было оптимально у вас (каждый юзер задействует свое ядро процессора). Если перевести на ВЕБ, то как ни крути, эти же длинные процессы будут выполняться на "одном" сервере (т.е. все ядра будут физически заняты на нем). Ничего нельзя придумать, кроме ускорения алгоритма счета... Или пересмотра идеологии рождения выходных "кубов"...

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

На ВФП, кстати, неплохо у нас получается крутить с 10-ок таких длинных процессов, на сервере 24-ядерном (правда, там реально меньше в 2 раза, каждый физический раздвоен, надо бы убрать это безобразие). ОС выделяет каждому ВФП по ядру (видно в диспетчере задач), и они весело крутятся со своей скоростью, не мешая друг другу. Но если запустить ВФП-процессов больше чем физических ядер, то и это счастье ломается, сервер "встает", видно, что все становится медленнее не на 1/12 раза, а в 2 раза и больше.

Кстати, надо смотреть, занимают ли ХП оракла, например, по ядру на юзера, или выполняются на одном ядре... может и так быть...

Есть дурацкий совет - "переписать на Си или ассемблере" ) Я долго обьясняю вопрошающему (и себе), что алгоритм не только сложный, но и привязан к фреймерку и метаданным, изложить который в ХП какого-то SQL-T нереально (данные рождаются из каких-то сложных конфигурационных файлов, у каждого юзера свои, конфигурации превращаются в какие-то невообразимые обьекты, вобщем унреал)



Исправлено 1 раз(а). Последнее : of63, 13.01.20 19:10

JuK
Но промежуточную таблицу может формировать любой пользователь.

при этом основное требование возможность формировать эти промежуточные таблицы параллельно с разными входными условиями (в основном разный период, вырезать из сформированных таблиц определенный период не получиться т.к. идет просчет сроков при формировании выходной таблицы).

Предположим, первый пользователь запустил формирование данных за период с 01.01.2020 по 31.01.2020. И в это же самое время другой пользователь запустил формирование данных за период с 01.01.2020 по 10.01.2020. Какие данные в результате получим за первые 10 дней? И получим ли вообще хоть что-нибудь за этот период?

С другой стороны, первый пользователь запусти формирование данных с 01.01.2020 по 10.01.2020, а другой с 15.01.2020 по 31.01.2020. А третий пользователь захотел посмотреть данные за период с 11.01.2020 по 14.01.2020. А данных нет. Как он отличит отсутствие данных по той причине, что их реально нет, от отсутствия данных по той причине, что их пока не обновили?

Т.е. у Вас при таком способе подготовки промежуточных данных очень большие организационные проблемы. Ну, или очень "выдрессированные" пользователи

Если все-таки одна общая база, то не вижу причин, почему нельзя оставить все "как есть". Тот же самый запуск у каждого пользователя с локального компьютера. Просто результат теперь будут через Web смотреть

JuK
Т.е. вопрос: что может справиться с одновременным формированием этих промежуточных таблиц в количестве 50 штук и не умрет на день.
ХП на Оракле умирает (пробовали писать их, конечно может разрабы не оптимизировали их, но что есть).

"Не верю" (с)

Это не те объемы, чтобы ХП на промышленной СУБД "умер" (10 таблиц по 1,5 миллиона записей). Это значит, что алгоритм пересчета не оптимизирован. Его взяли "как есть" из кода FoxPro. Без переделки под новую среду. Ну, вот и получили... А это значит, что вне зависимости от того, какой инструмент Вы найдете на замену, он точно также "умрет". Ведь в любом случае необходима оптимизация под используемый инструмент



Исправлено 1 раз(а). Последнее : Владимир Максимов, 13.01.20 21:12

> Если все-таки одна общая база, то не вижу причин, почему нельзя оставить все "как есть". Тот же самый запуск у каждого пользователя с локального компьютера. Просто результат теперь будут через Web смотреть

Не так. Когда так говорит начальник, он имеет ввиду, чтобы и каждая кухарка на своем планшете могла это "смотреть" (выполнять выборку и обработку) на любом смартфоне.

Поясню. Моя модель интернет "сервисов", да просто современного языка визуальноориентированный "HTML" - это просто XML-подобный текст, который на отдает "сервер". Этот текст (согласно стандарту) изображения содержит и выполняемые вкрапления, типа "на событие такое-то выполни такой-то скрипт (обычная прога, фоксовая тоже бы сгодилась, если бы был штатный состав этой возможности в ИИС, или где-то в там), на таком то языке". Хорошая модель, но среди доступных языков нет фокса, есть ява (что еще есть и нет - не помню). Так мысль - что все едино. Щас не едино, эта "поддержка" ЯП есть на носимых устройствах не всех и не всегда (фокса нет нигде, яваподобное что-то есть везде, стандарта имений нет, не знаю, хотел бы узнать...). Не, этот корабль (долгий уверенный полет интернета) долго еще будет взлетать.

Ребята, затупил... ) Пишете (сервисы) кто как хочет, и скажите, как у кого получилось (а не вялый список параметров, который проф. пргер ЖуК не понимает), Позор для этой конторы от ТС с её "описаловом"...



Исправлено 2 раз(а). Последнее : of63, 14.01.20 01:03

сия история славна потерянным временем.





Исправлено 1 раз(а). Последнее : Vedmak, 25.01.20 02:32