Я просто говорю что новичка в питон не знающего sql лучше использовать абстракцию питона, чем учить sql

дык это ж повод изучить как раз

а не пытаться остаться в рамках питона

Я просто говорю что новичка в питон не знающего sql лучше использовать абстракцию питона, чем учить sql

Почему? Зная SQL - переключаться с фреймворка на фреймворк или языка на язык - будет вообще не проблема, потому что человек понимает основу. А изучив алхимию - он будет знать только алхимию и все. Как-то скудно.

про переключение с языка на язык - в смысле разные фреймворки на разных языках.

То есть выучил SQL и дальше используешь обвязки)

Почему? Зная SQL - переключаться с фреймворка на фреймворк или языка на язык - будет вообще не проблема, потому что человек понимает основу. А изучив алхимию - он будет знать только алхимию и все. Как-то скудно.

Даже больше! Зная SQL - можно на нем и программировать ?

а не пытаться остаться в рамках питона

согласен. Иногда Python лучше понимается, когда попрограммировал еще и на других языках)

Даже больше! Зная SQL - можно на нем и программировать ?

Запрограммировал игру на sql

Даже больше! Зная SQL - можно на нем и программировать ?

да, много кто так делает. Сотовые операторы (биллинги), банки)

Да и sql это не гибкость, потом ловишь hbase и сосешь хуй

Запрограммировал игру на sql

Ну формошлепки можно сделать на Oracle. Выглядит как привет из 90-х, но работает и даже нагрузку держит почти во всех банках)

Запрограммировал игру на sql

даже вирусы есть на sql

Да и sql это не гибкость, потом ловишь hbase и сосешь хуй

вот эти юнцы) Чтобы так говорить - надо попробовать сначала и с тем и с другим поработать. Совершенно разные инструменты под разные задачи. Мы, кстати, отказались от hbase в сторону elastic.

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

Ну справедливости ради документация плохо ложится, если это первый ЯП у человека. Там поразжевывать надо сначала

а как справочник потом збс, да

Можно Лутца почитать - там все максимально разжеванно. А по SQL - документацию по Postgres. Тем более там сейчас даже официальный перевод на русский есть. Выше кидал ссылки.

Ну справедливости ради документация плохо ложится, если это первый ЯП у человека. Там поразжевывать надо сначала

Это чёртов декларативный язык

Чего там не ложится

Как там агрегации в elastic?

Ну справедливости ради документация плохо ложится, если это первый ЯП у человека. Там поразжевывать надо сначала

но есть же гугл и стековерфлоу

Как там агрегации в elastic?

отлично)

Можно примеры?

И говорить челу что он новичек, не зная о нем, не очень вроде

Я не говорил новичек, я говорил - юнец. И основывался на Вашем выражении)

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations.html

Вот ссылка на документацию)

работает даже для realtime

а вот Hbase для realtime не тянет и есть проблемы в эксплуатации.

Я знаю как искать документацию, меня больше интересует причины перехода и количество данных

Сори, что не так понял про юнцов

Про реал тайм в hbase, вы что использовали?

То как подключали сейчас уже точно не скажу. А вот про объем данных и задачи - realtime анализ и предотвращение мошеннических операций по банковским картам. Это внутренняя задача, но траффик очень большой. Elastic показал более высокую скорость отклика, более удобный и более интересные возможности. Например, поддерживает, графовые структуры.

Мы как раз тогда сравнивали и дергнули коллег из mail.ru - у них там большая инсталяция. Пообщались, посмотрели, покрутили.

А реал тайм агрегации скок по скорости? На 300m записях?

разная глубина, разная сложность дает разную скорость. Метрику сейчас точно сказать не могу - нет под рукой. Но проводили именно сравнительный анализ. Данных значительно больше чем 300 * 10^6

А у вас как по скорости по отклику? И для каких задач используете, если не секрет?

И есть ли проблемы с масштабированием?

Мне надо ~300м с сложно агрегацией

Реал тайм

Думаем что выбирать

Нут маштабируемоть под k8s желательно

Что бы не паритсЯ

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

Тут надо смотреть на допустимое время отклика. У нас оно меньше секунды, поэтому мы идем на жертвы с местом. Если у вас большие данные и не хотите тратить место, но время можно 5-6 секунд - тогда больше маневра.

но проблемы есть у всех систем.

Ну время 2-3 секунды это норм

У elastic с сохранностью как у вас?

если это открыло то всё ок?

Правда что try/except замедляет работу программы и по возможности желательно его обходить?

У меня просто бесконечный цикл , который должен работать максимально быстро

