Сайзинг Arenadata DB
В современных системах управления базами данных, таких как Arenadata DB, существует несколько типов конфигураций, каждая из которых имеет свои особенности в плане производительности, емкости и стоимости. Важно правильно оценить потребности бизнеса и правильно выбрать подходящую конфигурацию для успешной реализации и масштабирования вашей инфраструктуры.
Существует три основные конфигурации узлов, которые обеспечивают различные уровни хранения и производительности данных:
Вариант конфигурации 1
Представленный вариант конфигурации узла позволяет эффективно хранить до 3.2 Тб чистых сжатых данных:
- CPU: 2x20 ядер;
- RAM: 256 Гб с возможностью доустановки до 512 Гб;
-
Disk storage:
- Controller1: 2x600 Гб SSD для ОС;
- Controller2: 12x1500 Гб HDD;
- NET: 10G Ethernet.
Вариант конфигурации 2
Представленный вариант конфигурации узла позволяет эффективно хранить до 3.2 Тб чистых сжатых данных:
- CPU: 2x10 ядер;
- RAM: 256 Гб с возможностью доустановки до 512 Гб;
-
Disk storage:
-
Controller1:
- 2x600 Гб SSD для ОС;
- 2x600 Гб SSD для pg_catalog;
- Controller2: 8x1200 Гб HDD;
- Controller3: 8x1200 Гб HDD;
-
Controller1:
- NET: 10G Ethernet.
Вариант конфигурации 3
Представленный вариант конфигурации узла позволяет эффективно хранить до 7 Тб чистых сжатых данных:
- CPU: 2x32 ядер;
- RAM: 512 Гб с возможностью доустановки до 768/1024 Гб;
-
Disk storage:
-
Controller1:
- 2x600 Гб SSD для ОС;
- 2x800 Гб SSD для pg_catalog;
- Controller2: 8x2400 Гб HDD (опционально SSD);
- Controller3: 8x2400 Гб HDD (опционально SSD);
-
Controller1:
- PCI: SSD NVME 1.5 Тб для горячих данных;
- NET: 2x40G Ethernet.
Выбор подходящей конфигурации зависит от ряда факторов, включая требуемый объем данных, тип нагрузки (например, OLAP или OLTP), количество пользователей и частоту запросов. Оценка этих факторов поможет вам определить, какая конфигурация будет наиболее эффективной для ваших нужд.
При выборе конфигурации важно учитывать следующие ключевые критерии:
1. Ожидаемый объем несжатых данных в кластере Arenadata DB
При оценке объема данных для кластеров Arenadata DB важно учитывать несколько факторов: количество данных, генерируемых пользователями (включая индексы, STG/ODS-слои, DDS, витрины данных и временные расчетные таблицы). На основе конфигураций узлов можно спрогнозировать объем данных с учетом коэффициента сжатия.
Существует 3 типовые конфигурации оборудования для работы с кластером Arenadata DB.
Конфигурация 1 — ориентирована на эффективное хранение до 3.2 Тб сжатыми данными.
Конфигурация 2 — также поддерживает до 3.2 Тб сжатыми данными, но с дополнительными оптимизациями для хранения и работы с большими объемами данных.
Конфигурация 3 — позволяет хранить до 7 Тб сжатыми данными, что обеспечивает более высокую производительность и больший объем хранилища.
2. Прогноз увеличения объема данных на 3 года
Для прогноза роста данных на 3 года нужно учитывать:
- Темпы роста бизнеса: Это может зависеть от роста пользователей, новых проектов и расширения системы.
- Тип данных: Если речь идет о динамических данных, таких как журналы транзакций или расчетные таблицы, рост может быть значительным.
Предположим, что данные будут расти на 30% в год. Пример прогноза увеличения объема данных для конфигурации 1 (6.4 Тб несжатых данных в первый год):
- Год 1: 6.4 Тб
- Год 2: 6.4 Тб × 1.3 = 8.32 Тб
- Год 3: 8.32 Тб × 1.3 = 10.82 Тб
3. Сжатие в текущей системе
В текущей системе сжатие может использоваться для уменьшения объема хранения данных. Коэффициент сжатия может варьироваться, но в индустриальных системах сжатие 2:1 является довольно стандартным.
4. Миграция с заменяемой системы
При миграции на Arenadata DB важно учитывать параметры старой системы, включая оборудование и используемую СУБД. Например, если используется PostgreSQL на виртуальных машинах с SSD-дисками, можно ожидать определенную разницу в производительности при переходе на Arenadata DB.
5. Рабочая нагрузка системы
Система может иметь различные виды рабочих нагрузок:
- Ad-hoc запросы: Требуют быстрого ответа на вопросы пользователя.
- OLAP-отчетность: Связана с выполнением сложных аналитических запросов на больших объемах данных.
- OLTP-нагрузка: Множество транзакций с высокими требованиями к производительности.
- ML-алгоритмы: Может потребовать дополнительного вычислительного ресурса для обработки и анализа больших данных.
6. Развертывание Arenadata DB
- BAREMETAL ON-PREMISES: Использование физического оборудования в ЦОД заказчика.
- VIRTUAL ON-PREMISES: Виртуализированные ресурсы под управлением гипервизора.
- CLOUD: Использование облачной инфраструктуры.
- HYBRID: Смешанный подход, где основная нагрузка идет на физическое оборудование, а для резервных нужд используется облако.
7. Количество пользователей и конкурентная нагрузка
Ожидаемое количество пользователей может варьироваться в зависимости от масштаба развертываемой системы. Для оценки конкурентной нагрузки можно использовать прогнозы числа пользователей в день или пиковое количество запросов в момент времени.
8. Ежедневные загрузки данных и SLA
Необходимо рассчитать, сколько данных будет загружаться ежедневно, а также требования по SLA для загрузки данных. Например, загрузка данных может составлять 10 Тб ежедневно, и необходимо, чтобы она завершалась за 12 часов.
9. Регламентные запросы
Регламентные запросы, как правило, имеют определенные временные ограничения для обработки. Например, запросы на обновление финансовых данных должны быть выполнены в течение 4 часов.
10. Проблемы производительности
Если существуют проблемы с производительностью, необходимо их указать, например, медленная загрузка или долгие запросы.
11. Дополнительные кластеры для DR
Если планируется создание DR-кластера, необходимо оценить его характеристики. Например, он может быть менее производительным по сравнению с основным кластером с пониженными характеристиками CPU и RAM.
12. Политика резервного копирования
Политика резервного копирования для СУБД (систем управления базами данных) является критически важной частью стратегии обеспечения надежности и устойчивости бизнес-операций. Она направлена на защиту данных от потерь в случае сбоя системы, аппаратных неисправностей, человеческой ошибки или других факторов, которые могут повлиять на доступность и целостность данных.
Резервное копирование должно быть организовано с учетом специфики СУБД и типов данных, которые в ней хранятся.
13. Интеграции с целевой системой
В случае использования системы управления базами данных, такой как Arenadata DB, важно учитывать, какие именно интеграции необходимы для эффективного сбора, обработки и анализа данных (например, с ETL-инструментом (каким) / очередью сообщений (какой) / Spark-загрузки / загрузки CSV-файлов и т.д.).
14. Модели данных
Для детального слоя могут быть использованы различные модели, например, Инмон, Кимбалл, или Anchor. Выбор зависит от требований и характеристик бизнеса.
Тщательная оценка этих требований поможет вам выбрать оптимальную конфигурацию для вашего кластера Arenadata DB, обеспечив его стабильную работу и соответствие бизнес-целям.
