Алексеев А.А.
ОПТИМИЗАЦИЯ БАЗ ДАННЫХ НА PHP ДЛЯ СКЛАДСКИХ СИСТЕМ *
Аннотация:
говоря про оптимизацию баз данных посредством PHP на складских системах, важно учитывать современные тенденции в данном направлении. Поставщики логистических услуг, предлагающие транспортные, складские и другие услуги, являются важными связями в различных корпоративных структурах. Посредством комплексных и взаимодополняющих услуг логистические компании также взаимодействуют с внутренними отделами своих компаний-клиентов, например, в области планирования и информационных технологий (ИТ), используя такие концепции, как сторонний поставщик логистических услуг (3PL) и четвертый поставщик логистических услуг (4PL). В будущем ведущие поставщики логистических услуг будут все чаще предлагать комплексные услуги по всей цепочке поставок, ориентированные на потоки продуктов и рынки сбыта, путем умелого сочетания услуг 3PL и 4PL. Это делает их «ускорителями бизнеса», особенно на развивающихся рынках.
Ключевые слова:
оптимизация, базы данных, логистические издержки, библиотека, информационные потоки
DOI 10.24412/2712-8849-2023-1168-635-643
УДК 004
Алексеев А.А.
магистрант
Московский финансово-промышленный университет «Синергия»
ORCID 0009-0009-4046-2393
(г. Москва, Россия)
ОПТИМИЗАЦИЯ БАЗ ДАННЫХ НА PHP ДЛЯ СКЛАДСКИХ СИСТЕМ
Аннотация: говоря про оптимизацию баз данных посредством PHP на складских системах, важно учитывать современные тенденции в данном направлении. Поставщики логистических услуг, предлагающие транспортные, складские и другие услуги, являются важными связями в различных корпоративных структурах. Посредством комплексных и взаимодополняющих услуг логистические компании также взаимодействуют с внутренними отделами своих компаний-клиентов, например, в области планирования и информационных технологий (ИТ), используя такие концепции, как сторонний поставщик логистических услуг (3PL) и четвертый поставщик логистических услуг (4PL). В будущем ведущие поставщики логистических услуг будут все чаще предлагать комплексные услуги по всей цепочке поставок, ориентированные на потоки продуктов и рынки сбыта, путем умелого сочетания услуг 3PL и 4PL. Это делает их «ускорителями бизнеса», особенно на развивающихся рынках.
Ключевые слова: оптимизация, базы данных, логистические издержки, библиотека, информационные потоки.
Введение
В рамках подхода к оптимизации управления цепочками поставок грузоотправители все чаще переносят планирование и контроль на внешних поставщиков услуг, включая логистические услуги, такие как транспортировка, хранение и услуги с добавленной стоимостью. Растущая интеграция ИТ-систем между грузоотправителями и поставщиками логистических услуг для повышения прозрачности и мониторинга может значительно увеличить сложность и связанные с этим затраты. Однако использование стандартов в программном обеспечении и интерфейсах позволяет сократить текущие настройки, а также высокие затраты на обслуживание и стоимость продукта. Примером разработки стандартного приложения для транспорта и логистики является совместное предприятие компаний Arvato, Quentia и ABE с продуктом best4log-X, который был разработан на базе SAP и предлагает всем участникам логистической цепочки одинаковые стандарты [1, c. 8].
Специализированные системы WMS со стандартизированными интерфейсами остаются популярным вариантом, но все чаще сталкиваются с конкуренцией со стороны веб-решений и улучшенных стандартов WMS со стороны поставщиков ERP. Стандартизация становится особенно важной, когда речь идет о быстрой и эффективной интеграции клиентов в существующие системы [2, c. 55]
Материалы и методы
В работе используется метод наблюдения, для проведения анализа существующих API предложений для рынка, формирующихся за счет использования PHP и открытых библиотек. Метод сравнения был для использования детального выяснения особенностей современных логистических API на PHP, а также классификации их основных функций. В качестве материалов использованы научные работы Николь Сидьман, Адама Ворлака, Нины Беровски и других авторов.
Результаты
Чтобы оптимизировать производительность базы данных, следует настроить журнал повторов базы данных и оптимизировать размер журнала повторов и буфера. Для баз данных Oracle следует просмотреть свойства журнала повторения в файле init.ora. Если служба интеграции данных работает на одном узле, а экземпляр Oracle существует локально на узле процесса службы, рекомендуется использовать протокол IPC для подключения к базе данных Oracle для повышения производительности. Вы можете настроить подключение к базе данных Oracle в файлах Listener.ora и tnsnames.ora. Чтобы устранить узкие места источника неструктурированных файлов, можно рассмотреть следующие решения: Не использовать кавычки или escape-символы в свойствах формата плоского файла с разделителями. Если используется escape-символ, разделитель интерпретируется как обычный символ в строке [3, c. 1645–1651].
Рис.1. Система оптимизации посредством облака (по данным [7)].
Производительность сопоставления можно повысить, если исходный файл не содержит кавычек и escape-символов. Если сопоставление считывается из источника плоского файла, можно повысить производительность сопоставления, задав количество байтов, считываемых службой интеграции данных на строку. Следует настроить длину строкового буфера в свойствах среды выполнения для источников неструктурированных файлов. По умолчанию служба интеграции данных считывает 1024 байта на строку. Если каждая строка в исходном файле короче значения по умолчанию, стоит уменьшить длину буфера в свойствах сопоставления. Простой фильтр источника в исходной базе данных может повлиять на производительность, особенно если индексы отсутствуют [4, c. 119–129]. Вместо этого следует использовать фильтр условий в настроенном объекте данных для повышения производительности. Следует использовать фильтр условий для нескольких одновременных сопоставлений из одного источника, чтобы оптимизировать производительность.
Однако в некоторых случаях может оказаться более эффективным фильтровать исходные данные непосредственно в исходной базе данных.
Рис.2. Реализация индексного хранения (По данным [9]).
Следует протестировать как фильтр базы данных, так и фильтр условий, чтобы определить, какой метод обеспечивает наилучшую производительность. Служба интеграции данных может считывать ограничения из различных типов источников данных. Ограничения — это условные выражения, которые должны быть выполнены для обработки строк. Прежде чем настраивать ограничения, следует убедиться, что исходные данные соответствуют условиям. Следует использовать команды SQL для установки ограничений в среде базы данных при подключении к базе данных. При написании выражений следует стараться избегать как можно большего количества вызовов агрегатных функций. Для каждого вызова агрегатной функции служба интеграции данных должна найти и сгруппировать данные [5, c. 18].
Например, в следующем выражении служба интеграции данных считывает COLUMN_A, находит сумму, затем считывает COLUMN_B, находит сумму и, наконец, сумму двух сумм. SUM(COLUMN_A) + SUM(COLUMN_B) Если сгруппировать агрегатные функции следующим образом, служба интеграции данных добавляет COLUMN_A к COLUMN_B, а затем вычисляет сумму. SUM(COLUMN_A + COLUMN_B) Часто используемые выражения рекомендуется заменять локальными переменными. Если используется одно и то же выражение несколько раз в преобразовании, следует определить его как локальную переменную. Хотя в преобразовании можно использовать только локальную переменную, это повышает производительность, поскольку переменная вычисляется только один раз [6, c. 58].
Следует также использовать числовые операторы вместо строковых операторов, поскольку служба интеграции данных может обрабатывать числовые операции быстрее, чем строковые операции. Например, если используются большие объемы данных в столбцах EMPLOYEE_NAME и EMPLOYEE_ID, настройка поиска по EMPLOYEE_ID повысит производительность. При выполнении сравнения между столбцами CHAR и VARCHAR скорость снижается, если в строках обнаруживаются конечные пробелы. Чтобы избежать этого, стоит использовать опцию TreatCHARasCHARonRead при настройке службы интеграции данных в администраторе Informatica, чтобы не обрезать конечные пробелы в конце исходных полей CHAR. Вместо использования LOOKUP предлагается рассмотреть DECODE. При использовании LOOKUP служба интеграции данных должна искать отдельную таблицу в базе данных, а DECODE интегрирует искомые значения в выражение, исключая операцию поиска в базе данных. Таким образом, DECODE — более мощный вариант, если нужен небольшой объем неизменяемых данных [7, c. 65]. TT
Рис. 3. Структурная анатомия API (По данным [9]).
Рекомендуется также включить оптимизацию push-in для активного преобразования Java. Однако это не должно иметь побочных эффектов и не должно влиять на результаты картирования. Для этого необходимо сохранить условие фильтра и реализовать код, который проверяет логику фильтра во время выполнения. Это позволяет оптимизатору удалить преобразование фильтра из оптимизированного отображения.
Обсуждение
Преобразования соединений могут повлиять на производительность, поскольку они требуют дополнительной памяти для промежуточных результатов. Чтобы устранить узкие места в преобразованиях следует рассмотреть следующие решения.
Необходимо установить главный источник как источник с меньшим количеством повторяющихся значений ключей, чтобы уменьшить требования к хранению. Также нужно ограничить количество строк в главном источнике, чтобы минимизировать количество сравнений. Необходимо выполнять соединения в базе данных, поскольку это более эффективно. Нужно настроить преобразование Joiner для использования отсортированных входных данных для минимизации дискового ввода-вывода. Необходимо также оптимизировать условие соединения и при необходимости использовать метод оптимизации полусоединения. Преобразования поиска влияют на производительность из-за различных факторов, таких как тип кэша и условия поиска.
Необходимо также использовать оптимальный драйвер базы данных. Служба интеграции данных может подключаться к таблицам поиска с помощью собственного драйвера базы данных или драйвера ODBC. Собственные драйверы базы данных обычно обеспечивают лучшую производительность сопоставления, чем драйверы ODBC. Чтобы повысить производительность поиска для источников в реляционных или неструктурированных файлах, стоит включить кэширование поиска в преобразовании. Это приводит к тому, что служба интеграции данных кэширует таблицу поиска вместо повторного запроса ее для каждой строки. Необходимо также сохранять таблицы поиска для поиска логических объектов данных. Для логических объектов данных можно включить кэширование объектов данных, чтобы повысить производительность поиска. Служба интеграции данных кэширует логический объект данных, чтобы избежать повторных запросов. Следует также выбирать правильный тип кэша, чтобы максимизировать производительность. Общие кэши могут использоваться совместно для нескольких преобразований в одном или нескольких сопоставлениях, тогда как постоянные кэши используются для хранения файлов кэша между запусками сопоставления.
Включение параллельных кэшей значительно повышает производительность, особенно в сопоставлениях с несколькими активными преобразованиями, где можно избежать времени ожидания. Необходимо настроить совпадения условий поиска, чтобы преобразование возвращало произвольное соответствующее значение вместо индексации всех портов для повышения производительности. Следует также уменьшить количество кэшированных строк в кэше, чтобы повысить производительность. Стоит добавить предложение WHERE в стандартный оператор SQL, чтобы повысить производительность поиска. Также следует использовать преобразование «Фильтр» для кэширования строк, соответствующих предложению WHERE. Важно также определить оператор ORDER BY. Чтобы повысить производительность, можно заменить автоматически созданный оператор ORDER BY адаптированной версией с меньшим количеством строк.
Заключение
Оптимизация баз данных на PHP является важным аспектом разработки складских систем. Эффективное управление данными позволяет повысить производительность приложения, снизить нагрузку на сервер и обеспечить более быстрый доступ к информации. Процесс оптимизации включает в себя несколько этапов, начиная с анализа текущей структуры базы данных и запросов, и заканчивая оптимизацией самого кода на PHP. Важно также следить за правильным индексированием таблиц, использовать кэширование и учитывать особенности работы с большими объемами данных. Оптимизация баз данных на PHP для складских систем помогает обеспечить бесперебойную работу приложения, снизить затраты на оборудование и обслуживание, а также улучшить пользовательский опыт. В конечном итоге, правильная оптимизация баз данных способствует более эффективной и надежной управляемости складскими процессами, что является критически важным для успешной деятельности предприятия.
СПИСОК ЛИТЕРАТУРЫ:
Alekseev A.A.
Moscow Financial and Industrial University Synergy
(Moscow, Russia)
OPTIMIZATION OF PHP DATABASES FOR WAREHOUSE SYSTEMS
Abstract: speaking about optimizing databases using PHP on warehouse systems, it is important to take into account current trends in this direction. Logistics service providers offering transportation, warehousing and other services are important connections in various corporate structures. Through integrated and complementary services, logistics companies also interact with the internal departments of their client companies, for example, in the field of planning and information technology (IT), using concepts such as a third-party logistics service provider (3PL) and a fourth logistics service provider (4PL).
Keywords: optimization, databases, logistics costs, library, information flows.
Номер журнала Вестник науки №11 (68) том 4
Ссылка для цитирования:
Алексеев А.А. ОПТИМИЗАЦИЯ БАЗ ДАННЫХ НА PHP ДЛЯ СКЛАДСКИХ СИСТЕМ // Вестник науки №11 (68) том 4. С. 635 - 643. 2023 г. ISSN 2712-8849 // Электронный ресурс: https://www.вестник-науки.рф/article/11141 (дата обращения: 17.05.2024 г.)
Вестник науки СМИ ЭЛ № ФС 77 - 84401 © 2023. 16+