Одного разу я писав утиліту для аналізу великого обсягу сильно пов'язаних даних на XML + C # - замовник хотів модні (в 2007 році) технології. Нічого складного - XML-документ завантажувався в пам'ять, послідовно оброблявся, результати складалися в базу. Проблема була в сильній пов'язаності - при обробці майже кожного вузла доводилося довантажувати цілі секції з різних кінців цього ж документа.
Коли співвідношення обсягу вхідних даних і обсягу ОЗУ машини перетнуло критичну позначку, програма збожеволіла. Показник Time in GC досяг значення 98%, а значить, програма не працювала, натомість Виконавча займалася очищенням і дефрагментацією пам'яті. Проведене розслідування показало - при нестачі пам'яті і спробі довантажити додаткові дані для обробки поточного вузла ОС скидала оброблювані дані в своп, а потім діставала їх назад. І збирач сміття працював над свопом, що в тисячі разів повільніше роботи з ОЗУ.
Рішенням був файловий ввід-висновок. Я переписав програму, використовуючи свій велосипедний сторінковий введення-виведення і формат CSV замість громіздкого XML. Після цього вона могла обробляти будь-який обсяг даних, незалежно від обмежень ОЗУ машини, з постійною швидкістю, не відволікаючись на дефрагментацію своп-файлу і взагалі його не використовуючи.
До чого я все це. Файловий обмін - чудова річ, і мало форматів краще, ніж CSV. Він легко читається машиною і людиною, його підтримують більшість програм - від офісних до наукових пакетів. Використовуючи магію bash, його можна бити на частини (підзадачі для обчислювальної ферми, наприклад) або об'єднувати (результати обчислень), записувати в мережу, в пристрої, в інші процеси, викласти в хмарне сховище або відправити email, перезапроса в разі відмови мережі, створити резервну копію, прийняти і обробити тисячею і одним способом.
Якщо технологія існує давно, це не означає, що вона погана. Це означає, що вона вже пережила пару поколінь бажаючих використовувати тільки новітні технології. Вони пішли або перегоріли, а технологія залишилася.
Немає коментарів:
Дописати коментар