Как работать с базой в приложениях на Tornado?

Question

[last7]

Есть задача реализовать реал-тайм приложение, начал копать в этим направлении, много узнал, но один вопрос остается открытым, как работать с данными? На примере Tornado-приложения?

Наткнулся на ответы нескольких категорий:
1) Использовать MongoDB (motor)
2) Использовать разные обертки на стандартный библиотеки аля psycopg2, которые позволяют выполнять асинхронные запросы.
3) Не использовать асинхронность, а делать маленькие-быстрые запросы.

Что лучше?
К примеру, с чатом, в принципе подойдет 3 пункт, так как сложных запросов там не предвидеться, но если нужно что-то по-серьезнее, JOIN или большую выборку, как быть?

Answer 1

[Сергей Мартынов]

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

1. Стоит ли писать полностью асинхронное приложение? Или стараться сделать синхронно работающее, но быстрое? Ответ зависит от специфики приложения.

Важно понимать, что во многих случаях за счет асинхронности вы не ускоряете ответ приложения на внешний запрос: если для ответа на запрос приложению надо сделать запрос в mongodb и на основе полученных данных - запрос в mysql, то вы все равно не ответите наружу раньше, чем выполните эти два запроса. По сути, в этом случае вы экономите только память (и немножко - процессор), потому что вместо 40 параллельно запущенных процессов, отвечающих на запросы, можете запустить, скажем, 4 (по числу ядер).

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

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

2. Какую СУБД использовать? Много про это написано, но опять же - исходя из задач. В последние годы NoSQL-базы очень хорошо развились и предлагают интересные возможности. Например, если писать чат с прибамбасами, то может пригодиться механизм publish-subscribe (есть в явном виде в redis, также реализуется на mongo и других). Если масштаб проекта большой и нужно масштабирование и надежность, то стоит посмотреть на riak и aerospike (они хорошо скейлятся в многосерверные конфигурации). И т.д. и т.п. - если надо, напишите подробнее о проекте, подумаем.

3. Как работать с данной СУБД конкретно из python? Я не большой специалист именно по python, но насколько понимаю, есть библиотеки для асинхронной работы как с SQL-СУБД (по крайней мере, для Postgres), так и с NoSQL (по крайней мере, есть для Mongo и для redis).

Comments

[last7]

Спасибо за ответ.

1) В принципе, я понимаю, что писать полностью асинхронное приложение не совсем правильно, и не собираюсь это делать.
2) "Какую СУБД использовать?", "Как работать с данной СУБД конкретно из python?", тут или мой вопрос не совсем конкретен или вы слегка ошиблись, тут лучше поставить вопрос ни "кукую", а "как". То есть у нас есть чат: у юзеров есть права (писать в чат, писать карсом и другие), как по мне за ними нужно залезть в базу, также допустим у нас есть Модерация, когда юзера можно забанить моментально.

Если сами сообщения и т.д. можно писать сначала в редис, а потом переносить в базу (для ведения истории, и к примеру для того чтобы сообщить юзеру за какое сообщение его забанили), то права и "забанненость", как по мне нужно писать сразу в базу, а права это скорее всего будет тот же JOIN, а забанненость, может быть не простой галкой (UPDATE), а более сложным запросом (добавление в группу, с последующим записью в лог т.д.).

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

От сюда мой вопрос: "как" работать с данными. Скорее всего я не первый и были придуманы примерные паттерны реализации таких сервисов. К примеру MongoDB я применять не хочу, у нас в проекте хватает редиса с простгресом, а насколько хорошо обертка под постгрес - неизвестно.

Понимаю, что проекты разные, и под каждый можно придумать свое решение, но берут сомнение, что всю историю торнадо не придумали ничего лучше редиса и других publish-subscribe.