Недавно мы протестировали подход, который мы называем КДМ , при работе с большими объемами данных — сотни гигабайт. В рамках задачи мы обработали 12–24 миллиона записей и сравнили производительность решения-квинтета с аналогичным функционалом в обычных таблицах.
Новых открытий мы не сделали, но подтвердили гипотезы, озвученные ранее: насколько универсальный конструктор в руках так называемого «чайника» проигрывает профессионально настроенной базе данных.
Мы тоже теперь знаем, что делать в такой ситуации — решение достаточно простое и надежное, и у нас есть опыт организации компромиссного решения для любого объема больших данных.
При разработке системы сверки отчетности нам потребовалось загрузить данные из одной из форм отчетности, которая содержит до 24 миллионов записей на каждую отчетную дату.
Там должны быть данные за 7 лет ежедневных расчетов.
Объемы, прямо скажем, не для универсального конструктора, а для узкоспециализированной системы, но мы уже увлеклись этой идеей и пришлось искать решение.
Пользователи работают с таким большим объемом данных только в пределах одной отчетной даты, поэтому в справочной системе все это хранится в таблице, секционированной по этой дате.
Индексы остальных 26 полей данных в этой форме не используются.
Первое, что мы сделали, конечно же, создали в конструкторе необходимую структуру данных и загрузили туда несколько дат. Загрузка одной из самых маленьких дат занимает около 14 часов, что уже недопустимо долго: 12,5 миллионов записей по 27 атрибутов, помещенных в полмиллиарда записей по 5 полей с построением трех индексов, два из которых составные.
Общий объем этих данных на диске составляет чуть больше 18 ГБ.
Стоит отметить две особенности этой формы:Для сравнения, те же данные, загруженные в обычную таблицу реляционной базы данных, занимают 2,3 ГБ (в 8 раз меньше) с индексом по дате и загружаются менее чем за полчаса (в 28 раз быстрее).Это, можно сказать, самый радикальный случай, который можно выбрать для сравнения.
- Нормализовать практически невозможно, в отличие, например, от формы 110, рассмотренной в предыдущая публикация
- Не использует индексы на основе атрибутов записей — пользователю выгоднее подождать минуту, чем тратить деньги на индексы
В большинстве случаев разница в объёмах данных между QDM и обычной базой данных не столь существенна, если не сказать очень маленький .
В обоих случаях данные вставлялись прямо из файла кусками по 100 тысяч записей, без отключения индексов.
Помня о том, что для таких объёмов данных использовать конструктор нецелесообразно, мы всё же провели тесты производительности: для разных случаев сравнили массовую обработку записей конструктором и нашу неиндексированную таблицу.
Нам нужно было определить предел объёма данных для хранения, которые мы впредь будем использовать обычную таблицу, а не наш конструктор.
Как мы и ожидали, работа с небольшими наборами данных, например, по отдельному аккаунту или клиенту, в дизайнере выглядит вполне комфортно (время отклика в пределах секунды), в отличие от таблицы без индексов, где приходится ждать ответ в течение нескольких минут. При этом основная задача приложения — массовая выборка и агрегирование данных в различных разделах — может занимать в дизайнере в разы больше времени.
Ниже приведены сводные результаты выборок, которые мы сделали для постепенно увеличивающегося объема агрегированных данных:
| Количество записей | Время выборки, с | |
|---|---|---|
| Конструктор | Таблица без индексов | |
| 1 | 0.16 | 56 |
| 5 | 0.23 | 55 |
| 50 | 1.86 | 53 |
| 600 | 2.35 | 56 |
| 5000 | 14.7 | 56 |
| 12000 | 125 | 56 |
| 100000 | 254 | 57 |
| 650000 | 2663 | 57 |
| 1000000 | 2314 | 57 |
| 5000000 | 9675 | 69 |
| 12500000 | 764 | 89 |
Из таблицы и графика ниже видно, что агрегирование полного набора данных в течение дня занимает заметно меньше времени, чем выборка более 5% данных с помощью индекса.Графическое отображение одних и тех же результатов с использованием логарифмической шкалы для сравнения чисел разного порядка:Вот почему оптимизаторы запросов РСУБД игнорируют индекс в такой ситуации, в то время как наш сервисный механизм в данный момент лишен такой возможности.
Производительность конструктора при обработке полного набора данных почти на порядок ниже, чем у обычной таблицы, что вполне нормально для конструктора - важно избежать лавинообразного падения производительности, и эта цель достигнута.
было достигнуто.
Исследование показало, что количество записей в базе данных практически не влияет на скорость построения страниц, навигации и небольших выборок в модели данных «квинтет».
При объеме обрабатываемых данных до 10 000 записей (а это максимальный выбор сопутствующих данных для экземпляра любого субъекта хозяйствования в информационной системе) можно комфортно работать с базой данных объемом в сотни гигабайт и более.
Далее мы обучили наш плагин таблиц (описанный Здесь ) вызвать коннектор к произвольной базе данных, чтобы он прозрачно работал как с моделью данных «квинтет», так и с традиционными таблицами.
С точки зрения пользователя ему не важно, с каким источником данных он работает, главное, чтобы он мог выполнять важную для него работу в привычном интерфейсе, получая свои отчеты: 
Теперь мы переместим остальные эти огромные таблицы, которых в нашей базе данных всего два десятка из сотен, в отдельное хранилище, чтобы можно было комфортно с ними работать.
Так, мы можем использовать конструктор для небольших и средних таблиц, требующих интенсивного поиска и агрегации по произвольным атрибутам, а большие неиндексируемые объекты хранить в плоских традиционных таблицах, вызывать их из сторонних хранилищ или специализированных баз данных (Hadoop и другие).
NoSQL).
Конструктор лучше всего подходит для CRM-систем и подобных продуктов, где пользователь работает с одним клиентом, счетом или другим субъектом, а аналитические функции вынесены в отдельное специализированное хранилище.
Теги: #программирование #Анализ и проектирование систем #Бизнес-модели #sql #Идеальный код #QDM #квинтетная модель данных #IdeaV
-
«Ebay: Что Вы Можете Продать?»
19 Oct, 24 -
Прогнозы Google На 2009 Год.
19 Oct, 24 -
Ит-Образование В Школах И Университетах
19 Oct, 24 -
Коворкинг. Преимущества И Недостатки.
19 Oct, 24 -
Минимальный Размер Контента В Сетке Css
19 Oct, 24
