Очень рад за наших ребят. Недавно по физике тоже заняли. Будут ли поощрены ребята правительством РФ, интересно. Победители Олимпиады в Токио получат по 4млн рублей.
Не считая того что в красном банке все документы валютного контроля нужно готовить самому. Приправляем это все интуитивно непонятным интерфейсом и каждый приход валюты на транзит ней счёт сопровождается звонками в суппорт где девушка рассказывает что нужно сделать минут 10. Я даже записывал на бумаге.
Но… затем мне понадобился паспорт сделки. И все ещё больше усложнилось. Плюнул и пришёл в модуль банк, теперь от меня требуется акт выполненных работ, всю остальную рутину менеджер делает сам. Не нарадуюсь.
Вы абсолютно правы. Но я имел ввиду почему последовательное сканирование в постгрессе занимает 2 секунды, а на мускуле 19 при равных условиях. Я не говорю мускуль такой плохой, возможно где-то что-то упустил.
Честно говоря, не знаю откуда у вас такие цифры по поводу времени выполнения запроса вообще. Создал базу с тремя полями, два BIGINT, одно VARCHAR. Заполнил числами от 111111111111 до 111121111111, и того 10М. Создал составной индекс. Итого:
1. При запросе с выборкой небольшого диапазона, где планер использует индекс: постгрес — avg 0.2 ms, мускуль — avg 0.3 ms. на 10 запросах.
2. При запросе очень большого диапазона, где планер решает использовать последовательное сканирование вместо индекса: постгрес — примерно 2 секунды, мускуль — 19 секунд.
Тесты конечно же чисто для примера. И в запросах где используется индекс разницы практически нет, но при Seq Scan, разница огромная и я честно говоря не знаю с чем это связано.
Все тесты проводились с настройками из коробки и ничего не подкручено.
Мы планируем реализовать логирование изменений в таблицах с помощью триггеров. Была проблема с идентификацией пользователя который совершил изменение. Думаю что этим расширением можно будет записывать необходимые данные, а в триггере уже их читать и писать в исторические таблицы?
в плане администрирования сложнее. Но, честно говоря, не пойму про какие файлы настроек вы говорите. Знаю postgresql.conf, pg_hba.conf. Настройки этих двух файлов хватит чтобы начать работать. Кстати по поводу последнего, он дает очень гибкую возможность настройки прав доступа. В мускуле очень этого не хватало. возможность ограничить подсеть по CIDR это просто сказка. Не говоря о других вичах этого файла.
Конечно это не просто два запроса подряд, но и не хранимочка на страницу, это даже не хранимочка а подобие лямбды. По мне так вполне достойная замена ON CONFLICT пока она еще не появилась:
DO $pgfunc$
BEGIN
BEGIN
INSERT INTO ...;
EXCEPTION WHEN unique_violation THEN
UPDATE ...;
END;
END
$pgfunc$
Пересоздавать нет, но нормальной мастер-мастер репликации в постгрес нет. Я не пробовал но то что есть, удручает количеством ограничений — https://wiki.postgresql.org/wiki/BDR_Command_Restrictions.
Я так понял 40мс — поиск в постгре, 2мс — поиск в мускуле? Это интересно, какое кол-во строк, индексы создавали? Если можете покажите план выполнения, пожалуйста (для постгрес добавьте опцию ANALYZE).
У нас тоже перконовский кластер мастер-мастер в работе, и я да я скажу что это круто — когда тебе не приходится пересоздавать мастер заново когда произошел свитч на слейв. Это плюс бесспорный из немногих.
На счет pgpool2 он у нас тоже не заработал, но зато заработал https://github.com/2ndQuadrant/repmgr, и прекрасно себя чувствует, там хоть что то автоматизировано в сравнении с голым постгрес. И все танцы с бубном вокруг фэйловинга и репликации как по мне покрываются Point In Time Recovery. Когда после сбоя потеря данных после восстановления минимальна, вплоть до нескольких секунд. Главное данные, а админы переживут. Один раз настроил и все работает.
Да конечно постгрес не для личного бложика на вордпрес, а для действительно серьезных проектов и относительно больших нагрузок. А там уже нет таких вопросов как — «Тут даже нет ничего из коробки?!!!»
Очень рад за наших ребят. Недавно по физике тоже заняли. Будут ли поощрены ребята правительством РФ, интересно. Победители Олимпиады в Токио получат по 4млн рублей.
Не считая того что в красном банке все документы валютного контроля нужно готовить самому. Приправляем это все интуитивно непонятным интерфейсом и каждый приход валюты на транзит ней счёт сопровождается звонками в суппорт где девушка рассказывает что нужно сделать минут 10. Я даже записывал на бумаге.
Но… затем мне понадобился паспорт сделки. И все ещё больше усложнилось. Плюнул и пришёл в модуль банк, теперь от меня требуется акт выполненных работ, всю остальную рутину менеджер делает сам. Не нарадуюсь.
1. При запросе с выборкой небольшого диапазона, где планер использует индекс: постгрес — avg 0.2 ms, мускуль — avg 0.3 ms. на 10 запросах.
2. При запросе очень большого диапазона, где планер решает использовать последовательное сканирование вместо индекса: постгрес — примерно 2 секунды, мускуль — 19 секунд.
Тесты конечно же чисто для примера. И в запросах где используется индекс разницы практически нет, но при Seq Scan, разница огромная и я честно говоря не знаю с чем это связано.
Все тесты проводились с настройками из коробки и ничего не подкручено.
DO $pgfunc$
BEGIN
BEGIN
INSERT INTO ...;
EXCEPTION WHEN unique_violation THEN
UPDATE ...;
END;
END
$pgfunc$
На счет pgpool2 он у нас тоже не заработал, но зато заработал https://github.com/2ndQuadrant/repmgr, и прекрасно себя чувствует, там хоть что то автоматизировано в сравнении с голым постгрес. И все танцы с бубном вокруг фэйловинга и репликации как по мне покрываются Point In Time Recovery. Когда после сбоя потеря данных после восстановления минимальна, вплоть до нескольких секунд. Главное данные, а админы переживут. Один раз настроил и все работает.
Да конечно постгрес не для личного бложика на вордпрес, а для действительно серьезных проектов и относительно больших нагрузок. А там уже нет таких вопросов как — «Тут даже нет ничего из коробки?!!!»