У меня просто бесконечный цикл , который должен работать максимально быстро

Немного оксюморон

Хочешь максимально быстро - пиши на Си

Не хочешь писать на Си - измерь время работы так и этак

try/except стоит пользоваться там, где он необходим можешь их выкинуть, конечно, но медленно работающий бесконечный цикл - это лучше, чем неработающий бесконечный цикл, потому что у тебя крашнулось приложение

а еще while True любит 100% ядра CPU жрать, поэтому обычно туда вставляют какой-нибудь time.sleep(0.1)

try/except стоит пользоваться там, где он необходим можешь их выкинуть, конечно, но медленно работающий бесконечный цикл - это лучше, чем неработающий бесконечный цикл, потому что у тебя крашнулось приложение

я читал что try except можно почти везде, потому что это вроде как очень пайтон-стайл программирование и полезно для флоу

да

все так

но вот насчет производительности я хз

У elastic с сохранностью как у вас?

никак. Мы не надеемся на нее. Всегда есть резерв. Ну и данные x3

еще фишка - ''.format() в разы медленннее '' % tuple() хотя первый рекомендуют юзать вместо второго

интересно почему. Ибо tuple быстрее по определению?

но вот насчет производительности я хз

производительность не страдает, так как, в отличае от C/C++, передача контекста очень дешевая операция. Поэтому лучше везде использовать именно try/except

не знаю, не интересовался

ERROR: S client not available

интересно почему. Ибо tuple быстрее по определению?

Особености реализации в Python3

Просто метод написан быстрее, что неудивительно при явном задании типов в форматной строке

Причем тут вообще тупл

не знаю, не интересовался

Это правильно. Надо уметь останавливаться и не копать глубже, чем надо в текущем моменте

иначе утонуть можно

Особености реализации в Python3

но к python 2.7 тоже относится Python 2.7.13 (default, Dec 17 2016, 23:03:43) In [1]: %timeit 'foo {0:s}'.format('bar') 1000000 loops, best of 3: 292 ns per loop In [2]: %timeit 'foo %s' % ('bar',) 10000000 loops, best of 3: 133 ns per loop

Это, напомню, питон

Тут не гоняются за наносекундами

Если вам надо наносекунды

Вы пользуетесь не тем инструментом

Тут не гоняются за наносекундами

я знаю. я к тому, что оптимизировать в питоне можно дохера где

в т.ч. там, где люди обычно даже не догадываются

еще фишка - ''.format() в разы медленннее '' % tuple() хотя первый рекомендуют юзать вместо второго

надо смотреть реализацию нативную. второй вариант очень похож на просто сишный printf

надо смотреть реализацию нативную. второй вариант очень похож на просто сишный printf

скорее всего так и есть, да )

Так, стоп, что-то я под вечер затупил. format в 3-м Python рекомендован и работает быстрее чем %

Так, стоп, что-то я под вечер затупил. format в 3-м Python рекомендован и работает быстрее чем %

Рекомендован да, работает быстрее - ой ли

Мне сейчас негде проверить, но я очень сомневаюсь

Python 3.6.1 (default, Apr 4 2017, 09:40:51) In [1]: %timeit 'foo {0:s}'.format('bar') 401 ns ± 7.46 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each) In [2]: %timeit 'foo %s' % ('bar',) 17 ns ± 0.0799 ns per loop (mean ± std. dev. of 7 runs, 100000000 loops each)

гыгыгы

ой, пойду f"" проверю

Вангую общий код с форматом

Спасибо за объяснение) тогда не о чем не переживаю)

In [3]: bar = 'bar' In [4]: %timeit f"foo {bar}" 17.2 ns ± 0.118 ns per loop (mean ± std. dev. of 7 runs, 100000000 loops each)

охуеть

))))

А logging влияет?

In [3]: bar = 'bar' In [4]: %timeit f"foo {bar}" 17.2 ns ± 0.118 ns per loop (mean ± std. dev. of 7 runs, 100000000 loops each)

А вот это неожиданно, прикольно

На скорость работы?

А logging влияет?

timeit в руки

In [6]: %timeit f'foo {foo}' 100000000 loops, best of 3: 9.89 ns per loop In [7]: %timeit 'foo %s' % ('bar',) 100000000 loops, best of 3: 9.89 ns per loop In [8]: %timeit 'foo {}'.format('bar') The slowest run took 8.76 times longer than the fastest. This could mean that an intermediate result is being cached. 10000000 loops, best of 3: 183 ns per loop

На скорость работы?

Особенно если ты логируешь удп-запросами.

Особенно если ты логируешь удп-запросами.

на локальную же тачку