vikholodov

Попробуйте https://checkio.org/ - там как раз лучшие решения и вообще решения других можно посмотреть только после того, как сам решишь. Но там по-английски всё.

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

может быть стоит другую работу поискать ?

Посмотрите portals.aliexpress.com/help/help_center_API.html

На сколько я понял получить сырые данные можно толькл используя DataChannel и MSE

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

Если даунтайм не принципиален, то нужно остановить базу, и воспользоваться одним из следующих вариантов:
1. Скопировать файлы с базой на новый сервер с помощью rsync, и заменить ими имеющиеся. На новом сервере должна быть установлена точно такая же версия Postgres.
2. Направить вывод pg_dump на старом сервере на вход pg_restore на новом через ssh:

pg_dump -Fc db_name | ssh user@new_server "pg_restore -d db_name"

В противном случае лучше нанять для этой операции опытного DBA.

Настраиваете потоковую репликацию, через pg_basebackup снимаете копию, запускаете как реплику. Когда догонит ведующую базу выключаете мастер и повышаете реплику до нового мастера.
Даунтайм минута вне зависимости от объёма данных. Ну может ещё минута если понадобится рестарт мастера из-за смены wal_level, listen_addresses или max_wal_senders

https://wiki.postgresql.org/wiki/Streaming_Replication

13 секунд для прямого вхождения как то слишком долго.
Мне кажется что у вас падает из за архитектуры БД.
Посмотрите htop во время индексации — скорее всего всю память сжирает SQL из за тяжелых запросов, а не elastic-sphinx.
Попробуйте перекинуть все товары в mongodb и сделать таким образом денормализованную базу товаров.

1. Про нехватку памяти проверьте сначала, запутить скрипт и в консоле запустите top - наблюдайте как растёт память.
2. Если у вас 5млн записей, то вы принципиально неправильно сделали работу. Вы зачитываете в память сразу всё, хотя ваша единичная операция требует всего одного продукта.
Пишите код правильно, а не делайте костыли, которые восстанавливают работу после того как что-то у вас отвалилось.
3. Вы поулчаете данные по 1000 позиций в connect ... встройте туда же вашу обработку для Product, тупо копипастом хотя бы - это решит проблемы с памятью, если проблема именно в этом.
Обрбатывайте по 1000 позиций за раз.

Ещё поясню:
- когда заканчивается память - это нештатная ситуация для всей системы и для СУБД в первую очередь, есть вероятность потерять данные
- сохранять состояние offset для client.service.doGetItemsList тоже хорошая идея для случаев обрыва связи, но это только если она у вас рвётся