Нужно единоразово записать 200 тыс заспросов за одну секунду, на этом все, дальше ничего записывать не нужно. Т.е. это единоразовая операция, но очень критичная к скорости. У нас кластер. Важно чтобы при смерти любой из машин данные не потерялись.
Bulk insert не подходит, данные придут с разных клиентов.
Монга 3 заявляет что держит 300k инсертов в секунду, но не факт что на нашем железе будут такие же показатели, и ребята которые с ней плотно работали сказали, что не стали бы расчитывать на такую цифру у монги. И это вероятно цифра запись локально а не в кластере.
Есть дргуая идея, например записать в rabbitmq. Но опять же вопрос выдержит ли он такую цифру, и все ли там будет нормально если сделать кластер из рэбитов в разных ДЦ с точки зрения надежности и скорости.
Была еще идея записывать в файлы, но тут проблема как не потерять файлы при смерти машины и как их синхронизировать.
Можно рассмотреть какие-то другие технологии, если данные не подойдут.
Я упомянул что bulk insert не подходит, т.к. запросы с разных клиентов. А без этого 200к за секунду я вставить уже не легко. Мускул и постргес такое врядли потянут. Записать в текстовик не проблема, проблема в том, что у нас кластер, и как потом эти текстовики обьединять и синкать уже проблема. Плюс если в момент записи свалистся одна машинка, текстовый файл умрет данные потеряются. В случае с базами там есть репликация и в монге например есть write concern, что гарантирует сохранность данных.
un1t:
при правильной настройке постгрез потянет
текстовик = лог файл => логи можно пушить в несколько мест
текстовики синкаються (внимание!) rsync, а потом запихиваются в бд
Про монгу. Поищи видео мучений яндекса с монгой.
Мое личное мнение - монга специфический продукт, под хипстеров. Про репликацию и всякие "write concern" на бд без транзакция не хочется говорить
rsync не гарантирует сохранность данных, машина может умерать до того как rsync выполнится, плюс сложно завязать ожидание и отдачу клиенту ответа на rsync. Не подскажешь что там надо в постгресе потюнить чтобы столько потянул?
я бы на вашем месте использовал очереди - например RabbitMQ или ActiveMQ. отправить в очередь 200к сообщений не проблема? а если в одно сообщение например уложить 100 объектов то вообще получится 1000 сообщений. Так как очередь персистентна то при падении нечего не потеряется.
На другом конце очереди стоит слушатель который спокойно в фоне уже раскладывает данные в БД
> отправить в очередь 200к сообщений не проблема?
Вы у меня справшиваете? я не знаю выдержит ли rabbitmq 200к записей за секунду или нет, особенно с учетом того что нужна репликация. Поэтому и спрашиваю, может кто-то тестил что-то подобное. Сгруппировать объекты нельзя.
epolyak: Данные придут с 200 тыс клиентов с каждого по одному сообщению один раз и одновременно. Подскажи пожалуйста, в rabbitmq есть что-то вроде write concern в монге? Т.е. нода в которую я отправил данные ответит мне до того как произодет репликация или после? Меня интересует сценарий, если я отправил данные, нода ответила, что приняла данные, реплицировать данные на другие не успела и сдохла.
я сегодня для интереса тестировал libuv (pyuv), питон выдал 25к/сек на одно ядро под доккером на своем буке
т.е. на мощном сервере может вытянуть 50к на ядро (х 4 ядра), может быть норм
но там ещё сохранение и т.п.
так же нужно балансер тестировать если одна входная точка, nginx вытянет 200к?
ещё вместо балансера можно попробовать зафоркать питон, что-б один порт на все pyuv процессы.
ещё, т.к. задача маленькая, то можно взять golang - будет быстрее чем nginx+python.
Можно быстро записать в redis, на несколько машин, 2 или более (т.е. копии), а потом потихоньку слить куда надо, например в монгу. Либо реплику там настроить.
Можно задублировать запросы клиентов на второй сервер, и пусть оба пишут в файл.
Хотя объем маленький, 60Мб, можно и в памяти подержать пока в базу не запишется.
http запросы? питон дольше http будет разгребать...
