Когда не просто стыдно за свой старый код
Особенность системы - всё кэшировать, что позволяет старницу делать сколь угодно сложной, если она закэширована, всё работает быстро.
Конечно под это ложится неплохо big data.
ага, хрен бы там. Система даже на обычных объёмах начала тупить.
Всё началось со скурпёлёзного загрузчика для csv файлов. Написал. Скачал рандомный файл с сервака microsoft на 7 гб. Начал загрузку. После отладки и выяснения причин что было не так, решил остановить загрузку и протетстить как оно работает хотя бы на 100 000 строк.
1. Горлышко №1. Сначала выяснилось, что система долго запускается. Оказывается, функция, которая следит за корректностью данных в БД подгружала данные в RAM, а не делала всё SQL запросами. Чтобы понять насколько это непростая штука, я хоть и переписал всё за 2 дня, но отладкой ещё неделю занимался. Функция делает нечто подобное:
2. Горлышко №2. Мне уже после первого пункта стало страшно. Я гнался за универсальностью, не думая об объёмах данных... Те часто грузил всё из БД и обрабатывал в RAM... вторая проблема заключается в том, что при редактирвоании сущности, я выводил все значения, если тип парамтера checkbox, list, radiobutton... Конечно браузер не мог вывести 100 000 значений на каждый парамтер. Это было нужно, чтобы редактировать сразу весь объект, а потом сохранить всё на сервер одной кнопкой, а не для каждого значения параметра отправлять запрос. Стало понятно, что такое решение не подходит. Заменил на альтернативное (для radiobutton при большом числе значений появляется так же кнопка "Выбрать"):
3. Горлышко №3. (ещё не решённое). А что если у сущности будет очень много параметров. Не значений, а параметров? Например, если
СУЩНОСТЬ = товар
АТРИБУТ = парамтеры товары
ЗНАЧЕНИЯ = значения товара
если АТТРИБУТОВ у товара будет очень много, так, что браузер не сможет их вывести? Значит, надо предусмотреть параметры товара выводить постранично? или как? продумать надо. Ибо в этом случае нагнётся не просто редактирование товара, но и в админке общий просмотр - очень широкая таблица будет долго грузится (тут правда уже почти готово решение - выводить не все столбцы, какие выводить уже можно выбрать).
4. Горлышки №4х (ещё не решённое). Это куча мелких функций, которые сейчас работают через RAM (запрос в БД - получаение результата в RAM - вычисление - запись в БД, а надо одним запросом в БД). Им всем надо писать альтернативы в SQL. Их число ещё не подсчитывал, но по ощущениям их много.
PS Короче, чтобы выдержать объёмы банков (например, я сейчас в Aльфе, там в каждой таблице по 1-20 млн записей и таблиц дофига), надо ещё потрудиться...
Конечно под это ложится неплохо big data.
ага, хрен бы там. Система даже на обычных объёмах начала тупить.
Всё началось со скурпёлёзного загрузчика для csv файлов. Написал. Скачал рандомный файл с сервака microsoft на 7 гб. Начал загрузку. После отладки и выяснения причин что было не так, решил остановить загрузку и протетстить как оно работает хотя бы на 100 000 строк.
1. Горлышко №1. Сначала выяснилось, что система долго запускается. Оказывается, функция, которая следит за корректностью данных в БД подгружала данные в RAM, а не делала всё SQL запросами. Чтобы понять насколько это непростая штука, я хоть и переписал всё за 2 дня, но отладкой ещё неделю занимался. Функция делает нечто подобное:
2. Горлышко №2. Мне уже после первого пункта стало страшно. Я гнался за универсальностью, не думая об объёмах данных... Те часто грузил всё из БД и обрабатывал в RAM... вторая проблема заключается в том, что при редактирвоании сущности, я выводил все значения, если тип парамтера checkbox, list, radiobutton... Конечно браузер не мог вывести 100 000 значений на каждый парамтер. Это было нужно, чтобы редактировать сразу весь объект, а потом сохранить всё на сервер одной кнопкой, а не для каждого значения параметра отправлять запрос. Стало понятно, что такое решение не подходит. Заменил на альтернативное (для radiobutton при большом числе значений появляется так же кнопка "Выбрать"):
3. Горлышко №3. (ещё не решённое). А что если у сущности будет очень много параметров. Не значений, а параметров? Например, если
СУЩНОСТЬ = товар
АТРИБУТ = парамтеры товары
ЗНАЧЕНИЯ = значения товара
если АТТРИБУТОВ у товара будет очень много, так, что браузер не сможет их вывести? Значит, надо предусмотреть параметры товара выводить постранично? или как? продумать надо. Ибо в этом случае нагнётся не просто редактирование товара, но и в админке общий просмотр - очень широкая таблица будет долго грузится (тут правда уже почти готово решение - выводить не все столбцы, какие выводить уже можно выбрать).
4. Горлышки №4х (ещё не решённое). Это куча мелких функций, которые сейчас работают через RAM (запрос в БД - получаение результата в RAM - вычисление - запись в БД, а надо одним запросом в БД). Им всем надо писать альтернативы в SQL. Их число ещё не подсчитывал, но по ощущениям их много.
PS Короче, чтобы выдержать объёмы банков (например, я сейчас в Aльфе, там в каждой таблице по 1-20 млн записей и таблиц дофига), надо ещё потрудиться...