Использую интерфейсы для получения данных из БД и подобных вещей, так что их можно заменить заглушками, но они довольно большие - половина текста теста будет составлять заглушка. А вот шаблоны в контроллерах, подключение к БД (в пакете бд) и тп все же как то нужно тестировать.
OLAP (если не ошибаюсь) больше подходит для аналитики (просмотры/продажи за периоды (или другой показатель)) и вряд ли решит проблемы сложных фильтраций ...
romy4: интересный вариант, спасибо. Но подойдет ли для этого постгря? Не будет более эффективно сложить в noSQL БД? Где процесс формирования данных положить на плечи mapreduce?
sim3x: ок, спасибо, не получается вот что: обычный запрос включает 7 LEFT JOIN (порядок выборки 5-7 минуты), в денормализованной таблице (поэксперементировал на 200 колонках) скорость выше 1-2 минуты (без индексов). Но если денормализововать полностью будет 1000 колонок, стоит ли это делать?
Как запустить мне ясно, мне не ясно как сохранить запрос.
Под "динамически" я имел ввиду что для новых запросов не нужен программист, в вашем верианте черзе Celery он будет нужен каждый раз когда нужно будет поменять/зменить/дополнить
1) В принципе, я понимаю, что писать полностью асинхронное приложение не совсем правильно, и не собираюсь это делать.
2) "Какую СУБД использовать?", "Как работать с данной СУБД конкретно из python?", тут или мой вопрос не совсем конкретен или вы слегка ошиблись, тут лучше поставить вопрос ни "кукую", а "как". То есть у нас есть чат: у юзеров есть права (писать в чат, писать карсом и другие), как по мне за ними нужно залезть в базу, также допустим у нас есть Модерация, когда юзера можно забанить моментально.
Если сами сообщения и т.д. можно писать сначала в редис, а потом переносить в базу (для ведения истории, и к примеру для того чтобы сообщить юзеру за какое сообщение его забанили), то права и "забанненость", как по мне нужно писать сразу в базу, а права это скорее всего будет тот же JOIN, а забанненость, может быть не простой галкой (UPDATE), а более сложным запросом (добавление в группу, с последующим записью в лог т.д.).
А это только чат, можно придумать более сложный вариант ...
От сюда мой вопрос: "как" работать с данными. Скорее всего я не первый и были придуманы примерные паттерны реализации таких сервисов. К примеру MongoDB я применять не хочу, у нас в проекте хватает редиса с простгресом, а насколько хорошо обертка под постгрес - неизвестно.
Понимаю, что проекты разные, и под каждый можно придумать свое решение, но берут сомнение, что всю историю торнадо не придумали ничего лучше редиса и других publish-subscribe.
Думаю, тормозит все же рендер, (не измерял профайлером), но если использовать "блочный кэш" в шаблонах, и обернуть только вывод товаров (не фильтер, ни другие элементы, только for с товарами) время отдачи сокращается с 800мс до 200мс.
Спасибо, про js думал, но на крупных сайтах сделано не через него, просто хочется понять, как большие сайты совмещают и общий кэш и индивидуальный.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.