Асинхронное программирование

ну и причем здесь асинхронное программирование ? или услышал где то красивое слово и решил что оно тебе поможет ?

dlang

/thread

Асинхронность здесь не нужна, а нужно именно паралельное выполнение. Но если нагрузку на БД большую делать нельзя, то и вообще по очереди в один поток. В любом случае Go идеально справится с задачей и потребует меньше ОЗУ.

100-150 тысяч
примерно 5-30 метров

2TB данных в день примерно что ли?

но не то, чтобы оно целый день это выполнялось

ну да, скачать 2Тб и залить их в базу, это так быстро, что пора уже отбросить и искать ботлнек в языке.

Асинхронное, это если бы у тебя эта прога чтор-то делала и если пристлали файлик - нужно все отбросить и распарсить его. А в данном случае я вижу обычное распарлеливание с чем питон не так хорошо справится, а джава потребует ОЗУ. Может быть лучше на Go ? Там давольно просито все то распаралелить.

Да не, обычно меньше 1Тб. Просто этот сервис должен отработать 1 раз в полночь и так каждый день.

обычно меньше 1Тб
обычно

у тебя уже есть написанный прототип? в чём смысл искать языки под сферическую задачу, и иметь риск наступить на грабли, если можно выявить, что не так с имеющимся прототипом, на нынешнем языке?

А есть не прототип. Есть система, которая перестала вывозить объемы данных и нам спустили ее сверху, мол, надо, чтобы вывозила. За последнее время выросли объемы поставляемых данных и оно там накрылось. Написано так, что лучше переписать заново, чем разбираться в этом.

В го завезли человеческий йсон парсер?

Google - fast json parser. Вот что тебе надо.

Ах да, и результаты в базу из файлов загружать. Типа такого - https://dev.mysql.com/doc/refman/5.7/en/load-data.html

На чем система?..

Терабайт данных прокачать и сложить в БД - выбор языка не так уж важен, если только там не PHP у вас этим занимается. Скорее надо подумать над масштабированием базы и очередью задач. Модно - Golang, но если для JSON не определена схема, то это будет больно надо брать Python.

Он тормозной, от алиэкспресса есть более шустрая реализация.

Напиши прототип на питоне по-быстрому да проверь, на том же Go кода придётся писать в 10 раз больше

scala + akka-streams

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

каждый поток должен использовать вот эту либу: https://github.com/alibaba/fastjson

сами потоки есть в стандартной библиотеке. Туториалов море, вот первый нагуглившийся: вот или вот. Если задача плоская, то можно начать с Executors.newFixedThreadPool(8), если map-reduce то гугли туториалы по Fork Join Framework

Все таки притом, если работать с jdbc классически, то вставка будет медленной, раундтрип, мы вставляем, ожидаем подтверждения от базы. Если против базы использовать async драйвер то скорость упрется только в диск. Тестировал на postgres.

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html ?

кроме вставки по одному элементу есть еще ЛОАД сразу всего

Просто batch увеличит скорость в пару-тройку раз, на сколько я помню.

Написано так, что лучше переписать заново, чем разбираться в этом.

Очередной студент с горящими глазами? Погугли

Джоэл Спольски Вещи, которые вам не стоит делать никогда

Впрочем, ты скорее всего работаешь в госконторе, так что можешь начинать переписывать. Только по-нормальному работать приложение начинает после 3-го переписывания...

Кста, а в девятку же добавили джосона?

javascript, там очень быстрый json-парсер

Думаю самый быстрый парсера будет на Си или Ржавом.

Оно не уменьшит время ожидания коммита в БД. А только увеличит.

JEP 198: Light-Weight JSON API Status: Candidate

похоже, что нет. Иначе был бы какой-то из завершенных статусов типа Closed или Delivered

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

А данные одновременно проходят?
Если да, то никакой озу не хватит, при неблокирующем апи конечно.
Любопытно какого рода данные и что это за бизнес кейс.

да, но это (одно время) / (кучу запросов), результат будет значительно меньше чем (маленькое время) * (число маленьких запросов в куче). Или я чего то не понимаю?

Человеческий настолько, насколько он может быть в языке со статической типизацией без дженериков :)

По теме: судя по описанию задачи, структура json не меняется. Поэтому не вижу проблемы маршалить данные в структуры, накапливать и добавлять в БД.

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

