Сколько это много данных для Excel?

Question

[Иван]

Какие есть метрики оценки файлов Excel на "это для экселя уже много".
Есть ли какая то официальная документация где написано типа "если в экселе 100500 ячеек заполнено это уже ограничение системы" или в Мб
Суть в том что есть годами сложившаяся традиция решения определенных задач в Excel.
Некоторые файлы превратились в "навороченный софт" из кучи взаимосвязей, данных, графиков и VBA.
В некоторых случаях сильно "тормозят" что не удивительно.

Однако не понятно, каким образом вычислить из чего проблема.
из формул/связей или за большого количества данных.

вообщем тут вероятно даже три вопроса:
1. точные метрики и как мерять что "эта задача уже не для Эксель".
2. как оценить влияние тех или иных сущностей (формулы , графики) на общую производительсть файла.
3. где проходит граница между Excel и БД/Python/R

Comments

[Иван]

John Smith, да такие штуки я читал. 100500 советов. проблема в том что нужно взять конкретный файл (а по сути программу из кучи формул/VBA/данных) и какой то конкретной тулзой проверить.
Тулза говорит "вот смотри чувак у тебя 200 графиков а это 100(условно) мб места на диске и 10% от производительности при обновлении файла. типа того что то . или явно показал что какой нибудь lookup жрет 50% времени на пересчет.
Такую вот бы штуку).

Answer 1

[Saboteur]

Суть в том что есть годами сложившаяся традиция решения определенных задач в Excel.

С годами версии экселя меняются. Когда-то давно был предел в 65 тысяч строк. Когда-то давно был предел в 1-5 мегабайт на файл.

Если брать просто данные, то эксель довольно неплохо справляется с большими объемами, там скорее упирается в оперативку на конкретном компе.
Но если начинаете оформлять, то я видел как довольно небольшой файл, но с оформлением в каждой ячейке вынуждают эксель зависать.

Много связей с внешними файлами - плохо. Эксель все-таки не база данных, и обновление из разных файлов будет подтормаживать.

Если у вас много функционала, возможно имеет смысл подумать о каком-то приложении, может быть с базой, но можно и напополам.
Тем более что с Экселем напрямую могут работать многие библиотеки.

Comments

[Иван]

на интуитивном уровне понятно, что надо менять инструмент решения задачи и отходить от экселя.
однако нужно как то измерить существующие файлы. т.к. быстро не переписать на новый софт, и часть все равно придется оптимизировать.

[Saboteur]

Отходите постепенно.
Эксель - формат с которым многие могут работать. Может сперва диаграммы рисовать где-то отдельно, а данные будут браться из экселя. Так потихоньку и перейдете

Answer 2

[Владимир Коротенко]

Я обычно смотрю инструкцию
1.
https://support.office.com/ru-ru/article/%D1%82%D0...

2. гугл excel profiler
3. У вас видимо уже.

Comments

[Иван]

1. это как бы частности. как оценить конкретный файл который содержит кучу всяких сущностей.
2. вы чем то пользовались (не для профилирования VBA) а именно для оценки влияния той или иной сущности на общую производительность файла?
3. "видимо пора" - это такая метрика, типа "у меня файл тупит, пора написать за N денег супер софт чтобы это прошло". какие то метрики нужны.
переходить на другое решение тдовольно долго и заморочно.
переносить на БД и делать поверх этого софт.
мы смотрели в сторону jupiter notebooks (т.к. много графиков да и python условно "все умеет"). но это отдельный вопрос на что переходят в таких случаях

[Владимир Коротенко]

1. Это верхняя оценка лимитов за которые выходить не стоит
2. Интуицией и фидбеком мол тормозит, под каждую задачу ищу подходящий инструмент, понять что конкретно тормозит.
3. Есть правила UI дизайна. Считается хорошим тоном обеспечить реакцию программы в 33-40 ms выше 200ms в офисных программах это субъективно тормоза которые человек ощущает, а если еще печатает вслепую это вообще мрак. Возвращаясь к пункту 2 нужен профайлер для сбора метрик.

Перенос софта. Всегда проблема. Возможно расширить это все. Например в Sharepoint есть Excel Services. Все считается на сервере, там же кэшируется и отдает результат.

Насчет питона. Лично я не понимаю хайпа. Язык содержит кучу костылей, да позволяет просто что то сделать, но вам нужно лопатить тонны нефти, возможно стоит написать на чем нибудь типа C# или Java.

Другой вариант это OLAP кубы, эксель прекрасно с ними работает, всю логику рулит сиквел.
Еще один это SSRS там тоже можно создать кастомные запросы и выводить готовый отчет.

В общем серебряной пули нет и я упомянул только основные технологии, на самом деле их сильно больше

Answer 3

[rostislav-zp]

я на практике сталкивался с таким-была выгрузка из двух баз данных.нужно было сделать нечеткий текстовый поиск и объеденить по ключевому столбцу в одну таблицу.использовал fuzzy lookup.ексель сравнивал 90тыс строк из одной таблицы с 300 строк из другой.на больших объемах крашился.это занимало по 40 минут на core i7 при учете того,что ексель нагружает каждое ядро только на 25%.результаты многократно повторял и склеивал в итоговую таблицу.сейчас я уже знаю,что такое pover pivot и решил бы эту задачу правильно и быстрее.но тогда вариантов не было.сроки поджимали.на питоне это можно было идеально реализовать,но человек,который взялся за решение задачи-провалил все сроки и так ничего и не сделал.пока искал решение ускорения расчетов в екселе,чего только не находил.даже cuda ядра с видеокарты люди подключают(но дальше прототипа дело не пошло).вообще работая с olap кубами и pover pivot+ pover query+pover bi- могу сказать,что до ограничений я так и не дошел.ютуб творит чудеса в плане обучения.посмотрите каналы станислава салостея и николая павлова.там информаци более чем достаточно.а если дальше копать,то я например питон и node red использую.
и как сказали выше-нужно быть внимательным с условным форматированием.по этому вопросу вот отличное решение https://www.youtube.com/watch?v=sc9xyMl1uu8&list=P...