Как лучше смасштабировать приложение?

Question

[beduin01]

Есть 100 секций данных. Есть приложение которое их обрабатывает результаты пишет в SQLite. Проблема в том что:
- приложение однопоточное
- на компе нет 100 ядер чтобы запустить 100 копий, каждая из которых обрабатывала бы свою секцию, а я потом базы данных слил.

Ничем кроме VPS не пользовался. Есть ли какие-то облачные сервисы где можно много слабых ядер получить? Памяти много не надо.

Просто я вижу единственным вариантом где-то найти 100-ядерную систему и там запустить 100 копий приложения. Есть подобные сервисы?

Comments

[Илья]

А зачем вам именно 100 ядер? У вас каждое приложение грузит ядро на 100% ?

[Илья]

Вам разово или на постоянку?

[beduin01]

Ну может хватило бы 50 ядер. Просто я не знаю как планировщик процессов все раскидывать будет.
По идее разово т.к. когда будет обработано 100% данных и все будет слито воедино я смогу запускать одну копию которая будет свежие данные успевать обработать.
Пока вся проблема в архивных данных.

[Александр Юдаков]

Поддержу Илья.
С чего вы взяли, что узким местом является процессор?
Вы измерили загрузку процессора и получилось 100%?

Answer 1

[Иван Шумов]

Я буду, наверное, максимально прост в рекомендациях:

• AWS Lambda + AWS Step Functions
  
• GCP Cloud Functions + GCP Dataflow
  
• Azure Functions + Azure Logic Apps
  

собственно я перечислил горизонтальные вычислительные мощности + оркестратор к каждой из них.
Oт SQLite придется отказаться

Comments

[Иван Шумов]

И тег Big Data не относится к вопросу

[beduin01]

>Oт SQLite придется отказаться
Увы приложение только с ней работает. Ну то есть у меня есть возможность результат на файловую систему писать, но не уверен, что это лучше.

А эти все сервисы про одно и тоже? Или есть какие-то нюансы?

[Иван Шумов]

beduin01, дело в том что файловые блокировки просто не дадут работать с такой нагрузкой с большей долей вероятности. Вот и все. Как минимум надо будет прочитать файл и отправить в очередь на обработку.

Да, сервисы +- одинаковые. Выбирать больше под знания языков программирования и личный комфорт

[beduin01]

Иван Шумов, а файловые блокировки в какой момент? Просто у меня 90% всех тормозов от одиночных INSERT-ов, но из за специфики данных пакетную вставку сделать не совсем понятно как т.к. мне нужно каждый раз заваленные результаты анализировать и вносить правки в лежащие в виде текста правила разбора

[Иван Шумов]

beduin01, SQLite это файловая база. То есть это тупо XML файл на самом деле. Поэтому все тормоза и проблемы связанные с ней в том что во-первых перезапись происходить целико, а во-вторых все ограничено скоростью работы диска. SQLite работает когда хранить надо ну, пару килобайт, да и то только для всяких редких историй. Для многопоточность его вообще нельзя использовать - параллельная запись может просто потерять данные от других потоков. Тут нет транзакционности и параллельного доступа

[beduin01]

Иван Шумов, да я вот тоже про это думал, только вариант писать результаты на файловую систему и потом сливать их в один большой INSERT (в нормальную БД) мне не очень нравится. Или это может быть решением?

[Иван Шумов]

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

[beduin01]

Иван Шумов, к сожалению БД поменять не могу.
Есть постоянно пополняемый архив данных и приложение которое их приводит к требуемому виду. У приложения есть набор правил разбора. Правила - в виде текстового конфига. Задача выполнить процессинг всех данных путем подкидывания новых правил и нажатию на кнопку "попытаться зарепроцессеить зафейленые".

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

На выходе мне нужно заполнить БД Oracle.

Задача звучит как-то так %)

[Иван Шумов]

beduin01, тогда сочувствую. Есть часть системы, которую увы не можете изменить, а значит и ускорить. Ну, по крайней мере, если смотреть на процесс записи. Страдайте и не пользуйтесь инструментами над которыми у вас нет контроля на будущее

[Sanes]

beduin01, что там может быть такого уникального, что нельзя поменять БД? Уже давным-давно замена сервера БД не является чем-то сложным. Как минимум с SQLite на MySQL или Postgre.

[Everything_is_not_so_bad]

Иван Шумов,

SQLite работает когда хранить надо ну, пару килобайт, да и то только для всяких редких историй.

откуда инфа?

[Иван Шумов]

Роман Мирр, опыт и знание как работает цикл обработки данных. Понятное дело что я утрировал, но в общем схема такая что параллельная обработка файлов приводит к гарантированным проблемам и требует перехода на транзакционную систему

[Everything_is_not_so_bad]

Иван Шумов,

а во-вторых все ограничено скоростью работы диска.

это касается любой СУБД, у которой хранилище на "диске".
https://www.sqlite.org/threadsafe.html

Multi-thread. In this mode, SQLite can be safely used by multiple threads provided that no single database connection is used simultaneously in two or more threads

https://stackoverflow.com/questions/1680249/how-to...
https://www.sqlite.org/faq.html
#19

[Иван Шумов]

Роман Мирр, да видел я это. и там же люди соглашаются с тем что это все велосипеды и все-равно работает через одно место.скорости это не добавит, с целостностью все-равно проблемы. Ну не стоит заниматься фигней

[Everything_is_not_so_bad]

BEGIN .. COMMIT решает проблему со скоростью.

[Иван Шумов]

Роман Мирр, нет)

[Everything_is_not_so_bad]

Иван Шумов, ответ от специалиста по облачным технологиям не удивляет.

[Иван Шумов]

Роман Мирр, транзакционность всегда замедляла

Answer 2

[Everything_is_not_so_bad]

Можно создать 100 потоков или 100 корутин и отправлять данные в очередь, а оттуда в БД.