для этой задачи, внезапно - быстрее всего (и точно проще) будет JS.

потому что..

Правильно понимаешь. Но их в любом случае придется ждать конкретному потоку. Т.е. 32 треда могут все простаивать в ожидании БД.

Плюсую мнение, что тут важна многопоточность, а асинхронность мало чем поможет. В питоне с многопоточностью все не так просто, но вообще задача решаема.

Я плюсую Питон просто потому, что не люблю Джавку. Ну и кроме того на Питоне подобные утилитарные задачи решать проще чем на Джаве.

Да, спасибо за комментарий. Я слегка не в курсе просто про async драйвер.

В целом проблему я понимаю, согласен с ней.

Верно ли я понимаю что с тем же успехом можно обойтись делая запрос используя какой нибудь асинхронный примитив (н-р Future в скале)?

Или асинхронный драйвер имеет какие-то ещё плюшки под капотом?

Не нужен тут asyncio

http://chriskiehl.com/article/parallelism-in-one-line/

по количеству ядер процессора на машине

Неправильно.

почему неправильно?

Все потоки будут блокированные I/O, общением с базой. Потому потоков тогда делать уж много, потому что тут не многопоток а канкаренси нужен.

Просто batch увеличит скорость в пару-тройку раз

Сработает. Только иногда бизнеслогика не позволяет сделать батч, но это не случай ТС.

Про скалу я хз, насколько мне известно Future особо ничем не отличается от Runnable при исполнении на JVM. И он также залочит тред на обычном IO. Есть костыли типа Quasar фреймворка, которые пытаются эмулировать коурутины, что позволит избежать лока треда на IO. Но лучше ими не пользоваться, к тому же сейчас идет работа над переносом идей Quasar в JVM для нативной поддержки коурутин без костылей.

ИМХО, пайтон.

upd: сервер БД не утонет в собственном трафике, случайно?

Потому что рост производительности параллельных вычислений от числа потоков нелинеен (искать Закон Амдала). Тем более на практике узким местом станет I/O. При этом, без тестов нельзя сказать, где будет ожидание, может потоки будут ждать, когда выполнится самый медленный (тогда по идее можно больше потоков пускать, если один заведомо тормознутый), а может они упрутся в скорость считывания данных с диска/сети, тогда в них вообще смысла нет, можно смело сокращать их количество.

Ты бы сначала определил где у тебя проблема, а потом бы уже искал решение. Может у тебя СУБД тормозит, ты ж, наверное, insert'ами туда всё это пихаешь? Многие СУБД могут в импорт из CSV и делают это намного быстрее. А может у тебя не хватает пропускной способности сети и большую часть времени прога занята ожиданием ответа? Или само оборудование не вывозит. Ты запусти сначала профайлер и посмотри где проблема, может она решается совсем не выбором языка.

javascript, там очень быстрый json-парсер

еще бы, что может быть быстрее noop

Future не отличается от Runnable особо, это (условно)верно. Мысль была такая (псевдо-код)

List[Future] fs = new List()
while(need) {
jsonValue = parseJson
fs.push(new Future {
  jdbc->batchInsert(jsonValue)
})
}

Значит не завезли. Понятно.

Это ничем не будет отличаться от кода:

List[Future] fs = new List()
while(need) {
jsonValue = parseJson
fs.push(new Runnable {
  jdbc->batchInsert(jsonValue)
})
}

Просто на Future, если его положишь в тредпул, то тредпул по окончанию сделает колбек.

Вот что первое в гугле нашел https://github.com/alaisi/postgres-async-driver

Есть такая задача: каждый день надо парсить относительно большое количество json-файлов (порядка 100-150 тысяч). Каждый файл весит примерно 5-30 метров. Файлы надо скачать, распарсить и уложить в базу. В принципе, на скорость пофиг, но не то, чтобы оно целый день это выполнялось.

JSON и есть его узкое место.

Выбираю между java и python (может быть, кто то что-то другое предложит). С питоном все понятно - тут рулит asyncio для таких штук и по бенчам из инета работает быстро, но не так быстро как Java, но я не знаю есть ли что-то подобное асинхронное для джавы? Что щас модно применять? Используется ли оно для подобных задач?

Rx, лучше всего его. Python - узкое место будет работа с самим JSON'ом. Я бы советовал брать Java/C#/etc...

С + JsonC + pthread

thread/