Тестирование производительности аналитических запросов в PostgreSQL, ClickHouse и clickhousedb_fdw (PostgreSQL)

ClickHouse — конечно быстрый. Но статья (понимаю, что перевод) нацелена на популяризацию clickhousedb_fdw его автором (кстати, что на счёт выброса при Q14?) с явным пренебрежением способностями PostgreSQL:

1. никто так не хранит BigData в PostgreSQL, для этого есть расширения TimescaleDB и pg_pathman как раз для хранения больших временных рядов (логи, данные с датчиков, прочие факты во времени и статистические данные).
2. индексы тоже можно создавать по разному и разного типа, так что большой индекс btree может вести себя неоднозначно на большой таблице (к примеру, если страницы индекса не помещаются в памяти)
3. настройки postgres по умолчанию рассчитаны на "запуск даже на кофеварке", их нужно тюнить, хотя бы с помощью PgTune.
4. для выборки агрегированных хитрых значений могут использоваться дополнительные расширения, к примеру, pipelineDB или другие механизмы.

Конечно, ClickHouse быстрый, и чаще всего разумнее будет не париться, а настроить именно его для хранилища больших данных — чтобы настроить postgres для bigdata, нужно потратить прилично времени, чтобы понять для чего и как это делать. Но бывает так, что таковы правила игры (проекта или легаси-инфраструктура), что есть только postgres и ничего другого быть не может).

Было бы здорово увидеть сравнение этих монстров не "из коробки", а на максимуме своих возможностей)) вот это был бы обзор. В статье есть ссылка на исходный датасет. Если у кого-то дойдут руки до сравнения — то это будет хороший материал для статьи!

Запуск на Эльбрусе платформы для нейросетей PuzzleLib

Здравствуйте! Подскажите, пожалуйста, как именно подключить cblas_sgemm вместо numpy в модулях на python? В документации МЦСТ ничего о cblas_sgemm нет, да и в numpy тоже. Очень много людей будет в восторге, если покажете как. Спасибо!

Логическая репликация между версиями PostgreSQL

имеется в виду, что логическая репликация не работает с партиционированными таблицами, или под фрагментированием понимается что-то другое?

Пишем в PostgreSQL на субсветовой: 1 host, 1 day, 1TB

про pg_pathman пишу, потому что ваше решение под заголовком PG10: второй шанс мне показалось сложноватым, у них в либе всё реализовано и можно использовать с минимальными настройками, просто попробуйте на досуге, может понравится. Про запись понятно, ускорили, да и ssd тоже позволит расти в ширь. Всё равно рано или поздно крупная нагруженная БД думает стать кластером)) я сам в кластерах ноль, но было бы приятно послушать опыт "коллег по цеху")

Пишем в PostgreSQL на субсветовой: 1 host, 1 day, 1TB

Спасибо за статью! Почему не используете pg_pathman для секционирования? Как именно вы кешируете данные? У вас одна БД на кластер? Рассматриваете увеличение пропускной способности на чтение?

Разработка чрезвычайно быстрых программ на Python

timeit — игрушечка. Наткнулся сегодня на новую библиотеку для профайлинга, djn ссылка, библиотека scalene. Запустил тест функции, которую приводит автор в самом начале, вот результат:
python -m scalene main.py

main.py: % of CPU time = 100.00% out of  14.46s.
         | CPU %    | CPU %    |
  Line   | (Python) | (C)      | [main.py]
