Инструментальное хранилище информации Call Detail Record
"ЯХОНТ-СХД-CDR" - специализированное инструментальное хранилище данных, оптимизированное для накопления и быстрого поиска в информации CDR о соединениях абонентов телефонных сетей связи (PSTN, GSM/CDMA). Используемые "традиционные" подходы создания хранилищ данных сформировались за последние десять лет и основываются на применении оборудования хранения Hi-End класса с общецелевыми СУБД (Oracle, Microsoft SQL, некоторыми специализированными - Sybase IQ, Greenwich и т.д.). Это приводит к стоимости хранилищ CDR в несколько миллионов долларов, при этом затраты на создание самого хранилища составляют до 90% от всех затрат на оборудование в аналогичных проектах. Все "традиционные" решения основываются на общей архитектуре: выделенный мощный сервер, FC/SAN инфраструктура, дорогостоящие контроллеры, большое количество включенных в нее дисковых массивов. В итоге цена за 1 терабайт составляет десятки тысяч долларов. Обратной стороной простоты использования подобных решений является их крайне низкая производительность - до 8 мбайт/сек загрузки новой информации CDR в системах на базе MS SQL/Oracle, до 120 тыс. CDR/сек на основе некоторых специализированных СУБД (в то время как само оборудование обеспечивает в десятки раз большие скорости работы).
В обоих случаях увеличение скорости загрузки новых данных и наращивание емкости системы хранения наталкиваются на непреодолимый технический барьер для их модернизации.
На определенном этапе стоимость расширения в расчете на 1 Тб начинает многократно превышать стоимость прошлых этапов, в то время как скорость поиска информации в хранилище резко падает ниже минимально приемлемой.
Специализированные аппаратно-программные и колоночные СУБД, нашедшие повсеместное применение в аналитических задачах построения операционной отчетности операторами связи и банками (Teradata, Vertica), рассчитаны, прежде всего, на небольшой объем извлекаемых по запросу данных со сложной логикой их вычисления и выдачей сводных агрегированных данных.
Получение исходных записей наталкивается на существенные затраты вычислительных ресурсов при их сборке из колонок, на которые они разбиты при записи в систему (что может многократно превысить само время поиска). В поисковых задачах же, наоборот, необходимо получение по результату любого запроса всей информации о каждом соединении без каких-либо ограничений на количество записей в получаемом результате. Другая альтернатива - применение систем на основе HBase/Hadoop - влечет рост требуемого количества оборудования в геометрической прогрессии: кВТ электроэнергии и большое количество стойко-мест, обслуживание каждой системы требует постоянного присутствия инженеров, каждый комплекс уникален.
Как правило, конечному заказчику оставалось только смириться со сложившейся ситуацией, так как альтернативных и экономически эффективных способов организации мощных хранилищ CDR, удовлетворяющих реальные потребности, не существовало. В комплексе "ЯХОНТ-СХД-CDR" компания "НОРСИ-ТРАНС" представляет новый, эффективный подход к реализации высокопроизводительных систем специального хранения и поиска в информации CDR, обеспечивающий решение поисковых задач.
Это по-настоящему революционный продукт, в корне меняющий представление о системах хранения и поиска в информации CDR:
- От 4 до 10 раз стоимость системы хранения меньше стоимости решений с "традиционным" подходом и прочих аналогов на рынке СХД;
- Высокопроизводительный поиск в накапливаемой информации - на порядок быстрее аналогов;
- Существенная экономия на занимаемом дисковом пространстве по сравнению с аналогами.
Внедрив хранилище, заказчик получает:
- Загрузку от 700 тыс. CDR/сек до 4 млн. CDR/сек в зависимости от модели (см. Таблицу базовых моделей)
- Выполнение не менее 1 млн. запросов в сутки по всему объему накопленных данных;
- Масштабирование до 20 Пбайт с одинаковой стоимостью за 1 терабайт полезной емкости;
- Высококвалифицированную консультационную поддержку и помощь от разработчика при внедрении системы в собственную инфраструктуру;
- Быстрый эффект от внедрения – сроки поставки 90 дней;
- Самую низкую на рынке стоимость за 1 Тб емкости.
Краткое описание и возможности:
- Специализированный SQL-диалект, подключение к хранилищу через ODBC-интерфейс;
- Специально сконструированная под обработку информации CDR, собственная технология записи и загрузки, высокоскоростные алгоритмы индексирования поступающих данных в режиме реального времени;
- Работа хранилища с учетом неравномерного поступления информации в течение суток и поступления CDR прошлых периодов с существенным запозданием;
- Не требует администрирования и каких-либо дополнительных настроек, круглосуточный автономный режим работы, "включил и забыл";
- Интегрированная система мониторинга и диагностики состояния оборудования и программного обеспечения;
- Получение по результату запроса экстремально больших объемов данных без ухудшения скорости работы системы в целом (до нескольких млрд. записей в одном запросе);
- Отбор по запросам информации о соединениях по MSISDN (вызывающий, вызываемый, номер переадресации), IMSI, IMEI/MIN, до 10 000 критериев в одном запросе;
- Отбор по местоположению абонентов (геозоны) информации о соединениях по критериям: LAC/Cell-ID, поддержка до 1000 критериев в одном запросе;
- Обработка запросов по номерам коммутаторов, номерам SMS-центров, получение всех CDR за указанный период времени;
- Обработка пользовательских составных SQL-запросов со специализированной логикой, поддержка поиска по маскам с использованием "*", "?";
- Накопление информации CDR различных операторов связи в одной системе с возможностью поиска как по отдельным телекоммуникационным операторам, так и по всему объему данных без увеличения времени поиска;
- Специальный режим конвертирования (переноса) данных из существующих систем – загрузка до 30 Тбайт в сутки (в зависимости от модели) текстовых данных CDR для быстрого наполнения хранилища данными прошлых периодов при его запуске у заказчика;
- Работоспособность хранилища в случае отказа одного либо нескольких узлов с сохранением скоростных характеристик;
- Скорость поиска не зависит от заданного в запросе периода - одинаковая для запроса за последнюю неделю и за неделю год назад;
- Посуточное разбиение поступающих данных на каждом узле по времени соединений в CDR обеспечивает поиск только по запрошенному периоду без обращения ко всему объему информации;
- Автоматическое удаление накопленных CDR самых старших периодов, циклическая запись новой поступающей информации.
Массово-параллельная архитектура (МРР) хранилища:
МРР-архитектура представляет собой линейный список узлов, последовательно заполняемых данными. В ходе работы системы запись идет одновременно в N узлов - "окно записи", после их заполнения система переходит на следующие узлы.
Ключевые технические характеристики:
- Обслуживание до 100 одновременных запросов на одном хранилище с параллельной загрузкой обновлений данных;
- Обработка не менее 1 млн. запросов в сутки, возможность получения по запросу результата до нескольких млрд. записей;
- Получение результата запроса 1 000…100 000 записей/сек (в зависимости от разброса данных на дисках);
- Наращивание емкости за счет установки дополнительных типовых узлов хранения;
- Емкость хранилища = количество узлов накопления и поиска * емкость одного узла (Тбайт);
- Типовые модели включают от 2 до 36 узлов, возможно наращивание емкости хранилища до 20 Пбайт за счет увеличения количества узлов;
- Оборудование Hewlett-Packard Proliant DL/SL series (2U/4U);
- OS Linux RHEL .
Подключение хранилищ и доступ к данным:
- ODBC-интерфейс (библиотеки для Linux/Windows x64), специализированный SQL-диалект (в т.ч. SDK с демо-примерами работы с хранилищем);
- NoSQL интерфейс (в т. ч. SDK с примерами подготовки запросов и получения результатов по конкретным видам запросов), обеспечивающий получение результата в реальном времени за счет исключения расходов на SQL интерфейс;
- Прием на вход текстовых файлов содержащих CDR-записи (CSV/fixed-length);
- Загрузка и индексация поступающих на вход данных CDR на скорости 100-400 Мб/сек (0,8 Гбит...3Гбит) в зависимости от модели хранилища.
Базовые модели хранилищ:
Модель* | Технические характеристики | Полезная емкость** | Узлов | Загрузка данных*** | Поиск информации по MSISDN/IMSI/IMEI/Cell-ID за сутки |
---|---|---|---|---|---|
Минимальный вариант (5U) | 2 кВт / 100 кг | 36 Тб | 2 | до 1.4 млн. CDR/сек //до 4 млрд. CDR/сутки | |
Стационарный (24U) | 8 кВт / 400 кг | 180 Тб/480 Тб | 10/4 | до 3 млн./CDR сек // до 5 млрд. CDR/сутки | |
Стационарный (42U) | 14 кВт / 800 кг | 320 Тб/840 Тб | 18/7 | до 4 млн./CDR сек//до 6 млрд. CDR/сутки | Не более 1 сек.**** |
Стационарный (2x42U) | 28 кВт / 1 900 кг | 640 Тб/1,68 Пб | 36/14 | до 4 млн./CDR сек//до 7 млрд. CDR/сутки |
- * - без учета ИБП;
- ** - с учетом hot-spare, организации RAID, емкость узла зависит от применяемых моделей серверов HP Proliant (DL/SL);
- *** - пиковая нагрузка из расчета 120 байт на одну CDR;
- **** - в соответствии с суточным количеством информации в зависимости от модели (4…7 млрд. CDR/сутки).
Технология построения хранилищ нестандартной емкости (1-20Пб)
* - Технология "Яхонт-СХД-CDR" обеспечивает возможность размещения оборудования на территориально удаленных технологических площадках, объединяя серверные группы в одну единую систему хранения.
* - оценка максимального количества информации в сутки.
* в случае деления данных на N узлов при записи ("окно") скорость поиска линейно возрастает в N раз / определяется настройкой СХД при пуске, время работы запросов в таблице включает выгрузку результата во внешние CSV-текстовые файлы, т.е. полностью готовый результат.
Соответствие размеров абонентских баз операторов и объемов суточной информации CDR:
Количество абонентов | Примерное суточное количество CDR* | Базовая модель / максимальный срок хранения данных (месяцев) без перезаписи устаревшей информации | |||
---|---|---|---|---|---|
Минимальный | 24U | 42U | 2x42U | ||
500 000 | 150 млн. | 37 | 183 | 326 | 652 |
1 000 000 | 300 млн. | 18 | 92 | 163 | 326 |
2 000 000 | 600 млн. | 9 | 46 | 81 | 163 |
3 000 000 | 900 млн. | 6 | 31 | 54 | 109 |
5 000 000 | 1,5 млрд. | 4 | 18 | 33 | 65 |
10 000 000 | 3 млрд. | 4 | 9 | 16 | 33 |
20 000 000 | 6 млрд. | - | - | 8 | 16 |
Примерная производительность 1-3 узлов хранилища на некоторых типовых видах запросов*
Псевдо-SQL | Примерный размер результата, строк | Время работы (секунд) узлов ("окно")* | Период обработки | Количество обрабатываемых данных (CDR) | ||
---|---|---|---|---|---|---|
1 | 2 | 3 | 1 сутки | 1 млрд. | ||
SELECT* FROM calls WHEREcall_date > T1 AND call_date < T2 AND calling=`XXXX` OR called=`XXXX` | 0 | 0,2 | 0,2 | 0,2 | ||
<10 | 0,3 | 0,2 | 0,2 | |||
200 | 1 | 0,5 | 0,5 | |||
SELECT * FROM calls WHERE call_date > T1 AND call_date < T2 AND base_station=’XXXXX-YYYYY’ | <10000 | 10 | 5 | 2 | ||
SELECT * FROM calls WHERE call_date < T1 AND call date < T2 AND imsi='XXXX' | <100 | 0,5 | 0,2 | 0,2 | ||
SELECT * FROM calls WHERE calling=`XXXX` or called=`XXXX` | 1 | 1 | 1 | 1 | 31 сутки | 31 млрд. |
SELECT * FROM calls WHERE Imei=`XXXX` | 1000 | 10 | 5 | 2 | ||
SELECT * FROM calls WHERE calling=`XXXX` or called=`XXXX` | 10 000 | 15 | 7 | 3 | ||
SELECT count(*)FROM calls WHERE calling=`XXXX` or called=`XXXX` | 10 000 | 6 | 3 | 3 |
Применение:
- В качестве основного компонента при построении систем долгосрочного накопления и поиска в информации CDR;
- Как основное хранилище данных в системах легального контроля при хранении информации о соединениях абонентов операторов телефонной связи;
- В качестве бессрочного архива отобранной информации о телефонных соединениях абонентов в составе центров мониторинга.
Если Вас заинтересовало данное решение, заполните, пожалуйста, анкету и мы свяжемся с Вами. Спасибо!