Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Perl - оптимальное сравнение массивов
|
|||
|---|---|---|---|
|
#18+
Есть пара источников данных, по несколько тысяч элементов в каждом. У каждой записи есть массив из нескольких (обычно до 10) чисел. Можно сравнить в лоб, как строки: join(',', sort(@a)) eq join(',', sort(@b)) Либо можно использовать smartmatch: sort(@a) ~~ sort(@b) Но в обоих случаях используется сортировка. А нет ли более эффективного способа? ________________________ Мы смотрим с оптимизмом... ...в оптический прицел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2015, 15:00 |
|
||
|
Perl - оптимальное сравнение массивов
|
|||
|---|---|---|---|
|
#18+
Ну начни с рассматривания источников данных. Откуда ты берешь содержимое массивов @a и @b? И какое собственно говоря сравнение тебе нужно? Если тебе надо найти содержится ли массив @a в источнике для массива @b это одно. И тогда действительно надо волноваться о способе сравнения массивов. А если у тебя есть два позиционированных источника и массив @a на строке 1324 надо сравнивать с массивом @b на строке 1324 то скорее всего сортировки массивов это такая незначительная мелочь будет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2015, 06:08 |
|
||
|
Perl - оптимальное сравнение массивов
|
|||
|---|---|---|---|
|
#18+
У меня две базы данных, информацию в которых нужно синхронизировать в одном направлении. Но они слишком разнородные (одна это Oracle, вторая это веб-сервис), поэтому синхронизацию осуществляет скрипт по расписанию. Строка — это клиент, а массив чисел — это услуги, которые доступны для клиента. Если значения идентичные (то есть в базе-приемнике у клиента набор услуг такой же, как в базе-источнике), то ничего делать не нужно. Если значения разные, то в базе-приемнике нужно задать клиенту такой же набор услуг, как в базе-источнике. Особенность работы базы-приемника (веб-сервиса) такова, что установление сессии происходит довольно долго, а запрос выполняется довольно быстро. Поэтому построчная обработка не подходит, нужно одним запросом получить список клиентов с услугами, затем обработать весь список, составить пакетное задание на обновление и вторым запросом это пакетное задание отправить на веб-сервис. Сейчас у меня примерно такой код: Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. В принципе неплохо и быстро работает. Но хотелось бы по возможности избавится от двух сортировок при каждом проходе цикла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2015, 13:05 |
|
||
|
Perl - оптимальное сравнение массивов
|
|||
|---|---|---|---|
|
#18+
Alibek B.У меня две базы данных, информацию в которых нужно синхронизировать в одном направлении.Все. На этом можно остановится. Шагай читать учебники по базам данных. Ключевые слова: replication/репликация , ETL (Extract Transform Load) , CDC (Change data capture) . Для более детального ответа, вспомни какие СУБД тебе надо синхронизировать и задавай вопросы по репликации данных между этими двумя базами в соответствующем форуме. Перл может использоваться для этого, но это будет очень неэффективно. Примерно как разглаживать асфальт при помощи рубанка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2015, 19:45 |
|
||
|
Perl - оптимальное сравнение массивов
|
|||
|---|---|---|---|
|
#18+
White OwlКлючевые слова: replication/репликация , ETL (Extract Transform Load) , CDC (Change data capture) . Ну это не всегда возможно. На сервере с Oracle нет интернета по соображениям безопасности, соответственно нет связи с веб-сервисом. Да и даже если бы был, типовые инструменты не позволяют работать с произвольным веб-сервисом. То есть все равно нужно писать свой скрипт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2015, 12:38 |
|
||
|
Perl - оптимальное сравнение массивов
|
|||
|---|---|---|---|
|
#18+
Alibek B.На сервере с Oracle нет интернета по соображениям безопасности, соответственно нет связи с веб-сервисом.Ну здрасте, для самоделки связь есть, а для всего остального нет??? Вполне хватит если у "спрятанного" сервера была связь с другой машиной в интранете. Чтобы было куда кидать или откуда читать репликационные пакеты. Репликация не обязательно делается прямой связью база-база. Можно и так конечно, но база-база это почти всегда серьезное проседание по производительности и потому не рекомендуется. Alibek B.Да и даже если бы был, типовые инструменты не позволяют работать с произвольным веб-сервисом. То есть все равно нужно писать свой скрипт.Глупости. "произвольный веб-сервис" это всегда какая-то база данных. Не обязательно даже СУБД, но обязательно база. Все что тебе нужно, это уметь выгружать обновления из базы-источника. Самое простое это иметь во всех нужных таблицах поле типа Change_TimeStamp. И раз в цать времени делаешь select * from table where Change_TimeStamp>:last_session. Выгрузил результат во внешний файл, записал текущий timestamp в отдельный файл для будущей сессии. Файл с изменениями любым способом (да хоть на дискете) отнес на базу-приемник и загрузил ее методом insert or update. Все. И никаких сравнений массивов нафиг не нужно. Кароче, читай ссылки что я тебе дал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2015, 18:31 |
|
||
|
Perl - оптимальное сравнение массивов
|
|||
|---|---|---|---|
|
#18+
White OwlНу здрасте, для самоделки связь есть, а для всего остального нет??? Сервер в защищенной и закрытой сети (интранет). Веб-сервис в публичной сети (интернет). Самоделка на отдельном сервере в DMZ. Вполне типовое и обкатанное решение. White OwlСамое простое это иметь во всех нужных таблицах поле типа Change_TimeStamp. И раз в цать времени делаешь select * from table where Change_TimeStamp>:last_session. Выгрузил результат во внешний файл, записал текущий timestamp в отдельный файл для будущей сессии. Файл с изменениями любым способом (да хоть на дискете) отнес на базу-приемник и загрузил ее методом insert or update. Понятно. У меня это сложновато будет сделать, поскольку структуры данных слишком сильно отличается, это совершенно не связанные между собой информационные системы. Поэтому преобразовать изменения для того, чтобы воспроизвести их в базе-приемнике, будет сложнее и дольше, чем сравнивать строки. Во-всяком случае пока количество записей измеряется тысячами, а не сотнями тысяч. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2015, 11:56 |
|
||
|
Perl - оптимальное сравнение массивов
|
|||
|---|---|---|---|
|
#18+
Alibek B.White OwlНу здрасте, для самоделки связь есть, а для всего остального нет??? Сервер в защищенной и закрытой сети (интранет). Веб-сервис в публичной сети (интернет). Самоделка на отдельном сервере в DMZ. Вполне типовое и обкатанное решение.Ну и? Еще раз повторяю вопрос: почему ты считаешь что типовая система репликации не сможет справится с типовой сетевой топологией? Alibek B.Поэтому преобразовать изменения для того, чтобы воспроизвести их в базе-приемнике, будет сложнее и дольше, чем сравнивать строки.С чего это вдруг? Ты серьезно предпочитаешь сравнивать массивы на несколько тысяч элементов, если есть альтернатива переформировать массив с десятком элементов??? Не, если хочешь извращаться и тормозить, то флаг в руки, барабан на шею и вперед ... на увольнение. В нормальных конторах твою проблему решают используя CDC или ETL. В любом случае, читай учебники по репликации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2015, 17:57 |
|
||
|
|

start [/forum/topic.php?fid=23&msg=39021036&tid=1461609]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 298ms |
| total: | 462ms |

| 0 / 0 |
