В целом с джангой ситуация странная. Вроде всё есть, но как только начинаешь пользоваться натыкаешься на ограничения.
Ну например, как сделать роут который будет перенаправлять GET запрос на /accounts на один View action а POST на другой?
Хочется написать в views.py:
# GET /accounts
def index(...):
pass
#POST /accounts
def create(...):
pass
итд.
Хочется нормальных миграций написанных руками. Пользоваться syncdb на продакшне просто стрёмно. Да иногда, просто надо выполнить код на питоне в процессе обновления схемы.
Хочется нормальных фикстур типа FactoryGirl, а не хардкора на json.
Хочется отдельных настроек для dev/test/staging/production, а не только settings_local.py.
С передачей информации быстрее скорости света есть одна маааааленькая проблема — вы сможете передавать информацию в прошлое. Но вы ведь не получали письма от будущего себя к себе настоящему, правда?
> Вы вообще знакомы с тем, как работает асинхронный ввод/вывод?
1. Вообще знаком. Кстати epoll/kqueue — это не асинхронный IO, это event notification.
2. В случае, когда вычисления занимают незначительную часть, можно использовать любой скриптовый язык с поддержкой epoll/kqueue (Python twisted, ruby event machine, итд), а не изобретать велосипеды для С++.
Процессор не простаивает, а занимается… чем? Пасьянс раскладывает? В данном случае бОльшая часть работы заключается в ожидании данных. Тут не важно какой язык — C++/asm/bash. В любом случае пользовательский процесс будет торчать в wait.
Hint: вы когда-нибудь видели чтобы nginx грузил процессор?
> Я читал про Go, и он мне не приглянулся: не увидел в его фичах настоящей изюминки, а текущая реализация, судя по тестам, слишком заметно проигрывает по производительности чистому C.
Ну за то в вашей реализации изюма хоть отбавляй. Особенно повезет программисту, которому придется после вас разбираться в вашем препроцессоре без документации. В отличии от Go/Erlang/Whatever.
Что касается производительности — вы делаете запрос по сети для подгрузки данных, а это 5-10мс на tcp/ip, чтение данных с диска и пересылку по сети. Если вы очень круты, то это будет менее 1мс, но всё равно слишком медленно для того чтобы оправдать использование Си.
Боюсь сравнение с groovy в данном случае не корректно. В вашем примере использовался non blocking evented сервер. Подозреваю, что при такой архитектуре все соединения обрабатываются одним покотом и нам тупо нехватит CPU.
Можно ли этот groovy++ сервер запустить на 16ядрах без необходимости дополнительно синхронизировать доступ к общим данным, например, списку открытых сокетов?
В случае с erlang можно запустить хоть на 160 ядрах всех 10 машин кластера.
Если вы уверены, что на вашем сайте все номера должны будут иметь вид +7 (XXX) XXX-XX-XX, то имеет смысл просто выкидывать все символы кроме цифр и потом выводить как вам угодно.
А в случае, если вы работаете на уровне страны или всего мира, то без базы кодов городов не обойтись.
Вот это можно записать немного проще:
^((\+?7|8)[ \-] ?)?((\(\d{3}\))|(\d{3}))?([ \-])?(\d{3}[\- ]?\d{2}[\- ]?\d{2})$
[ \-] лучше заменить на [\s-] #символ '-' можно не экранировать если он идет последним
используя ' ' в регулярках вы закрываете себе возможность использовать многострочные regexp, поэтому лучше использовать \s
И первый же select count(*) from articles для построения постранички приведет к тому, что БД полезет шуршать по всем партициям, что в случае с постгресом, будет означать N запросов.
Запросы select * from article where id = X будут выполняться так же быстро, как без партиционирования. А в умную БД которая поймет, что при ORDER BY id DESC LIMIT 10 надо смотреть только в последнюю партицию мне не верится.
Я затрудняюсь привести пример, когда партишнинг таблицы в рамках одного сервера приведет к заметному выигрышу в производительности. Обратных примеров видел достаточно.
Просто 20млн Primary Key должны влезать в память, и если у вас постгре хоть немного настроен, то проблем с выборкой по индексу быть не должно.
p.s.
У нас 40+ млн записей и индекс по PK занимает 900мег (опять отожрался), и выборка по индексу отрабатывает за 0.060 ms. Правда памяти 16гиг и база должна целиком влезать…
Похоже?
Ну например, как сделать роут который будет перенаправлять GET запрос на /accounts на один View action а POST на другой?
Хочется написать в views.py:
# GET /accounts
def index(...):
pass
#POST /accounts
def create(...):
pass
итд.
Хочется нормальных миграций написанных руками. Пользоваться syncdb на продакшне просто стрёмно. Да иногда, просто надо выполнить код на питоне в процессе обновления схемы.
Хочется нормальных фикстур типа FactoryGirl, а не хардкора на json.
Хочется отдельных настроек для dev/test/staging/production, а не только settings_local.py.
Сейчас занимаюсь проектом на джанге. После рельсы просто тоска. И да, опыт на пхп у меня тоже есть.
1. Вообще знаком. Кстати epoll/kqueue — это не асинхронный IO, это event notification.
2. В случае, когда вычисления занимают незначительную часть, можно использовать любой скриптовый язык с поддержкой epoll/kqueue (Python twisted, ruby event machine, итд), а не изобретать велосипеды для С++.
Hint: вы когда-нибудь видели чтобы nginx грузил процессор?
Ну за то в вашей реализации изюма хоть отбавляй. Особенно повезет программисту, которому придется после вас разбираться в вашем препроцессоре без документации. В отличии от Go/Erlang/Whatever.
Что касается производительности — вы делаете запрос по сети для подгрузки данных, а это 5-10мс на tcp/ip, чтение данных с диска и пересылку по сети. Если вы очень круты, то это будет менее 1мс, но всё равно слишком медленно для того чтобы оправдать использование Си.
Ну, это круто :) Побольше бы таких платформ.
> а сколько будет оверхед от шаринга каких-либо данных на эти 10 машин?
Это скорее зависит от данных, чем от языка программирования. Шарить информацию о 512к открытых соединениях — это вообще не проблема.
Можно ли этот groovy++ сервер запустить на 16ядрах без необходимости дополнительно синхронизировать доступ к общим данным, например, списку открытых сокетов?
В случае с erlang можно запустить хоть на 160 ядрах всех 10 машин кластера.
Зачем вы пишите \d{1}?
Зачем у вас -?\d{1} повторяется 7 раз?
</regexp-nazzi>
Прочтите и не позорьтесь так — www.books.ru/shop/books/592346
А в случае, если вы работаете на уровне страны или всего мира, то без базы кодов городов не обойтись.
Вот это можно записать немного проще:
^((\+?7|8)[ \-] ?)?((\(\d{3}\))|(\d{3}))?([ \-])?(\d{3}[\- ]?\d{2}[\- ]?\d{2})$
[ \-] лучше заменить на [\s-] #символ '-' можно не экранировать если он идет последним
используя ' ' в регулярках вы закрываете себе возможность использовать многострочные regexp, поэтому лучше использовать \s
Запросы select * from article where id = X будут выполняться так же быстро, как без партиционирования. А в умную БД которая поймет, что при ORDER BY id DESC LIMIT 10 надо смотреть только в последнюю партицию мне не верится.
Я затрудняюсь привести пример, когда партишнинг таблицы в рамках одного сервера приведет к заметному выигрышу в производительности. Обратных примеров видел достаточно.
Просто 20млн Primary Key должны влезать в память, и если у вас постгре хоть немного настроен, то проблем с выборкой по индексу быть не должно.
p.s.
У нас 40+ млн записей и индекс по PK занимает 900мег (опять отожрался), и выборка по индексу отрабатывает за 0.060 ms. Правда памяти 16гиг и база должна целиком влезать…