--------------------------------------------------------------------------------
     1   |          |          | import sys
     2   |          |          |
     3   |          |          | import timeit
     4   |          |          |
     5   |          |          | import time
     6   |          |          | from   functools import wraps
     7   |          |          |
     8   |          |          | from   decimal import *
     9   |          |          |
    21   |          |          | def timeit_wrapper(func):
    22   |          |          |     @wraps(func)
    23   |          |          |     def wrapper(*args, **kwargs):
    24   |          |          |         start = time.process_time()
    25   |          |          |         func_return_val = func(*args, **kwargs)
    26   |          |          |         end = time.process_time()
    27   |          |          |         print('{0:<10} {1:<8} {2:^8}'.format(
    28   |          |          |             'module', 'function', 'time'))
    29   |          |          |         print('{0:<10}.{1:<8} : {2:<8}'.format(
    30   |          |          |             func.__module__,
    31   |          |          |             func.__name__,
    32   |          |          |             end - start))
    33   |          |          |         return func_return_val
    34   |  67.97%  |  32.03%  |     return wrapper
    35   |          |          |
    36   |          |          | @timeit_wrapper
    37   |          |          | def exp(x):
    38   |          |          |     getcontext().prec += 2
    39   |          |          |     i, lasts, s, fact, num = 0, 0, 1, 1, 1
    40   |          |          |     while s != lasts:
    41   |          |          |         lasts = s
    42   |          |          |         i += 1
    43   |          |          |         fact *= i
    44   |          |          |         num *= x
    45   |          |          |         s += num / fact
    46   |          |          |     getcontext().prec -= 2
    47   |          |          |     return +s
    48   |          |          |
    49   |          |          | def test():
    50   |          |          |     exp(Decimal(3000))
    51   |          |          |
    52   |          |          | if __name__ == '__main__':
    53   |          |          |
    54   |          |          |     if sys.argv[-1] == 'timeit':
    55   |          |          |         print('timeit',
    56   |          |          |               timeit.timeit("test()",
    57   |          |          |               setup = "from __main__ import test",
    58   |          |          |               number = 1))
    59   |          |          |     else:
    60   |          |          |         test()
    61   |          |          |
    62   |          |          | """
    63   |          |          | Способы запуска:
    64   |          |          | 1. time python3 main.py
    65   |          |          | 2. python3 -m cProfile -s time main.py
    66   |          |          | 3. python3 main.py timeit # но внутри
    67   |          |          | 4. python3 -m scalene main.py
    68   |          |          | ""

Разработка чрезвычайно быстрых программ на Python

А чем питону мешает динамическая типизация? Никогда не возникало проблем с этим — всегда знаешь что должно быть в переменной по логике программы, если писать комментарии, логично рассуждать и документировать апи. Уже не первый раз слышу про динамическую типизацию в питоне в подобном ключе — что это его ложка дёгтя. Решительно не понимаю подобных проблем… В конце концов, если напутали с типами данных — то проект по хорошему должен быть покрыт тестами и тесты сразу же скажут где и что поправить, это же не беда вселенского масштаба?

10 фич для ускорения анализа данных в Python

Спасибо, перевели всё, включая пол автора) Классная библиотека pandas-profiling, тем более на примере известного Титаника, возьмём на заметку! Но вот всё остальное — скорее про Jupyter Notebook, далеко не все им пользуются.

Python в Mobile development

Зависит от провайдера. Действительно — у некоторых людей сайт www.kivy.org не открывается. Один мой коллега на вопрос "Почему больше не пользуешься kivy?" ответил как раз, что не пользуется по причине заблокированного сайта, однако он был сильно удивлён, когда я при нём же открыл сайт в рабочем браузере. Но тоже знаю людей, которые до сих пор жалуются на заблокированный сайт.

Python в Mobile development

Да, действительно — и всё. Я собираю приложение на специальной виртуальной машине, предоставленной один из участников сообщества. Показывал первую версию программы широкому кругу лиц в живую. Процесс стал намного проще, чем в Android Stuido. Я тоже слышал страшные истории про бульдозер, киви и извращенцев, собирающих мобилки на питоне. В 2019 году — это всё неправда. Огромнейший плюс подобного подхода — возможность затащить в мобильное приложение ЛЮБУЮ библиотеку на питоне для любых целей, а спектр этих либ и задач намного шире, чем у джавы и даже джаваскрипт. Так что действительно нашёл всего один минус — размер приложения, но 20 МБ по сегодняшним меркам — это не критично))

Python в Mobile development

Из минусов kivy — это только размер приложений. Обычно это примерно 20мб. Но сейчас это курам на смех. Из плюсов — любая либа на питон может быть использована в мобильном приложении. У меня был случпй: нужно было найти либы доя трубы, исты и спидтеста. На джаве я этого не нашёл, а вот на питоне — за 1 минуту все либы нашёл, потом внедрил в приложение

Python в Mobile development

Спасибо за вашу работу! То, что вы делаете — это прекрасно! Но хотелось бы понять две вещи: 1. является ли KivyMD "prodaction ready" (чтобы не переживать за баги в серьёзных приложениях для бизнеса) и 2. когда появится полноценный сайт с документацией? Раньше айтишники по способу усвоения информации делились на два типа — те, кто признают только книги и те, кто читают документацию с ПК. Теперь вот появился третий тип — те, кто учится по youtube роликам. Способ иногда более наглядный, но нет возможности скопировать фрагмент и запустить, а также в напечатанной документации быстрее найти нужный код. Понимаю, что это всё долго и больно, но Вы хотя бы рассматриваете в планах создание документации, мануалов и туториалов?

Как уменьшить использование памяти и ускорить работу кода на Python с помощью генераторов

В комментариях много раз упоминали, что тест скорости неверный — генератор ничего не делает. Посмотрим же на истинные результаты. Для этого исправим код — мы будем не просто получать все квадраты ЧЁТНЫХ (привет автору) чисел, а будем вычислять их общую сумму.

Первый тест без генератора:

# python3 -m pip install memory_profiler

import memory_profiler
import time

def check_even(numbers):

    even = []
    for num in numbers:
        if num % 2 == 0:
            even.append(num * num) 
    return even

if __name__ == '__main__':

    number    = 10**8
    m1        = memory_profiler.memory_usage()
    t1        = time.clock()
    cubes     = check_even(range(number))
    sum_cubes = sum(cubes)
    m2        = memory_profiler.memory_usage()
    t2        = time.clock()
    time_diff = t2 - t1
    mem_diff  = m2[0] - m1[0]
    print(f"It took {time_diff} Secs and {mem_diff} Mb to calculate\n" +
          f"the sum of squares of first {number} even numbers (it is {sum_cubes})")

Результат:

It took 22.652704714 Secs and 1936.12109375 Mb to calculate
the sum of squares of first 100000000 even numbers (it is 166666661666666700000000)

Причём заметим, что сначала я отдельно вычислил все значения, а уже потом посчитал их сумму и записал в новую переменную. Если сделать это в одну строку sum_cubes = sum(check_even(range(number))), то замер используемой памяти покажет всего 1.109375 Mb использованной памяти. Но по факту будет использованы все те же 2 ГБ памяти для вычислений списка квадратов — он просто будет сразу же уничтожен. Поэтому здесь может показаться, что память используется мало — это ошибочное предположение. При number = 10**9 мой тест завершается с MemoryError (переполнение памяти).

А вот тест с генератором:

# python3 -m pip install memory_profiler

import memory_profiler
import time

def check_even(numbers):

    for num in numbers:
        if num % 2 == 0:
            yield num * num 

if __name__ == '__main__':

    number    = 10**8
    m1        = memory_profiler.memory_usage()
    t1        = time.clock()
    sum_cubes = sum(check_even(range(number)))
    m2        = memory_profiler.memory_usage()
    t2        = time.clock()
    time_diff = t2 - t1
    mem_diff  = m2[0] - m1[0]
    print(f"It took {time_diff} Secs and {mem_diff} Mb to calculate\n" +
          f"the sum of squares of first {number} even numbers (it is {sum_cubes})")

Результат:

It took 17.981277267 Secs and 0.04296875 Mb to calculate
the sum of squares of first 100000000 even numbers (it is 166666661666666700000000)

Подводим итог: с генератором скорость увеличилась на 15%, при этом памяти использовалось почти на 2 ГБ меньше.

А вот результаты теста с генератором при number == 10**9 (в 10 раз больше, чем в первоначальном тесте):

It took 182.005517055 Secs and 0.078125 Mb to calculate
the sum of squares of first 1000000000 even numbers (it is 166666666166666667000000000)

без генератора вообще получим переполнение памяти

Компьютерное зрение всем, даром

Ещё добавлю, что стало гораздо проще искать информацию — теперь проще и быстрее нагуглить проблему, чем открыть книжку или найти раздел в мануале/документации, даже если точно помнишь где искать :) Всё это безумно ускоряет разработку. Если конечно вы не сидите в строгой организации без доступа к интернету, от этого кстати очень страдает наша оборонка =((

Компьютерное зрение всем, даром

То странное чувство, когда твою статью упоминают в другой статье на Хабре) Вообще не очень понятно что хотел сказать автор. Немножко похоже на пост для привлечения внимания. Уверен, что на хабре есть масса достойных статей на тему компьютерного зрения. OpenCV используется для безумного числа полезных и не очень вещей. От автоматизации рыбалки в WOW до зомби шутера в дополненной реальности. Про Java вопрос странный — у каждого языка свои области применения, а также своя секта адептов, решающих все задачи только на этом языке, не знаю в каком соотношении находятся эти группы людей. Дабы не разводить holy war скажу, что ещё многое зависит от библиотек вокруг языка. Вот кстати о Java — сейчас мне пришлось писать мобильное приложение под android для оценки качества сотовой связи. Начал я в android studio на Java, а закончил бульдозером и киви на python: ничего не имею против Java, но я просто не нашёл библиотек, которые могут выполнять sppedtest, работать с youtube и instagram — запросы в гугле не дали результата. А вот на python я нашёл все три либы за минуту. А возможно, я просто адепт секты python и нормальный джавист бы нашёл нужные либы за пол минуты. ИМХО нужно быть гибким и не зацикливаться на одном языке (я всё же написал часть программы на java, но стал переписывать на python в силу недостатка времени, но чёрт возьми, через три дня знакомства с java я стал немного понимать этот мир).

Улучшение производительности Zabbix + PostgreSQL при помощи партиционирования и индексирования

На главном dashboard (панели) Zabbix server health график Values processed per second (снизу слева).

Насчёт того, что centos прям полетит по сравнению с Ubuntu server терзают сомнения.

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

Улучшение производительности Zabbix + PostgreSQL при помощи партиционирования и индексирования

Экстремальные нагрузки по моему ИМХО — от 10к параметров в секунду. Наш тест держит 3333 в секунду и это для него не предел. У вас виртуалка — сразу потеря мощности, видимо развернули образ с Ubuntu с сайта Zabbix, он только «чтобы посмотреть». Разверните нормальный CentOS или Debian, сразу разница будет. Как опрашиваете хосты — активный опрос тоже минус к скорости. Хороший вариант — почти все параметры хостов пассивные, приходят от активного прокси, прокси уже активно спрашивает параметры хостов (если есть активные агенты — ещё лучше, тем более если NAT). Сейчас для хорошей производительности Zabbix нужно либо настраивать PostgreSQL + tsdb, либо разворачивать glaber.io с ClickHouse, как написал товарищ denaspireone в первом комментарии, который кстати является разработчиком) Мы с Zabbix разобрались не за один день, причём до сих пор поверхностно, так что дерзайте! Стратегии разворачивания, успешные кейсы и практики — известны и описаны в сети, моя статья больше про PostgreSQL, на самом деле :)

Улучшение производительности Zabbix + PostgreSQL при помощи партиционирования и индексирования

Конечно так и должно быть, просто сам Zabbix заявляет, что они ещё не в полной мере подружили TimescaleDB со внутренним механизмом формирования SQL запросов сервера Zabbix, обещают в версии 4.4 окончательно задействовать весь потенциал tsdb. В tsdb и так уже есть партиционирование — деление гипертаблиц на чанки. Обязательно разверну тот же самый мониторинг, но с tsdb и сравню эти подходы. На момент написания этой статьи была только версия Zabbix 4.0 без поддержки tsdb — дело было весной, просто только сейчас дошли руки систематизировать материал и поделиться с общественностью. Ведь в основном статья про способы оптимизации БД PostgreSQL — то, что может пригодиться большинству новичков и даже некоторым бывалым DBA.

Улучшение производительности Zabbix + PostgreSQL при помощи партиционирования и индексирования

Спасибо за отсылку к Glaber, обязательно попробуем! ClickHouse конечно обеспечит высокую производительность, давно шли разговоры про поддержку ClickHouse для Zabbix. В недалёком будущем может и сам Zabbix станет поддерживать ClickHouse. А может в 12 версии PostgreSQL появится поддержка внешних подключаемых источников данных, в числе которых тоже окажется ClickHouse. Поживём — увидим) Сейчас учёка в Glaber хранится тоже в ClickHouse? Нет ли сильных расхождений по документации с Zabbix?

Улучшение производительности Zabbix + PostgreSQL при помощи партиционирования и индексирования

Тогда это больше вопрос по самому Zabbix — в документации есть общая инструкция для обновления компонентов между версиями:
https://www.zabbix.com/documentation/devel/ru/manual/installation/upgrade/sources
Версия 4.4 ещё в разработке) Я бы посоветовал вам сравнить файлы разметки БД для версии с которой собираетесь обновляться и версию, на которую собираетесь переходить. Внимательно изучите разделы "Что нового" между этими версиями. В версиях 4.х БД PostgreSQL вряд ли меняется — единственное нововведение, это появление расширения TimescaleDB, но и его установка вообще дело добровольное.