Под синхронизацией в бд я понимаю сравнение двух наборов данных, затем вставку недостающих записей и удаление лишних.
Потоковая синхронизация была бы нужна, когда одновременно меняются данные в объекте-хранилище и читаются из него. В моем случае хранилище заменяется целиком на новое.
Не совсем понял для чего разделять на 2 этапа. Сейчас в csv файле присутствуют следующие наборы данных:
в формате ^\d{4},\d{6}$ (таких записей большинство)
в формате ^[A-Za-zА-Яа-я\d\s-]+,\d+$
ошибочные данные, например З вместо 3 в номере паспорта
Проверять на соответствие формату не требуется, достаточно проверить присутствует ли комбинация Серия + Номер в csv-файле.
У меня нет истории записей и других источников, только этот csv-файл из открытого доступа. В данной реализации нет ложных срабатываний, сжатые данные эквивалентны исходному csv-файлу с точностью до порядка строк. Т.е. выполняется условие:
Паспорта со строковыми сериями также должны проверяться на наличие в списке.
Нагрузочное тестирование не делал. Можно расширить сервис, добавив проверку списка паспортов. Должно работать быстро, т.к. поиск идет в памяти и сложность близка к O(1).
Сейчас (после некоторых оптимизаций) обновление занимает менее 6 минут и запускается по расписанию раз в сутки. Обновляется обьект в памяти.
Особых требований нет, нужно сделать по возможности оптимально по скорости и памяти.
Не пробовал решение с базой, но могу предположить, что в моем варианте обновление данных будет работать быстрее. Учтите что данные могут как добавляться в csv так и удаляться из него. Исходный серивис имеет возможность сообщить об ошибке с внесением последующих корректировок. Таким образом для бд надо предусмотреть синхронизацию данных. В моем варианте этого не требуется.
Познавательно. Дополнил алгоритм оптимизацией из этой статьи:
Длина массива будет зависеть от максимального номера в серии. Другими словами, если в серии 3382 встречается только один паспорт с номером 000032, то для всей серии потребуется 4 байта.
Под синхронизацией в бд я понимаю сравнение двух наборов данных, затем вставку недостающих записей и удаление лишних.
Потоковая синхронизация была бы нужна, когда одновременно меняются данные в объекте-хранилище и читаются из него. В моем случае хранилище заменяется целиком на новое.
Не совсем понял для чего разделять на 2 этапа. Сейчас в csv файле присутствуют следующие наборы данных:
в формате
^\d{4},\d{6}$(таких записей большинство)в формате
^[A-Za-zА-Яа-я\d\s-]+,\d+$ошибочные данные, например
Звместо3в номере паспортаПроверять на соответствие формату не требуется, достаточно проверить присутствует ли комбинация Серия + Номер в csv-файле.
У меня нет истории записей и других источников, только этот csv-файл из открытого доступа. В данной реализации нет ложных срабатываний, сжатые данные эквивалентны исходному csv-файлу с точностью до порядка строк. Т.е. выполняется условие:
SORT(original.csv) = SORT(Unpack(Pack(original.csv)))Паспорта со строковыми сериями также должны проверяться на наличие в списке.
Нагрузочное тестирование не делал. Можно расширить сервис, добавив проверку списка паспортов. Должно работать быстро, т.к. поиск идет в памяти и сложность близка к
O(1).Сейчас (после некоторых оптимизаций) обновление занимает менее 6 минут и запускается по расписанию раз в сутки. Обновляется обьект в памяти.
Особых требований нет, нужно сделать по возможности оптимально по скорости и памяти.
Спасибо, полезные замечания! Сжатие ускорилось на 19 секунд (25%).
Не пробовал решение с базой, но могу предположить, что в моем варианте обновление данных будет работать быстрее. Учтите что данные могут как добавляться в csv так и удаляться из него. Исходный серивис имеет возможность сообщить об ошибке с внесением последующих корректировок. Таким образом для бд надо предусмотреть синхронизацию данных. В моем варианте этого не требуется.
Познавательно. Дополнил алгоритм оптимизацией из этой статьи:
В итоге сжатие улучшилось на 10%.
Так как данные хранятся в памяти, обновление не требует прерывания работы сервиса.