Offtopic про регулярки. Если их можно заменить на поиск через indexOf или еще как-то, то желательно заменить. Сталкивался с очень серьезным падением производительности (на порядок) в нагруженном сервисе именно на поиске подстрок через регулярки.
Ну что за безысходность. Ок, тогда вернемся к комарам и пусть кусают всех кроме людей. Возможно ли такое, что их какие-то запахи отталкивают и это прошито гинетически? Есть ли у человека специфический запах, который можно прошить в днк комара как отталкивающий?
С Oracle на Pg не мигрировал. С Firebird мигрировал. Мигрировали с Fb 2.5 на Pg 10. По самому переносу данных и повторении структур - ничего особенного. Написали руками код миграции на node. Из особенностей только булевы поля добавились. А вот все триггеры, процедуры пришлось переписывать с нуля. И по ходу эксплуатации иногда ловить ошибки, что в Pg в триггерах нужно возвращать new, а в Fb не нужно и местами при ручном переносе это не замечалось.
На Pg был ощутимый рост скорости запросов при тех же индексах. Некоторые запросы ускорились в десятки раз (как помню, Firebird не очень любил not in () условия). Также на pg для аналитических запросов (отчеты, где кучи join-ов, аггрегация, подселекты) настроили master-slave репликацию, что позволило еще сильнее разгрузить оперативную базу.
После марта докупил сбера и белуги. В сбер я просто верю, что он непотопляем. А белуга по моим умозаключениям будет расти из-за ухода импортного алкоголя.
Покупайте российские акции. Почти все крупные банки имеют приложения для работы с акциями, фондами, облигациями. Как раз с началом спец. операции всё упало. Не ясно только, будет ли еще падать или уже только расти.
Есть ещё фонды в коммерческую недвижимость, которые вроде как растут с роста стоимости самой недвижимости и аренды. Кто бы умный про них ещё что-то сказал. Вдруг тоже есть нюансы.
Безусловно, при разных обстоятельствах можно руководствоваться соображениями оптимизации, либо соображения расширения ресурсов. Да и обработка порой требуется разная (где-то арифметику выполнить, а где-то сходить в разные api).
Но, тем не менее, когда вы выбираете обработку в прикладной системе, то должны учитывать, что помимо запроса СУБД еще будут затраты на кодирование данных в сетевой протокол и обратно, передачу по сети, работу драйвера прикладного языка. Также у вас не будет под рукой кешей, которые уже сформированы в СУБД и могут быть использованы в PL/PG/whatever SQL.
Также я не являюсь ярым сторонником того или иного подхода и в своих проектах опираюсь на следующие критерии:
Частота выполнения операции.
Затрагиваемый объем данных
Наличие в БД программного кода (от ваших коллег, возможно предыдущих)
Сложность реализации (в обе стороны работает)
Необходимость перекачки данных в две стороны (из СУБД и после обратно)
Для деревьев использовали внешнюю таблицу на основе AL+MP + добавляли childIndex для сортировки детей. Если нужно было объединять в иерархию несколько сущностей (таблиц), то вместо одной ссылки на таблицу сущностей добавлялось больше столбцов-ссылок. Непротиворечивость ссылок в рамках одной записи обеспечивалось дополнительным столбцом с индексом сущности.
Создание иерархии во внешней таблице позволяет избежать модификации основный таблиц и строить больше одной иерархии на основе базовой таблицы. Недостатком такого подхода является необходимость поддерживать актуальность иерархических таблиц вместе с основными.
Offtopic про регулярки. Если их можно заменить на поиск через indexOf или еще как-то, то желательно заменить. Сталкивался с очень серьезным падением производительности (на порядок) в нагруженном сервисе именно на поиске подстрок через регулярки.
Ну что за безысходность. Ок, тогда вернемся к комарам и пусть кусают всех кроме людей. Возможно ли такое, что их какие-то запахи отталкивают и это прошито гинетически? Есть ли у человека специфический запах, который можно прошить в днк комара как отталкивающий?
Мухами пусть заменятся. Те хоть дерьмо жрут, а не кровь.
Можно вывести комаров, которые через 5-7 поколений не смогут давать потомство? Или которых кровь человека не будет привлекать?
С Oracle на Pg не мигрировал. С Firebird мигрировал. Мигрировали с Fb 2.5 на Pg 10. По самому переносу данных и повторении структур - ничего особенного. Написали руками код миграции на node. Из особенностей только булевы поля добавились. А вот все триггеры, процедуры пришлось переписывать с нуля. И по ходу эксплуатации иногда ловить ошибки, что в Pg в триггерах нужно возвращать new, а в Fb не нужно и местами при ручном переносе это не замечалось.
На Pg был ощутимый рост скорости запросов при тех же индексах. Некоторые запросы ускорились в десятки раз (как помню, Firebird не очень любил not in () условия). Также на pg для аналитических запросов (отчеты, где кучи join-ов, аггрегация, подселекты) настроили master-slave репликацию, что позволило еще сильнее разгрузить оперативную базу.
Вместо спорта танцами заняться можно. Хип хоп или бальные не важно. Это и интересно и двигаешься там очень плотно и метаболизм разгоняешь.
Но ведь вклады под 20% были на несколько месяцев. Т.е. на год их нельзя было оформить. Или в каких-то банках было можно?
Не секрет, но я в основном до марта покупал :)
После марта докупил сбера и белуги. В сбер я просто верю, что он непотопляем. А белуга по моим умозаключениям будет расти из-за ухода импортного алкоголя.
Покупайте российские акции. Почти все крупные банки имеют приложения для работы с акциями, фондами, облигациями. Как раз с началом спец. операции всё упало. Не ясно только, будет ли еще падать или уже только расти.
Есть ещё фонды в коммерческую недвижимость, которые вроде как растут с роста стоимости самой недвижимости и аренды. Кто бы умный про них ещё что-то сказал. Вдруг тоже есть нюансы.
Так значит модель с онлифанс тоже сможет вложиться в производство и рост ВВП.
Безусловно, при разных обстоятельствах можно руководствоваться соображениями оптимизации, либо соображения расширения ресурсов. Да и обработка порой требуется разная (где-то арифметику выполнить, а где-то сходить в разные api).
Но, тем не менее, когда вы выбираете обработку в прикладной системе, то должны учитывать, что помимо запроса СУБД еще будут затраты на кодирование данных в сетевой протокол и обратно, передачу по сети, работу драйвера прикладного языка. Также у вас не будет под рукой кешей, которые уже сформированы в СУБД и могут быть использованы в PL/PG/whatever SQL.
Также я не являюсь ярым сторонником того или иного подхода и в своих проектах опираюсь на следующие критерии:
Частота выполнения операции.
Затрагиваемый объем данных
Наличие в БД программного кода (от ваших коллег, возможно предыдущих)
Сложность реализации (в обе стороны работает)
Необходимость перекачки данных в две стороны (из СУБД и после обратно)
Алгоритмы запихивают в СУБД чтобы не гонять данные с СУБД туда и обратно. Гонять большие данные - дорогая операция.
Отличная серия статей. Есть ли что-то похожее на переезд с MS SQL на Pg?
Можно узнать самую дорогую статью расходов по материалам? Что там такого наукоемкого или редкого, что так дорого стоит произвести?
Искали возможность удешевления операции? Что именно кроме труда специалистов стоит так дорого? Или себестоимость низкая, а такой ценой снижаете спрос?
Для деревьев использовали внешнюю таблицу на основе AL+MP + добавляли childIndex для сортировки детей. Если нужно было объединять в иерархию несколько сущностей (таблиц), то вместо одной ссылки на таблицу сущностей добавлялось больше столбцов-ссылок. Непротиворечивость ссылок в рамках одной записи обеспечивалось дополнительным столбцом с индексом сущности.
Создание иерархии во внешней таблице позволяет избежать модификации основный таблиц и строить больше одной иерархии на основе базовой таблицы. Недостатком такого подхода является необходимость поддерживать актуальность иерархических таблиц вместе с основными.
Всё равно не ясно. Курс же на 4 месяца согласно самому началу статьи.
del
Что-то не сходится. 2459*4 < 24000