Сомневаюсь, скорее речь идет о том, что я его в принципе могу получить если захочу или например получение платежного документа по электронной почте тоже можно считать соблюдением нормы.
Смотрели, но я бы не сказал, что тормозит, определенные издержки есть, но гораздо большие выгоды может принести изменение сценарий формирования, а не само формирование, потому что в первом случае мы оптимизируем формирование, а во втором вовсе можем от него отказаться в момент обращения
Согласен. Более того сценарий, когда все зарегистрированные пользователи хотели бы видеть платежный документ перед оплатой, сомнителен. Например, за сотовый телефон я счет детальный не смотрю, плачу по выставляемой сумме. Так что, по идее, следует изменить сам процесс, исключить формирование платежного документа в принципе, оставив только по запросу. Но, чтобы принять такое решение, нужна статистика и согласие заказчика.
Да, давно развивается, выбран как универсальное решение для формирования печатных шаблонов еще на заре проекта, картинок нет, только QR код и линейный штрих-код, да отнимает достаточно ресурсов техники, но экономит ресурсы разработки, готовых дизайнеров отчетов местной прописки не так уж и много.
Логично, хорошая стратегия, единственный нюанс, если одновременно нажмут кнопку 1000 пользователей, то возникнет очередь формирования и пользователь может получить чуть позже чем привык
Замечательно, в нашем случае ситуация была такая: диски старой модели, запасов не осталось, бюджет ЦОД на год утвержден и потрачен, планово диски купят в следующем году (на всякий случай, не в этом проекте), по замерам IOPS в момент проблем был в районе 180, СУБД при это хорошо упиралась в диск.
Все относительно, две команды не кормили фул тайм, каждый этап занимал в среднем от 40 до 80 часов разработки.
По поводу хайлоад или нет можно долго спорить, для себя критерий вывел, когда число пользователей превышает 100 000, но это только мое мнение.
По поводу покупки SSD, довольно не бюджетно, кроме того гос ЦОД ( к примеру в одном из государственных ЦОД мы ждали замены обычного жесткого диска в течении 5 месяцев) не сильно заинтересован в покупке дорогих дисков и, что самое главное, резервирования таких дисков, на случай выхода из строя.
Не все вопросы решаются IT, но мы хотим сделать жизнь людей лучше, хоть в чем-то. Кстати, тоже живу в 24 этажном доме, причем сменили управляющую компанию и ситуация в разы улучшилась, как с мусором, так и с другими вопросами.
1. использовать высокоскоростную библиотеку формирования ПДФ, учитывая что формат открытый и генерацию PDF можно на коленке набросать практически с plain-text
вариант хорош, но труднее поддерживать, формы часто меняются, пока используем FastReport.
переложить формирование ПДФа на клиента, используя javascript — parall.ax/products/jspdf например
а вот это не вариант, клиенты даже не знают, что формируется PDF пока они заняты другими разделами сайта, нагружать слабые мобильные приложения (такие тоже имеют доступ к порталу) не есть хорошо
если же вы не предрассчитываете платежные данные по клиенту
нет, мы давно отделили оперативные данные, тут проблемы нет, да и в основной системе принцип другой не как в 1С
количество документов, на тот момент да около того. Если брать на текущий момент (>1 000 000 в месяц), то около 7 Тб получится, что достаточно весомо для нас. Я согласен с вами, при отсутствии ограничений по железу, этот вариант очень хорош.
Даже если 80к в час — это чуть больше 20 запросов в секунду, это совсем мало.
Запросов было гораздо больше в секунду. Стоит учитывать неравномерное распределение по времени, к тому же здесь речь идет про сформированные платежные документы. Физически запросов было на порядок больше — кроме формирования платежного документа пользователь выполнял много других запросов: просмотр размера оплаты по услугам, внесение показаний прибора учета и так далее…
Делать партиционирование на десятках миллионов — уже возникают вопросы.
Вопросы партиционирования в первую очередь были связаны с возможностью независимо обновлять данные районов и во вторую очередь с тем, что время выполнения запроса к БД PostgreSQL (актуальной на тот момент версии) существенно выше при десятке миллионов записей в таблице по сравнению с сотней тысяч записей в таблице.
Как я понял это для формирования платежных документов. Тоже вопрос — зачем формировать платежные документы при заходе на сайт? Можно же их заранее нагенерить. Закончился отчетный период — запустили джобу и все.
Да, этот вариант был бы хорошим решением, кроме потребности в дисковой памяти, нужно учитывать, что запрос на формирование платежного документа может быть осуществлен за любой месяц в пределах 3-х лет.
Ну и если геренируется много запросов, смотрели ли в сторону денормализации данных, в отдельных случаях это может ускорить систему не в разы, а в сотни и тысячи раз.
Данные денормализованные, в максимально простом виде, для того чтобы в одном запросе участвовала только 1 таблица.
Согласен, это простой вариант и первый приходит на ум. Частично мы так и сделали:
«Ключевые решения, предпринятые на этом этапе:
— Отделение части информации оперативной базы данных»
К сожалению, на полноценный кластер не было возможности перейти по техническим причинам (ресурсы серверов ограничены), кроме того в этом случае усложнялась процедура обновления данных. В качестве альтернативы рассматриваем выделение «горячих» данных в NoSQL базу данных в памяти, этого должно хватить при росте нагрузки в 3-5 раз от текущего.
Плюс, главным потребителем времени является не столько обращение к БД, сколько формирование файла платежного документа.
80к в сутки распределены неравномерно, пик нагрузки приходится на отдельные часы. На тот момент это было для нас достаточно высоконагруженной системой, генерирующей в пик несколько сотен обращений в секунду, в будущем нагрузка будет только возрастать. Кроме того, на графике зафиксированы не сами запросы или загрузки страницы, а количество сформированных платежных документов.
По поводу хайлоад или нет можно долго спорить, для себя критерий вывел, когда число пользователей превышает 100 000, но это только мое мнение.
По поводу покупки SSD, довольно не бюджетно, кроме того гос ЦОД ( к примеру в одном из государственных ЦОД мы ждали замены обычного жесткого диска в течении 5 месяцев) не сильно заинтересован в покупке дорогих дисков и, что самое главное, резервирования таких дисков, на случай выхода из строя.
а вот это не вариант, клиенты даже не знают, что формируется PDF пока они заняты другими разделами сайта, нагружать слабые мобильные приложения (такие тоже имеют доступ к порталу) не есть хорошо
нет, мы давно отделили оперативные данные, тут проблемы нет, да и в основной системе принцип другой не как в 1С
Вопросы партиционирования в первую очередь были связаны с возможностью независимо обновлять данные районов и во вторую очередь с тем, что время выполнения запроса к БД PostgreSQL (актуальной на тот момент версии) существенно выше при десятке миллионов записей в таблице по сравнению с сотней тысяч записей в таблице.
Да, этот вариант был бы хорошим решением, кроме потребности в дисковой памяти, нужно учитывать, что запрос на формирование платежного документа может быть осуществлен за любой месяц в пределах 3-х лет.
Данные денормализованные, в максимально простом виде, для того чтобы в одном запросе участвовала только 1 таблица.
«Ключевые решения, предпринятые на этом этапе:
— Отделение части информации оперативной базы данных»
К сожалению, на полноценный кластер не было возможности перейти по техническим причинам (ресурсы серверов ограничены), кроме того в этом случае усложнялась процедура обновления данных. В качестве альтернативы рассматриваем выделение «горячих» данных в NoSQL базу данных в памяти, этого должно хватить при росте нагрузки в 3-5 раз от текущего.
Плюс, главным потребителем времени является не столько обращение к БД, сколько формирование файла платежного документа.