Иногда перед разработчиком, аналитиком или даже бизнес-пользователем встает задача выполнить какие-то финансовые расчеты, соблюдая два строгих требования. Во-первых, даже для миллиардных сумм необходимо обеспечить точность до копейки, во-вторых, перекрестные итоги тоже должны сходиться до копейки.
Архитектор ИС
Производственный календарь в PostgreSQL
![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/f4d/32b/f75/f4d32bf75901603a1738fe30bc4fc34b.png)
Новый Год уже совсем на носу, а значит нужен свежий производственный календарь в базе данных PostgreSQL. Но как совершенно обленившийся IT-шник, заводить его руками не хочется. Хочется, чтобы вызовом одной функции он сразу появился. Ну а уж из этой функции можно его сохранить в табличку и спокойно использовать до следующего Нового Года. А тогда опять просто вызвать вызвать функцию и с чистой совестью отрапортовать о выполненной работе. Цель статьи - показать возможности COPY ... FROM PROGRAM и простейшие приемы парсинга XML в PostgreSQL.
Немного про OR в SQL запросах
![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/2eb/403/021/2eb40302182dde5027a4a15288cfc88e.png)
Несмотря на избитость темы и многочисленные рекомендации избегать OR в выражениях WHERE/ON SQL запросов, жизнь вносит свои коррективы. Иногда сама постановка задачи подразумевает необходимость использовать OR. Я не собираюсь здесь рассматривать простые случаи, а сразу возьму быка за рога и рассмотрю случай, когда OR должно привести к двум разным выборкам по разным индексам одной и той же таблицы.
Мой первый принтер к ZX Spectrum
![](https://habrastorage.org/r/w780/getpro/habr/upload_files/8a2/ffd/b88/8a2ffdb888b86ed78aa5e26e0e374612.jpg)
После дембеля в ноябре 1986 году я, вместо того чтобы посвятить всё свое свободное время алкоголю и женщинам, по инициативе отца и не без его помощи собрал ZX Spectrum. Вариант, "Львов", так я сам оттуда, а отец даже принимал косвенное участие в его проектировании. Как раз в те годы, когда я сапогами стучал в Советской Армии. Если более точно, то ремонтировал и обслуживал телеграфные аппараты на командном пункте ПВО страны. Это присказка.
Прошел год. На дворе январь 1988 года после успешно сданной сессии. Общежитие в Зеленограде. Народ играет на моем ZX Spectrum. А кто не играет, обсуждает, что неплохо бы его применять не только для игрушек, но и еще для чего-то полезного. Например, для курсовых и дипломных проектов. Так как про TR-DOS мы в эти годы даже не слышали, а подключение дисковода к ZX Spectrum казалось фантастикой, то обсуждались способы, как бы перенести файлы с кассеты на хотя бы на ДВК-2, чтобы оттуда их распечатать. Купить принтер тогда тоже казалось фантастикой.
В процессе этих фантастических дискуссий я вспоминаю о том, как ремонтировал телеграфные аппараты в армии и мечтательно заявляю:
-- Ну хотя бы рулонный телеграфный аппарат где-то надыбать! Хотя бы древний и убогий T-63, который я наизусть знаю и точно смогу починить.
И вдруг я слышу ответ от соседа по комнате:
-- Так у меня на практике, на городской АТС, целая груда списанных рулонных телеграфных аппаратов валяется.
Ура! Есть цель, есть средства, нужен план. Хотя зачем студентам план? "Чего тут думать! Трясти надо!" (с) - если кто не знает этот анекдот, могу потом найти его.
Проблемы при переходе с MS SQL на PostgreSQL. Типы данных
Исходя из того, что предыдущую статью не заминусовали и даже не сильно критиковали, попробую продолжить серию и поделиться с проблемами некоторых различий типов данных в MS SQL и PostgreSQL.
Проблемы при переходе с MS SQL на PostgreSQL.Активное использование временных таблиц
Сначала я думал просто перечислить наиболее распространенные проблемы, возникающие при переходе с MS SQL на PostgreSQL. Но решил, что просто перечисление будет мало информативным. Поэтому, пока ограничился наиболее частой проблемой, приводящей к деградации производительности при переходе с MS SQL на PostgreSQL. Если статья окажется нужной, то продолжу рассматривать остальные проблемы.
Немного про SLA для DWH на PostgreSQL
В некоторых случаях в DWH приходится периодическим заданием очищать таблицу и заполнять ее новыми актуальными данными. Например, раз в сутки. Если в таблице десятки или сотни тысяч строк, то это не проблема. А вот если миллиард - то уже точно проблема. Потому что каким бы способом ее не заполнять, но в течении достаточно длительного времени данные из этой таблицы не будут доступны пользователям. А если система должна быть доступна 24/7, то такие процессы начинают заметно ухудшать SLA.
Как не потерять производительность при секционировании в MS SQL
Рассмотрим достаточно распространенную ситуацию. Имеется огромная таблица примерно следующей структуры:
Как обучить миллионы моделей прогнозирования временными сериями
![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/0ed/161/924/0ed16192484d41de26783b8a8df94dd9.png)
Не буду вдаваться в подробности о том, откуда берутся миллионы временных серий и почему они умудряются изменяться еженедельно. Просто возникла задача еженедельно сделать прогноз на 2-8 недель по паре миллионов временных серий. Причем не просто прогноз, а с кроссвалидацией и выбором наиболее оптимальной модели (ARIMA, нейронная сеть, и т.п.).
Имеется свыше терабайта исходных данных и достаточно сложные алгоритмы трансформации и чистки данных. Чтобы не гонять большие массивы данных по сети решено было реализовать прототип на одном сервере.
Аналитики с диапазонами дат в MS SQL
![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/8bf/62d/c56/8bf62dc56598dddaca845345e795e487.png)
Развернув очередной обратно разработчику Pull Request с поиском по аналитике, принимающей разные значения в разные промежутки времени, я решил на планерке обсудить этот вопрос. И был удивлен, что подавляющее большинство разработчиков не понимают, как эффективно искать на SQL в таких случаях. Погуглив, ради интереса, обнаружил, что этот вопрос как-то обходится стороной сообществом. В итоге решил написать статью, заодно ссылаясь на нее самому.
Сразу хочу уточнить, что речь идет именно об MS SQL, так как, например, в PostgreSQL уже есть диапазонные типы и виды индексов, позволяющие их индексировать.
1C (и не только) c PostgreSQL
![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/804/2ee/117/8042ee1176d06befa6e4ffcbc83234e5.png)
Уже несколько лет назад я столкнулся с проблемой производительности 1С на PostgreSQL в некоторых запросах, которые на MS SQL выполнялись относительно быстро. Тогда же выяснилось, что в 99% случаев такие запросы можно оптимизировать так, что они начинают выполняться даже быстрее, чем на MS SQL, всего навсего добавлением нужных индексов во временные таблицы.
Как быстрее всего передавать данные с PostgreSQL на MS SQL
![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/07c/656/993/07c6569933aa4769de7acf87e8a44588.png)
Однажды мне потребовалось забирать регулярно относительно большие объемы данных в MS SQL из PostgreSQL. Неожиданно выяснилось, что самый очевидный способ, через Linked Server на родные ODBC к PostgreSQL, очень медленный.
Опыт использования автомобильных АКБ с UPS
![](https://habrastorage.org/r/w780/getpro/habr/upload_files/337/fcd/add/337fcdaddc1dd6238349d8089046587a.jpg)
Мысли использовать автомобильные АКБ с UPS бродят по просторам интернета очень давно. Плюсы очевидны - стоимость ампер*часа автомобильных АКБ на порядок ниже, чем у родных АКБ для UPS. Многие даже успешно подключили. Я же только обобщил опыт из разных источников.
Information
- Rating
- 1,650-th
- Location
- Москва, Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity